Subject: RE: A use for site local addresses?

From: "BAUDOT Alain FTRD/DMI/CAE" <[email-masked]>
Date: Fri, 28 Mar 2003 14:18:04 +0100

Hi Margaret,

> On the contrary, some of the pushback on site-local addressing
> has been from people who run real networks.  One of the deciding
> factors in the WG meeting discussion was the statement from a few
> real network operators that they don't need a special prefix for
> non-connected networks -- since they'll have to renumber when they
> connect, anyway, they could just use a random prefix on their
> disconnected networks.
> 
I actually don't understand why renumbering would be necessary while 
movingfrom disconnect to connect state. Do you make the assumption 
that only a single address must be used ?

I think one may need/want to use both site-local addresses (for local 
traffic exactly the same way than during disconnect state) and global
addresses (for external connections) together with address selection. 
In that case there is no need for NAT boxes, although that maybe used
anyway. Then, renumbering will happen only when changing of ISP.

On an other hand, site-local provides a global non-routable address
space, 
that may be very usefull for adressing nodes (e.g. an ISP back-bone)
that 
definitly do not need to be address from the outside.  

Alain.

--------------------------------------------------------------------
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: "Jeroen Massar" <[email-masked]>
Date: Fri, 28 Mar 2003 15:02:26 +0100

> that only a single address must be used ?

Because fec0:: (Site-local) would be used by many sites and
is not routable? or do you mean that the site actually runs
with a /48 from it's upstream, disconnects temporarily and
then reconnects while retaining the same space?
 
> anyway. Then, renumbering will happen only when changing of ISP.

How is your application going to differentiate between
site-local... oh wait, the application is going to need
to differentiate to some address space in some cases but
not all and clearly totally undefined. And you don't want
to go even near NAT. Otherwise you will have to fix up
all those protocols which carry IP addresses inside them.
One of the major contenders: H323.

If you imply NAT I think one can better stay at IPv4 where
you don't have end-to-end communications either. Which
was the reason otherwise that there are 128bits in the addresses?

> space, that may be very usefull for adressing nodes (e.g. an ISP
back-bone)
> that definitly do not need to be address from the outside.  

If you are an ISP you have a TLA with loads of /64's.
Use those and apply some firewalling & non-routing to
create *globally unique* non-routable address space.
So if you merge/connect on day you won't have to renumber.

Same goes for non-TLA holders, nobody claimed that
the assigned space should also be routed.

</repeat>

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Mar 2003 16:15:36 +0100

I think you're missing Alain's point. If a host happens to have 2 addresses
at a given moment, one left over from the disconnected state and one with
the recently available connected prefix, either address will work fine for
internal usage, and of course only the second one will work for external usage.

This does lead to DDNS and 2 face DNS, but that's where we are heading
in any case.

   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: "Jeroen Massar" <[email-masked]>
Date: Fri, 28 Mar 2003 16:25:52 +0100

Brian E Carpenter [mailto:[email-masked]] wrote:

> I think you're missing Alain's point. If a host happens to 
> have 2 addresses at a given moment, one left over from the
> disconnected state and one with the recently available
> connected prefix, either address will work fine for

That's indeed a different approach than what I had in mind.
And does indeed work as long as the 'disconnected prefix'
should never be mixed with another network ofcourse.
Thanks for the clarification.

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Sat, 29 Mar 2003 13:39:33 +0000

> This does lead to DDNS and 2 face DNS, but that's where we are heading

So is it actually having a recommended prefix for disconnected networks
that's the issue, or having special scope prrocessing for a specific prefix,
or both? :)   I think this is what Alain is indirectly asking/suggesting.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2003 09:57:25 +0200

> or both? :)   I think this is what Alain is indirectly asking/suggesting.

When IPv6 began, it was certainly the disconnected sites argument that
made me happy with site locals; but we hadn't thought through the scope
issues or the issues of intermittently connected sites, and both of those
are messy enough that I am now against site locals.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 31 Mar 2003 09:08:25 +0100

> are messy enough that I am now against site locals.

So, as Michel asked, what's the solution for intermittently connected sites
in the absence of site locals?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2003 11:46:51 +0200

> in the absence of site locals?

Well, I'd hoped to avoid that question until we had mailing list consensus
on deprecating SLs.

But since you ask, I think it has to be some form of GUPI prefix, plus of
course a PA prefix during periods of connection.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 31 Mar 2003 11:10:44 +0100

> Well, I'd hoped to avoid that question until we had mailing list consensus

I think (even) more people would back the deprecation of the specific 
"problem" cases can be addressed first.

Tim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 31 Mar 2003 13:38:45 +0300 (EEST)

> in the absence of site locals?

Route advertisements with long-enough lifetimes and fast-enough
_deprecation_ (when reconnecting) seems one approach to look at more 
closely, IMO.

-- 
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: "EricLKlein" <[email-masked]>
Date: Mon, 31 Mar 2003 15:44:40 +0300

> Well, I'd hoped to avoid that question until we had mailing list consensus

I would tend to say that we are a long way from consensus about SL's.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2003 17:15:10 +0200

> I would tend to say that we are a long way from consensus about SL's.

Tony's draft (http://www.tndh.net/~tony/ietf/site-local.txt) makes
a good case for globally unique provider independent addresses
with a non-routeability option. It would be interesting to know
if we have consensus about that.

IMHO it doesn't make a case for SLs in their present incarnation
(i.e. ambiguous address space). There is a lot of operational pain
in ambiguous address, once you start building VPNs between business
partners or otherwise merging "private" networks. I think we should
also seek consensus that ambiguous addresses are unacceptable.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 09:27:37 -0800

Pekka Savola wrote:
> Route advertisements with long-enough lifetimes and 
> fast-enough _deprecation_ (when reconnecting) seems one 
> approach to look at more 
> closely, IMO.

Rather than continue to send this nonsense, please look closely at it
because you will find that it is a seriously broken model. Deprecation
at reconnection will cause internal connections to drop. If you delay
the deprecation, connections to the site with the valid allocation will
not be possible. This is not a valid approach.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 09:42:56 -0800

Brian E Carpenter wrote:
> EricLKlein wrote:
> > 
> > Brian E Carpenter wrote:
> > > Well, I'd hoped to avoid that question until we had mailing list 
> > > consensus on deprecating SLs.
> > >
> > 

That is the understatement of the day...

> 
> Tony's draft (http://www.tndh.net/~tony/ietf/site-local.txt) 
> makes a good case for globally unique provider independent 
> addresses with a non-routeability option. It would be 
> interesting to know if we have consensus about that.

Keep in mind it was a quick hack from prior email, so there may be other
points that people want addressed.

> 
> IMHO it doesn't make a case for SLs in their present 
> incarnation (i.e. ambiguous address space). There is a lot of 
> operational pain in ambiguous address, once you start 
> building VPNs between business partners or otherwise merging 
> "private" networks. I think we should also seek consensus 
> that ambiguous addresses are unacceptable.

I agree ambiguous addresses are unacceptable for some purposes, but that
does not mean all uses are invalid. Maybe the real problem here is that
we only provide a site controlled address space that is ambiguous. If we
had a PI space, I believe there would be no need to argue about
keeping/deprecating the ambiguous space. It sounds like your issue is
with the logic about prefering the short /10. If we dropped the logic
and added a flag in the RA to indicate the prefix applications should
prefer to cover the intermittently connected case, would you still have
an issue with the ambiguous addresses existing?

Tony