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

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

At Tue, 16 Oct 2018 21:28:37 +1100,
Jen Linkova <[e-mail]> wrote:

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

I'm afraid we're talking about different issues...maybe I wasn't clear
enough in the above comment, so let me rephrase it: assume if you have
100 leaf subnets, each of which has an RA-advertising router.  If you
want to deploy draft-pref64folks-6man-ra-pref64, you'll need to
configure those 100 routers separately; if the prefix is changed,
you'll need to update the config on these 100 routers.  On the other
hand, if you use a DNS-based approach (RFC7050) you'll only have to
configure/update the DNS(64) server (there may be multiple instances
of such server and you may have to configure each of them by hand, but
I assume the number of such instances is generally much smaller than
the number of leaf subnets).

This is different from other SLAAC parameters such as PIO, since the
information is different for different subnets and each router needs
to be configured separately anyway.

To be clear, I'm not making this comment to say that ra-pref64 is
inferior to existing ways.  I just thought there's some tradeoff
between different approaches and it's fair to explain both pros and
cons.

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

Ah, okay.  Perhaps that was just my bad reading, but the intent wasn't
clear to me from the draft's context.  In fact, it looks like the
other two bullets talk about the case of multiple usable prefixes
(right?)  Also, if I understand it correctly, "the recommendations
given in Section 3 of [RFC7050]" also discusses the case of multiple
usable prefixes:

   When multiple Pref64 were discovered via RA Pref64 Option [...],
   host behaviour with regards to synthesizing IPv6 addresses from IPv4
   addresses SHOULD follow the recommendations given in Section 3 of
   [RFC7050], limited to the NAT64 prefixes that have non-zero
   lifetime..

Only the above one bullet should mean the renumbering case since the
pref64 option should only support at most one usable prefix.  And then
the above paragraph still looks awkward: since "this option specifies
exactly one NAT64 prefix for all IPv4 destinations" (from Section 3)
I'd expect we only have at most one prefix that has non-zero
lifetime.  And then there's no point of applying the above
"recommendation" since it's "limited to the NAT64 prefixes that have
non-zero lifetime" (btw there's a redundant period here).

Perhaps I'm still misunderstanding something fundamental, but I
personally see some need for editorial clarification.

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

See above.  Now I see how these two can coexist, but at least to me
it's not so obvious for fresh readers just from this text.  More
explanation to clarify the intent would help.

--
JINMEI, Tatuya