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

From: Brian Haberman <[email-masked]>
Date: Tue, 30 Sep 2003 10:56:20 -0400

[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.

If we can separate out the operational issues from the local
addressing goals, the title may fit better.

> 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.
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.

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.

> 
>    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?

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.  I also suggest that multi-homing
be taken out of this document.

> 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?

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.

Third, I would suggest some text be added to discuss the tradeoffs
of the global routability of these addresses.

> 
> 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?

How does renumbering differ from a planned outage?  When those
occur, applications either restart or are restarted once the
change is made.

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.

> 
> 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.

> 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.

> 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?

> 
>    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.

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.

> 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.

> 
>    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?

> 3.8 Compatible with Site Naming System
> 

Since the document assumes that addressing will be the solution,
why have this section on naming?

> 3.9 Compatible with VPN

See my comments on section 3.5.  This is a prime example for
the use of global addresses.

> 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.

> 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.

> 
> 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.

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.

>    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.

> 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.

> 
>    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.

Regards,
Brian

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Sep 2003 12:49:54 -0400

Here are my comments on draft-hain-templin-ipv6-limitedrange-02.txt...

Global organization - as I read the doc (others' reactions may differ), I
feel like I'm reading a document that is based on some assumptions about the
solution before describing the problem.  In particular, the first sentence
in the second paragraph of the Introduction:

    There is a perceived need for an addressing scheme that supports
    local communications within sites.

seems to me to conclude, without explicit support for the conclusion, that
something like site-local addresses is required.  Even the title, "Goals for
an Addressing Scheme to Support Local Communications within Sites" suggests
the outcome.  I suggest renaming the doc to "Goals for Local Communication
within Sites".

It turns out that you do have support for the "perceived need" in section 4.
So my suggestion would be to swap sections 3 and 4, and add a sentence in
the introduction:

    There is a perceived need for an addressing scheme that supports
    local communications within sites.  The next section gives
    several scenarios in which local communications within a site
    are required.

Then, the goals can be justified by reference to the scenarios.

Comments about scenarios:

4.2 Why would an organization ever have to expose the internal networks
being deployed and what office is coordinating the effort?

4.3 Is this test network connected to the Internet?

4.4 I think this scenario would be clearer if it were labelled "Static
Configuration with Addresses" or some such.  The problem is really static
configuration of an address rather than caching an address learned through
some other process.

4.6 What about a completely disconnected ad-hoc network (not necessarily
mobile)?  I'm thinking of 5 guys in a bar using an ad hoc network with no
Internet connection...

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?
Is the "local traffic" between hosts within the merged A/B site?

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Sep 2003 12:41:18 -0700

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]

> of the "goals" are really operational rather than addressing

Actually, Ralph Droms had a similar comment (see his post
on this thread) and suggested the following title:

  "Goals for Local Communications Within Sites"

> addressing goals, the title may fit better.

I like Ralph's title suggestion; any others?

> 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."

> 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.

> that will be caused without local addressing.

Any specific text suggestions would be welcome.

> 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?

> caused without local addressing.

Again, specific text suggestions would be welcome.

> 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.

> First, why is no payment a goal as far as ease of acquisition is

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.

> 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.

> of the global routability of these addresses.

Suggestions?

> 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].

> occur, applications either restart or are restarted once the

We don't want applications to have to restart; we want them
to continue through to completion.

> of time (months, years, decades, etc).  If that is the requirement,

Long period of time, perhaps, but how long is difficult to
quantify. Again, perhaps this is a question for the [BAKER]
renumbering draft.

> defined already, so someone will not re-define them.  I suggest taking

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.)

> not for special handling by an app.

I have no opinion on this question; do you have anything
to add on this subject, Tony?

> Doesn't this directly conflict with the requirement in 3.1 for

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?

> 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.

> 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.

> from the old prefix and re-establish through the new prefix.

OK.

> What is the purpose of having this short discussion of PI addresses

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?

> why have this section on naming?

Didn't quite understand this comment; can you clarify?

> 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.

> cost, of using a portion of your global space vs. local addresses.

Again, I'll have to ask that Tony comment on this one.

> prefix is doesn't reveal what internal networks are being deployed.

This one also for Tony.

> 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.

> to "keep" the prefix during the intermittently connected time.

But, would this take us back into solution space again?

> can, once again, be accomplished through many other means besides a

Are you suggesting any changes for the document in this comment?

> defined by the manager.  And that can be accomplished in several ways.

OK.

> operational issues between using such an approach and using a local

OK; we can investigate this further.

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Sep 2003 13:01:41 -0700

Hello Ralph,

Thanks for the comments; please see my responses below:

Fred
[email-masked]

> the outcome.  I suggest renaming the doc to "Goals for Local 

As I also responded to Brian Haberman, a title change seems
appropriate and your suggestion looks good.

Any other suggestions for a new title?

> Then, the goals can be justified by reference to the scenarios.

The section-swap sounds like a very reasonable suggestion
for the next draft version.

> 4.3 Is this test network connected to the Internet?

I believe these are best for Tony to answer.

> configuration of an address rather than caching an address learned 

Agree with the comment as a reasonable suggestion for the
next draft version.

> mobile)?  I'm thinking of 5 guys in a bar using an ad hoc network with no

This scenario seems to be covered already in section 4.6.1,
but please let us know if you think text changes are needed.

> 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?

> Is the "local traffic" between hosts within the merged A/B site?

Essentially, yes. Again, the disposition of this block of text
probably warrants further discussion.

---

From: Andrew White <[email-masked]>
Date: Wed, 01 Oct 2003 11:00:38 +1000

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 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).

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