Subject: Re: "unique enough" [RE: globally unique site local addresses]

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Nov 2002 18:35:31 -0500

>
>What I am failing to understand is what we are looking for. The <insert 
>letter>GUPI model will drive the development of NATs.

Why do you think so?

In particular, why do you think that GUPI addresses would drive the
development of NATs any more than the current IPv6 site-local addresses?

Do you really think that it is realistic to just tell everyone to use
provider-assigned addresses throughout their network?

We've been getting feedback from network administrators that they need
a form of local addressing that allows their internal numbering, firewall
configuration, etc. to be independent of their ISP-provided addresses.

People want to use site-locals for this, but the ambiguity of site-locals
causes all sorts of problems for applications, routing protocols, transport
protocols, etc. especially when running on site border nodes (nodes that
are in more than one site at the same time).

It is my belief that if we ignore this problem, and simply limit site-
locals to disconnected networks (a la RFC 1918 addresses), then IPv6
NAT will arise to allow sites to separate internal addressing from
external addressing.

What we really need is a better way to solve this problem, one that doesn't
have the problems of site-local addresses.  And, that's why we're discussing
GUPI addresses.  Is there a better way to solve this problem that we
haven't considered?

Margaret

--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 3 Dec 2002 18:09:55 +0100

>> What I am failing to understand is what we are looking for. The 
>> <insert letter>GUPI model will drive the development of NATs.
>
> Why do you think so?

Well, see my mail to Keith. I think that people have to much strange 
ideas on what NATs will give them, that anything that will have a 
"scope" will lead them down that road. What I am failing to understand 
is what benefits the complexity and additional administration of either 
GUPIs or GUSLs will give us over just assigning plain IPv6 addresses.

> development of NATs any more than the current IPv6 site-local 

I think both have the potential to drive us down that road. SLs 
probably more than the other.

> provider-assigned addresses throughout their network?

No. But I fail to see what we gain with creating a special block from 
where we assign PI addresses. The RIRs can equally well assign PI space 
from the current IPv6 unicast space. Sure, this will lead to growth in 
the size of the DFZ, but that is a routing problem.

I just get the feeling that we are using to much duck tape to work 
around a different problem.

> configuration, etc. to be independent of their ISP-provided addresses.

So let's give them PI space from the RIRs pools of IPv6 addresses. 
Currently I am more worried about the lack of assignments from the RIRs 
  rather than them assigning to many.

> NAT will arise to allow sites to separate internal addressing from

So let's give them PI space!!! We don't really need more abbreviations, 
we have the address space so far, we are still far from hitting the 
roof of the routing table in IPv6....

This would solve the uniqueness problem and take away the NAT worries.

> GUPI addresses.  Is there a better way to solve this problem that we

"Real" addresses?

- kurtis -

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 04 Dec 2002 05:54:10 -0500

>from the current IPv6 unicast space. Sure, this will lead to growth in the 
>size of the DFZ, but that is a routing problem.

I think we're arguing the same side here...

I'd like to see addresses available to enterprises (and home users, for
that matter) with the following properties:

         1) globally unique
         2) provider independent (AKA "portable")
         3) globally routable
         4) indistinguishable from provider-allocated addresses by
                 routers, applications, etc.

However, the concern that has been voiced by many in the IPv6 WG is that
property (3) cannot be provided in a scalable manner.  This has led to a
belief that we can't have property (4), because ISPs will need to know
which prefix advertisements to accept, and which to block...

>So let's give them PI space!!! We don't really need more abbreviations, we 
>have the address space so far, we are still far from hitting the roof of 
>the routing table in IPv6....

I don't care what we call it...

I read your draft on multi6 regarding "longer prefix" multihoming, and was
surprised to see your assertion regarding how far we are from having a
route scaling problem in IPv6...

But, do you really think that we will continue to have fairly small routing
tables if we allow every enterprise (and home?) to get its own portable
address allocation?  Or would we need to come up with some way to
assign these addresses in an aggregable manner.

Are you proposing a particular mechanism that would allow aggregation of
PI address allocations?

I know that there is a geography-based PI allocation proposal in mutli6, but I
don't understand how they produce aggregation.  There are multiple providers
in every city, and those providers networks may not be topologically
"close" to each other, even though they are geographically close.

>This would solve the uniqueness problem and take away the NAT worries.

True, but it would cause IPv6 routing table growth...  Do you have an
answer for that?

Margaret

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Dec 2002 17:52:15 +0100

>> where we assign PI addresses. The RIRs can equally well assign PI 
>> space from the current IPv6 unicast space. Sure, this will lead to 
>> growth in the size of the DFZ, but that is a routing problem.
>

Agreed.

> I don't care what we call it...

I don't think that this business requires more abreviation 
inflation....:)

> route scaling problem in IPv6...

You where not at the rebellion/ad-hoc/let's get out of here and go for 
bee multi6 meeting on Thursday in Atlanta. What I (and I think Thomas) 
said, was that we simply don't know this yet. With ~250 non 6bone 
routes in the DFZ we can't really telä if this is a scaling problem or 
not. When I configured my first BGP router we had just hit above 25k 
routes and people where telling me this was the end. I see a problem, 
but not for v6, and not now. We have no idea of how popular multihoming 
will be or what the impacts of cost etc will be.

Maybe every mobile device will be multihomed, maybe the costs are to 
high? No one knows. We nee more data and experience.

One thing I have been think of. Do we know what the increased 
prefix-length does to implementations and the effect on convergence 
times? What I would like to do is have someone load a bunch of routers 
up with the current 130k routes but with a prefix length of 128n bits, 
what happens? What is the cost?

> assign these addresses in an aggregable manner.

In the cast above - no. But with 250 routes I am more worried about 
IPv6 not happening at all than us running out of scaling. You still 
have the dinner at stake with me. I guess that we will have (with good 
margin) a better understanding of the problem and the solutions in 
advance to a real scaling problem.

> Are you proposing a particular mechanism that would allow aggregation 

Not in the draft I have worked on now. In futuer? Yes, we will need a 
solution to the scaling problem, but that needs to be achieved with a 
routing solutions as well as perhaps a solution to addresses.

> True, but it would cause IPv6 routing table growth...  Do you have an

Without a question! But now we need to but time and deployment more 
than anything else.

- kurtis -

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 09 Dec 2002 09:50:04 -0500

>
>You where not at the rebellion/ad-hoc/let's get out of here and go for bee 
>multi6 meeting on Thursday in Atlanta.

I was not actually aware of these meetings until later...  I have
since joined the mailing list.

>prefix-length does to implementations and the effect on convergence times? 
>What I would like to do is have someone load a bunch of routers up with 
>the current 130k routes but with a prefix length of 128n bits, what 
>happens? What is the cost?

I don't know if anyone has studied this.  It is a very interesting
question.

>routing solutions as well as perhaps a solution to addresses.

Right.  I think that we will actually need to make a fairly major change
to the routing architecture of the Internet somewhere down the line, in
order to support continued growth.  I don't know what form it will take,
but it will probably require some changes to IPv6, at least to the
structure or allocation or IPv6 addresses.

>Without a question! But now we need to but time and deployment more than 
>anything else.

I'm not sure I can quite agree...

I have the following things running around in my brain, and they aren't
converging:

         - We need to provide PI addressing in IPv6, or we will
                 see wide deployment of IPv6 NAT in enterprises
                 and homes.  No one seems to be disagreeing with
                 this.

         - We think that the use of NAT is one of the serious
                 architectural problems facing the Internet today,
                 and that NAT is blocking the advancement of the
                 Internet in many ways.  For an IPv6 Internet to
                 be a "success", we must avoid the wide-scale
                 deployment of IPv6 NAT.

         - We don't currently have a fully developed plan for
                 aggregable, scalable IPv6 PI addressing.  Some
                 folks are working on this problem, but no one
                 has claimed to have a full answer yet.

         - We know that providing widely-used PI addresses in IPv6
                 will result in substantially larger routing
                 tables than doing straight PA addressing.

         - We also know that routing table size is a real scaling
                 factor in the IPv4 Internet, for which we have not
                 determined an adequate solution.

         - Routing table growth is not (yet) a scaling problem
                 for IPv6, because of limited deployment.  However,
                 wide deployment of IPv6 is also a criteria for
                 "success", so we need to build a scalable
                 solution...

         - However, "success" must also include the avoidance of
                 wide-scale IPv6 NAT deployment, which we can only
                 achieve if we provide PI addresses...

         [Ad infinitim.]

So, where do we go from here?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Dec 2002 13:25:31 -0500

>                  has claimed to have a full answer yet.

AFAIK, addressing isn't the problem, routing of non-aggregatable 
addresses is.

>                  tables than doing straight PA addressing.

we don't know that.  some people believe that.  my belief is
that such concerns are well-placed, though I don't share the belief
that wide use of PI addresses inherently leads to having ISPs trying
to globally route them.

>                  determined an adequate solution.

my understanding is that routing table size isn't the issue for IPv4.  
it was once, many years ago.  last I knew, the current limiting factor
was the complexity of the routing computation, and the consequent time 
required to adapt to changes in the topology.  that's subtly different
than routing table size.

note however that routing table size could be an issue once again
with IPv6, since flat routing of large #s of /48 prefixes would
presumably exhaust the forwarding table space in most routers...

Keith

---

From: Ronald van der Pol <[email-masked]>
Date: Wed, 11 Dec 2002 16:10:51 +0100

>                 and homes.  No one seems to be disagreeing with

I don't know yet if I agree or not :-) I agree that it is a good
idea to explore the topic of PI addressing. But if you look at the
requirements, it might be better to take a more fundamental approach
and look into the separatiion of locator and identifier.

I _do_ agree that we must avoid IPv6 NAT!

	rvdp

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 15 Dec 2002 20:19:01 +0100

>> times? What I would like to do is have someone load a bunch of 
>> routers up with the current 130k routes but with a prefix length of 
>> 128n bits, what happens? What is the cost?
>

My concern with this is that there are a lot more factors like the 
above one that we do not know the answer to - still we are already 
talking about solutions. I think we need to understand the problem 
first.

> I have the following things running around in my brain, and they aren't

[snip]

> So, where do we go from here?

Actually I think your list was a very good start! The more we can 
dissect the problem, and try and see the consequences of each of the 
pieces or the need for each piece, the better final solution we will be 
able to engineer. But this takes time and   in the mean time we need to 
get a solution out that gives us some breathing space. The solution I 
suggested is also something that we can back out of. Just as we are 
doing with the 6bone addresses.

What we discussed in Atlanta was that we needed a road-map. I took on 
the task of writing it and hope to get it out soon. What you wrote is 
an essential pice of this.

- kurtis -