RE: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

[<[e-mail]>]

Jen,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jen Linkova [mailto:[e-mail]]
> Envoyé : vendredi 7 décembre 2018 08:17
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Fred Baker; 神明達哉; 6man; [e-mail]
> Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>
> 
> On Fri, Dec 7, 2018 at 5:34 PM <[e-mail]> wrote:
> > The example you provided is discussed in RFC7050. Please note that it is
> not an issue in existing deployments (cellular) because it is the clat module
> which is doing the discovery using a DNS server provided in PCO (cellular
> networks).
> >
> > The two other mechanisms in draft-ietf-v6ops-transition-ipv4aas-11#section-
> 3.2.1 solve that issue anyway.
> 
> Two other mechanisms have the following disadvantages:
> - require deploying additional services just for providing devices
> with information about NAT64 prefix (== operational costs);

[Med] Not sure to understand this one. No one said that you need to deploy dhcp just because you need to learn pref64!! 

> - signalling any changes are problematic;

[Med] No sure to understand this one, too. The problem is more on the RA side rather than a centralized approach. RFC7051 says explicitly the following: 

   Compared to the DHCPv6 equivalent solution in Section 5.6, the
   management overhead is greater with the RA-based solution.  With the
   DHCPv6-based solution, the management can be centralized to a few
   DHCPv6 servers compared to the RA-based solution where each access
   router is supposed to be configured with the same information.

RA is more concerned with stale Pref64s vs. others. 

> - some devices basically do not support those mechanisms;

[Med] This would apply to any piece of configuration, not only the one discussed in this draft. If I want to provision a SIP proxy, a DOTS server, or DS-Lite AFTR using RA, would 6man let me do that? 

> 
> Also, the network is the authoritative source of information re: the
> presence of NAT64 translators and the prefixes used. As NAT64 prefix
> is the essential part of the network configuration information (it's
> required to provide access to IPv4-only resources), RA seems to be
> perfectly suitable to contain that information.

[Med] RFC7051 already covered this: 

   -  The RA-based solution involves changes and management on network-
      side nodes that are not really part of the NAT64/DNS64 deployment
      or aware of issues caused by NAT64/DNS64.

> 
> RFC7050 is a hack which has a fundamental problem: "to be able to use
> DNSSEC, let's trust unverifiable DNS response". It's the best thing we
> have currently but we can do better.

[Med] Existing mechanisms already solve this. 

s/xxx/RA in the text below would also be fine, but this is just yet another way of doing it. 

==

   The stub resolver on the host will try to obtain (native) AAAA
   records, and if they are not found, the DNS64 function on the host
   will query for A records and then synthesize AAAA records.  Using the
   PREFIX64 xxx, the host's stub-resolver can learn the prefix
   used for IPv6/IPv4 translation and synthesize AAAA records
   accordingly.

   Because synthetic AAAA records cannot be successfully validated in a
   host, learning the Pref64::/n used to construct IPv4-converted IPv6
   addresses allows the use of DNSSEC.  As discussed in Section 5.5 of
   [RFC6147], a security-aware and validating host has to perform the
   DNS64 function locally.
==

> 
> > > -----Message d'origine-----
> > > De : ipv6 [mailto:[e-mail]] De la part de Fred Baker
> > > Envoyé : jeudi 6 décembre 2018 21:45
> > > À : 神明達哉
> > > Cc : IPv6 IPv6 List; 6man Chairs
> > > Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>
> > >
> > >
> > >
> > > > On Dec 6, 2018, at 2:46 PM, 神明達哉 <[e-mail]> wrote:
> > > >
> > > > As for the adoption call, I don't have a strong opinion but do share
> > > > the concern of some others about introducing duplicate functionality.
> > > > Since each mechanism is different, it's easy to come up with a reason
> > > > of "why this" by pointing to a gap.  But IMO it should also justify
> > > > the duplication (despite Section 3.2 of RFC1958) by explaining the
> > > > benefits of filling the gap outweigh the disadvantages of having
> > > > duplicates.  According to the current text of the draft and
> > > > discussions on this list, I don't think we complete this homework.
> > >
> > > From my perspective, the value in the "why this" domain is that it sorts
> out
> > > some security issues. For example, with RFC 7050's approach, imagine that
> > > you're using resolver X and your ISP is advertising ipv4only.arpa using
> > > resolver Y under the assumption that you are or should be using resolver
> Y.
> > > Imagine that the advertised prefixes differ. The feature just broke for
> you.
> > >
> > > Putting the prefix in the RA on a given LAN reliably identifies the
> prefix
> > > that folks on that LAN should use.
> > >
> > > I'd be very happy if the other mechanisms were deprecated, and software
> and
> > > configurations using them put on notice that they need to change
> accordingly.
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> 
> 
> --
> SY, Jen Linkova aka Furry