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

From: "Michel Py" <[email-masked]>
Date: Fri, 9 May 2003 14:37:59 -0700

> Alain Durand wrote:
> Everybody want a free lunch in this story:
> routable PI.

I would have said that this might be the free lunch that everybody
wants. Unfortunately, free lunches are like freedom: in the end they're
anything but free.

> There is no reason to think that those non-routable
> PI will not be advertized in the DMZ if enough money
> is put on the table.

Exactly.

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: "Christian Huitema" <[email-masked]>
Date: Sat, 10 May 2003 15:56:00 -0700

> A suggestion: it would be convenient, in some cases, to have a few bits
> available for a subnet ID.  Scanarios in which there isn't a unique
> interface (with a unique EUI-48) for each subnet are obscure, but it's
> easier to imagine cases where there's only one EUI-48 that's *conveninent*
> to use.  Also, note that the EUI-48 includes the scope and multicast bits,
> which will always be zero in this use, so we can compress the EUI-48 to a
> 46 bit field.  I suggest having a 10-bit prefix, 46-bit compressed EUI-48
> field, then 8 bits of subnet ID.  The prefix can't be fec0::/10, because
> that has site-local scope semantics; it could perhaps be fe40::/10.

Well, an alternative would be to use the U and G bit to indicate whether the 48 bit identifier is unique or picked at random. Allowing a "random number" as an escape patch would solve the case of "unnumbered links", those for which there is no handy number to use.

-- Christian Huitema

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 May 2003 05:02:08 -0400

Bob,

This is an excellent idea and it will work.  I hear others risk issues I
believe the risk is worth it and I also believe this is very
implementable expediently.  What is so elegant about this proposal is
that it completely eliminates the need for an implemented scoping
architercture within products today until those of us who build and ship
stacks in the market have more experience with the scoping architecture
of IPv6 in the OS networking subsystem kernels within the vendor and
open source community.

This is a compromise I will support here and in the non IETF forums
where we don't do standards but real deployment.

Thank You for your leadership and those you acknowledged in the spec for
their contributions.

Regards,
/jim

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 11 May 2003 16:46:02 -0700

> We need site prefixes, not link prefixes, even for SOHO networks.

Are you actually sure of that? Every solution implies a trade-off. Automatic link prefixes are at one end of the trade-off; configured "site" prefixes at the other end. If you want isolation of some classes of addresses, you can achieve that with a firewall, and effectively block reachability of links outside your site. So, why not let two flowers bloom? Besides, what is a site? 
 
-- Christian Huitema

---

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

> Brian E Carpenter wrote:
> In response to both you and Christian, I think the arguments why
> we need /48s, and can afford to give them, are in RFC 3177.
> That doesn't exclude /64 in some cases, but as a general solution,
> we should assume the need for subnets and not assume automatic
> subnet numbering.

I completely agree with this.

Michel.

---

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

Michel,

>Who's talking about a handful of few megacorps? Although it might be
>unfair, they will get their prefix announced no matter what; this is a
>fact of life.
>
>What do you plan to do in order to prevent small and mid-size businesses
>from announcing their prefix? All it takes is one salesdroid to figure
>it out; today lots of ISPs would gladly leak the customer's prefix for
>free just as an incentive to keep an existing customer or capture a new
>one.

I agree that if these non-aggregatable /48 prefixes were to be widely 
advertised it would create a route scaling problem for the Internet.  This 
would, of course, be vary bad.  However, I do not think this is likely to 
happen.

I think the length of the prefix (i.e., /48) helps to make this very hard 
beyond a few directly connected ISPs.  I think ISPs will as a general 
policy filter all prefixes longer than "n", where "n" is <= 48.  I think 
this type of filtering is fairly common in IPv4.  This will make it very 
hard for a /48 prefix of any type to be widely advertised, unless (as I 
think Pekka Savola said) they are willing to pay all ISPs to carry 
it.  This should be enough of a disincentive to keep it from being a 
significant problem.

Bob

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 13 May 2003 10:27:20 -0700

> > free just as an incentive to keep an existing customer or capture a
new

The only way to prevent that from happening is peer pressure from other
ISPs. In practice the only tool ISPs have is to filter out announces of
offending prefixes. Where the IETF can help is with a definition of
"offending", so ISPs who filter can point to a standard when they get
sued. Possible definition of offending include prefixes that are too
long, prefixes that start by a scoped out string, etc.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 13 May 2003 10:29:12 -0700

> it.  This should be enough of a disincentive to keep it from being a

OTOH, it possible to use overlay technologies, e.g. distributed hash
tables, to route these packets over a PA-addressed network.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Tue, 13 May 2003 10:57:34 -0700

Bob,

> I agree that if these non-aggregatable /48 prefixes were to be
> widely advertised it would create a route scaling problem for
> the Internet. This would, of course, be vary bad. However, I do
> not think this is likely to happen.
> I think the length of the prefix (i.e., /48) helps to make this
> very hard beyond a few directly connected ISPs.  I think ISPs
> will as a general policy filter all prefixes longer than "n",
> where "n" is <= 48.  I think this type of filtering is fairly
> common in IPv4.  This will make it very hard for a /48 prefix
> of any type to be widely advertised, unless (as I think Pekka
> Savola said) they are willing to pay all ISPs to carry it.
> This should be enough of a disincentive to keep it from being
> a significant problem.

I do not share this point of view. As of today, I am already getting all
kinds of prefix announcements from one of my IPv6 ISPs, not only /48s
but all the way down to /64s. They don't filter at all, and this is
_before_ any kind of PI addressing scheme is available.

> Christian Huitema wrote:
> The only way to prevent that from happening is peer pressure
> from other ISPs. In practice the only tool ISPs have is to
> filter out announces of offending prefixes.

I agree. However, peer pressure happens only when there are a relatively
small number of black sheep and/or when peering is difficult. In today's
IPv6 business model without a DFZ where everyone provides free transit
to everyone, it is relatively easy for an ISP that would decide not to
filter (because they want to capture the IPv6 market) to find peers that
would think the same way.

Playing the devil's advocate, there even are some technical arguments
for doing this: yes it does increase routing table size but OTOH it can
reduce "scenic routing".

Since this would provide a "solution" to the multihoming problem you can
be sure that they would be popular, especially if the addresses are
issued by some official entity/registry that has IETF/IANA's blessing.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 13 May 2003 11:02:31 -0700

Bob,

> Bob Hinden wrote:
> 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.

My reading as well, which is precisely why I say that it would have been
possible to remove ambiguity of site-local addresses because they had a
limited scope and why it's not possible with globally unique IPv6 local
unicast addresses because of the lack of limitation by scope.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 13 May 2003 18:41:44 -0400

FOlks,

unicast scope to implementor means this.  I must know from a state
machine or conditon that an address applies to a specific interface for
a scope: link-local, site-local, and global. This is a simple definition
and suggest for what I am about to say the more complex regarding slices
through hosts, nets, and interfaces is not needed for now.

as implementors we know how to do global address it can go over any
scope above. as implementors "most" of us (not all IMO) have learned how
to do deal with link-local when on same machine for two different links.
we have proven we know this by interoperability testing, IPv6 forum lab
testing, test suites, test beds running, and with early adopter
customers we have using multiple links and link-local.  

we also know the affect above as standards architectects and designers
of extensions to protocols.  we understand the above "clearly" in my
view.

Ipv6 some day will be able to go far beyond this simple scoping and its
in the architecture.

Bob's spec gives us site communications but with global scoping and with
some rules to reduce pain.  All pain no.  But enough to move forward.
The spec removed the abmbiguity of scoping from the discussion to give
users a means to use addresses only within their site.  We have the
skill here to build a standard from it, implement it and deploy it after
those two acts.

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.

Just my .25cents,
/jim

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Tuesday, May 13, 2003 7:52 AM
> To: Brian E Carpenter
> Cc: Michel Py; [email-masked]
> Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses
> 
> 
> 
> Hi Brian,
> 
> At 07:39 AM 5/13/2003 +0200, Brian E Carpenter wrote:
> >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.
> 
> 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.
> 
> 
> > > I though we were on agreement that routing table bloat was not a 
> > > good idea?
> >
> >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.
> 
> 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: "Michel Py" <[email-masked]>
Date: Tue, 13 May 2003 18:17:08 -0700

Christian,

> Christian Huitema wrote:
> The only way to prevent that from happening is to define a form
> of scoping. If the GUILUA addresses are supposed to be in a scope
> of their own, then the hosts stacks can be instructed that they
> cannot be used as a source address when communicating with a
> non-GUILUA destination, and vice versa.

This would be too restrictive to many. There are plenty of legitimate
uses where a host with a GUILUA address would have to talk to a host
with a global address within the same organization.

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Wed, 14 May 2003 00:22:24 -0400 (EDT)

"Christian Huitema" <[email-masked]> wrote:

|> I think the length of the prefix (i.e., /48) helps to make this very
|hard
|> beyond a few directly connected ISPs.  I think ISPs will as a general
|> policy filter all prefixes longer than "n", where "n" is <= 48.  I
|think
|> this type of filtering is fairly common in IPv4.  This will make it
|very
|> hard for a /48 prefix of any type to be widely advertised, unless (as
|I
|> think Pekka Savola said) they are willing to pay all ISPs to carry
|> it.  This should be enough of a disincentive to keep it from being a
|> significant problem.
|
|OTOH, it possible to use overlay technologies, e.g. distributed hash
|tables, to route these packets over a PA-addressed network.

With any luck the use of the "overlay" addresses could overtake the use of the
"native" PA addresses (without causing any central routing table explosion, of
course).  At that time we would be faced with answering the awkward question of
why we didn't simply allow routable PI addresses via distributed routing in the
first place...

				Dan Lanciani
				ddl@danlan.*com

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 14 May 2003 06:42:30 -0400

Your point about stating the obvious?
thanks
/jim

> From: David Conrad [mailto:[email-masked]] 
> Sent: Tuesday, May 13, 2003 7:03 PM
> To: Bound, Jim
> Cc: Eliot Lear; Christian Huitema; Bob Hinden; Margaret 
> Wasserman; [email-masked]
> Router renumbering is trivial compared to modifying applications 
> running within a site that have hardcoded addresses in ASCII 
> text files.
> 
> On Tuesday, May 13, 2003, at 03:48  PM, Bound, Jim wrote:
> 
> > We could start with router vendors implementing router 
> renumbering on 
> > test beds and at interoperability events :--) /jim
> >
> >> From: Eliot Lear [mailto:[email-masked]]
> >> Sent: Tuesday, May 13, 2003 5:52 PM
> >> To: Christian Huitema
> >> Cc: Bob Hinden; Margaret Wasserman; [email-masked]
> >>> The only way to prevent that from happening is to define 
> a form of 
> >>> scoping.
> >>
> >> I disagree.  I think the only way to deal with the problem 
> I describe 
> >> is to deal with renumbering properly.  Now, where shall that
> >> work be done?
> >>
> >> Eliot
> >>
> >>
> >>

---

From: "Michel Py" <[email-masked]>
Date: Fri, 16 May 2003 10:35:37 -0700

Brian,

> Brian E Carpenter wrote:
> - 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)?

This leads to having the decisions of the address selection and TE being
made by the site's edge router because it's the only box that has enough
knowledge of the topology. Same would apply to flow label I think: there
are numerous advantages of the address selection being done by the
router that labels flows, with mutual awareness of the process.

Although I agree that they could be cases like DMZ web servers that
could get a copy of the routing table and the site's egress policy, most
hosts within a site should have only one address (identifier) and let
the SBR decides which PA address it maps to.

In other words, a host could have multiple PA addresses but these
addresses must be virtualized and projected in the SBR.

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

I never considered scope to be helpful with sophisticated traffic
engineering. Scope can help with blackholing and with no-brainer
decisions; I consider it more like a "last resort" TE solution.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 19 May 2003 19:38:33 -0700

>> Margaret Wasserman wrote:
>> Who said that the aim of IPv6 was to be able to do
>> everything that IPv4 can do?

> Robert Elz wrote:
> 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".

I could not agree more.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 29 May 2003 20:41:13 -0700

> Hans Kruse wrote:
> I actually see a lot of value in the /56 proposal

I will side with Brian Carpenter on this one: we have RFC3177 and I do
not see enough reasons to re-visit it at this time.

Michel.