RE: IPv6 only host NAT64 requirements?

[<[e-mail]>]

Hi Ole,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ole Troan [mailto:[e-mail]]
> Envoyé : vendredi 17 novembre 2017 10:20
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Jen Linkova; 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> Med,
> 
> Thanks for all the references. Seems like most bases have been covered
> here. ;-)
> 
> For the IETF NAT64 IMHO

[Med] As you are mentioning "IETF" explicitly, NAT64 may not be the appropriate "IPv4 service continuity" solution here. 

 I need:
>  - No dependency on DNS64. Want to use recursive resolver I trust plus
> local validating resolver.
>  - Not depend on the success of PCP for NAT64 prefix discovery
>  - If the host couldn't learn the NAT64 prefix any other way, I suppose it
> could throw an ICMP echo towards
>    64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
> 

[Med] Fair. That is another "add my favorite solution" to the list. 

> But I also see there being different deployment options here.
> Btw, for multiple NSPs, couldn't you partly solve that by injecting more
> specifics into routing?

[Med] It is not only about forwarding/routing, but also how a host can pick the appropriate prefix64 for address synthesis. Things may be obvious if you can consider the example of RFC7050:


                      NAT64 "A" ----- IPv4-only servers in a data center
                     /
   IPv6-only node---<
                     \
                      NAT64 "B" ----- IPv4 Internet 


> 
> Cheers,
> Ole
> 
> 
> > On 17 Nov 2017, at 16:47, <[e-mail]>
> <[e-mail]> wrote:
> >
> > Hi Jen,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Jen Linkova [mailto:[e-mail]]
> >> Envoyé : vendredi 17 novembre 2017 09:31
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : Ole Troan; 6man WG; Mark Andrews
> >> Objet : Re: IPv6 only host NAT64 requirements?
> >>
> >> On Thu, Nov 16, 2017 at 12:35 AM,  <[e-mail]>
> wrote:
> >>>> IMHO the optimal solution is:
> >>>> - the network SHOULD provide a host with NAT64 prefix information in
> >>>> RA (I do not believe that information needs to be duplicated in DHCP
> >>>> at all);
> >>>
> >>> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3
> >>
> >> Thanks for pointing this out. To be honest I disagree with what that
> >> section says.
> >
> > [Med] I also disagree with many of the points in RFC7051, but that is
> the document which reflects the IETF consensus on learning prefix64s.
> >
> > We had many opportunities in the past to ignore the recommendations in
> RFC7051, but we didn't. For example, RFC8115 says the following:
> >
> > ==
> >   Note that it was tempting to define three distinct DHCPv6 options,
> >   but that approach was not adopted because it has a side effect: the
> >   specification of a DHCPv6 option that could be used to discover
> >   unicast Prefix64s in environments where multicast is not enabled.
> >   Such a side effect conflicts with the recommendation to support the
> >   Well-Known DNS Name heuristic discovery-based method for unicast-only
> >   environments (Section 6 of [RFC7051]).
> > ==
> >
> >> I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
> >> not mention all those issues with multihoming for example but....
> >> If you are saying that the prefix should not be distributed via RAs
> >> because it needs to be configured on routers, then what about DNS
> >> servers and SLAAC prefixes themselves?
> >> There are SLAAC-only networks out there while RFC7934 does not
> >> recommend DHCPv6 as the only way to configure clients.
> >> So between those two RA does look like a better way.
> >
> > [Med] It is evident that RA-based approach may be a good candidate for
> some deployments. Others may argue that another solution is appropriate
> for their deployment, and so on.
> >
> >>
> >>> Things may get complex if multiple NSPs are used for load-balancing or
> >> if destination based NAT64s are deployed. A list of issues is
> elaborated
> >> in https://tools.ietf.org/html/rfc7225#section-3.1
> >>
> >> It's more like v6ops question but I'm really curious if multiple
> >> prefixes scenario is real.
> >> RA option might contain multiple prefixes anyway.
> >
> > [Med] Indeed. It is already ACKed in 7051:
> >
> >   Note: If the RA would include multiple NSPs, Issue #5 could be solved
> >   as well, but only if nodes as a group would select different NSPs,
> >   hence supporting load balancing.  As this is not clear, this item is
> >   not yet listed under PROs or CONs.
> >
> >>
> >>>>>> On 15 Nov 2017, at 08:06, Mark Andrews <[e-mail]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <[e-mail]>
> >>>> wrote:
> >>>>>>>
> >>>>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <[e-mail]>
> >> wrote:
> >>>>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa
> >> can
> >>>> be a preconfigured
> >>>>>>> zone which allows CLAT to get its mapping.  All the phones have
> >> CLAT
> >>>> support.
> >>>>>>>
> >>>>>>> That's an interesting idea. It would work in theory, but such a
> >>>> network would completely break devices that don't support 464xlat.
> That
> >>>> gives up one of the major advantages of NAT64/DNS64, which is that
> it's
> >> a
> >>>> 90% solution even just by itself - yes, IPv4-only applications and
> >> address
> >>>> literals exist, but most simple client/server applications Just Work
> >>>> behind it.
> >>>>>>
> >>>>>> And that 90% “solution” has lots of down sides.  It basically
> >> requires
> >>>> EVERY DNS VALIDATOR ON
> >>>>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
> >>>> SERVER.
> >>>>>>
> >>>>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first
> >>>> mooted.  It keeps on
> >>>>>> requiring more and more highly invasive node changes to support.
> It
> >>>> was from the very beginning
> >>>>>> bad engineering.   To get IPv4 as a service some node changes are
> >>>> required.  Lets make sure they
> >>>>>> are MINIMAL ones.
> >>>>>>
> >>>>>> Just for the record DNSSEC validators need to send BOTH CD=0 and
> >> CD=1
> >>>> queries to get answers
> >>>>>> though a upstream VALIDATING server which includes a VALIDATING
> >> DNS64
> >>>> server as CD=0 and
> >>>>>> CD=1 address different DNSSEC threats.  I tried very hard to point
> >> that
> >>>> out when RFC 6147 was
> >>>>>> being written but the working group decide that CD indicated
> whether
> >>>> the client was validating or
> >>>>>> not.  There is NO SUCH INDICATION in a DNS message.
> >>>>>>
> >>>>>> If a query arrives at a vDNS64 device with the "Checking Disabled"
> >>>>>>  (CD) bit set, it is an indication that the querying agent wants
> >> all
> >>>>>>  the validation data so it can do checking itself.  By local
> >> policy,
> >>>>>>  vDNS64 could still validate, but it must return all data to the
> >>>>>>  querying agent anyway.
> >>>>>>
> >>>>>> CD=0 queries causes the upstream validating servers to reject
> >> incoming
> >>>> spoofed answers
> >>>>>> or stale answers (this is a common operational problem).
> >>>>>>
> >>>>>> CD=1 queries allow the validation to succeed when the upstream
> >>>> validator has a bad trust
> >>>>>> anchor or a bad clock which is rejecting legitimate answers.
> >>>>>>
> >>>>>> A validating client can’t just send CD=1 queries as the upstream
> >>>> validator doesn’t kick in.
> >>>>>> The upstream validator can lock onto a stale answer source.  It
> >> needs
> >>>> to send CD=0 queries
> >>>>>> on validation failure to force the upstream validator to try
> >> multiple
> >>>> sources.
> >>>>>>
> >>>>>> A validating client can’t just send CD=0.  It needs to send CD=1 on
> >>>> SERVFAIL in case the
> >>>>>> upstream validator has a bad trust anchor (likely with the upcoming
> >>>> root KSK roll) or has
> >>>>>> a bad clock (these usually get fixed fast).
> >>>>>>
> >>>>>> Now to get a answer from a signed zone with servers with stale
> >> answers
> >>>> a validatiing DNS64 client
> >>>>>> needs to send:
> >>>>>>
> >>>>>> a) send CD=1 and validation failure send CD=0 then on AAAA
> >> validation
> >>>> failure send CD=1 and
> >>>>>>   hope the TTL was not 0 and that is not cachable and there is no
> >>>> assurance that you won’t get
> >>>>>>   a answer from a stale source.
> >>>>>>
> >>>>>>      or
> >>>>>>
> >>>>>> b) send CD=0 and on validation failure of the AAAA send CD=1 and
> >> hope
> >>>> the TTL was not 0 as
> >>>>>>   that is not cachable and there is no assurance that you won’t get
> >> a
> >>>> answer from a stale source.
> >>>>>>
> >>>>>> TTL=0 answers exist.
> >>>>>>
> >>>>>> Note none of this is documented in a RFC.  You have to understand
> >> how
> >>>> both DNSSEC and DNS64 work to
> >>>>>> realise this.
> >>>>>>
> >>>>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks
> >> prefix
> >>>> discover for DNS VALIDATORS.
> >>>>>> Note “ad” is set in the flags.  Yes, I’ve submitted a errata.  Yes,
> >>>> I’ve opened a ticket to get it fixed but
> >>>>>> based on past experience that could take months if it happens at
> >> all.
> >>>> You will note that the recursive
> >>>>>> server is running on the loopback interface so all DNS answers are
> >>>> being validated here.
> >>>>>>
> >>>>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
> >>>>>> ;; BADCOOKIE, retrying.
> >>>>>>
> >>>>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
> >>>>>> ;; global options: +cmd
> >>>>>> ;; Got answer:
> >>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
> >>>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0,
> >> ADDITIONAL: 1
> >>>>>>
> >>>>>> ;; OPT PSEUDOSECTION:
> >>>>>> ; EDNS: version: 0, flags:; udp: 4096
> >>>>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
> >>>>>> ;; QUESTION SECTION:
> >>>>>> ;IPV4ONLY.ARPA.                       IN      A
> >>>>>>
> >>>>>> ;; ANSWER SECTION:
> >>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
> >>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
> >>>>>>
> >>>>>> ;; Query time: 0 msec
> >>>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >>>>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
> >>>>>> ;; MSG SIZE  rcvd: 115
> >>>>>>
> >>>>>> [rock:bind9/bin/named] marka%
> >>>>>>
> >>>>>>> It's not true that all phones have clat support. Notably, Apple
> not
> >>>> only does not support it but appears ideologically opposed to it on
> the
> >>>> grounds that it does not have a good exit strategy (because it makes
> it
> >>>> possible to run IPv4-only apps forever).
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Mark Andrews, ISC
> >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>> PHONE: [phone]              INTERNET: [e-mail]
> >>>>>>
> >>>>>> -------------------------------------------------------------------
> -
> >>>>>> IETF IPv6 working group mailing list
> >>>>>> [e-mail]
> >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>> -------------------------------------------------------------------
> -
> >>>>>
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>>> IETF IPv6 working group mailing list
> >>>>> [e-mail]
> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> SY, Jen Linkova aka Furry
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> [e-mail]
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>
> >>
> >>
> >> --
> >> SY, Jen Linkova aka Furry