Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing

From: Brian McGehee <[email-masked]>
Date: Tue, 1 Apr 2003 15:16:28 -0800 (PST)

NO -- Do not deprecate site-local unicast addressing

- Site-locals should be retained for disconnected sites.  If not SL, then
a mechanism needs to be adopted that can provide a private means of
selecting from a private address space that is "reserved" for this 
function.  2002 is not a working alternative.
- Site-locals should be retained for intermittently connected sites.
- Site-locals should be retained as a means for internal connections to 
survive global prefix renumbering.

- Other (please specify).  Continually changing the specs will only 
further alienate those that refuse to adopt.  Not offering equivalents to 
what exists today (rfc 1918) will accomplish the same.  (and do we really 
want to put all the NAT vendors out of business? ;-)  "Necessity drives ingenuity."

Brian McGehee
Native6, Inc.
www.native6group.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 [email-masked]
--------------------------------------------------------------------

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 12:53:04 +0200

> survive global prefix renumbering.

All of the above will make the address not unique.
Have fun merging your networks.

> further alienate those that refuse to adopt.  Not offering 
> equivalents to what exists today (rfc 1918) will accomplish the same.
> (and  do we really want to put all the NAT vendors out of business?
;-)  
> "Necessity drives ingenuity."

Here you are already levelling NAT with SL.
If you already intend to NAT, stay with IPv4, you will have the same
problems and still won't get back the end to end connectivity which
was one of the major things IPv6 was built for. Or we could just
do IPv6 with 32bits again...

Greets,
 Jeroen

---

From: "Brian McGehee" <[email-masked]>
Date: Wed, 2 Apr 2003 03:55:50 -0800

*Notes below

* I agree "NAT != SL"!   Except in the case that hosts need "global"
connectivity and they ONLY have  a SL address will require NAT.  Or they
should have a second IPv6 globally unique unicast address (which isn't that
hard to have multiple addresses???)

* I can envision an enterprise environment that is comfortable using
FEC0::/10 for internal communications but a host has a globally unique
address also for external communications (on hosts that have this
neccessity)  This could be comfortable to a network admin/ops/noc.

----- Original Message -----
From: "Jeroen Massar" <[email-masked]>
To: "'Brian McGehee'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 02, 2003 2:53 AM
Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local
Addressing)

> Have fun merging your networks.

* Anyone that has had to merge 2 very large networks will know the great
amount of design, architecture, and planning that has to go into such a
project.  It's not as easy as changing "a DHCP range" or a "handful of RAs"
even if they were Globally unique IPv6 (or globally unique IPv4 addresses).
I agree that IPv6 stateless Auto-Config adds a lot of room to make this an
easier process but it doesn't solve the unique problems that come up in
merging two large enterprise networks.

* Yes.  There is the chance that SL will "overlap" in a situation of merging
two IPv6 enterprise networks.  But if we don't offer SL.  What will people
choose for private addressing?  I would REALLY like to see an alternative to
SL that maybe provides for a set of bits that relate to Geography?  ISP?
etc?  I'm open to other suggestions.  But without an alternative I have to
vote "NO".  Let's see some alternatives?  Please, again!=> Let's not
alienate those that are already afraid of change by "changing" things.

> do IPv6 with 32bits again...

* Yes if anyone chooses to do NAT.  They should have that option, and an
IPv6 address space to appropriately use for such functionality [it's a
feature, not a bug](some people feel strongly that NAT is a security
feature).

* Again we shouldn't "take away" from what is already there.  From what
people are comfortable with!  I am not a proponent of NAT (bottlenecking,
added administration, etc...)  but we need to continue to support
environments that exists today.  If a company decides to incorporate NAT in
their firewall(s) (or even NAT-PT/NAPT-PT), well let's let them!  We've
introduced these ideas in IPv4, they exist today.  The current "IPv6 RFC's"
and "IPv6 literature" document this continued support clearly (FEC0::/10).
Constantly changing the standards scares "people" away from adoption.  Do we
really want to make such a drastic change.  (I'm still trying to deal w/ the
deprecation of A6 records.  They worked GREAT in renumbering!)  Yes.  IPv6
offers 340 undecillion (or sextillion depending on where your from)
addresses.  Enough to address every device in the world.  Great.  But we
need to offer all the functionality that exists today.  They exist for
reason (besides just lack of address space.  Some people feel
secure/comfortable behind NAT!)  ...my $.02

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 14:14:44 +0200

Brian McGehee [mailto:[email-masked]] wrote:

> connectivity and they ONLY have  a SL address will require 
> NAT.  Or they should have a second IPv6 globally unique unicast
address 
> (which isn't that hard to have multiple addresses???)

Use a firewall to block incoming packets.

> neccessity)  This could be comfortable to a network admin/ops/noc.

Then don't route a certain prefix.

> * Anyone that has had to merge 2 very large networks will 
> know the great amount of design, architecture, and planning
> that has to go into such a project.  It's not as easy as
> changing "a DHCP range" or a "handful of RAs" even if they
> were Globally unique IPv6 (or globally unique IPv4 addresses).
> I agree that IPv6 stateless Auto-Config adds a lot of room to 
> make this an easier process but it doesn't solve the unique
> problems that come up in merging two large enterprise networks.

If they are globally unique, one doesn't HAVE to renumber.
And indeed the problems of renumbering lie in configuration items
not in the network numbering itself.

> * Yes.  There is the chance that SL will "overlap" in a 
> situation of merging two IPv6 enterprise networks. 
> But if we don't offer SL.  What will people
> choose for private addressing?  I would REALLY like to see an 
> alternative to SL that maybe provides for a set of bits that
> relate to Geography?  ISP?
> etc?  I'm open to other suggestions.  But without an 
> alternative I have to vote "NO".  Let's see some alternatives?
> Please, again!=> Let's not alienate those that are already
> afraid of change by "changing" things.

A central registry where one can obtain unique disconnected
space per /48.

> * Yes if anyone chooses to do NAT.  They should have that 
> option, and an IPv6 address space to appropriately use for
> such functionality [it's a feature, not a bug](some people
> feel strongly that NAT is a security feature).

If you intend to do it then just stay with IPv4 without
end-to-end connectivity and don't drag down the rest of us.

> * Again we shouldn't "take away" from what is already there.  
> From what people are comfortable with!  I am not a proponent
> of NAT (bottlenecking, added administration, etc...)  but we
> need to continue to support environments that exists today.
> If a company decides to incorporate NAT in their firewall(s)

"Look mom he said NAT and firewall in one sentence"

> (or even NAT-PT/NAPT-PT), well let's let them!  We've
> introduced these ideas in IPv4, they exist today.

They didn't pay with money a very long time ago.
Should we now all go exchange eggs, chicken and wild
beast again as a currency?

That's called evolution. There is no need for NAT which
is apparently the sole reason you want SL.

> The current "IPv6 RFC's" and "IPv6 literature" document this
> continued support clearly (FEC0::/10).

And people have realized that it was a mistake and want to
clear that mistake up before it starts to hurt hard.

> Constantly changing the standards scares "people" away from 
> adoption.  Do we really want to make such a drastic change.
> (I'm still trying to deal w/ the deprecation of A6 records.
> They worked GREAT in renumbering!)

If you have a real use for A6, just like A6, then document
it and bring it forward, thats where these WG's are all about.

> Yes.  IPv6 offers 340 undecillion (or sextillion depending
> on where your from) addresses.  Enough to address every
> device in the world.  

Indeed so where did we need SL for again? To NAT????

> Great.  But we need to offer all the functionality that
> exists today.  They exist for reason (besides just lack
> of address space.

And which reasons where that again, I don't recall you
mentioning ANY reason here that doesn't relate to NAT.
Again, if you want NAT, then stick to IPv4.

>  Some people feel secure/comfortable behind NAT!)
>  ...my $.02

You should not feel secure behind a NAT. NAT has nothing
to do with security. Not routing a prefix somehow has though.

Apparently you have no other need for SL than to NAT.
I rest my case.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 08:25:52 -0800

> Use a firewall to block incoming packets.

Brian is right, having a second prefix is what they should do. 

> Then don't route a certain prefix.

Using filtering on a single global prefix does not work when nodes that
need external access are on the same segment with those that shouldn't
have it. Prefix filtering is the answer, but the prefix to filter is
FEC0::/10.

Tony 

> > > > - Site-locals should be retained for disconnected 
> sites.  If not 
> > > > SL, then a mechanism needs to be adopted that can provide a
> > private means of
> > > > - Site-locals should be retained as a means for internal 
> > > > connections to survive global prefix renumbering.
> > >
> And indeed the problems of renumbering lie in configuration 
> items not in the network numbering itself.
> 
> > > was one of the major things IPv6 was built for. Or we 
> could just do 
> > > IPv6 with 32bits again...
> > 
> > The current "IPv6 RFC's" and "IPv6 literature" document 
> this continued 
> > support clearly (FEC0::/10).
> 
> device in the 
> > world.
> exists today.  
> > They exist for reason (besides just lack of address space.
> 
> mentioning ANY reason here that doesn't relate to NAT. Again, 
> if you want NAT, then stick to IPv4.
>

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 18:31:59 +0200

> Brian is right, having a second prefix is what they should do. 

Could do, it's another solution to their problem.

> have it. Prefix filtering is the answer, but the prefix to filter is

Any rationale why it should be fec0::/10 and not just a prefix
picked by the administrator from the /48 they already have?

Firewalling is firewalling, even if one filters fec0::/10 or
2001:db8::/32
it doesn't change a bit in implementation or use.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 08:43:29 -0800

Jeroen Massar wrote:
> > > ...
> Any rationale why it should be fec0::/10 and not just a 
> prefix picked by the administrator from the /48 they already have?
> 
> 2001:db8::/32 it doesn't change a bit in implementation or use.

Yes it does. Clearly all you are thinking about is the firewall end of
the issue, where it really doesn't matter. If the prefix is not
well-known, it has to be manually configured into the devices that need
to use it. If the site changes /48's, that means touching every one of
those devices again. This is a non-starter for most system managers.
They will use FEC0 & NAT if this is the solution proposed to them.

Tony

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 18:57:35 +0200

> They will use FEC0 & NAT if this is the solution proposed to them.

I am not thinking about the firewalling end, I am thinking
about why the heck did we change the address space to 128bits
if the IP's are still not globally unique, which SL imply.
Fortunatly Andrew White just pointed out these two:

draft-hinden-ipv6-global-site-local-00.txt
draft-white-auto-subnet-00.txt

And I do see a future in these, but not in the current setup for SL.
See "RE: alternatives to site-locals?"
Message-Id: <[email-masked]>

Greets,
 Jeroen

---

From: "Brian McGehee" <[email-masked]>
Date: Thu, 3 Apr 2003 10:19:37 -0800

----- Original Message -----
From: "Jeroen Massar" <[email-masked]>
To: "'Brian McGehee'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 02, 2003 4:14 AM
Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local
Addressing)

> Then don't route a certain prefix.
Which prefix?  SL Prefix?  Where is the alternative?