Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 01 Oct 2003 08:33:38 -0400

Fred Templin wrote:

> Brian,
> 
> Thanks for sending the detailed comments. Will give a first-pass
> at them below, but may require a couple of iterations.
> 
> Fred
> [email-masked]
> 
> Brian Haberman wrote:
> 
>>
>> [WG chair hat off]
>>
>> Below are my comments on the Hain/Templin draft.  Globally,
>> I think that these goals are worthwhile for the entire IPv6
>> protocol suite.  This type of functionality is needed in order
>> for people to feel comfortable migrating from v4 to v6.
>>
>>
>>>  Goals for an Addressing Scheme to Support Local Communications within
>>>                                  Sites
>>
>>
>>
>> The title still implies that these goals will be satisfied
>> by an addressing scheme rather than some other mechanism.  As
>> it has been noted in the past, some of these goals are not
>> specific or require a local addressing scheme.  In fact, some
>> of the "goals" are really operational rather than addressing
>> issues.
> 
> 
> 
> Actually, Ralph Droms had a similar comment (see his post
> on this thread) and suggested the following title:
> 
>  "Goals for Local Communications Within Sites"

That sounds better to me.  It focuses the discussion on the
aspects of local communication without hinting at a solution.

> 
>> If we can separate out the operational issues from the local
>> addressing goals, the title may fit better.
> 
> 
> 
> I like Ralph's title suggestion; any others?
> 
>>
>>> 1. Introduction
>>>
>>>    The IPv6 addressing architecture [RFC3513] specifies global and
>>>    local-use unicast addresses. Global addresses are understood to have
>>>    unlimited range and may be used as the source and destination
>>>    addresses in packets that originate from any point on the connected
>>>    global IPv6 Internet. Local-use addresses are intended for use only
>>>    within the range of a single link/site, but their specification does
>>>    not address operational considerations and does not account for the
>>>    esoteric nature of terms such as "site".
>>
>>
>>
>> I cannot determine what the last sentence is trying to say.
> 
> 
> 
> How about:
> 
>  "...but their specification does not address operational
>    considerations for real-world deployments."

So with the title change, I would suggest re-writing the Intro
to focus on the aspects of local communications.  Describe the
characteristics/features of local communication that need to be
preserved.  You could keep some text on local addresses as an
example.

> 
>> Further along in the document, it expressly talks about operation
>> considerations.  In fact, the whole document assumes that these
>> considerations should all be fixed by a local addressing scheme.
> 
> 
> 
> Not the intention, and will work to fix this. We want
> to support local communications within sites, but this
> need not be through a *local addressing* scheme.
> 
>> Perhaps what needs to be discussed here is why only having global
>> addresses would not suffice.  Describe the operational problems
>> that will be caused without local addressing.
> 
> 
> 
> Any specific text suggestions would be welcome.
> 
>>>
>>>    There is a perceived need for an addressing scheme that supports
>>>    local communications within sites. Of special interest are "active
>>>    sites", e.g., sites that are intermittently-connected or disconnected
>>>    from the global Internet, sites that frequently change provider
>>>    points of attachment, sites that temporarily or permanently merge
>>>    with other sites, multi-homed sites, etc. This memo will discuss
>>>    goals for an addressing scheme to support local communications within
>>>    sites in the context of real world deployment scenarios.
>>
>>
>>
>> I find the use of the word "perceived" in the first sentence of this
>> paragraph and in other places in this document.  If it is just a
>> perceived need, can't these goals be solved with other tools?  Or
>> put in other terms, will operators use different tools if they are
>> provided/defined/developed?
> 
> 
> 
> Well, there is an actual need for local communications within sites
> and any form of communications requires addressing. Would your
> concerns be satisfied if we struck the word "perceived" wherever
> it occurs?

Yes.

> 
>> Also, multi-homing is a different issue altogether.  I can't see
>> where it needs to be discussed other than as a subset of a possible
>> renumbering scenario.
>>
>> Like my comments on the introduction, I would firm up the issues
>> caused without local addressing.
> 
> 
> 
> Again, specific text suggestions would be welcome.

I would suggest just dropping the reference to multi-homing in this
case.

> 
>> I also suggest that multi-homing be taken out of this document. 
> 
> 
> 
> Agree; we already have RFC 3582 and don't want to re-create it here.
> 
>>
>>> 3.1 Easy to Acquire
>>>
>>>    Some portion of the address space should be made available that
>>>    requires no public registration, payment, customer/provider
>>>    relationship, or approval. These addresses should be architecturally
>>>    supported and end-user-controlled.
>>
>>
>>
>> A few issues with this section.
>>
>> First, why is no payment a goal as far as ease of acquisition is
>> concerned?
> 
> 
> 
> Not intending the non-payment aspect for the entire address space,
> as indicated by: "*Some portion* of the address space..". What we
> are intending to say is that some scenarios may require autonomous
> address configuration with no interactions with a registry, and
> those scenarios should be supported.

OK.  Then I would recommend stating it in that fashion.  That is,
some portion of the address space should be obtainable with no
payment and no registry interaction.  An example would be useful
as well.

> 
>> Second, how can conflict resolution occur without some form of
>> public registration?  No registry is fine if we are talking
>> about a strictly disconnected network, but for connected networks
>> a conflict resolution capability is a good thing to have.
> 
> 
> 
> Not what we're intending to say; clearly, some scenarios will
> require conflict resolution such as can only be enforced through
> public registration. We touch on this in section 3.5.

How about some discussion on whether conflict resolution capability
is more/less important than no registry/payment?

> 
>> Third, I would suggest some text be added to discuss the tradeoffs
>> of the global routability of these addresses.
> 
> 
> 
> Suggestions?
> 
>>>
>>> 3.2 Stable
>>>
>>>    Applications that enable local communications should use addresses
>>>    that support session stability (i.e., connection survivability)
>>>    during intermittent connectivity, site mergers, change to a new
>>>    provider, etc. In particular, session stability should not be
>>>    affected by renumbering events [BAKER].
>>
>>
>>
>> How often do you expect renumbering events to occur?
> 
> 
> 
> In fixed environments, perhaps quite rarely; in mobile environments,
> perhaps quite often. This seems like a question for [BAKER].

My point is more in terms of how this document wants to define stable.
In my view, stability has different meanings when discussing the
renumbering of a network versus having that network be subject to
intermittent connectivity to the Internet.  In the former, you expect
a drastic change to occur to the prefix(es) in use.  While in the
latter, it is quite possible that the same prefix will remain in use
as long as your point-of-attachments are to the same provider.

> 
>> How does renumbering differ from a planned outage?  When those
>> occur, applications either restart or are restarted once the
>> change is made.
> 
> 
> 
> We don't want applications to have to restart; we want them
> to continue through to completion.
> 
>> In addition, just because a subnetwork disconnects, it doesn't
>> terminate the use of prefixes within the subnetwork.  So, the
>> apps can keep using those addresses until the nodes are told
>> of new ones.
>>
>> The requirement seems to be for a stable address for a long period
>> of time (months, years, decades, etc).  If that is the requirement,
>> then state it as such. 
> 
> 
> 
> Long period of time, perhaps, but how long is difficult to
> quantify. Again, perhaps this is a question for the [BAKER]
> renumbering draft.

I think it is quite pertinent to this draft.  How long must an
address remain stable in order to satisfy this document's stability
goal?

> 
>>
>>>
>>> 3.3 Multiple Link Support
>>>
>>>    Addresses for local communications within sites should support
>>>    operation over multiple links, e.g., via L3 routing, L2 bridging or
>>>    some combination thereof. As such, subnetting consistent with the
>>>    recommendations in ([RFC3177], section 3) should be supported.
>>>
>>>    Link-local addresses in IPv6: "are designed to be used for addressing
>>>    on a single link for purposes such as automatic address
>>>    configuration, neighbor discovery, or when no routers are present"
>>>    ([RFC3513], section 2.5.6). By definition, link-local addresses have
>>>    a single link range of operation and will not meet this goal.
>>
>>
>>
>> I don't think this section even belongs here.  We have link-locals
>> defined already, so someone will not re-define them.  I suggest taking
>> it out altogether.
> 
> 
> 
> Remove all of section 3.3, or just the second paragraph?
> (The first paragraph is the only text in the document that
> speaks to the possibility of subnetting within the site.)

Taking out just the second paragraph should be fine.

> 
>>>
>>> 3.4 Well-known Prefix
>>
>>
>>
>> I think this section is an excellent example of trying to solve
>> an operational issue with an addressing scheme.  Several people
>> have suggested this before, but a "well-known" prefix can just as
>> easily be carved out of one's global prefix.
>>
>> In addition, how exactly does an app figure out "the hint"?  It
>> has no way of knowing which side of the site boundary it currently
>> resides.  The well-known prefix works for filtering at boundaries,
>> not for special handling by an app.
> 
> 
> 
> I have no opinion on this question; do you have anything
> to add on this subject, Tony?
> 
> 
>>> 3.5 Globally Unique
>>>
>>>    Addresses used by sites should be globally unique such that site
>>>    mergers will not result in collisions. Global uniqueness is based on
>>>    the statistical properties of address allocations, therefore
>>>    proposals should specify a suitable means for random prefix
>>>    generation. Addressing scheme proposals should also provide a
>>>    suitable means for conflict resolution, e.g., certification through a
>>>    central registry, distributed database, etc.
>>
>>
>>
>> Doesn't this directly conflict with the requirement in 3.1 for
>> no public registry?
> 
> 
> 
> As I mentioned in response to the section 3.1 comments, we want
> to support both those scenarions that require autonomous address
> configuration with no registration in which statistical uniqueness
> is sufficient, and those that require conflict resolution and true
> global uniqueness as provided through a registration authority.
> Can you suggest a way for us to clarify?

Perhaps the initial list of requirements should spell out the relative
importance between requirements.  Is it more important to have a
registry that assists with conflict resolution or having no central
registry?  Or are they equal and a solution should try and provide
both?

> 
>>>
>>>    Sufficient global uniqueness is needed to support, e.g.:
>>>
>>>    o  VPNs between enterprises
>>>
>>>    o  dynamically created VPNs in support of temporary virtual
>>>       organizations
>>>
>>>    o  service provider co-location of hosts that reside in the address
>>>       space of multiple customers
>>>
>>>    o  formation of virtual organizations (Grids) among enterprises
>>>
>>>    o  mergers and acquisitions of enterprises such that address spaces
>>>       do not collide
>>
>>
>>
>> I am confused by this list.  One could argue that all of the above
>> put together requires globally routed addresses.
> 
> 
> 
> The objective of this document is to present the goals for
> local communications within sites; not to argue for one
> solution alternative over another. If others use this document
> as a talking point for arguing the solution alternatives, then
> the document will have served its purpose.
> 
>> Perhaps the better way to approach this is to discuss the tradeoffs
>> of centrally-allocated addresses and locally-allocated addresses in
>> supporting tools such as VPNs.
> 
> 
> 
> OK, if f we can do so without departing from the goals focus
> and getting too close to the realm of solutions. Any suggetions
> would be welcome.
> 
>>> 3.6 Usable in the Absence of a Provider
>>>
>>>    Active sites need addresses that can be used when there is no active
>>>    link to a provider. In the case of intermittently-connected sites,
>>>    provider access may be unavailable for long periods but this should
>>>    not disrupt local communications within the site. In the case of
>>>    sites moving to new provider points of attachment, frequent
>>>    renumbering events may occur but, again, local communications should
>>>    not be disrupted.
>>>
>>
>> The current scheme for renumbering allows for overlapping of the
>> old and new prefixes for a period of time.  This would apply to
>> the intermittently-connected sites as well.  Apps can continue to
>> use the old prefixes for internal sessions until the pre-planned,
>> hard cutover.  Once that cutover occurs, the apps will disconnect
>> from the old prefix and re-establish through the new prefix.
> 
> 
> 
> OK.
> 
>>
>>>    PI addresses provide one solution alternative genre that also
>>>    appliies to cases where network managers want global access. The
>>>    issue is that PI addresses with no designed aggregation properties
>>>    may lead to global routing table explosion (if advertised outside the
>>>    site) given current routing technologies. For this reason, PI
>>>    addressing scheme proposals should either provide reasonable
>>>    aggregation properties or a detailed analysis of their interactions
>>>    with global routing technologies. PA and other non-PI proposals
>>>    should explain how the proposed addressing schemes will support local
>>>    communications in the presence of intermittent and/or disconnected
>>>    provider access.
>>
>>
>>
>> What is the purpose of having this short discussion of PI addresses
>> in this document? 
> 
> 
> 
> Well, your point could be made that this is getting away from goals
> and touching too closely on solution space. I could live with dropping
> this text, if that is what you are suggesting. Tony?

I don't see the benefit of having a short discussion of PI space in
this doc, so I would suggest removing it.

> 
>>
>>> 3.8 Compatible with Site Naming System
>>>
>>
>> Since the document assumes that addressing will be the solution,
>> why have this section on naming?
> 
> 
> 
> Didn't quite understand this comment; can you clarify?

Is this section specifying a requirement that any solution be
compatible with DNS?  Should an addressing-based solution
refrain from adding new DNS records?  Should it refrain from
using two-faced DNS?

> 
>>> 3.9 Compatible with VPN
>>>
>>
>> See my comments on section 3.5.  This is a prime example for
>> the use of global addresses.
> 
> 
> 
> If you think this is getting away from goals and coming too
> close to solutions, please explain; the section seems to be
> describing a goal to me.
> 
>>> 4.1 Border Filtering
>>>
>>>    Network managers limit specific applications to internal use, so they
>>>    configure them to only work with a filtered address range. This
>>>    simplifies the border filter to an address prefix, rather than
>>>    needing to employ deep packet inspection to track a potentially
>>>    dynamic range of ports.
>>>
>>
>> Again, if they are connected to the Internet, they can carve out a
>> portion of the global prefix IF you want to rely on this type of
>> filtering for "application protection".  I have the same concern
>> about this section as raised with section 3.4  In discussing the
>> issue of filtering, I would like to see the tradeoffs, e.g. real
>> cost, of using a portion of your global space vs. local addresses.
> 
> 
> 
> Again, I'll have to ask that Tony comment on this one.
> 
>>> 4.2 Maintaining Confidentiality of the Address Space
>>>
>>>    Private space may be used to avoid exposing to competitors what
>>>    internal networks they are deploying and which office is coordinating
>>>    that effort. Network managers also don't have to expose business
>>>    plans to a registrar for evaluation for networks that are not
>>>    attached to the global Internet. Some have stated that if they are
>>>    required to register for public space for every internal use network,
>>>    they are more likely to pick random numbers than tip off the
>>>    competition.
>>
>>
>>
>> Can you give an example of how this works?  Knowing what someone's
>> prefix is doesn't reveal what internal networks are being deployed.
> 
> 
> 
> This one also for Tony.
> 
>>>
>>> 4.3 Test Networks
>>>
>>>    Another significant use of private address space is test networks.
>>>    Frequently these are large, elaborate networks with a mix of public
>>>    and private address space. Use of random unallocated space runs the
>>>    risk of collision with legitimate addresses on remote networks.
>>
>>
>>
>> But you can mitigate that risk if you sub-divide your public space
>> and filter the chunk you want private.
>>
>>
>>> 4.5 Mobile Router with Personal Area Network
>>
>>
>>
>>> 4.6.2 Groups of Nodes that Travel Together
>>
>>
>>
>> I made this comment earlier, but it applies to these two sections
>> as well.  Just because a network is dis-connected, does not mean
>> it can't keep using the prefix it was assigned when it was connected.
> 
> 
> 
> Well, again we are talking about goals here - not solutions.
> The goal is to support local communications within groups
> of nodes that travel together with possible long periods of
> intermittent/disconnected access. The solution is out of scope
> for this document.

My concern is more with the distinction between a renumbering
event and re-connection to the same provider.  The latter can
allow you to continue using the prefix you were originally given.

> 
>> I suggest that this section spell out the issues of long-term use
>> of an ISP-assigned prefix after the dis-connection.  And that this
>> take into account whether the customer has negotiated the rights
>> to "keep" the prefix during the intermittently connected time.
> 
> 
> 
> But, would this take us back into solution space again?
> 
>>>    Research ships at sea intermittently connect via INMARSAT, or when in
>>>    port, the shipboard network is connected to shore via Ethernet. Of
>>>    utmost importance is that the systems on board the ship all function,
>>>    providing data collection and analysis without interruption. Static
>>>    addressing is used on most intra-ship network components and servers.
>>>    It's quite expensive to operate a research ship, so eliminating
>>>    points of failure is important. Scientists on board collaborate with
>>>    colleagues back home by sharing of data and email. Currently private
>>>    address space is employed for several reasons: 1) it provides the
>>>    ability to allocate significant address space to each ship without
>>>    needing to worry about how many computers will be on a given cruise.
>>>    2) it provides separate address space for each ship. 3) it simplifies
>>>    filtering to ensure shipboard traffic is not permitted to transmit
>>>    out or bring up expensive satellite links.
>>
>>
>>
>> Point 1 is a no-op, it can be accomplished with almost any addressing
>> mechanism.  Point 2 screams for the use of global addresses.  And 3
>> can, once again, be accomplished through many other means besides a
>> special address range.
> 
> 
> 
> Are you suggesting any changes for the document in this comment?

Well, the last portion talks about some important issues.  The
current use of IPv4 private addresses is done to accomplish those
three points.  Those are important to know.  So I think they need
to be closer to the beginning of the document as target goals.

> 
>>> 5. Perceived Advantages of Limited Range Addressing Solutions
>>>
>>>    Limited range addressing solutions allow filtering, and filtering
>>>    creates addressing boundaries no matter where the bits come from. The
>>>    point is that some addresses are only valid within the range defined
>>>    by the local network manager.
>>
>>
>>
>> I agree with this sentence.  Some addresses are only valid in an area
>> defined by the manager.  And that can be accomplished in several ways.
> 
> 
> 
> OK.
> 
>>>    In the simple case, hosts that are allowed external access have a
>>>    policy that allows them to configure both global and limited range
>>>    prefixes, while those that are not allowed global access have a
>>>    policy that only allows limited range. Address selection policy
>>>    tables might need modifications to enable the selection of limited
>>>    range address space over global addresses. Given such modifications,
>>>    address selection rules will prefer the smallest range so internal
>>>    communications are forced to stay internal by the hard filter at the
>>>    border.
>>>
>>>    If an application chooses to assert a policy that is different from
>>>    the network manager's filtering rules, it will fail. Having a well
>>>    defined limited range address space that is known to have filtering
>>>    applied allows applications to have a hint about potential range
>>>    restrictions. We can choose to leave the network managers to figure
>>>    out their own adhoc mechanisms, or we can put them in a structured
>>>    limited range address space so that applications will have a chance
>>>    to react appropriately.
>>
>>
>>
>> This paragraph raises the point that the proposals by Zill and
>> Bellovin or other similar approaches to advertise "special" prefixes
>> via an RA may be useful tools for us to provide.  And I am sure others
>> will see the same.  Perhaps there needs to be some wrap-up on the
>> operational issues between using such an approach and using a local
>> addressing scheme.
> 
> 
> 
> OK; we can investigate this further.
> 

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Oct 2003 16:22:44 +0200

below...

Andrew White wrote:
> 
> As the originator of section 4.8, I'll speak to this one...
> 
> Fred Templin wrote:
> >
> > > 4.8 I'm afraid I couldn't understand this scenario at all.  When the
> > > two sites connect, do they essentially merge into a single,
> > > multi-homed site?
> >
> > I believe the answer to this is yes, and I believe Brian Haberman
> > also expressed concerns about such scenarios since they touch on
> > site multi-homing. (My answer to Brian is that we are not trying
> > to re-create RFC 3582 in this document.) What you would suggest
> > in terms of this block of text?
> 
> I don't think it's possible to completely divorce local addressing from
> multi-homing, unless we want to go down the NAT path (any takers?  No, I
> thought not).

Agreed. It would be rather tragic to define a new form of address to meet
the requirements in this draft, and another very similar new form of address
to meet multihoming requirements. It should be a goal to avoid this, and it
needs to be a shared goal of the ipv6 and multi6 WGs.

So I don't think it's possible to eliminate mention of multihoming from
this draft, but it should be mentioned mainly for this reason.

    Brian C

> 
> One local addressing model that both Tony and I have been envisioning (and
> IMO the most compelling) is that of disjoint, overlapping addressing
> spaces.  The local network uses an internal addressing scheme for all
> internal operations.  When and if 'external' connectivity is applied (which
> may be another 'local' network) the external space is also made available to
> all nodes within the network that want external operation.  Local nodes are
> configured to prefer the internal addresses for internal use and the global
> addresses for destinations that don't have a matching internal address.
> 
> Note that the 'internal' addresses could be global unicast addresses or
> 'local' addresses.  Likewise the 'external' addresses, although these will
> probably be global.  The key issue is that the 'internal' addresses are
> provider independent.  The core address space of the network is independent
> of the presence or absence of an ISP.
> 
> For the 'zeroconf home' scenario, registration-free local addresses become
> very attractive for the internal address space.  They don't need to care
> about ISPs or any external stuff, and unique address spaces can be easily
> configured.  And a RFC3484 implementation will favour them over global
> addresses.
> 
> Connecting two of these networks together is interesting.  The assumption is
> that the connection is via a 'local' channel - one that is (virtually)
> 'inside' whatever mechanisms define the borders between the local address
> spaces and the global space.  However, what sort of 'merging' occurs is
> harder to determine.
> 
> Some scenarios:
> 
> (1) Minimal merging:  The two 'local' networks talk via a pair of gateways,
> and all traffic for the other network's address space/s is directed to that
> network's gateway.  DNS and like services are similarly redirected.
> 
> (2) Routing table merging: Full routing information is passed across the two
> networks.  Addresses are allocated independently by each network.
> 
> (3) Full merging: The two networks become one network, sharing prefixes
> originally owned by one or the other network across all nodes.
> 
> Option 1 is probably easiest.  Local addresses provide an advantage here
> again, in that if both networks are using local addresses RFC3484 will cause
> inter-network communications to favour the local addresses.
> 
> The most interesting case in network merging occurs when the local addresses
> are allocated by the routers, using the strategy described in
> 'draft-white-auto-subnet-00'
> (<ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-white-auto-subnet-00.txt>).
> >From an address allocation perspective, only 'external' prefixes are
> propagated - the internal addressing scheme is built into the routers.
> Under this model, there is no need to propagate the internal prefixes - the
> address spaces are already compatible.  All that is required is to connect
> the routes and propagate service information (such as DNS).  External
> prefixes still need to be propagated.
> 
> --
> Andrew White
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Fred Templin <[email-masked]>
Date: Fri, 03 Oct 2003 12:01:09 -0700

Brian,

For the most part, agree with all of your points of clarification;
thanks. One item for further discussion:

> address remain stable in order to satisfy this document's stability

I think this question is going to be very much dependent on
the use case scenarios. For example, in the future we may see
deeply-networked homes in which we will have long-lived
sessions, such as playing a 3hr video between the DVD player
and home theater system. Indeed, there may be "always-on"
sessions such as the home-security system monitoring
intrusion-detection sensors around the house.

On the other end of the spectrum, we will have highly-mobile
environments, e.g., a vehicle that visits different Internet access
points (and receives different prefix advertisements) every five
miles or so it travels down the road.

So, where do we draw the line?

Fred
[email-masked]