Subject: Draft on Globally Unique IPv6 Local Unicast Addresses

From: Bob Hinden <[email-masked]>
Date: Wed, 07 May 2003 11:32:31 -0700

I just submitted a draft titled "Globally Unique IPv6 Local Unicast 
Addresses".  I believe this is a good alternative to Site-Local 
addresses.  Please review the draft when it is out and send comments to the 
list.

My intent in writing the draft was to put together a (hopefully) complete 
solution that folks can look out to see if the benefits exceed the 
cost/complexity.

I suggest that the initial comments be limited to whether you think this 
approach (i.e., globally unique but not globally routing prefixes) is 
reasonable for the IPv6 working group to pursue.  There are many details 
such as field sizes, allocation procedures, etc. can be debated 
endlessly.  I think it is important to see if there is a possibility of 
reaching a consensus to peruse an approach like this.  Then we can debate 
the details.

Thanks,

Bob

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Thu, 08 May 2003 17:09:18 -0700

I've read the draft, here are some comments.

1- This is clearly better than "current" Site Local addresses.
The "ambiguity" factor is removed. Now the question is:
Is this better enough? I have concerns when those
addresses will be used in conjonction of globally routable
addresses on the same node.

3- The whole idea of a switch on a box to say that this node is "allowed"
to talk to the outside is not realistic in open environments where users
bring their own machine (ex: 802.11 hot spots, university campus 
networks,...)
and would lead to difficult to diagnose situations.

4- For this to work, the current rules on default address selection
would probably have to change to say: prefer greater scope when available.

5- But even then, it is unclear how multi-party applications would work.
Say, A & B are within the same site, C is external.
A is "allowed" to communicate externaly, B is not. If the application
running on A wants to communicate with both 'easily', it would
make sense to use the globaly routable address for both connections.

6- As seen in the example before, this does not remove the burden for
applications to deal with 'scoped addresses'.

7- Take the example of 2 sites, A & B using 2 "local" prefixes
and 2 global prefixes at the same time. Now, A and B
decide to establish an 'extranet' connection and would like
to 'scope' their inter-communications by using those special addresses.
How is address selection suppose to handle this?
Is it expected that A & B will somehow have to make their local
view of the DNS visible to the other?

So, as a conclusion, this is only appealing if you think that the concept
of scoped addresses is good and the only issue with Site Local addresses
was thier ambiguity. If you believe that introducing scope in 
applications via
special classes of addresses is not a good think to do, and it would
be better done it via routing alone, this proposal does no good.

- Alain.

ps: minor nits at this point, this proposal is mixing architecture
properties with policy decisions. The way bits are managed
bellow the initial /7 or /8 allocation up to the /64 boundary
are not relevant to this discussion. You may want to suggest
/48 allocation as in RFC3177, but there is nothing technical
about it. The way bits are allocated in that space (random,
delegation, aggregation on criterias other than network toplology,...)
is a completly orthogonal discussion.

ps2: Using the HD ratio to analyse the address space
properties would help. I ran some numbers if you're interested.

---

From: Andrew White <[email-masked]>
Date: Fri, 09 May 2003 13:13:58 +1000

> make sense to use the globaly routable address for both connections.

If A is proxying the connections both ways, it can happily use the local
address for B and the global address for C.

If A is forwarding an address reference, B + C are never going to be able to
communicate no matter which 'B' address is passed to C (since B can't
communicate externally).

If B can communicate externally, but only on some addresses, it seems the
solutions are either:

* A passes the NAME of C (or B), and lets the two nodes figure out which
address to use.

* A knows about potential filtering rules, and thus chooses the appropriate
address.

That said, consider for a moment if B has only global addresses...

(1) If B has only one address, then it doesn't matter what A (or B or C)
does, the connection between B and C will succeed or fail depending on
filters (and network state).

(2) If B has multiple addresses with identical filtering, see (1).

(3) If B has multiple addresses with non-identical filtering, then A either
passes C a name and trusts that the external-OK one is in the DNS.  Or it
guesses which address to pass.  Or it passes all of them.  Very similar to
the local + global case, except in that case the application can tell that
it shouldn't expect the local address to work.

I've seen this point (#5) come up a few times, and I believe it to be a red
herring.  There seem to be two obvious solutions:

(1) Ban multihomed hosts (except for routers).

(2) Write applications so that they don't assume single-homed hosts and an
unfiltered address space.  Or, "applications that forward addresses across
filtering boundaries need to apply the address selection rules to their
forwarding."

> would probably have to change to say: prefer greater scope when

I disagree.  Is there a good reason an internal-internal app wouldn't prefer
a local rather than global address?

> applications to deal with 'scoped addresses'.

Only those apps wishing to do cross-scope forwarding of addresses.  All
others may remain blissfully ignorant and let address selection 'do the
right thing'.

> view of the DNS visible to the other?

Yes.

If site A and site B create a tunnel, they have effectively merged.  Some
additional effort will be required to ensure that DNS requests in A for B
can travel across the tunnel to B, and vice versa.

If no tunnel exists, the sites cannot merge, and therefore cannot
communicate 'locally'.

-- 
Andrew White

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 May 2003 09:03:06 +0300 (EEST)

> applications to deal with 'scoped addresses'.

It seems to me that this could also be considered a feature.  If B is not
allowed to communicate externally, participating in a multi-party app
should fail with C that is outside of the site.  However, referrals work
(to some degree) because they are not ambiguous.  On the other hand, if A
uses a global IPv6 address and B a local IPv6 address, those should also
be able to communicate with each other.

I haven't read the draft yet so there may be holes here: but the point is,
if the border is being made with access-list type filtering at the edge of
the site, it doesn't matter: internal "local-only" users and internal
"global-only" or "local+global" users should very well be able to
communicate with each other inside the site, with "prefer greatest scope"
rule.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Thu, 08 May 2003 23:15:24 -0700

Alain,

Thanks for the feedback.

My intent in the draft (and apparently it should have been clearer) was to 
not say these were scoped addresses (or more accurately that have smaller 
scope than global unicast).  I say they are intended for local 
communication, but can be used for non-local communication if the 
appropriate routes are set up.  So I would say that applications may have 
to select between these addresses based and global unicast for reasons of 
reachability, but I don't think this is different from having to select 
from multiple global unicast addresses.

Bob

At 05:09 PM 5/8/2003, Alain Durand wrote:
>bring their own machine (ex: 802.11 hot spots, university campus networks,...)
>was thier ambiguity. If you believe that introducing scope in applications via

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 May 2003 10:23:59 +0200

Alain Durand wrote:
....
> be better done it via routing alone, this proposal does no good.

I don't think the second sentence is true. Even if applications have
no understanding of scope, the kind of problems with RFC 1918 addresses
that have to be handled today by complex /32 static route configurations
(and would need /128 routes in IPv6 under FEC0::) will be handled much
more simply with /48 routes. In other words, this proposal solves the
ambiguity problem regardless of scope.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Fri, 09 May 2003 09:19:00 -0700

Bob Hinden wrote:

> Alain,
>
> Thanks for the feedback.
>
> My intent in the draft (and apparently it should have been clearer) 
> was to not say these were scoped addresses (or more accurately that 
> have smaller scope than global unicast).  I say they are intended for 
> local communication, but can be used for non-local communication if 
> the appropriate routes are set up. 

It all depend on the definition of "scope" you're using.
Those addresses are globally unique but one cannot assumed they can
be reached from anywhere in the Internet.
So, I claim that their "perceptive" value for an application is less 
than the one
of global unicast addresses.

> So I would say that applications may have to select between these 
> addresses based and global unicast for reasons of reachability, but I 
> don't think this is different from having to select from multiple 
> global unicast addresses. 

I disagree. See above. In multi-party environment, I a node needs to pass
an IP address as identifier/locator to a peer, the odds of this to work are
better if you use global unicast addresses. The issues are the same as 
with SL:
If A, B & C do not share the same 'view' of the routable addres space,
and there is an intersection at B, things will go wrong.

    - Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 17 May 2003 09:07:48 -0700

I have been occupied for the last two weeks, and wanted to wait until I
had time to seriously comment.

> solution that folks can look out to see if the benefits exceed the 

I don't believe this is complete since it only deals with the ambiguity
part of the problem. I sent in the updated version -01 of my local scope
requirements draft last weekend, and I understand it has made it through
the I-D editor queue. 

> reasonable for the IPv6 working group to pursue.  

As others have commented, a registry fails to meet the need for a
completely free easy to automate mechanism. Christian raised the concern
about the number of bits needed, but as kre noted the real domain is
limited to the sets where interconnections actually occur. Having both
an automated and a manual mechanism like your proposal allows automation
for the vast majority of unmanaged cases, but if a collision occurs,
there is an alternative to work around it. I would expect some network
managers to find your registry appealing in that it hints at an
assurance of collision free space. As kre noted, you can't ever assure
that because anyone can stomp on an allocation.

One specific comment about this doc, we should have learned from the
2373 experience that putting operational policy in an IETF doc will
eventually lead to trouble. In particular, identifying a specific
monetary value does not belong here. 

I am not sure that it is reasonable for the IPv6 WG to work on this. In
any case, a PI mechanism needs to be dealt with in parallel, and this
should not be forwarded until the PI approach can move with it. At the
same time, we probably should identify the issues related to name to
address mapping, and comment on the operational issues related to
applications that pass limited scope addresses outside their realm of
reachability. It may also be useful to have a BCP requiring scope
matching for the time being. (maybe that paragraph is the basis for a
bof to develop a charter)

Comments on the mail thread.
Bob Hinden wrote:
> Margaret,
> 
> >Bob's proposal explicitly defines a type of addresses that are not 
> >expected to be routed throughout the Internet.  So, these 
> addresses are 
> >local, not globally routable.
> >
> >However, Bob's proposal defines addresses that are unique throughout 
> >the Internet.  No single address identifies one node when 
> used within 
> >one "scope" and another node when used in another "scope".  
> So, these 
> >are not "scoped addresses", as defined in the IPv6 Scoped Addressing 
> >Architecture.
> >
> >I *think* that Bob and I are using the same definition for the term 
> >"scoped", but I hope he'll correct me if I'm wrong.
> 
> I tried hard to not define the term "scoped address".  I only 
> used the word 
> "scope" once in the draft and that referred to global scope 
> addresses.  I 
> may remove that use in the next version :-)
> 
> The globally unique IPv6 local unicast addresses are not 
> limited in their 
> use to any scope less than global by their design because they have 
> prefixes that are globally unique.  By comparison site-local 
> addresses were 
> limited to a limited scope by their design because they had 
> non-globally 
> unique prefixes.
> 
> So yes, I think we agree.

This is duplicitous and deceptive. The second sentence of the draft says
these are not to be globally routed, therefore they are explicitly of
different scope than a global scope address which are intended to be
globally routed. Claiming they 'are not limited in their use to any
scope less than global' at the same time the doc says they are limited
in that way is confusing and wrong.

Eliot Lear wrote:
> I disagree.  I think the only way to deal with the problem I 
> describe is 
> to deal with renumbering properly. 

If renumbering actually made any sense, we would reclaim the entire IPv4
space and start over. After all if it is good for the edge it must be
even better and simpler for the core. Forced renumbering is a fantasy,
so the WG needs to get over it. Any attempt to force network managers to
change addresses will simply ensure they install a nat to isolate
themselves from that insanity. 

Bound, Jim wrote:
> ...
> To me this is a no brainer and problem solved.  Why not spend 
> our time making the spec better and ready for IESG for PS 
> whenever we can instead of debating its merits.  This IMO is 
> the mature, time-to-market, and compromised solution for us 
> all to get what we want and do some real work as a team and 
> move forward.

Because the problem is not solved. Polishing this and promoting it as
the solution only prolongs the reconing day. Until app developers
(including name resolution services) stop assuming the network is a flat
routing space, the system will be broken.

Andrew White wrote:

> Considering that using a local addressing scheme is optional 
> and that the justifications for using such a scheme usually 
> centre around having an addressing and routing architecture 
> that works regardless of ISPs and global prefixes, let's 
> assume that the existence of such addresses implies that the 
> network wants applications to favour these prefixes.

I agree.

> 
> Let's further assume hosts implement default address 
> selection (RFC3484). 
> To favour local addresses, we give them a 'scope' (for the purposes of
> RFC3484) that is smaller than global unicast.
> 

There will be addresses with a scope smaller than global unicast, I
think your point is to provide a mechanism to identify which ones they
are.

> Name -> address lookups will then return addresses in the 
> following order:
> 
> Src has local address:
>   - Local addresses (longest prefix match first)
>   - Global addresses (if src also has global, longest prefix 
> match first) Src has only global address
>   - Global addresses (longest prefix match first)
>   - Local addresses

Yes order might help apps that don't bother to look, but I don't think
order matters as much as making sure that the address resolution
mechanism doesn't return local addresses for queries that originate
outside the reachable domain. There are many ways to accomplish this, so
I think our job is to define the requirement and let the specific
mechanism figure out the appropriate approach. 

> One advantage of local addresses is this:
> - things that don't care about filters and scopes and ... 
> don't have to.
> - things that need to care about filters and scopes have more 
> information than they otherwise would.
> 

Yes !!!

Tony

---

From: Eliot Lear <[email-masked]>
Date: Sun, 18 May 2003 04:31:27 -0700

Tony,

> I am not sure that it is reasonable for the IPv6 WG to work on this.

Given that it would make little sense to have both this and a site-local 
mechanism, I don't see how you could avoid doing the work in the same area.

> In any case, a PI mechanism needs to be dealt with in parallel, and this
> should not be forwarded until the PI approach can move with it. 

I agree with this point, and as I believe others have said, I believe we 
need to recognize that the same issues would hit us with the doc prefix 
that was proposed.

> At the

This gets simplified since we've deprecated site-local.

> space and start over. 

Were this the only issue in order to reclaim IP addresses, perhaps it 
would have happened!  As you well know there are all sorts of 
ambiguities of ownership of IPv4 addresses.

> After all if it is good for the edge it must be
> even better and simpler for the core. 

Funny you should mention this- much of the edge renumbers all the time. 
  That's what DHCP and PPP have given us.  Our problem space in only 
this regard has narrowed significantly since IPng began.  In other ways, 
it's grown.

> Forced renumbering is a fantasy,

Except for most of the edge.

> so the WG needs to get over it. 

No.  The IP version 6 development team made a grave error by not 
properly dealing with administrative concerns in the beginning, so 
please let's deal with it now.

> Any attempt to force network managers to

Were this the root cause of the problem I would agree.  But it is not, 
and so I don't.  Make renumbering easier, so network managers needn't 
object to it.  It's clearly possible, since it has been done on the edge 
once before.  If you can manage such a transition in the end points you 
can manage it in the core.  The hard remains the interaction with DNS, 
as far as I tell.

I am by far not the first to identify the problem.  The solution space 
cannot be rocket science, but my suspicion is that it does require 
enrollment of some sort in order to really scale.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 18 May 2003 09:47:02 -0400

Hi Eliot,

>mechanism, I don't see how you could avoid doing the work in the same area.

It would be possible to move the whole concept of "local"
addressing (with the exception of link-local, which we
already have well-defined) out of the IPv6 WG and into a
separate WG.

This would have some advantages, most important of which,
IMO, is that it would allow the original IPv6 WG to focus
on finishing up the remaining pieces of IPv6 and bug
fixing some of the older pieces, while the new WG could
focus on the issue of local addressing.

>need to recognize that the same issues would hit us with the doc prefix 

I certainly think that work on a PI routing model should
happen outside of the IPv6 WG.  I'm not even totally
sure that this should be in the Internet area, rather than
Routing.

>No.  The IP version 6 development team made a grave error by not properly 
>dealing with administrative concerns in the beginning, so please let's 
>deal with it now.

Why do you think that the problem of renumbering specifically
falls under the auspices of the IPv6 WG?

The IPv6 WG has already done some work on router renumbering,
but, depending on how far you want to go, renumbering is
actually a systemic issue.  Do you want to renumber DNS,
security associations, existing connections?  If so, these
are problems for the DNS groups, the security area and the
the transport area, not just the IPv6 WG.

Margaret

---

From: "EricLKlein" <[email-masked]>
Date: Sun, 18 May 2003 18:16:54 +0300

----- Original Message -----
From: Margaret Wasserman
> focus on the issue of local addressing.

I am not sure how we can "finish the remaining pieces of IPv6" without
resolving the whole Link-Local issue. As far as I can tell no consensus has
been reached, and we are all anticipating (or dreading) the hijacking of
addresses to be used as locals as no alternative has been supported by the
WG to replace what has been stated in the RFC's for the past 2 years (ie:
FE8, FE9, FEA, and FEB).

Currently there are over 40 places on the internet where this information
occures as registered by Yahoo
(
http://search.yahoo.com/search?p=%2Bipv6+%2B%22local+address%22+%2BFE8+&ei=U
TF-8&vm=i&n=20&fl=0&x=wrt )

So eithter we as the IPNG WG find an answer and spread it soon, or these
addresses will be as good as hijacked based on published recommendations on
many hardware and software sites.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 May 2003 21:19:12 +0300 (EEST)

> sure that this should be in the Internet area, rather than

Or even Ops & Mgmt.  (Many aspects of PI, at least with current tradeoffs 
require policies and operations action -- rather than protocols.)

/me runs

---

From: Robert Elz <[email-masked]>
Date: Sun, 18 May 2003 21:30:32 +0700

Date:        Sun, 18 May 2003 09:47:02 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | This would have some advantages, most important of which,
  | IMO, is that it would allow the original IPv6 WG to focus
  | on finishing up the remaining pieces of IPv6 and bug
  | fixing some of the older pieces, while the new WG could
  | focus on the issue of local addressing.

It isn't possible to "finish" IPv6 without local addressing - one of
the aims of IPv6 was to be able to do everything that IPv4 can do
(better ways where possible), so there won't be any justifications for
anyone to stay with IPv4, because v6 can't do X.

IPv4 has local (private) addresses that are immune from outside control.
IPv6 needs the same, or something demonstrably better.

Just deciding that *you* don't need the things (for any value of "you")
or think that they're evil, isn't good enough.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 19 May 2003 07:46:41 -0400

Hi Robert,

At 09:30 PM 5/18/2003 +0700, Robert Elz wrote:
>It isn't possible to "finish" IPv6 without local addressing -

IMO, if IPv6 is successful, it will never be "finished".  Is
IPv4 finished?  However, we can finish up some pieces (i.e
the MIBs).

IMO, we should be trying to move to a model where there is
no single IPv6 WG, and work on different parts of IPv6 is
occurring in parallel in several WGs of smaller scope.  This
would allow more community visibility in what work is taking
place in IPv6, and would allow us to get specialists/experts
involved who only care about specific IPv6 work areas.

>one of

Who said that the aim of IPv6 was to be able to do everything
that IPv4 can do?  While I think that, in general, IPv6 _can_
do everything that IPv4 can do, it certainly wouldn't make
sense to duplicate any features of IPv4 that:

         - Were included as compromises to conserve
                 address space, or
         - We later determined were a Bad Idea.

Some argue that local addressing (a la RFC 1918) falls into
both of these categories.

>IPv6 needs the same, or something demonstrably better.

I personally think that we will need some type of provider-
independent local addressing, iff we can't figure out a way
to globally route provider-independent addresses...  But,
that's just my opinion.

You seem to start with the premise that we won't be able
to find a scalable, provider-independent routing mechanism.

It hasn't been demonstrated (yet) that there is rough
consensus in the WG about this, and we probably won't be
able to demonstrate that until the WG comes to some agreement
on the requirements for local addressing (which we could
already have, although they aren't written down -- do they
need to be?) and until we have a proposal that gains rough
consensus in the WG.

This is a very complicated topic, and there are a lot of
trade-offs that need to be considered between pursuing
non-globally-routable local addressing mechanisms, pursuing
provider-independent routing mechanisms, pursuing automated
renumbering systems to obviate (one of the) need(s) for
local addressing, etc.

The fact that I think that this chunk of work is something
that could reasonably be broken off into a separate, focused
WG doesn't mean that I think it should die.  In fact, I
think it is less likely to die if it gets its own resources
(dedicated meeting time, dedicated chairs, etc.).  However,
this isn't my decision -- the decision about how to organize
the work in the area belongs to the ADs.

Margaret

---

From: Sergey Gerasimov <[email-masked]>
Date: Mon, 19 May 2003 09:28:27 -0700

Hello,

We are trying to resolve the following scenario for multi-homed (2 
frontplanes) device:

1. device does not have very good UI until netwrok connected
2. device has .11 and .3 frontplanes hot at the same time
3. initial power up is likely stateless, likely link local on some or 
all frontplanes
4. initial .11 configuration is likely ad-hoc (peer to peeer)

Now, if device comes up in .11 ad-hoc link local and .3 link local, then 
there is no connectivity between the .3 and .11 but they are on the same 
subnet (have same prefix in v6 world).  Rotuing table is not likely to 
be accessible (or would be very hard to navigate) without sophisticated 
UI (web) which requires network connectivity.  The potential problem 
here is that packets will be routed to the wrong frontplane depending on 
the order in which the routes are inserted in the cache.

I understand that some possible ways are to battle this:

1. create a precendence oreder for the frontplanes (e.g. .3 always 
first, .11 always last)
2. disallow same subnets (what about v6?) for different frontplanes
3. manipulate routing cache (manually or via some set of rules)
4. ... others ...?

I am sure somebody has already come across this one and has some ideas. 
 Any information will be helpful.  It is really not a v6 question only, 
but appears to apply to both v6 and v4.

Thanks,
Sergey

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 May 2003 18:58:15 +0200

In your previous mail you wrote:

   there is no connectivity between the .3 and .11 but they are on the same 
   subnet (have same prefix in v6 world).

=> this seems to be a bug: two different links should not share
an on-line prefix.

=> IMHO this is the obvious solution.

=> I agree, IPv4 won't work too in your case.

Regards

[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 19 May 2003 10:12:18 -0700

Is this perhaps a case for the multi-link subnet proposal?

Fred
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 May 2003 21:30:30 +0700

Date:        Mon, 19 May 2003 07:46:41 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Who said that the aim of IPv6 was to be able to do everything
  | that IPv4 can do?

It was something from the early days of the WG.   The actual wording
I am half remembering might have been from Steve Deering, but that's
no more than a guess.

But it should be obvious - if there's anything (even half way supportable)
that IPv4 can do, that IPv6 doesn't have an answer to, then there will be
a class of users who will simply say "IPv6 is impossible, it cannot handle
my needs".

  | While I think that, in general, IPv6 _can_
  | do everything that IPv4 can do, it certainly wouldn't make
  | sense to duplicate any features of IPv4 that:
  | 
  |          - Were included as compromises to conserve
  |                  address space, or

Compromises, no - but address space conservation is still important.

There are lots of IPv6 addresses (there were once lots of IPv4 addresses
too...) but they're not an infinite resource, and they'll eventually
run out.   There are enough that if we do a decent job of management,
they'll outlast other parts of the protocol for sure - but there aren't
enough that we can afford to be stupid in the way they're allocated.

Eg: (stupid suggestion no-one is making that I know of) one might
argue that /24 addresses (16M of them) are as many as can possibly be
flat routed, so that's the allocation size that the RIR's should be
giving out - and then everyone should go get their own private /24
(or make that /32 with a 2001 meaningless prefix grafted on the front
if you like)    If we were to do something that dumb though, we'd be
out of IPv6 addresses in no time - we still need address conservation
measures developed for IPv4 (including CIDR and more)

  |          - We later determined were a Bad Idea.

Anything truly a bad idea from IPv4 has fallen out of use, and is
no longer relevant (and that isn't an empty set).   What you're
probably referring to though are things that some people argue are
bad ideas, but which are in very widespread use.   That stuff isn't
really "bad idea", its "I don't like that" - and is really prejudice.

  | Some argue that local addressing (a la RFC 1918) falls into
  | both of these categories.

They do - but they can't deny how much it is used.   We certainly don't
have to duplicate everything in IPv4 the way it was done exactly, what
we need is something that fills the needs that anything which is in
actual use in IPv4 fulfill.  That is, we need methods to offer the
functions that 1918 addresses offer, it doesn't have to be done the same
way as 1918 does it.

  | You seem to start with the premise that we won't be able
  | to find a scalable, provider-independent routing mechanism.

I start with the premise that after years of trying, we haven't
managed to come up with any kind of topology insensitive global
addressing that allows routing that scales.   (Note: topology
independent is what is important, not provider-independent).

I am not willing to bet a cent that we will magically find a solution
in the next year or so - especially given that no-one seemed to like
the only half way promising method that was ever proposed (that is,
having the end hosts run the routing function, and source routing).

Yet, we still have needs to handle, that we cannot simply afford to
ignore if no means of topology independent routing ever gets found.

Do you have any proposals for methods which might actually work for
topology independent routing that might even give rise to some hope
that there ever will be such a method?   If you don't, perhaps you
should stop suggesting to the WG that waiting for this is a useful
way to accomplish anything at all.

  | It hasn't been demonstrated (yet) that there is rough
  | consensus in the WG about this,

I wasn't able to work out what antecedent "this" had here.

  | pursuing automated
  | renumbering systems to obviate (one of the) need(s) for
  | local addressing, etc.

No, but you're not the only one to leap to this incorrect conclusion.

The easier renumbering is, the more we need local addressing, not
the less - if renumbering is practically impossible, then topology
(provider) dependent addresses become (essentially) stable - by customer
lock in.   That's not good from other viewpoints, but it makes for
stable addressing.  It is when addresses are changing that some
stable local addressing is needed, not for when globals are stable.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 May 2003 00:17:15 +0700

Date:        Mon, 19 May 2003 09:28:27 -0700
    From:        Sergey Gerasimov <[email-masked]>
    Message-ID:  <[email-masked]>

  | Now, if device comes up in .11 ad-hoc link local and .3 link local, then 
  | there is no connectivity between the .3 and .11 but they are on the same 
  | subnet (have same prefix in v6 world).

v6:

No, they have the same numeric value, in different scopes.  The address
needs a scope identifier to indicate which scope (subnet for LL) it
is within.

  | 4. ... others ...?

The scope identifier fixes this.   The API has a defined way to
include that in the binary form of addresses, but there's no standard
way to include it in textual representations - some OS's write it
as address%scope where scope is the name of the interface connected
to the subnet in question (it isn't really important, as at this level,
no portability is really required).

  | I am sure somebody has already come across this one and has some ideas. 
  |  Any information will be helpful.  It is really not a v6 question only, 
  | but appears to apply to both v6 and v4.

For v4, multiple connected link local nets generally gets a "don't go
there", or "Danger, Will Robinson" type response.   It probably isn't
worth any kind of standardised mechanism this late in the v4 game
(though you could certainly do one, probably like v6's, if only for
consistency, for your own needs).

It is however very opportune that you have raised this issue just now,
as it should help to point out to (some) people that applications really
need to deal with this kind of scenario - which means that they need to
be able to deal with scoped ambiguous addresses, and that whatever they
believe they have simplified in the silly attempt to delete site-local
addresses amounts to approximately zero.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 19 May 2003 13:34:08 -0400

At 09:30 PM 5/19/2003 +0700, Robert Elz wrote:

Hi Robert,

>functions that 1918 addresses offer, it doesn't have to be done the same

Which is why we suggested that the WG should work on understand the
requirements for local addressing.  In other words, what operational
needs are filled by RFC 1918 addresses and/or NAT?  Then we can talk
about how to meet those needs in IPv6, hopefully in a way that is
more architecturally sound.  So far, we seem to have a list that runs
something like:

         - Addressing for disconnected networks.
         - Simple local access control?  (Although I'm not
                 sure anyone uses RFC 1918 for this in IPv4.)
         - Portable local addressing for:
                 - Intermittently connected networks.
                 - Renumbered networks (i.e. ISP changes).

There should, I think, be a set of requirements under each of these
areas...  For instance, an administrator shouldn't have to pay an
ISP for service in order to number a disconnected network.

We don't necessarily need a single solution that solves all of
these cases.  There may be different solutions for different cases.
There may be also people in the WG, though, who disagree about
whether we need to solve some of these problems.

IMO, the best way to drive discussion on this would be to put forth a
fairly simple requirements document that covers each of these cases.
If no one else does it before I have time, maybe I'll do it...  but
I'd rather that someone else did it.

>No, but you're not the only one to leap to this incorrect conclusion.

I don't actually think that renumbering obviates the need for
portable addressing...  I was just listing one of the fairly
vocal views in the WG right now.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 19 May 2003 11:05:23 -0700

Just a followup to my previous note:

It was not my intent to say that Bob was intentionally trying to be
deceptive and mislead the working group. So I apologize to Bob if it
came across that way. 

I was trying to point out the contradiction between:
Margaret: 
> >addresses are local, not globally routable.
Bob:
> prefixes that are globally unique. 

and the subsequent claim that the chairs agree on the definition. The
definition can not be both, limited to local use, and not limited to
less than global, at the same time. Either these are unlimited and
useful globally, or they are local (for some definition of local).
Claiming they are both at the same time is the problem here.

Tony

---

From: Sergey Gerasimov <[email-masked]>
Date: Mon, 19 May 2003 12:22:10 -0700

Hello,

there are couple of things that still do not appear clear to me.
I understand that v4 has a problem and that is something we are trying to solve here locallly as we cannot get away from the dual stack.  However, here is what I read in the RFC2461 for v6:

When sending a packet to a destination, a node uses a combination of
the Destination Cache, the Prefix List, and the Default Router List
to determine the IP address of the appropriate next hop, an operation
known as "next-hop determination".  Once the IP address of the next
hop is known, the Neighbor Cache is consulted for link-layer	
information about that neighbor.

Now, let's say we have a node that has a leg in .11 ad-hoc, FE80:xxx   configured and a leg in .3, also link local configured.  Assuming prefix and default router caches are empty, all communications are link local.  Now we have a mobile workstation that joined our ad-hoc network and we want to transmit to it.  Mobile workstation also has a link local address.  Aren't we going to end up sending on the .3 leg anyways if it is first in the table?

I guess I am also a bit fuzzy on what happens when we get a connection from the remote node to us.  I think that neighbour discovery happens first (solicited from the remote connecting to us, if link local?, or from router if global?) and that populates our destination cache ... however, does tdestination cache contain the interface identifier that was (is) associated with the neghour discovery exchange?  That is something I could not quite get from the RFC.

Thanks a lot!
Sergey

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 May 2003 08:52:49 +0700

Date:        Mon, 19 May 2003 12:22:10 -0700
    From:        Sergey Gerasimov <[email-masked]>
    Message-ID:  <[email-masked]>

  | Now, let's say we have a node that has a leg in .11 ad-hoc, FE80:xxx
  | configured and a leg in .3, also link local configured.  Assuming prefix
  | and default router caches are empty, all communications are link local.

Yes.   What you need to do though is consider that LL addresses aren't
128 bits long, they're 144 bits (or something else like that).   The extra
16 bits aren't sent on the wire, they're local to your node.   For LL
addresses, they just number interfaces (0 1 2 3 ...) (or that's the usual
way, but because they're local to you internally, you can use any other
scheme you like - including making them be 32 or 64 bits as required, and
making them be a pointer to an interface structure or similar).

The extra bits should be considered as the most significant bits of the
address (which is relevant when doing longest match comparisons and such,
but only there).

Once you understand that the addresses are longer than 128 bits everything
gets simpler to understand, and the ambiguity that you believe exists
really doesn't exist at all.

The only issue that's left is where these extra bits come from, since
they're local to your node, they're obviously not in the DNS, or anywhere
else like that.

There are two cases to consider - when you receive the address from over
the wire, and when it originates in your node.

The first is easy - when a packet arrives, it arrives over some interface.
That interface "belongs" to one of these extra identifiers, that identifier
is what is used.   That is, in yoru case, you might decide that the .3
interface should have identifier "3" and the .11 interface should be "11".
(This is convenient for this example, but in real life would obviuously
not make sense, as there are likely to be multiple .3 interfaces, and
they can't all be called "3" - only one of them - there might even be
multiple .11 interfaces, though that's proabably less likely).

Now, any time you receive any address (in headers, or anywhere else)
that's FE80::xxx from the .3 interface, you should consider (and store)
the address as 3:FE80::XXXX - if from the .11 interface, you should
treat it as 11:FE80::XXXX (or B:FE80::XXXX as you prefer).

The IPv6 sockaddr struct has a field into which the extra identifier
is put, so when the address is passed back to the application (if it
is), everything is included.

When an address comes from an application, the application needs to fill
in that extra field - if the app is just passing back an address it
previously got from the kernel (getpeername() or similar) then the
data will be there already (even for global addresses, which don't need
the extra bits, in theory anyway, it is there - should be set to 0).

LLL addresses generally don't (certainly shouldn't) come from the DNS,
so that's not an issue (the DNS has no possible way to store your nodes
private identification numbers, obviously).   Other name to address
conversion mechanisms aren't yet finished - but anything that is doing
dynamic discovery (sending requests for a name, getting back answers)
is getting the answer over a specific link, and the ID comes from the
link over which the answer was received.

Where the address (numeric address) originates from a user, the user
is responsible for supplying the info - and getaddrinfo() should be
able to parse addresses containing scope identifiers into the 128
bit "address" and the extra "scope ID".  On the system I use, that's
done like

	ping fe80::1%ex0   or   ping fe80::1%wi0

where ex0 and wi0 are my .3 and .11 interfaces (resp).   Getaddrinfo()
extracts the interface name, looks it up in the kernel, extracts the
numeric identifier associated (3 or 11 in our example) and includes it
in the address structure returned.

The actual syntax is irrelevant (I have seen other OSs where the
app is required to get the scope identifier from a separate arg to the
command, and include it in the address itself - which seems pretty
dumb to me, but "whatever works").

All this means that most applications need to do nothing at all special,
if the OS is sane - it all "just works", but some need to take special
care when they deal with addresses, to notice when LL addresses appear,
and handle the scope ID appropriately (which includes not sending packets
with one scope-id to a node whose address is in a different scope).
[The same is true of site local addresses, for which most nodes will
have only one scope-ID which simplifies things very little actually,
but the required LL processing carries forth naturally to SL as well.]

Does this help?

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 May 2003 11:45:09 +0200

> Claiming they are both at the same time is the problem here.

I think the underlying problem is that there is no black and white
distinction between local and global, when network mergers, service
hosting, and VPNs, are considered. I can see very well how to use
Bob's proposal in such an ambiguous situation, without worrying
too much about whether it's local or global or something in between.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 May 2003 10:48:59 -0700

Margaret Wasserman wrote:
> need to be?) 

Again, I offer:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt
specifically documenting the requirements. Please stop saying they
aren't written down. The WG has not produced a document, but that is not
the only source of requirements. If people feel the list is inaccurate
or incomplete, please let me know.

> renumbering systems to obviate (one of the) need(s) for local 
> addressing, etc.
> 

In this case, it is broad enough that it probably belongs in the General
Area. There aspects that touch all of the other areas, so putting it in
any one is likely to overlook something.

Tony

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 22 May 2003 12:07:58 -0700

Tony,

> http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt

I read the document, and it seems to me there needs to be a
discussion of cases in which link-local addressing (fe80::) is
insufficient. In my opinion, it comes down to identifying use
cases in which flat vs. hierarchical local addressing schemes
are most appropriate. I believe this is a very difficult subject
to get one's arms around, but one that a local scope address
requirements document needs to tackle.

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 May 2003 13:39:13 -0700

Fred L. Templin wrote:
> discussion of cases in which link-local addressing (fe80::) 
> is insufficient. In my opinion, it comes down to identifying 
> use cases in which flat vs. hierarchical local addressing 
> schemes are most appropriate. I believe this is a very 
> difficult subject to get one's arms around, but one that a 
> local scope address requirements document needs to tackle.

I guess I accept the premise that the document should deal with it, but
it is not clear to me what form that would take beyond the direct
evidence that people have deployed networks that are larger scope than a
single link, and smaller scope than global. Their requirement for larger
than a single L2 link is ??? 

Clearly compartmentalization and traffic isolation comes to mind, but
how much of that requirement is based on anecdotal requirements from
broken implementations of > 15 years ago. Routing convergence is another
frequent reason, but again global flat L2 host routing is not the
problem it once was. 

Is it sufficient to say that network managers insist on the protection
offered by a scope less than global, but simply 'want' the
organizational structure of an L3 hierarchy that is larger than a single
L2 link? If not, what is the real requirement for hierarchy? Is this the
philosophical argument about L2 vs. L3 being better, or are we really
talking about something like the need for a network to be constructed
out of differing L2 media types for cost reasons. If different media is
the reason, the arguments are more about interconnecting dissimilar
media than hierarchy. Which brings us back to the question of how large
does a network need to be to 'require' hierarchy rather than simply
'want' it? 

Tony

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 22 May 2003 14:41:34 -0700

Tony,

You are hitting exactly on the points that concern me, and I
believe some implications for a local-use addressing scheme
become evident from what you've said. I think this is approx.
90% about the phiolosophical argument about L2 vs. L3; issues
with constructing networks out of differing L2 media types
can be overcome.

Your final question on how large does a network need to be
to 'require' rather than 'want' hierarchy is very poignant.
Seems like it might warrant some examination in the document.

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 May 2003 14:29:21 +0200

> Seems like it might warrant some examination in the document.

If the network manager *wants* hierarchy, then it's a customer
requirement, and the discussion's over.

Even in a penny-ante network like the one I used to run at CERN,
with a few hundred LANs and a few thousand hosts, there is no doubt
that internal hierarchy was desirable, for simplicity of administration
and operations. With serious sized networks of a few thousand LANs,
there is no doubt whatever. But the managers of those LANs in many cases
are exactly the people who want some form of "local" addressing, for
the reasons Tony's draft gives. 

So I don't think the case really needs to be made any more strongly
than Tony makes it.

While we're on Tony's draft, it doesn't IMHO give enough attention
to four reasons why non-ambiguity is essential:

- VPNs between enterprises both of which use "local" space
- hosting by service providers of hosts that reside in their customers' "local" space
- formation of virtual organizations (Grids) among enterprises using "local" space
- mergers and acquisitions of enterprises using "local" space

So, why I am putting "local" in quotes? Because I think it's now
clear that it's poor terminology. These addresses (as my four cases
above show) are not local. They are not global either. They have what
we might call "limited scope," but there is no simple rule that tells
you what the scope is. 

My conclusion: what we need is a family of "limited-scope unambiguous addresses"
and Tony's draft should express the requirements for those. (They will also serve
very nicely as identifiers for multi6.)

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 May 2003 10:04:07 -0700

Brian,

>- mergers and acquisitions of enterprises using "local" space

It would be good to capture these in a requirements draft.

>we might call "limited scope," but there is no simple rule that tells

I agree that "local" isn't a good description as the addresses can be used 
beyond a site and as you point out above this is a feature.  It is 
different notion of scope than the way that local, site, global scope are 
used.  It is more related to a set of routing configurations.   I think we 
need a better way to capture the idea here.  One thought is the scope is 
"virtual" in the way VPN is used.  Virtual scope?  Virtual unicast addresses?

>very nicely as identifiers for multi6.)\

Sounds like a plan to me :-)

Bob

---

From: Stephen Sprunk <[email-masked]>
Date: Fri, 23 May 2003 17:39:31 -0500

> Except for most of the edge.

If you define the edge as individual hosts, sure.  I think, for the
purposes of this debate, the "edge" is supposed to mean all non-
transit networks.

> please let's deal with it now.

IMHO, we face a serious challenge since edge (by my definition) network
managers rarely participate in the IETF process.  Many companies
actually prohibit employees from participating in public fora, and even
those of us who can are often forced to discuss hypothetical networks
or situations to avoid breaching NDAs, which then get ripped apart by
the technical purists.

> object to it. 

Neither IPv4 nor IPv6 has any semblance of multi-router renumbering
tools or protocols.  Either we modify IPv6 to have wire protocols for
distributing prefix information to routers, requiring scrapping much
of vendors' control plane code, or we create some external tools to
automate the renumbering process on today's code.  Do you have any
other general strategies for solving the problem?

> It's clearly possible, since it has been done on the edge 

Renumbering residential or SOHO customers' hosts and even CPE is
doable today, but that's only the tip of the iceberg.

> enrollment of some sort in order to really scale.

Enrollment?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Sat, 24 May 2003 02:11:19 -0700

> other general strategies for solving the problem?

Yes (although I certainly didn't code it or think of it), and it's in 
Cisco's code as well- it's called prefix delegation.  I believe the key 
problem is around how DNS gets updated.

Eliot