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

[Jen Linkova <[e-mail]>]

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?

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

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

How?

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

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

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

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