Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses

From: "Michel Py" <[email-masked]>
Date: Mon, 12 May 2003 08:41:28 -0700

Brian,

>> Michel Py wrote:
>> It has nothing to do with the prefix itself but with the scope. 

> Brian E Carpenter wrote:
> Of course. And why is the scope issue different, just because
> we have removed the ambiguity?

I read this the same way Jim does:

> Jim Bound wrote:
> What is so elegant about this proposal is that it completely
> eliminates the need for an implemented scoping architercture
> within products today

There is "no scoping" written all over Bob's draft. Without getting into
the "is this a good thing or not" stuff so far I have not seen any
proposal that could mitigate the risk of removing ambiguity without
creating a swamp if there is no scoping to back it up. In other words,
if scoping goes the ambiguity will remain.

>>>> 2. We can't enforce operators to filter the prefix. I dropped 
>>>> filters on my BGP feeds and from one of my peers (a well-known 
>>>> player) I get all kinds of crud including /64 routes, /48 routes, 
>>>> /41 routes, name it I get it.

>>> I think there will be Darwinian effects here, as we saw during the 
>>> first years of CIDR. But yes, if someone pays enough, they will get 
>>> their /64 announced. That will happen whatever we write in RFCs.

>> My point exactly. We can't rely on this alone.

> Now explain why it's a problem, if the customers pay
> enough to cover the costs. 

I though we were on agreement that routing table bloat was not a good
idea?

Michel.

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Tue, 13 May 2003 07:39:16 +0200

> if scoping goes the ambiguity will remain.

Well, I am too literal minded to have read that in the proposal. I think
it changes the scoping debate, but doesn't abolish it. As Tony Hain has
pointed out, scope is a fact of life, whether we architect it or not.

> I though we were on agreement that routing table bloat was not a good

Indeed. But if a few Megacorps are willing to pay the ISPs to carry
specific routes, that won't bloat the tables. If a lot of medium size
companies tried the same, it would be bad.

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Tue, 13 May 2003 07:51:59 -0400

Hi Brian,

>pointed out, scope is a fact of life, whether we architect it or not.

At this point, I think we're really having an argument about what
"scope" means...

Does it mean that addresses have a certain scope in which they are:
reachable?  routable?  unique?  Does it mean that the match the
description of scoped addressing in the IPv6 Scoped Addressing
Architecture?

I apply the following terms to these distinctions:

         Reachable & Unreachable
         Globally Routable & Local
         Globally Unique & Ambiguous

I think of "scoped" addresses as unreachable, local and ambiguous,
with all three attributes constrained at the same boundary (the
site boundary, in the case of site-locals).

So, by my definitions, the addresses described in Bob's proposal
are _local_ addresses, but they are not _scoped_ addresses.

It seems to me, though, that they may be _scoped_ by your
definition and Tony's...  Could you provide a definition?

I am pretty certain that we all agree that there will continue to
be firewalls in IPv6, and that those firewalls will make some
addresses (and some address/port combinations) unreachable from
other parts of the network.  This will apply to both globally
routable and local addresses, so any address could be unreachable
from some parts of the network.

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.

>companies tried the same, it would be bad.

As long as the cost of having a private address block routed across
the Internet is high-enough that it makes financial sense for a
Megacorp to do it, but it doesn't make sense for a mid-sized company
to do it, then this would work fine...

Personally, I think that the IETF should design the right technical
solutions for addressing and leave it up to the registries and
providers to determine the appropriate policies and business models
for addressing.  But, perhaps I'm just naive.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 May 2003 15:54:26 +0200

Margaret,

I have to be a bit careful here... I don't want to restart the
scope wars on this thread, but I have severe doubts whether scope
rules can be defined with the sort of mathematical clarity
you might like. Given the prevalence of VPNs between private 
networks, I have difficulty knowing what a useful definition would 
look like. So I will actually decline to answer the question
about what scope means, because I don't know any more (apart from
link-local). 

This is linked to your last point. We do have to leave a lot of this to
the operations community, and the question is what can we usefully
give them in the way of generic scope mechanisms?

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 May 2003 10:04:39 -0400

Hi Brian,

At 03:54 PM 5/13/2003 +0200, Brian E Carpenter wrote:
>scope wars on this thread,

I certainly don't either...

>but I have severe doubts whether scope

Well, since we don't seem to have agreement on what the term
means outside of the link-local case, perhaps we should try
to stop using it?  I think that it just leads to miscommunication.

>give them in the way of generic scope mechanisms?

Perhaps we should try asking them what they need?  I realize
that this is easier said than done (I'm fairly involved in
the network management area...), but I think it's at least
worth a try.

Margaret

---

From: Bob Hinden <[email-masked]>
Date: Tue, 13 May 2003 10:26:54 -0700

Margaret,

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

Bob

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 May 2003 20:58:05 +0300 (EEST)

> So yes, I think we agree.

What would you propose to do with default address selection, if any?

Should a preference in it be given to truly global or globally unique 
local addresses, or should these be indistinguishable from the point of 
view?

This "addresses tried first" ordering is of some importance -- which one 
reason for having this "scope" concept.

-- 
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: Eliot Lear <[email-masked]>
Date: Tue, 13 May 2003 11:18:01 -0700

Bob,

I've read the draft, and ultimately I think Michel is correct in a 
couple of important ways that need to be carefully considered:

1.  There really is no way to keep these addresses out of DNS.  That's 
an operational BCP, perhaps, but the standard can't do much here.

2.  It might be just as well because big honking enterprises are going 
to get their prefixes announced into the DFZ *anyway*.

While it's good simplify the architectural constructs, particularly when 
it comes to the ambiguity introduced with SLs, and while I see this 
draft as addressing the disconnected network reasonably well, I'm still 
left with the concern that what will really happen is that people will 
go and get a PI address in order to avoid renumbering and then end up 
NATing *that* because it won't be routable.  So while it's an marked 
improvement over SLs, I'm not sure it's enough of an improvement on its own.

That begs the question.  What is?  I am hearing deafening silence when 
it comes to how prefix delegation will handle a large scale renumbering, 
particularly from a DNS standpoint.  Are we expecting this to work 
through DDNS?  If so, will a renumbering event today cause a DDOS attack 
on the name server?

Where is this work to be done?

Eliot

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 May 2003 05:22:14 +0700

Date:        Tue, 13 May 2003 07:51:59 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | At this point, I think we're really having an argument about what
  | "scope" means...

This has all been most amusing...

  | I think of "scoped" addresses as unreachable, local and ambiguous,

That's an odd definition, which seems designed more such that LLs and SLs
(those kinds of addresses) are the only ones that get the label attached,
as if "scope" is a pejorative annotation, and must be avoided at all costs
just because it is evil (regardless of what it implies).

  | It seems to me, though, that they may be _scoped_ by your
  | definition and Tony's...  Could you provide a definition?

For me, a scoped address is anything which doesn't work similarly at
any two points on the connected internet (similarly to allow differences
related to RTT, packet loss rates, etc, to be ignored - but that's all that
should be ignored).   Actually all addresses are scoped - the "global"
addresses we talk of are scoped to our Internet - someone setting up a
rival internet could use all the same addresses in their own "global" scope.

But I'm not sure this matters.

  | However, Bob's proposal defines addresses that are unique throughout
  | the Internet.

That lasted all of a day...   The proposals to allow people to invent their
own random numbers rather than paying 10 Eur to some bureaucracy (along with
a delay of probably several days) took that long to appear - with the
(perfectly correct) rationalisation that allow it or not, people will do it,
so there may as well at least be a way to formalise it.

Brian contended that (some) people will want addresses that are known unique,
but without some kind of enforcement policy that's impossible, and Bob's
proposal has exactly none of that - the addresses are local and private,
which means that no-one can know what addresses I'm using (unless I tell
them) and so there's no way they can know that I just happened to pick the
same number they did.

The only way to enforce uniqueness is to make the addresses fail to work in
some respect that matters (IP6.ARPA doesn't matter, so it doesn't help).
The only way that matters for addresses really is routing, so for any address
that isn't globally routed, ambiguity will be a fact of life.   Accept it.

Christian used the birthday paradox to assume that 41 bits of random number
would not be enough - but while I am no statistician, I suspect that he
got the domain wrong - it doesn't matter in the slightest what the probability
is of a clash of identifiers with everyone else in the world, they don't
see my ID and I don't see theirs - the set of sites (organisations if "site"
is another bad word) with whom I want to have a high probability of no
duplications is the ones with whom I want to share these addresses, and
that set will usually be numbered in the hundreds, perhaps thousands, but
certainly not billions.

In any case, after all this, it is interesting to see that what we're left
with is exactly Paul Francis NUSLA proposal (from a bit over 2 years ago I
think, or was it 3?) except perhaps with the prefix changed.

Truly nothing new...  (and yes, I know the draft says that, this is not
a criticism).

kre

ps: for what it is worth, I have no problems with this proposal, except the
silly idea that anyone with half a brain would pay money to have a random
number allocated.   It retains the parts of site local that are important.
Unfortunately (for Jim), it won't allow the scoping in his implementation
to be removed, that's still needed for link locals - the only simplification
this will allow (to anything) is to avoid the need for scope-aware routing.
I'd also have no problem if the prefix were a /10 instead of /7, that's
big enough.

pps: No way could the ISOC just be handed the right to administer this space
if it were to be administered - there's enormous revenue at stake here,
and Govts all over the place are going to want to try and get it into their
domain, so they get the benefits - India and China certainly have good claims,
why should their (combined) > 2B population all be sending revenue to yet
another US based organisation?

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 May 2003 14:46:57 -0700

> reason for having this "scope" concept.

Pekka is right. The real question behind Bob's proposal is not so much
to know if it creates scopes or not, but what is the impact on the 
applications.

If applications need to be aware of those addresses and take different 
actions
if/when different combination of "bob's" or "regular" addresses exist, 
we
end up with much of the issues we had with Site Local, ambiguity 
excepted.
This needs to be clarified.

	- Alain.

---

From: Andrew White <[email-masked]>
Date: Thu, 15 May 2003 11:36:36 +1000

> This needs to be clarified.

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.

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.

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

Likewise, src address selection will choose a global address (longest prefix
match) for traffic destined for a global address, and a local address
(longest prefix match) for traffic destined to a local address.

Destination Rule #2 favours matching source and destination scopes.  Rule #8
favours smaller scope over larger.  Rule #9 favours longest prefix match.

Thus, in order of preference:
  Source -> Dest
  ----------------
  Local  -> Local
  Global -> Global
  Global -> Local
  Local  -> Global

Assuming that the host's IP library does its job, the application may ignore
the distinction between local and global addresses UNLESS it intends to
forward addresses between other hosts AND these referrals may cross the
local filtering boundary.  One obvious solution is to forward names
instead.  The other is to have a configuration switch telling the app that
it may not use local destination addresses.

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.

Of course, referrals may still fail even with globals, so any application
doing referrals probably wants a bunch of recovery mechanisms.  And thus can
be ignorant of local addresses too, and accept that it may need to try a few
addresses to get it to work.

-- 
Andrew White

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 May 2003 13:41:03 +0200

below...

> Thus, in order of preference:

The trouble is that none of this answers the real world questions
that a sophisticated applications environment ought to want to ask,
such as:

- which pair(*) of addresses will give the best reliability|throughput|delay?
- which pair of addresses will stay within a specified security boundary
  (e.g. within the corporate firewall, within a given VPN connection, within
   a given Grid virtual organization)?

I'm increasingly concerned that there is no way to resolve such questions
by examining the prefix bits in an address or by defining scope as a set
of concentric circles such as link-site-global.

(*) 'pair' becomes 'set' for a referral or SCTP scenario, and the questions
become correspondingly more complex.
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Thu, 15 May 2003 20:06:23 +0700

Date:        Thu, 15 May 2003 13:41:03 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | The trouble is that none of this answers the real world questions
  | that a sophisticated applications environment ought to want to ask,
  | such as:

  | I'm increasingly concerned that there is no way to resolve such questions
  | by examining the prefix bits in an address or by defining scope as a set
  | of concentric circles such as link-site-global.

Why is this a surprise?

Of course answers to those questions aren't going to be as simple as
looking at a few bits - we shouldn't expect them to be, nor should we
be criticising the bits for being unable to provide those answers.

This is obvious as soon as you notice that the answers to the questions
have a temporal component - which addressing manages to select the
link which is most reliable (etc) varies as link conditions change, yet
we obviously don't want the addressing to do so.

Network boundaries could be delimited by addressing - but only as long
as the network boundaries are nice fixed stable things, planned well
in advance.   That certainly won't serve every need.

But that we cannot possibly solve every possible problem that exists
with addressing doesn't mean that we shouldn't get whatever advantages
that we can.   We need stable local addressing.  Whether that is the SL
addresses that we have now, or the addresses in Bob's proposal (which
despite his desire to make them different from SL's, have ended up
being essentially the same - currently the one big difference is the
bigger address space, that's really it, and that there are no multi-site
nodes in his proposal).    That this happened is no surprise - there's
a demand that this kind of addressing fills, and everyone knows it.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 May 2003 16:09:41 +0200

kre,

I won't disagree. I just don't want people to believe that
we can define an addressing format, a scope rule, and we're done.

   Brian