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

[Jen Linkova <[e-mail]>]

On Thu, Oct 18, 2018 at 5:22 AM 神明達哉 <[e-mail]> wrote:
> 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).

I see your point. I think I just assumed that router configuration
provisioning problem is slightly outside of the scope of this draft.
I need to configure with  much more than 100 routers with:
- PIO (unique config for each interface on each router);
- RDNSS (limited number of configuration templates applied on each inteface)
- other SLAAC options (usually identical for all routers or very
limited number of templates).

Most likely large-scale deployments would need some provisioning
systems anyway so I'm not sure the draft should discuss it - at least
I'm not sure about wording..

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

Not necessary - one might need to configure RDNSS and timers.

> > >   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?)

Well, the logic is:
- we should allow more than one PREF64 option per RA (as it would be
needed for renumbering);
- as we can not say 'PREF64 Option can be seen only once' we need to
define the host behavior if multiple prefixes are received;
- for consistency reason we refer to RFC7050.

>Also, if I understand it correctly, "the recommendations
> given in Section 3 of [RFC7050]" also discusses the case of multiple
> usable prefixes:

We shall either explicitly prohibit multiple prefixes (which might be
undesirable) or define what to do.

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

One option specifies one PREF64 (the same way as one PIO defines one prefix).
Multiple options/multiple prefixes do not make much sense from
operational perspective (IMHO) but I'm not sure we shall say 'MUST
NOT'.

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

I see your point - thanks a lot for your comments, it's really
valuable to get a readability feedback. We'll see if we can improve
the text.

-- 
SY, Jen Linkova aka Furry