Re: [dhcwg] I-D Action: draft-fsc-softwire-dhcp4o6-saddr-opt-06.txt

[神明達哉 <[e-mail]>]

At Fri, 18 Nov 2016 10:37:21 +0900,
Ian Farrer <[e-mail]> wrote:

> [if - RFC7227 defines an IPv6 prefix option as being variable length with padding to the nearest octet, so yes it would be truncated in your example. I will improve the text to clear this point up.
>
> This is an interesting interpretation as the intended use is to indicate a preferred prefix (/64 or shorter) for the client. in this context, if a longer prefix hint was supplied, then the longest match would only likely to be predictable for up to a /64.
>
> The question it raises is, if a /128 was supplied that belonged to a prefix which is delegated to a client, should the client configure this prefix and build the hinted address as it’s source (assuming it wasn’t in use and DAD was successful)? I’m not convinced that this is actually useful ATM and it may complicate things for error handling (what if DAD fails), but I’d appreciate your opinion.]

(Sorry for the delayed response).  Personally, I don't think this
draft should specify what the client does beyond what the draft
already says:

   If
   this option is received, the client MUST perform a longest prefix
   match between cipv6-prefix-hint and all prefixes/addresses in use on
   the device.  If a match is found, the selected prefix MUST then be
   used to bind the received IPv4 configuration to and source the tunnel
   from.  If no match is found, or the client doesn't receive
   OPTION_DHCP4O6_SADDR_HINT the client MAY select any valid IPv6
   address to use as the tunnel source.

Cases like /128 is covered in this generic text, and as you guessed
yourself, this case would simply result in 'no match' and the client
will select an arbitrary address (per the MAY).  This may result in
some operational failure in the end, but I think it's okay to say it's
a configuration/operation error, not a protocol issue.

--
JINMEI, Tatuya