 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
While this draft is a good start (and is arguably as good as
the 6to4 spec was), I think it still needs a bunch of work, as we’ve
learned from the 6to4 experience. First the draft needs to discuss the properties of IPv6 on
the 6rd interface: 1)
What’s the link model? Presumably it’s
an NBMA interface like 6to4, in which case multicast isn’t supported. But the
document needs to discuss this. 2)
One of the problems with 6to4 is that it violates the
IPv6 RFCs by not having a link-local address (see RFC 4291 section 2.1,
section paragraph, for example). Will 6rd repeat that
violation or not? Can packets be sent with a link-local address? 3)
The use of Neighbor Discovery on the interface needs to
be discussed. Are unicast RS/RA legal? Presumably
normal router discovery and address resolution are not used since it’s
NBMA. As RFC 4861 says: > Unless specified otherwise (in a document that covers
operating IP > over a particular link type) this document applies to
all link types. > However, because ND uses link-layer multicast for some
of its > services, it is possible that on some link types (e.g.,
Non-Broadcast > Multi-Access (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). > The services described in this document that are not
directly > dependent on multicast, such as Redirects, Next-hop
determination, > Neighbor Unreachability Detection, etc., are expected
to be provided > as specified in this document. Since 6rd doesn’t specify otherwise, I assume that
redirects, next-hop determination, NUD, etc are provided as specified in RFC
4861, correct? Compare how ISATAP addresses these in RFC 5214 section 8,
and 6RD needs to have a similar level of coverage. My second major concern with the current draft is that it is
too limited in scope compared to 6to4 where I believe it should be able
to be used in place of 6to4 (other than having private relays with a
network-specific prefix, instead of public relays with a well-known
prefix). Specifically there are two limitations introduced without good reason, that
need to be removed: 1)
The draft says a CE must have 1 or more LAN
interface. 6to4 can be used even when you don’t have a LAN interface
(up). Remove this limitation, as it’s not necessary and
doesn’t affect anything else. 2)
The DHCP option format for configuring a CPE is only
capable of holding a single BR address. To be able to replace
6to4, this must be capable of passing a list. Today many 6to4 gateways
are capable of using a list, and adding one default route for each relay
address, and this can facilitate load-spreading, failover, etc.
There’s no reason given to make 6rd less capable in this respect.
If a SP doesn’t want that, they don’t have to provide more than 1
address, but we should not prevent an SP from providing service
equivalent to what can be done with 6to4 today. -Dave |