[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving forward on Site-Local and Local Addressing



I think there is a small but important, difference here between what PI and limited-range can provide.

1) PI needs some kind of registration process.
2) Limited-range can be an automatic process.

It seems to me that 2) make sense in small networks, like unmanaged networks, where you will not ask the customers to go for 1.

Anyway, as it was pointed already in Vienna, there is, may be, a chance to have both 1 & 2, being a complementary solution.

Regards,
Jordi

----- Original Message ----- 
From: "Michael Thomas" <mat@cisco.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>
Cc: "Bob Hinden" <hinden@iprg.nokia.com>; <ipng@sunroof.eng.sun.com>; <gih@telstra.net>
Sent: Monday, August 04, 2003 11:38 PM
Subject: Re: Moving forward on Site-Local and Local Addressing


> 
> FWIW, I wasn't there but I agree with Alain. I've
> never seen any compelling evidence that scope qua
> scope is what people actually need. And scope
> brings any number of architectural questions to
> the fore. I'd be much, much more comfortable
> having an up/down pronouncement on whether PI
> addressing is feasible before we march down this
> road. There are very wide implications of both and
> I think there's a tremendous amount of discomfort
> with the possibility that scope will result in a
> back door for NAT's to invade ipv6. I don't think
> that anybody wants that. Before we head that
> direction, I'd like to see PI addressing, in an
> RFC preferrably, pronounced a dead end.
> 
> Mike
> 
> Alain Durand writes:
>  > 
>  > 
>  > Bob Hinden wrote:
>  > 
>  > > [IPv6 working group chair hat on]
>  > >
>  > > I think the working group has been making good progress on replacing 
>  > > site-local addresses and wanted to get feed back from the working 
>  > > group on how we should move forward.  This is not intended to directly 
>  > > relate to the ongoing appeal of the working groups decision to 
>  > > deprecate the usage site-local addresses, but to get feedback on how 
>  > > to proceed.  I think it is very important that we move forward on this 
>  > > issue and not rehash what has happened in the past.
>  > >
>  > > We now have a combined local addressing requirements document 
>  > > <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative 
>  > > to site-local addresses draft 
>  > > <draft-hinden-ipv6-global-local-addr-02.txt> (accepted as a working 
>  > > group item at the Vienna IETF), and will soon have a draft describing 
>  > > why site-local addresses are being deprecated and doing the formal 
>  > > deprecation (authors identified and outline discussed at the Vienna 
>  > > IETF).  Note that all of these documents will proceed through the 
>  > > normal working group and IETF processes of last calls and review.
>  > >
>  > > I think legitimate questions have been raised about how the working 
>  > > group should go about deprecating site-local addresses given their 
>  > > maturity in the current specifications and use in deployed products.  
>  > > Specifically should they be deprecated independently from having an 
>  > > alternative solution available, at the same time an alternative is 
>  > > available, or sometime after an alternative is available.  A forth 
>  > > alternative is to not replace site-local addresses in any form, but I 
>  > > think the working group has made it clear that this is not a 
>  > > reasonable alternative. 
>  > 
>  > I have a real problem here. As I commented in Vienna and is mentioned in 
>  > the minutes,
>  > the entire process this wg is going through is wrong as it is based on a 
>  > flawed logic.
>  > 
>  > We had site local addresses. After lengthy debates, the wg realized that 
>  > there were
>  > a number of significant issues that outweighed the reported benefits, so 
>  > there
>  > is an attempt to deprecate them. Until now, fine.
>  > 
>  > Now, some people convinced the wg that SL addresses were having a role
>  > that is not fulfilled by provider aggregated addresses. Fine again.
>  > 
>  > Then, we have a  'requirement' document that pretend to explain why we need
>  > 'local' addresses. If you read it carefully, and as acknowledged by one 
>  > of its main
>  > author in Vienna, almost all of those requirements (if not all) would be 
>  > fulfilled
>  > by provider independent addresses. Actually, there is nothing in it that
>  > explain why we need 'local range' addresses. The essence of those
>  > requirements is in the need for stable addresses that are
>  > independent from ISPs.
>  > 
>  > So using this document (I checked the new combined one, it is the same 
>  > issue)
>  > to justify introducing "local" addresses and doing so without clearly
>  > understanding the impact of those "ranged" addresses on the architecture
>  > and the current implementation is a flawed process.
>  > In particular, we need to understand the impact on address selection,
>  > and the layer violation that would be created by coupling DNS views & 
>  > routing.
>  > 
>  > IMHO, what need to happen is the following:
>  > 
>  > -1. Make an in-depth study of the consequences of introducing
>  >       addresses with different ranges.
>  > 
>  > -2. Realize that if the issue at stake here has more to do with getting 
>  > addresses
>  >       than with their actual scope/range, something probably can be
>  >       done working with the registries. It might be a cheaper path
>  >       than changing the protocols. After all, IPv6 addresses are plentiful,
>  >       we should have easy access to them!
>  > 
>  > What to do with Site Local addresses in the meantime is a non issue for me.
>  > 
>  >     - 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 majordomo@sunroof.eng.sun.com
>  > --------------------------------------------------------------------
> --------------------------------------------------------------------
> 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 

*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line at:
http://www.ipv6-es.com


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------