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

From: Ian Farrer <[email-masked]>
Date: Wed, 16 Nov 2016 10:56:16 +0900

Hi,

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.

Thanks,
Ian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Nov 2016 11:06:11 -0800

At Wed, 16 Nov 2016 10:56:16 +0900,
Ian Farrer <[email-masked]> wrote:

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

  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

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

--
JINMEI, Tatuya

---

From: Ian Farrer <[email-masked]>
Date: Fri, 18 Nov 2016 10:37:21 +0900

Hi Jinmei,

May thanks for your comments. Please see inline.

Cheers,
Ian

> On 18 Nov 2016, at 04:06, 神明達哉 <[email-masked]> 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.]

>  - non-0 "garbage" bits beyond the cipv6-hintlen-th bit

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

>   only be used when when encapsulated within one of the softwire

[if - Will fix in the next version]