Subject: Re: Enforcing unreachability of site local addresses

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 2 Dec 2002 12:52:50 +0100

> My memory of the discussions accords with the summary given by Keith
> above.  In addition, the general tenor of the discussion indicated to 
> me
> that the two issues were linked: that consensus on limiting site-locals
> was contingent upon initiation of an effort to design a workable scheme
> for privately-routable PIs, with the global routing of PIs left for
> subsequent discussion.

So the remaining question besides the PI issue would be to define 
"limit" then?

- kurtis -

--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Mon, 02 Dec 2002 07:39:49 -0500

At 12:52 PM 12/2/2002 +0100, Kurt Erik Lindqvist wrote:
>>above.  In addition, the general tenor of the discussion indicated to me
>So the remaining question besides the PI issue would be to define "limit" 
>then?

I had proposed limiting the use of site-locals to completely isolated
networks (i.e. test networks and/or networks that will never be
connected to other networks).  This would give administrators of
those networks an address space to use (FECO::/10) for those networks
that wouldn't conflict with anyone else's and could be filtered by ISPs,
etc. (in case anyone ever makes a mistake and connects an "isolated"
network to the Internet).  This is actually what site-local addresses
(and RFC 1918 addresses) were originally invented for...

If we limit site-locals to this case, they can be treated _exactly_ like
globals in all implementations (since they will be global to any network
where they should be used), and all BGP routers could ship with a default
filter to block propagation of these routes (which the administrator
would have modify in the unlikely event that he wanted to use BGP in
his completely isolated network).

I'm working on a draft that explains why I believe that site-locals
need to be limited to this extreme, and that draft will provider further
details of the proposal.  I'm actually NOT proposing any automatic
mechanism to enforce this restriction, as I just think that makes
implementations larger and more cluttered.

This was the "limited usage" model discussed at the Atlanta meeting.

There was also a "moderate usage" proposal put forth by Bob Hinden in
the meeting, which would allow the use of site-local, but would not
allow sites to border each other (site-local addresses would be
filtered in firewalls).  The details of this model haven't been
documented in detail, but it has the advantage that it would allow
the use of site-locals on intermittently connected networks (ones that
may not always have global addresses available from their ISP, or where
their ISP-provided addresses may change on each connection).

The WG had consensus to limit the use of site-locals to one of these
two proposals, but we were pretty much split down the middle between
them.  One of the issues, I think, is that neither one was well-enough
documented for people to understand the details.  So, I'm working on
documentation for the "limited usage" proposal.

Bob, are you or anyone else working to document the "moderate usage"
proposal?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Dec 2002 14:53:00 +0200 (EET)

> his completely isolated network).

I don't think site-locals are special enough to be specifically disallowed 
by default in BGP.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Bob Hinden <[email-masked]>
Date: Mon, 02 Dec 2002 11:30:11 -0800

Margaret,

>Bob, are you or anyone else working to document the "moderate usage"

Yes, I am working on a "moderate usage" draft.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 02 Dec 2002 11:30:11 -0800

Margaret,

Bob

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Dec 2002 14:53:00 +0200 (EET)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 3 Dec 2002 20:31:04 +0100

> (and RFC 1918 addresses) were originally invented for...

Well, even though I still think that this will create more problems 
that it solve, it would at least keep that current state (which is 
pretty bad though).

> globals in all implementations (since they will be global to any 

In implementations - yes. For application layer protocols like IP-Sec, 
VoIP, SIP etc they still have the potential to create problems if 
misused (and they will be)

> implementations larger and more cluttered.

What I would like the chairs to do is go and ask the applications area 
to write a draft on the impact on applications of SLs, GUPIs, GULS and 
"real" IPs.

- kurtis -

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 02 Dec 2002 07:39:49 -0500

Margaret

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 2 Dec 2002 12:52:50 +0100

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Dec 2002 16:42:00 +0100

> those networks an address space to use (FECO::/10) for those networks

The first question that comes to mind here then is - why would we need 
a /10 for this? That more than the currently totally allocated address 
space....

> (and RFC 1918 addresses) were originally invented for...

Yes, but that didn't really stop anyone....

> his completely isolated network).

The problem I see (and have been beaten to death here) is that people 
WILL connect them to the Internet. We have applications that can't  
handle this and that will break, and we will have really hard times 
implementing them.

> need to be limited to this extreme, and that draft will provider 

The above said - I will agree with you. Personally I think that we 
should use the opportunity of IPv6 to fix some of the design flaws of 
IPv4. One of them is that the shortage of address space led us to 
create RFC1918. We have the opportunity fix this, but there are to many 
people out there who don't see this as a benefit. As applications that 
don't work across NATs they will becomes more popular this will change 
- I remember having a discussion with a VPN customer who was telling me 
that a great invention NATs was. He then realized that buying VOIP 
transit from us would have saved him quite a lot of money, but he of 
course could not get that as he was behind a NAT. I guess they are 
still trying to figure out to get rid of it...

Anyway, although I don't like what you suggest above - I think it is 
the only think that we can get some sort of consensus for and move on. 
But I think that we need to learn from the RFC1918 mistake and make 
sure we include a enforcement method.

> implementations larger and more cluttered.

Probably, but see above.

> their ISP-provided addresses may change on each connection).

Well, to me the intermittently connected networks are covered above. If 
they have no network access, fine. If they do, they don't need SLs. 
Actually, what I am missing is why they couldn't use link locals when 
off-line, but never mind.

> two proposals, but we were pretty much split down the middle between

Wait - to ONE of them?

- kurtis -

---

From: "Digambar Rasal" <[email-masked]>
Date: Mon, 9 Dec 2002 16:42:32 +0530

Hi,

we are process of changing network to Ipv6 and looking for switches and
routers those are supporting Ipv6 or Ipv6 and Ipv4 . If anybody has idea
about it please let me know

Digambar  Rasal
Controlnet India Pvt Ltd
Verna Goa.

---

From: Mark Smith <[email-masked]>
Date: 09 Dec 2002 22:34:39 +1100

This page should be a good place to start :

http://www.ipv6.org/impl/index.html

---

From: "Sivaramakrishnan A" <[email-masked]>
Date: Mon, 9 Dec 2002 17:35:47 +0530

Our IPv6 supports Router functionality for platforms like 
VxWorks, QNX, OSE, etc... Please have a look at www.futsoft.com
~sivaram

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Digambar Rasal
Sent: Monday, 9 December 2002 4:43 PM
To: [email-masked]
Subject: Ipv6 enabled Switches and routers !

Hi,

Digambar  Rasal
Controlnet India Pvt Ltd
Verna Goa.

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Mon, 09 Dec 2002 09:09:23 -0500

>The first question that comes to mind here then is - why would we need a 
>/10 for this? That more than the currently totally allocated address space....

The /10 has been allocated for the purpose of "site-local" addressing
in the addressing architecture for years -- at least since 1995.  There
are already lots of implementations that know something special about these
addresses -- they are ambiguous and need a zone ID to fully qualify them,
and they are not to be forwarded outside "site" boundaries).

The use of these addresses, however, has not been fully defined in any
IPv6 specification, and the definition of a "site" is unclear.  The
scoped addressing architecture I-D is attempting to define the use of
these addresses, and we are currently trying to figure out what it should
say...  We have consensus to limit the use of these addresses in some
way, and we are working to determine a complete plan.

Regardless of what administrative or technical restrictions we place on
the use of these addresses, though, we are pretty much stuck with the /10
allocation of "site-local" addresses.  We can't reasonably reuse that
space for global-unique PI addresses (or any other global addresses),
because of the treatment that these addresses will receive from existing
implementations.

>Yes, but that didn't really stop anyone....

I know.  And, it will probably be very tempting for people to use these
addresses behind IPv6 NAT boxes, like in IPv4.

In my opinion, the only way that we will stop people from using NAT
(with or without IPv6 site-local addresses) will be to provider better
(architecturally cleaner, more convenient, more functional) mechanisms
for people to get the same benefits that they get from NATs today.
Although NATs may have started as a response to address space shortage,
today their use is driven by the needs for provider-independent addressing
and convenient access control.  So, we need to work on better ways to
provide those things in IPv6.

We also need to understand and document how a network operator could
reasonably run an operationally sound and secure network using global
IPv6 addresses and IPv4 NAT side-by-side.  There are a number of subtle
problems caused by this configuration, and we need to understand those
issues and educate network operators, enterprise operators, in particular,
about how to properly set-up a shared IPv4/IPv6 network.  That is one
of the major roles of the v6ops WG, BTW.

>The problem I see (and have been beaten to death here) is that people WILL 
>connect them to the Internet. We have applications that can't

Yes, you are probably right, but I think that the only way that we can
fight this is by providing _better_ solutions to the problems, and by
trying to educate people about how to deploy those solutions into
existing networks.

>The above said - I will agree with you.

Good, because I agree with you, too.

>Anyway, although I don't like what you suggest above - I think it is the 
>only think that we can get some sort of consensus for and move on. But I 
>think that we need to learn from the RFC1918 mistake and make sure we 
>include a enforcement method.

What sort of enforcement method would you suggest?

>>two proposals, but we were pretty much split down the middle between

We had three largish groups -- the folks who wanted to eliminate site-local
addresses from the architecture altogether, the folks who wanted to limit
site-locals to disconnected networks (the "limited usage" case) and the
folks who wanted to limit site-locals to sites that don't touch other
sites (the "moderate usage" case).  We were able to get consensus in the
room that we should limit the use of site-locals in some way, and that we
should further document both the "limited usage" case and the "moderate
usage" case, and try to figure out the right choice -- which may be one
of those cases, or something in between, I suppose.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Dec 2002 10:05:06 -0500

> sites (the "moderate usage" case).

As I said at the meeting, I don't think that way of dividing things was
particuarly useful, nor do I think the categories were defined with enough 
precision to allow people to be sure what group they were in.

However I did interpret the shows of hands as consensus that use of 
site-locals should be limited in some way.  

Ketih

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Dec 2002 17:37:03 -0800

Margaret,

>provide those things in IPv6.

I am not sure that this is really true.  When I was looking for a new DSL 
provider I found that in many cases I could get service at a specific 
bandwidth with a singe address for about $60 a month.  If I wanted a /29 
instead, it would cost about $30 more a month.  50% more for 6 usable 
addresses!  I think this is fairly common.  The lower cost DSL providers 
doen't even give the user to choice to get more addresses.  People are 
still being forced to run NAT in response to address scarcity.  We could 
only tell for sure if people would still run NAT for other reasons if 
addresses were readily available.

I ended up finding a different ISP who charged more money, but gave me more 
bandwidth and the addresses I wanted.  Most people would not be willing to 
do that and would be forced to run NAT.

Bob

---

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

> provide those things in IPv6.

I think that there are multiple ways to try and move users to another 
direction. One is that when there are enough interesting applications 
that the NAT users can't use because of NAT, they will start looking 
around. So I think we need to stop creating special cases so 
applications and functions will work through NAT boxes. This also goes 
for the transition mechanisms to IPv6.

Second, we need to document the negative sides of NAT on applications, 
as well as ways to achieve the same benefits you mentioned from NAT in 
other ways.

>> the only think that we can get some sort of consensus for and move 
>> on. But I think that we need to learn from the RFC1918 mistake and 
>> make sure we include a enforcement method.

Well, a first start is to have routers to not route these by default, 
or preferably not at all. Including them as a MUST filter prefix might 
also be a good idea. In principal any method we can come up with that

a) Don't distribute reachability information
b) Enforce packet filtering as default

is a step in the right direction.

- kurtis -

---

From: "Alan E. Beard" <[email-masked]>
Date: Thu, 19 Dec 2002 14:03:19 -0500 (EST)

Kurt:

First, my apologies for the delayed reply.  Response inline.

AEB

> So the remaining question besides the PI issue would be to define
Perhaps my use of the term "limit" was a bit ambiguous.  I intended this
to refer to the proposal, agreed to at the Atlanta IETF, to restrict the
use of site-local addressing to within the boundaries of the local site;
specifically, to prohibit the use of site-local addressing for transport
or end-system addresses for any traffic which leaves the boundary of the
site.  Given the concensus at IETF 55 on this matter I hadn't imagined
that further definition should be necessary, but the wording of my text
was admittedly less than perfectly clear.

Regards,

AEB

> - kurtis -

Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529