Subject: Re: [Softwires] Comments on draft-ietf-softwire-ipv6-6rd-00

From: Mark Smith <[email-masked]>
Date: Sat, 7 Nov 2009 20:16:54 +1030

Hi,

On Thu, 24 Sep 2009 09:43:51 +0200
Ole Troan <[email-masked]> wrote:

> Yoshifuji,
> 
> > Some comments on 6rd document.
> >
> > |4.  6rd Prefix Delegation
> > |
> > |   In 6rd, a customer site's IPv6 Delegated Prefix is derived from 2
> >                                                                    ~~~
> > |   elements:
> > |
> > |   1.  An IPv6 Prefix selected by the SP to be the common 6rd SP Prefix
> > |       for the given 6rd deployment (an SP can have multiple 6rd
> > |       deployments called domains).
> > |
> > |   2.  An assigned IPv4 address for the subscriber.  This IPv4 address
> > |       may be a global IPv4 address, or a Private RFC 1918 [RFC1918]
> > |       IPv4 address.
> > |
> > |   From these three items, the 6rd Delegated Prefix is automatically
> >               ~~~~~two?
> 
> thanks, updated!
> 
> > |   created for the customer site when IPv4 service is obtained.  From
> > |   the perspective of the 6rd CE LAN-Side functionality, this IPv6
> > |   delegated prefix is used in the same manner as a prefix obtained via
> > |   DHCPv6 Prefix Delegation [RFC3633].
> >
> > |6.1.  6rd DHCP option
> > :
> > |   The 6rd CE router MUST install a default route to the relay.  It
> > |   should also install a sink route for the delegated prefix.  As an
> > |   example using a subscriber IPv4 address of 10.100.100.1, a 6rd IPv4
> > |   relay address of 10.0.0.1, a v4suffix-length of 24 and 2001:ABC0::/28
> >                                                           2001:0DB8::/32
> > |   as the SP 6rd IPv6 prefix, the RIB will look like:
> > |
> > |      ::/0 -> 2001:ABC0:0000:0100::   (default route)
> >               2001:0DB8:0000:0100::
> > |      2001:ABC0:6464:0100::/56 -> Null0 (6rd prefix sink route)
> >       2001:0DB8:6464:0100::/56
> >
> > Note: With 2001:ABC0::/28 and 24 bit suffix, the results should
> > be 2001:ABC0:0000:1000:: and 2001:ABC6:4640:1000::/52.
> 
> well, spotted. left-over from when we explicitly encoded the domain id.
> fixed.
> 

That explains it. I read through this draft recently, and felt there
was either not enough information about encoding the domain id, or
alternatively a bit too much commentary about a domain id.

If it is preferred to not explicitly encode the domain id, then I'd
suggest something like simple and single paragraph describing how
multiple domains can be created using different shorter 6rd prefixes,
and that they could come out of a shorter aggregate IPv6 prefix if it
suits the network/routing topology. I'd then suggest through out the
rest of the draft that there is minimal mention of 6rd domains, unless
there are specific issues relating to multiple 6rd domains.

HTH,
Mark.

> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires