Call for testers: RFC 5569 (6rd) support in stf(4)

[Ondoy]

Hello Hiroki,

Thanks for your reply.
I think I now see how you this is supposed to work.
What I didn't (crucially) get first was that the BR IPv4 address is configured
at the CE when adding the IPv6 default route.

It is simpler to get when 6rdPrefixLen is 32 and IPv4MaskLen is 0.
Now I'm trying to figure out how to configure a CE using different
parameters (all else the same with your sample setup).

For example:
IPv4MaskLen   = 8
6rdPrefix        = 2001:db8:dd00::
6rdPrefixLen     = 40
6rdBRIPv4Address = 192.0.2.1 (c0 00 02 01)

given:
CE WAN IPv4      = 192.0.2.2 (c0 00 02 02)
so we'll get:
6rd delegated prefix (at the CE LAN side) = 2001:db8:dd00:0202::/64

To configure the LAN side interface, stf, and route:
# ifconfig fxp0 inet6 2001:db8:dd00:0202::1/64
# ifconfig stf0 inet6 2001:db8:dd00:0202::/32
# route add -inet6 default 2001:db8:ddc0:0002:0100::1
Is the above correct, or am I way off target?

Regards,
Ondoy


PS.
Please note that I refer to IPv4MaskLen, 6rdPrefix, 6rdPrefixLen and
6rdBRIPv4Address as defined in RFC 5969 (newly released doc for 6rd).


On Fri, Sep 24, 2010 at 2:14 PM, Hiroki Sato <hrs at freebsd.org> wrote:
> Ondoy <loki.fab at gmail.com> wrote
>  in <AANLkTik5amD6Sr5CEhyVu1fnbMvkevqZQ+FGW5ZPcNAa at mail.gmail.com>:
>
> lo> I haven't tried your patch yet but I need some clarifications.
> lo> RFC 5969 has the following elements for 6rd configuration:
> lo> IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, 6rdBRIPv4Address.
> lo>
> lo> >From your example, I think the following takes care of
> lo> 6rdPrefix and 6rdPrefixLen:
> lo>   # ifconfig stf0 inet6 2001:db8:c000:0202::/32
> lo>
> lo> How can we configure the IPv4MaskLen and 6rdBRIPv4Address?
>
>  6rdBRIPv4Address is a part just after prefixlen of an IPv6 address on
>  the stf.  In the case of 2001:db8:c000:0202::/32, it is c000:0202 =
>  192.0.2.2.  When a host wants to communicate with a BR router, just
>  specifying an IPv6 address with embedded BR IPv4 address is fine.  No
>  configuration of stf on that host is needed.
>
> lo> I suspect IPv4MaskLen is fixed at zero (use all 32 bits) in this patch.(?)
>
>  IPv4MaskLen can be set in the IPv6 routing table, not stf interface
>  itself.  The stf interface accepts 6rd IPv4 packet with a whole IPv4
>  source address range (this is equivalent to IPv4MaskLen=0 here) once,
>  but it delivers the decapsulated IPv6 packet with a valid route only.
>  So, if no route in 2001:db8::/32 which is more specific is added, no
>  IPv6 packet is delivered outside of the stf.
>
>  For example, the router has a route 2001:db8:c000:0200::/56 to
>  outside of the stf, IPv4MaskLen is virtually equal to /24.
>
> lo> As I understand from the specs, this can be variable.
> lo> It seems that at the CE, the IPv4 address of the BR is automatically
> lo> calculated from the dst/src IPv6 address. But what if the embedded
> lo> IPv4 address is not the whole 32 bits (IPv4MaskLen > 0)?
> lo>
> lo> Also, you mentioned that prefixlen of stf is from 0 to 32. Is this
> lo> the same as 6rdPrefixLen?
> lo> I think 6rdPrefixLen can be more than 32.
>
>  No, 6rdPrefixLen is implemented as "stf's prefixlen + 32" in the
>  patch.  So, the range is from 32 to 64 in terms of 6rdPrefixLen.
>
>  In short, a prefix with IPv4MaskLen=0 is always set to the stf, and
>  IPv4MaskLen is handled in the routing table.  Yes, I agree that this
>  is a bit confusing and maybe I will change the design and/or the way
>  to configure it in more intuitive fashion.  It is due to some
>  limitations in the internal structure of stf.
>
> lo> Lastly, I'm a bit confused with the IPv6 default route at the CE
> lo> (set to 2001:db8:c000:0201::1) since there's supposed to be
> lo> no IPv6 connection between the CE and the BR, only IPv4.
>
>  It works like following: the CE router has a route to 2001:db8::/32
>  on its stf, so an IPv6 packet with no direct IPv6 connection goes to
>  stf, then it will be encapsuled as a 6rd IPv4 packet, delivered to
>  the BR via IPv4, and decapsuled there.  The IPv4 address of the BR is
>  embedded in that address.
>
> -- Hiroki
>