Subject: Re: Node Requirements Issue 3

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Nov 2002 20:53:58 +0900

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

>> 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.

> 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

Please let me check, what is the goal of "this" BCP?

1. to discourage the use of SLs except in non-globally-connected
   networks, as you proposed before (attached)
2. to describe issues on using SLs without any limitation on the usage
   (i.e. it covers the case for globally-connected networks)

If we take the position 1 at this stage, we'll just see the same
discussion we've had so far on the document, and will go into the same
loop.  So, the document should be careful to be fair enough, at least
for now, and, IMO, should take the position 2.  Of course, we'll then
be able to take the decision of discouraging (or keeping) SLs, if the
fair document can convince the majority of the group.

If we're going to take the fair position for the moment, I'm willing
to help the effort in some areas.  I guess I can do something on DNS
(and perhaps applications.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Subject: RE: Limiting the Use of Site-Local
From: Margaret Wasserman <[email-masked]>
To: "Michel Py" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 28 Oct 2002 20:06:12 -0500

I have heard several arguments for why people might like
to use some sort of limited-scope addressing in special
circumstances.  I've also heard a couple of general benefits
(long-lived connections and dubious security benefits).

But, I haven't really heard any arguments that have swayed
me from my original position.

Private addressing causes significant complexities, and we
don't know how to solve all of the problems that it causes
for applications, DNS, routing protocols and network
management protocols.

Therefore, I don't think that we should define it as an
inherent part of IPv6.

There may be some significant advantages to private addressing,
so I _do_ support the idea of an IRTF WG being formed to sort
out the issues surrounding private addressing and make
recommendations regarding what the IETF should/shouldn't
standardize in this area.  I also think that an IAB document
in this area would be appropriate.  But, I don't want to see us
standardize a badly-thought-out private addressing scheme
at the core of IPv6.

In my opinion, there are three possible choices here:

	(1) Limit the scope of the IPv6 WG's problem, by
		forbidding the use of site-local addresses
		on globally-connected networks in the
		scoped addressing architecture.  This would
		not preclude work in this area by other
		groups within the IETF/IRTF, and we could
		remove the restriction when the implications
		are fully understood.

	(2) Develop a complete solution for scoped unicast
		addressing within the IPv6 WG.  This would
		include solving the problems they cause for
		all protocols/layers.

	(3) Define an IP-level solution for scoped addressing
		(similar to what is currently in the scoped
		addressing architecture), and consider all
		of the implications of that architecture on
		other protocols/layers to be someone else's
		problem.

The first choice is both responsible and doable.

I have deep concerns about the second choice, along two lines:
(1) I think it is important that we stabilize and complete IPv6
quickly, as folks are widely implementing and deploying it, and
(2) I don't know that we have the expertise (in the IPv6 WG or
anywhere in the IETF, without further research) to solve these
problems.

And, in my opinion, the third choice (which is what we seem to
be doing so far) is blatantly irresponsible.

Are there people who want to argue for choices #2 and/or #3?
Or are there other choices that I've left out?

Margaret

--------------------------------------------------------------------
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: Sat, 2 Nov 2002 17:56:07 +0100

>>> => 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.
>>
>> 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.
>
> => I don't disagree with that, but I don't
> see the relevance to my statement.

Well, my point was that operators might want to influence the network 
admins to go for no-NAT as they want to sell peer-to-peer services and 
that is one of the few drivers for operators to go to IPv6.

>
>>> => 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....
>>
>> This are all services / functions I could do in IPv4 as
>> well. Perhaps
>> not with the IPv4 address header though.
>
> => I'll be very interested in seeing a proposal on
> secure ARP, MIPv4 RO or the final Zeroconf solution
> for IPv4 autoconf....

I am not saying you can take all the protocols of IPv6 and transfer 
them to IPv4. I am saying you can achieve the same level of 
functionality in v4.

>
>>> If you choose to use SL with globally routable addresses
>>> 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 don't want it, don't use it. No one is
> suggesting that every site must use them.

No, but when I come up with the peer-to-peer service pidgins-over-IP, I 
will not be able to sell it to a (most likely) large part of the 
Internet connected enterprises as they are behind IPv6 NATs. They 
started out with networks that where not connected to the public 
Internet, got the site-locals, there friendly consulting company sold 
them a firewall, convinced them they where much safer if they stayed 
with the site-locals and bought the software-add-on license for 
IPv6-NAT.....

Does the story sound familiar? That enterprise is now waiting for the 
release of the pidgins-over-IP (or SIP or any other new protocol) proxy 
update for their firewall.....

>
>
> If you give people
>> a tool -
>> they will use it, and eventually someone will hurt
>> themselves with it.
>
> => I don't think so. People will do what they want
> with whatever addresses they invent. Network admins
> are not kids. They are convinced  that (in some cases)
> they need certain features. They will get there one

No. Network admins will buy what the latest marketing story in Packet 
Magazine or some IDG paper says. I am sorry - that is the way it works. 
Not for all, but for many. How many network admins do you think is 
following this discussion and understand the different concepts?

> way or another. You might disagree with their reasons
> or arguments, but there is no decision we take here
> that will change their minds immediately.

Here I agree. But that does not mean that we should not learn of the 
past. IPv6 has many flaws - mainly in that it does not address some of 
the more urgent problems on todays Internet besides address shortage. 
We have a window of opportunity to fix a lot of other things that where 
bad about IPv4. Let's be open minded and try and do that. Let's not 
blindly try and copy IPv4 with us.

>>
>> I have still to see an argument as to what there is with SLs that I
>> can't do with globaladdresses?
>
> => Well, if after reading all the mails you still
> think so, don't expect one from me :)
>

I am more worried that people are starting to give up on the discussion 
because it's locked....

- kurtis -