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

[Ian Farrer <[e-mail]>]

Hi Jinmei,

May thanks for your comments. Please see inline.

Cheers,
Ian

> On 18 Nov 2016, at 04:06, 神明達哉 <[e-mail]> wrote:
> 
> At Wed, 16 Nov 2016 10:56:16 +0900,
> Ian Farrer <[e-mail]> wrote:
> 
>> In advance of Friday’s presentation in (and hopefully re-homing to) DHC.
>> 
>> This version is a small update, adding some text about the creation
>> of a dedicated IPv6 address to use as a tunnel endpoint.
> 
> I've read it.  Overall I think it makes sense.  I have a few minor
> comments:
> 
> - Section 6.1
> 
>   o  cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix
>      for the client to bind the received IPv4 configuration to.
> 
>  Since the option diagram says "variable length", I assume it can be
>  truncated if the prefix length is smaller than 121.  I'd suggest
>  explicitly stating so, and I also think it's better to how much it
>  should (must) be truncated.  I guess the intent is to truncate it
>  to the number of bits specified in cipv6-hintlen, but the current
>  description doesn't clearly say so, and it can be longer than that.
>  Such "flexibility" doesn't necessarily lead to interoperability
>  problems, but unless the flexibility is needed for some reason it
>  would be better to be specific to avoid any troubles that come from
>  different interpretation of different implementations.  You may also
>  want to specify how the remaining redundant bits due to truncation
>  (if any) should be filled (e.g., when the prefix length is 124, what
>  the trailing 4 bits should be).  One common practice is to fill them
>  with 0.  You may or may not want to follow it, or you may or may not
>  want to be specific about this in the first place, but at least I'd
>  suggest you considering what to do.

[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.]

> 
>  On a related matter, you may also want to describe what the
>  recipient should do for some invalid or awkward values in terms of
>  validity of cipv6-hintlen and cipv6-prefix-hint.  There are some
>  obviously invalid values:
>  - cipv6-hintlen > 128
>  - cipv6-hintlen is too large for the actual address length (e.g.
>    cipv6-hintlen == 128 but cipv6-prefix-hint has only 8 bytes).
>  And there are some cases that are not necessarily invalid but are
>  awkward:
>  - cipv6-hintlen is too short (e.g., cipv6-hintlen == 64 but
>    cipv6-prefix-hint has 16 bytes)
>  - non-0 "garbage" bits beyond the cipv6-hintlen-th bit

[if - Agree. I’ll extend the client behavior section for this error checking]

> 
> Editorial nits:
> 
> - Section 1: s/DHCPv4 over DHCPv4/DHCPv4 over DHCPv6/
>   created softwires using DHCPv4 over DHCPv4 (DHCP 4o6), including
> 
> - Section 4.1: s/when when/when/
> 
>   only be used when when encapsulated within one of the softwire

[if - Will fix in the next version]

> 
> --
> JINMEI, Tatuya