Re: Request to Publish ISATAP

[Erik Nordmark <Erik.Nordmark@sun.com>]

Some additional information to take into account...


> > 	in 5.1, the document proposes a different handling of link-layer
> > 	address option in ND from the normal ND.
> 
> This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph
> on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the
> normative text that allows what ISATAP is doing is plain for all to see.

Correct.

> >       also in 5.2, the document
> > 	proposes special handling of router discovery.  ND and router discovery
> > 	have to be link-layer independent, and if we wish to make any changes
> > 	to ND/autoconf, we must update RFC2461/2462, in link-layer independent
> > 	manner.
> 
> Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1,
> we have the following text:
> 
>    However, because ND uses link-layer multicast for some of its
>    services, it is possible that on some link types (e.g., NBMA links)
>    alternative protocols or mechanisms to implement those services will
>    be specified (in the appropriate document covering the operation of
>    IP over a particular link type).
> 
> Clearly, no updates to RFC2461 are necessary since ISATAP is exactly
> such "the appropriate document..." as described above.

After RFC 2461 was written RFC 2491 "IPv6 over Non-Broadcast Multiple Access 
(NBMA) networks".
It makes sense for schemes that do IPv6 over NBMA to use that as the basis
and not provide additional and different changes to how ND works.

   Erik