Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt

[Mark Townsley <townsley at cisco.com>]

Dave - fyi draft-ietf-softwire-ipv6-6rd-01.txt is the latest spec, the 
draft-townsley version is retired. Thanks for the review, jetlagged comments 
inline...

Dave Thaler wrote:
> 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.

Yes, it is, and perhaps we are relying too much on the 6to4 basis here.
I don't want to rewrite RFC3056 completely in this document, but we can
certainly try to be more clear here on the link-model.

> 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?
Offhand, I see no need for a link-local here, but I think the right
thing to do would be to use the associated IPv4 address to create an
fe80:: link-local ala ISATAP.
> 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.
Right, neighbor discovery inside the tunnel is not required.
> 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.
So far this hasn't been important for the implementations we have, but
for completeness I agree we should specify this fully in the spec.
> 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.
Yes, of course, the CE could always be a host.
> 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.
IPv4 anycast is an important part of the design here as it eliminates
the complexity associated with the CE keeping track of which BR to use.
It might seem trivial for a CE to have multiple BR addresses, but this
comes with responsibility and associated complexity of knowing which are
up, down, loaded or not, etc. 6rd is designed to operate in an SP
network utilizing as much IPv4 infrastructure as possible, that includes
load-balancing, failover, etc. provided by using a single IPv4 anycast
address.

- Mark
> -Dave
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Softwires mailing list
> Softwires at ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>