Subject: RE: Node Requirements Issue 3

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 31 Oct 2002 23:52:21 +0100

> > of course, just because there are implementations of SL and that 
  > > customers
  > > have bought those implementations doesn't mean that 
  > widespread use of 
  > > SLs
  > > is something that IETF should endorse.
  > 
  > For what it's worth I agree. If we now specify a RFC1918 
  > like structure 
  > for IPv6, we will be faced with people doing NAT like 
  > structures -  for 
  > whatever reason, and a lot of what is considered the drive 
  > for IPv6 is 
  > gone.

=> Why is it gone ? Not everyone wants NATs and for those who
do, deprecating SL addresses will not help. It will just make
their (Network admins) behaviour less predictable.

  > 
  > I have long argued that IPv6 only contribution to networking is a 
  > increase in addressing space - there is nothing I can do on 
  > IPv6 that I 
  > can't do on IPv4. 

=> Yes there is. The address size itself allows to do things 
that you can't do with v4. Check out the SEND WG for example
or MIPv6, or address autoconf....

A lot of people have then told me that IPv6 would 
  > help with peer-to-peer communications. With SL this is 
  > gone. 

=> Obviously, if you choose to use SL for a disconnected
network you're not interested in P2P on a global level.
If you choose to use SL with globally routable addresses
in the same network, you can get P2P.

Even if 
  > there might be reasons for a site to not need globally unique 
  > addresses, the problem is that at some point in the future 
  > that device 
  > will be on the net, and instead of renumbering, someone 
  > will do IPv6 
  > NAT and the peer-to-peer/end-to-end models are gone. I agree that I 
  > don't think the installed base is a problem. If the small 
  > installations 
  > we have now is a problem, the problem of renumbering these 
  > sites with 
  > global addresses is not going to become smaller.
  > 
  > History will repeat it self.

=> i don't know why some people try to resist existing 
facts. If you can't change it accept it and try to make 
the best out of it, i.e. write a BCP to tell people 
about the consequences of certain actions. Any attempt
to change the world by deprecating SLs is an exercise
in futility. Much better to educate people and hope that
in time we will reduce the number of myths on the net. 

Hesham
--------------------------------------------------------------------
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: Fri, 1 Nov 2002 00:30:33 +0100

> their (Network admins) behaviour less predictable.

Maybe, but from a operator point of view, the advantage of being early 
on IPv6 is to enable your users to do peer-to-peer services. There are 
no new services I can launch just because I give out IPv6 address, on 
the contrary. There is most likely a higher cost involved.

> or MIPv6, or address autoconf....

This are all services / functions I could do in IPv4 as well. Perhaps 
not with the IPv4 address header though.

> network you're not interested in P2P on a global level.

At least not when I make that choice. That is how a lot of networks 
with RFC1918 space started out.

> in the same network, you can get P2P.

If I have globally routeable addresses in the first place to identify 
my network devices, why would I want SL? If you give people a tool - 
they will use it, and eventually someone will hurt themselves with it.

> facts. If you can't change it accept it and try to make

I am not resisting facts. I am trying to argue that we should learn 
from mistakes. There are people who are using RFC1918 space today and 
are happy with it. There also a number of large organizations that have 
it and are very limited by it. I don't want us to give out tools with 
instructions for people with warnings on them. If they are dangerous we 
should not give them out at all.

> in time we will reduce the number of myths on the net.

I have still to see an argument as to what there is with SLs that I 
can't do with globaladdresses?

- kurtis -

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 18:40:40 -0500

>   > like structure for IPv6, we will be faced with people doing NAT like 
>   > structures -  for whatever reason, and a lot of what is considered the drive 
>   > for IPv6 is gone.
> 

it's not the case that NATs only affect networks that use them.
widespread use of NATs makes the market for some kinds of apps
so small, and the circumstances under which they can be used
so difficult to recognize, that those apps essentially cannot
be made commercially viable - at least not without adding
a huge amount of overhead and complexity in the form of 
proxies and/or centralized servers, an doing addressing and
routing internal to the app.

similarly, it's not the case that SLs only affect networks that
use them if SLs are widely used.

> in the same network, you can get P2P.

presuming of course that the globally routable addresses
are usable by any node that needs them.

>   > Even if there might be reasons for a site to not need globally unique 
>   > that device will be on the net, and instead of renumbering, someone 
>   > will do IPv6 NAT and the peer-to-peer/end-to-end models are gone. 
>   > I agree that I don't think the installed base is a problem. If the small 
>   > installations we have now is a problem, the problem of renumbering these 
>   > sites with global addresses is not going to become smaller.
>   > 

SLs were not carved in stone by the hand of God and brought down from the mountain. 
They can indeed be deprecated, though I don't see much support for doing that.
They can also be discouraged.    A BCP that discourages uses of SLs except
in certain narrow cases and explains why is probably more useful than a 
BCP that tries to explain exactly when SLs cause problems and when they don't.
Of course, it's quite possible to have both.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 31 Oct 2002 19:38:46 -0500

>A BCP that discourages uses of SLs except

I just happen to have a somewhat incomplete document lying around
that I think could be an excellent start for this BCP.

Unfortunately, we're past the -00 draft deadline, so I can't
post it, but I will try to finish it up and post it after Atlanta.

Who would like to help me fill in the missing pieces?  I could
particularly use some help documenting the issues that site-locals
cause for:

         - Applications
         - Security Protocols (and security issues in general)
         - Transport Protocols (particularly the voice/session stuff)
         - DNS

Keith, can I sign you up to help with applications?

I think I have a good handle on the routing and network management
issues, and some general issues.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 20:04:00 -0500

> Keith, can I sign you up to help with applications?

absolutely.