Re: [v6ops] draft-pref64folks-6man-ra-pref64

[Jen Linkova <[e-mail]>]

Jinmei-san,

Thanks a lot for your feedback.
Comments inline.

On Tue, Oct 16, 2018 at 5:38 AM 神明達哉 <[e-mail]> wrote:
> - Section 1: it would be more reader friendly if it expands "PvD" on
>   its first use.

Good point. I'll update the Terminology section.

> - In section 2 (or somewhere else like in the introduction) I think
>   it's fair to point out that the RA approach has a drawback of
>   configuring local routers of each end subnet (where ordinary clients
>   reside).  It's unlike the advertisement of on-link/addrconf prefix
>   for which the router should inherently know and be configured with
>   anyway, so it looks to me to be a tradeoff between the router
>   configuration overhead and the advantages described in this section.

Well...Some vendors still require the prefix to be explicitly
configured under router-advertisement section to be included in PIOs
(just configuring /64 on the interface is not enough) so SLAAC does
require some explicit configuration anyway (and RDNSS and timers etc).
On the other hand, some vendor allow the configuration to be inherited
so in real life it will be one-line config to enable this option on
multiple interfaces...So, to be honest, I do not see much difference
between this option and any other SLAAC parameter...

>   Similarly, we might want to note that this case in Section 5 should
>   be (very?) atypical even if not forbidden:
>
>    o  The pref64 option presents in a single RA more than once;

It would be necessary for renumbering from one pref64 to another.
The old pref64 needs to be advertised with zero Lifetime, while the
new pref64 would have non-zero lifetime.

> - Section 3
>
>    For simplicity, this option only supports a NAT64 prefix length of 96
>    bits, as this is by the most common configuration used by hosts.
>
>   I have no problem with this restriction, but just saying "for
>   simplicity" sounds a bit awkward as it also mentions the case of
>   other prefix lengths and suggests other ways for such cases.  That's
>   awkward to me since it's not difficult at all to support multiple
>   different prefix lengths: just add another field to the option.  I
>   guess one (major?) background rationale is the desire to keep the
>   option length a multiple of 8 octets without padding.  I think
>   that's worth mentioning.

It's also configuration simplicity. But I see your point. We do try to
keep the option length to minimum,
to avoid increasing RA size. I'll try to rephrase this sentence to
make it more clear.

> - Section 3: these two don't read very consistently:
>    This option may appear more than once in a Router Advertisement.
> [...]
>    This option specifies exactly one NAT64 prefix for all IPv4
>    destinations.

Sorry, I'm not sure I understand why. For example, a PIO contains
exactly one prefix. However Prefix Information Option may appear more
than once in a Router Advertisement.
The same here.

>   If it intends to specify *exactly one* prefix, what's the point of
>   having more than one options (unless these options include exactly
>   the same prefix, which also makes no sense).  I guess this is rather
>   an editorial matter than a protocol problem - perhaps in this
>   context we just don't have to say the "may appear more than once"
>   sentence.

See the renumbering example above.

--
SY, Jen Linkova aka Furry