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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Jen Linkova [mailto:[e-mail]]
> Envoyé : vendredi 7 décembre 2018 09:56
> À : 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 6:41 PM <[e-mail]> wrote:
> > > > 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!!
> 
> Then it's my turn to be confused.
> Let's make sure we are on the same page:
> - I'm using SLAAC to configure devices;
> - I want to use the same mechanism to provide devices with NAT64 prefixs;
> - you are saying "there are two other mechanisms: DHCP option and PCP,
> which solves your problem"
> 
> doesn't it mean that I need to deploy either DHCPv6 or PCP to solve my
> problem?

[Med] 
* If you are attached to a cellular network, then the heuristic is just fine. Millions of devices are using it today. 
* If you don't want to use the heuristic even when you are connected from a cellular, then go for a dedicated PCO IE. 
* If you are in a fixed network (likely a CPE), it is likely that you already support DHCP for other matters. 
* If you are in a network which uses PCP because you have anyway other issues to solve because of the presence of a NAT64, then you can leverage on it. 

We do have a rich set of tools. 

> 
> > > - 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.
> 
> 1) not necessary the *same*

[Med] Agree. But, DHCP supports context-specific configuration information. Please check RFC7969. 

> 2) if SLAAC is used, each access router is supposed to be configured
> with the same information anyway (preferred lifetime, DNS, MTU etc).
> Obviously if the choice towards SLAAC was made, this is not a problem
> for the specific network (hint: automation)

[Med] Cool, It is fine to argue that signaling to contact all access routers or a subset of them is just OK because this can be automated. But it does not explain why "signalling any changes are problematic" which is your initial point.

> 
> > RA is more concerned with stale Pref64s vs. others.
> 
> How?

[Med] If you change a prefix on a NAT64 instance, you need to reflect that change appropriately in all or a subset of access routers. Hence the risk for stale Pref64. Errors may occur, even with automation. 

> 
> > > - 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.
> 
> Any IPv6-enabled device supports SLAAC. This is a mechanism I'm using
> to configure devices. I just need one more config option to be
> propagated.

[Med] We all know what can be configured using RA. There many many services that you cannot configure using RA. 

> 
> >If I want to provision a SIP proxy, a DOTS server, or DS-Lite AFTR using RA,
> would 6man let me do that?
> 
> This would be a question to the group. I probably would not object if
> you have a use case to solve...
> 
> >> 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
> 
> My network-side nodes which need to be changed for enabling pref64 RA
> option are *really* part of the NAT64 deployment. They are either
> doing NAT64 themselves
> or they have to have a route in their routing table pointing to the NAT64
> boxes.

[Med] This is deployment-specific. NAT64 function is not generally located in the access router in typical deployments. 

> 
> >       or aware of issues caused by NAT64/DNS64.
> 
> I read this as  "DHCPv6 servers and PCP boxes are fully 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.
> 
> I've explained above why it might not be desirable to deploy PCP just
> for making devices aware of NAT64 prefix..

[Med] I don't parse your answer. No one suggested to enable X just because you need to discover prefix64!  

> 
> >
> > 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
> 
> 
> 
> --
> SY, Jen Linkova aka Furry