Bob,
What about all the multicast scopes?
And will the new text in the Node Requirements document apply to
routers? That is where many of the issues arise with site-locals.
I won't even bring up the issues with DNS and site-locals.
My point is that I believe that a clean separation should be made
between global addresses and scoped addresses. We fully understand
how globals and link-locals work. All the others are still being
hashed out. If we make this break, the address architecture can
move along the standards track. The (great amount of) additional
work that needs to be done on scoped addresses can be carried out
under the scoped address architecture.
Brian
Bob Hinden wrote:
>
> Brian,
>
> I think this goes to far. We have recently had a long discussion on the
> list regarding unicast site-local that concluded with keeping the
> definition of unicast site-local addresses in the document (see my email on
> 21 Jun 2002, titled "Consensus on Site-Local Discussion"). Part of that
> was that we would add text to the Node Requirements document that nodes are
> only required to implement the rules specified in the default address
> selection document (now a Proposed Standard) and that there be no
> requirement that a node must be able to be part of more than one zone.
>
> Bob
>
> >I would go a step further. Since almost no one has implemented the
> >routing/forwarding of scoped addresses (multicast & unicast site
> >locals), I recommend:
> >
> > 1. Move all discussion of multicast scopes out of the addr-arch
> > and into the scoped addr-arch doc
> > 2. Move all text on site-local unicasts out of the addr-arch
> > doc and into the scoped addr-arch doc
> > 3. Add explicit text to the scoped addr-arch doc to define
> > how/when/where these scopes should be used
> >
> >This would allow the addr-arch doc to progress to DS without being
> >hung up on text involving scoped addresses but still describing the
> >pieces that we know work (e.g. global and link-local). It would also
> >make a clean delineation between global and scoped addresses.
> >
> >The scoped addr-arch doc can then be the home for future work on
> >scoped addresses.
> >
> >My reasoning is based on actually having implemented scoped routing
> >and forwarding. It is not trivial or for the weak of heart.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
