Michel,

I don't recall that we ever promised to support scoping of unicast
addresses. RFC 1752 refers to the scope field in multicast addresses,
which I certainly don't propose to abolish.

I don't see why the lack of explicit scope for IPv6 unicast is an
inhibitor. Satisfying the Hain/Templin requirements is necessary,
but that is orthogonal.

   Brian

Michel Py wrote:
> 
> Brian,
> 
> > Brian E Carpenter wrote:
> > I think we'd be better off to simply forget
> > about address scope.
> 
> At last, the real question.
> 
> Well, this could be both the best thing we could do for IPv6 and the
> worst thing we could do for IPv6.
> 
> It would be the best thing we could do for IPv6 because for numerous
> reasons it would simplify it and could allow for a faster deployment.
> 
> It would be the worst thing we could do for IPv6 because that would be a
> tacit admission that we have failed to deliver on the promises for IPv6,
> and are settling for IPv6 being IPv4 with more bits.
> 
> This could mean the death of IPv6 as enhancements in NATs are way
> cheaper than building a native v6 internet, and as long as the v4
> internet is not on the verge of collapse (which is going to take some
> years at best) IPv6 would not take off.
> 
> There are three things that could make IPv6 take off:
> 1) A killer app, which we still have to see.
> 
> 2) The v4 address space _really_ getting full, which will eventually
> happen but we simply don't know when (as the time frame keeps being
> pushed) and certainly not tomorrow morning.
> 
> 3) IPv6 being a lot more powerful than IPv4.
> 
> > Well, here's my attempt at becoming flame bait :-)
> 
> This was a sound question to ask. However, what you propose is giving up
> on item 3) above, and since there is nothing we can to rush the
> invention of a hypothetical killer app it actually jeopardizes the
> deployment of IPv6.
> 
> When time for 2) is around the corner, IPv6 will be deployed no matter
> what, quick and dirty. Instead of settling for what we can deliver
> today, why don't we use the remaining time to try to make it better?
> Might not produce anything else, but at least we would have tried until
> the last minute.
> 
> Michel.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to