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

[Fred Baker <[e-mail]>]

I'm not sure we disagree on your point. However, there is also the issue of shadowing services. For example, in my home I use an OpenDNS resolver; it's built into my router and I said "yes". If my ISP were implementing 464XLAT (they're not to my knowledge, but imagine) and wanted me to use a prefix of their choosing, OpenDNS could either have no record or give me something different. So the DNS approach has a fairly fundamental flaw.

What might be interesting on routers that want you to configure it manually would be a "use RFC 7050" configuration, in which the router got the record from DNS and advertised it in its RA.

> On Oct 17, 2018, at 11:22 AM, 神明達哉 <[e-mail]> wrote:
> 
> 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
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...