>>>>> On Thu, 31 Oct 2002 19:38:46 -0500, 
>>>>> Margaret Wasserman <[EMAIL PROTECTED]> 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 PROTECTED]

--- Begin Message ---
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 PROTECTED]
--------------------------------------------------------------------
--- End Message ---

Reply via email to