Subject: Fwd: New Version Notification for draft-pref64folks-6man-ra-pref64-02.txt

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Oct 2018 13:25:29 +1000

Hello,

We've just uploaded -02 version of draft-pref64folks-6man-ra-pref64.

It has now a section discussing multiple prefixes scenarios (inc. multihoming).
Unfortunately Brian's comment to explicitly mention in the abstract
that the prefix is always /96 slipped through the cracks - will be
addresses in -03.

Any comments/feedback is appreciated.

Thanks!

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Oct 2, 2018 at 1:05 PM
Subject: New Version Notification for draft-pref64folks-6man-ra-pref64-02.txt
To: Erik Kline <[email-masked]>, Lorenzo Colitti <[email-masked]>,
Jen Linkova <[email-masked]>

A new version of I-D, draft-pref64folks-6man-ra-pref64-02.txt
has been successfully submitted by Jen Linkova and posted to the
IETF repository.

Name:           draft-pref64folks-6man-ra-pref64
Revision:       02
Title:          Discovering PREF64 in Router Advertisements
Document date:  2018-10-01
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-pref64folks-6man-ra-pref64-02.txt
Status:
https://datatracker.ietf.org/doc/draft-pref64folks-6man-ra-pref64/
Htmlized:       https://tools.ietf.org/html/draft-pref64folks-6man-ra-pref64-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-pref64folks-6man-ra-pref64
Diff:
https://www.ietf.org/rfcdiff?url2=draft-pref64folks-6man-ra-pref64-02

Abstract:
   This document specifies a Router Advertisement option to communicate
   NAT64 prefixes to clients.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2018 12:32:57 +0900

> that the prefix is always /96 slipped through the cracks - will be

Brian, do you feel strongly that it needs to be in the abstract? It's
mentioned in many other places in the draft.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Oct 2018 14:16:11 +1000

Can we please consider adding additional field which is a DNS name that contains a APL RRset with the following semantics:

1) if a address in the A RRset matches the APL list then it is NOT mapped.  
2) if a address in the AAAA RRset matched the APL list then it is ignored when determine if a AAAA record exists.

The APL type was defined in the experimental RFC3123.  This has the ability to
encode ALC lists by address type.

If the name is “.” then do not perform a APL lookup.

This allow for DNS64 to be implemented in getaddrinfo() or similar.

BIND’s DNS64 implementations includes acl lists for both of these functions.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2018 13:18:59 +0900

During discussion on this topic in Montreal I believe we observed that the
common case of this option is for IPv6-only networks, and on IPv6-only
networks, such options are not useful because on an IPv6-only network
there's nothing an application can do with an A record. No?

On Tue, Oct 2, 2018 at 1:16 PM Mark Andrews <[email-masked]> wrote:

> Can we please consider adding additional field which is a DNS name that
> contains a APL RRset with the following semantics:
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Oct 2018 14:49:31 +1000

We looked at this and decided it would be too hard to encode the acl information
into a RA directly which led to everything else.  This provides a level of
indirection which opens things back up.

Mark

> On 2 Oct 2018, at 2:18 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> During discussion on this topic in Montreal I believe we observed that the common case of this option is for IPv6-only networks, and on IPv6-only networks, such options are not useful because on an IPv6-only network there's nothing an application can do with an A record. No?
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2018 17:01:21 +0900

But it's true that such an option would not be useful to hosts on IPv6-only
networks, right? Because the only information it provides is a way to
determine when to use A records directly instead, and that information is
not useful to a host on an IPv6-only network?

On Tue, Oct 2, 2018 at 1:49 PM Mark Andrews <[email-masked]> wrote:

> > During discussion on this topic in Montreal I believe we observed that
> the common case of this option is for IPv6-only networks, and on IPv6-only
> > 2) if a address in the AAAA RRset matched the APL list then it is
> ignored when determine if a AAAA record exists.
> >

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 Oct 2018 10:25:35 +0200

Hi Jen,

I'm not sure if I commented this in my previous review, but I had it in mind ... 464XLAT should be upper case, same as the other protocols.

I still believe, as indicated in my previous input, that something regarding the earlier conclusions and actual "true" from RFC7051 should be mention.

Considering that in some cases NAT64 can be used without DNS64 (even much easier with this RA option), in the sentences that you use NAT64/DNS64, it will be good to change that to "NAT64 or NAT64+DNS64", to make it clear. For example:

This speeds up the process of connecting to a network that
   supports NAT64/DNS64,

This speeds up the process of connecting to a network that
   Supports NAT64 or NAT64/DNS64,

In fact it can be stressed that with this option, earlier tricks required when DNS64 was not present, or the use of alternative NAT64 prefix learning techniques, is no longer needed. You mention in the document RFC7050/RFC7225, but it can be learn also using "tricks", such as those I mention in section 4.1.1 of https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include_text=1

In:
In a network that provides both IPv4 and NAT64, it may be desirable
   for certain IPv4 addresses not to be translated.  An example might be
   private address ranges that are local to the network and should not
   be reached through the NAT64.  This type of configuration cannot be
   conveyed to hosts using this option, or through other NAT64 prefix
   provisioning mechanisms such as [RFC7050] or [RFC7225].  This problem
   does not apply in IPv6-only networks, because in such networks, the
   host does not have an IPv4 address and cannot reach any IPv4
   destinations without the NAT64.

I think is worth to mention that it is expected that the "normally" private IPv4 addresses are "before" the NAT64, so routing must take care of that (same for other "special" addresses). I don't see a case for that not happening ... may be missing something here.

Regarding:
"When different Pref64 are discovered by using multiple mechanisms"

In https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1

We have this:
  464XLAT-7:  The priority for the NAT64 prefix, in case the network
               provides several choices, MUST be: 1) [RFC7225], 2)
               [RFC8115], and 3) [RFC7050].

I think we should have a MUST also in your document.

If this helps, I think we are in "sync" in the priority order (may be you also want to add RFC8115), as in a previous version of draft-ietf-v6ops-transition-ipv4aas, I had:

  464XLAT-7:  The priority for the NAT64 prefix, in case the network
               provides several choices, MUST be: 1) [RFC7225], 2)
               [RFC8115], 3) [I-D.pref64folks-6man-ra-pref64] and 4)
               [RFC7050].

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Jen Linkova <[email-masked]>
Fecha: martes, 2 de octubre de 2018, 5:26
Para: 6man <[email-masked]>
Asunto: Fwd: New Version Notification for draft-pref64folks-6man-ra-pref64-02.txt

    Hello,

    
    
    Thanks!
    
    ---------- Forwarded message ----------
    From:  <[email-masked]>
    Date: Tue, Oct 2, 2018 at 1:05 PM
    Subject: New Version Notification for draft-pref64folks-6man-ra-pref64-02.txt
    To: Erik Kline <[email-masked]>, Lorenzo Colitti <[email-masked]>,
    Jen Linkova <[email-masked]>

    
    
    Abstract:

    
    
    The IETF Secretariat

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2018 18:13:03 +0900

On Tue, Oct 2, 2018 at 5:27 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Considering that in some cases NAT64 can be used without DNS64 (even much
> easier with this RA option), in the sentences that you use NAT64/DNS64, it
> will be good to change that to "NAT64 or NAT64+DNS64", to make it clear.
> For example:
>

Should we just remove DNS64 everywhere, then?

> I think is worth to mention that it is expected that the "normally"
> private IPv4 addresses are "before" the NAT64, so routing must take care of
> that (same for other "special" addresses). I don't see a case for that not
> happening ... may be missing something here.
>

A case where private IPv4 addresses are beyond the NAT64 is a corporate
network that has servers on private IPv4 space. I happen to be writing to
you from such a network.

> In
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1
>
> We have this:

No, we should not have MUST in a standards track document that applies to
all IPv6 nodes and only defines the option format. MUST is needlessly
prescriptive, and implementations and other documents should be free to do
something else in the future without violating or updating this document.
Consider: if this document becomes an RFC, and later on, a future
operational need arises where the order should be changed, v6ops could not
publish a document recommending a different order, because any document
published by v6ops would not be able to override this MUST.

Yes, draft-ietf-v6ops-transition-ipv4aas says MUST, but it's informational,
so RFC 2119 language doesn't really have any formal effect.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 Oct 2018 11:21:21 +0200

Hi Lorenzo,

Below, in-line.

On Tue, Oct 2, 2018 at 5:27 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

 

I think there are still cases where DNS64 makes sense (for example a pure NAT64 network) … so I will not remove it, just make clear both options.

A case where private IPv4 addresses are beyond the NAT64 is a corporate network that has servers on private IPv4 space. I happen to be writing to you from such a network.

Got it!

Regarding:

We have this:

No, we should not have MUST in a standards track document that applies to all IPv6 nodes and only defines the option format. MUST is needlessly prescriptive, and implementations and other documents should be free to do something else in the future without violating or updating this document. Consider: if this document becomes an RFC, and later on, a future operational need arises where the order should be changed, v6ops could not publish a document recommending a different order, because any document published by v6ops would not be able to override this MUST.

Got the point, thanks!

Yes, draft-ietf-v6ops-transition-ipv4aas says MUST, but it's informational, so RFC 2119 language doesn't really have any formal effect.

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 08:55:10 -0400

Lorenzo Colitti <lorenzo=[email-masked]> wrote:
    > the common case of this option is for IPv6-only networks, and on
    > IPv6-only networks, such options are not useful because on an IPv6-only
    > network there's nothing an application can do with an A record. No?

What about a Dual-Stack enterprise network with an IPv6-only uplink?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 Oct 2018 21:41:57 -0700

On 10/1/2018 9:18 PM, Lorenzo Colitti wrote:

> IPv6-only networks, such options are not useful because on an
> IPv6-only network there's nothing an application can do with an A
> record. No?

No. The application could for example call its preferred address mapping
API that will use local data unavailable to the NAT64 or DNS64 gateway.
And applications that care will indeed use such API. Compared to the
ICE/STUN API used by P2P applications, that's a piece of cake.

If dealing with DNS64, applications will probably also use their
preferred mapping API. It will just be a tiny bit harder to write, since
the API will have to undo the DNS64 mapping before doing its own.

-- Christian Huitema

---

From: Jen Linkova <[email-masked]>
Date: Mon, 8 Oct 2018 13:36:46 +1100

> What about a Dual-Stack enterprise network with an IPv6-only uplink?

That's interesting scenario. Could you elaborate on the details?
So: dual-stack corporate network which has DNS64 deployed inside it
(as well as some v4-only resources, for which it would be desirable to
get A RR), connected via v6-only uplink to...what? an ISP which has
NAT64 somewhere? Or it's v6-only uplink to the corporate
core/backbone, which has NAT64 deployed?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Oct 2018 09:16:29 -0400

Jen Linkova <[email-masked]> wrote:
    >> Lorenzo Colitti <lorenzo=[email-masked]> wrote: > During
    >> discussion on this topic in Montreal I believe we observed that > the
    >> common case of this option is for IPv6-only networks, and on >
    >> IPv6-only > network there's nothing an application can do with an A
    >> record. No?
    >>

    > That's interesting scenario. Could you elaborate on the details?

I'm not saying it's realistic today, but maybe it would be in the future.

    > So:
    > dual-stack corporate network which has DNS64 deployed inside it (as
    > well as some v4-only resources, for which it would be desirable to get
    > A RR), connected via v6-only uplink to...what? an ISP which has NAT64
    > somewhere?

    > Or it's v6-only uplink to the corporate core/backbone, which
    > has NAT64 deployed?

Those are potentially very different scenarios, I think.
Imagining an Enterprise that had enough v4 to run their own NAT64, but did
not want to run NAT44 instead takes some effort.

I can however, imagine a situation where an enterprise goes IPv6-only,
extends that all over VPNs, etc. and then some division that has a VPN
connection only (such as might contain an R&D lab!!) discovers that they
still need access to local resources that HQ didn't even know about.

[Some significant part of the operational savings for IPv6-only shows up in
the way simplified VPN configuration between sites]

Making up AAAA RRs for devices that had v4-only addresses won't work when the
device is inside the NAT64.

The case where the ISP has it running makes more sense to me.
The Enterprise got a discount by giving up their IPv4, and rejigged their
network. Probably the Enterprise's network was outsource supported to the ISP
anyway. (Two ISPs I work with have this plan in mind, but neither has yet
gone ahead with it, to my knowledge)

Again, the "oops" situation is that the network had some internal resources
that were not IPv6 ready.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Oct 2018 10:22:26 +1100

> I'm not saying it's realistic today, but maybe it would be in the future.

Well, to find out how it's supposed to work more details might be required.

> still need access to local resources that HQ didn't even know about.

So that division is IPv6-only and how they need to access IPv4-only resources?
Well, it means that there will be NAT64 between v6-only and v4-only parts.

> device is inside the NAT64.

It looks like a design issue to me. NAT64 is supposed to be at the
border between
v6-only and v4-only/dual-stack networks.

> gone ahead with it, to my knowledge)

Well, this one looks a case for 464XLAT, no? You do not even need
DNS64 in this case.

> that were not IPv6 ready.

If the clients which need to access them, are dual-stacked, then they
should not be using DNS64 => the network should not be sending Pref64
option. Out of scope.
If the clients are v6-only, then those internal resources will be
sitting behind NAT64.

Or am I missing something here?
-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Oct 2018 08:45:12 +0900

> device is inside the NAT64.

Ok, but how is returning an A record going to help here? If the device
doesn't have an IPv4 address, even if you give it an A record, it's not
going to be able to use that A record to actually connect to the thing it
wants to connect to.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Oct 2018 08:53:44 +0900

> the API will have to undo the DNS64 mapping before doing its own.

So you're talking about a case where a sophisticated application:

   1. Doesn't have an IPv4 address and wants to connect to an IPv4-only
   destination.
   2. Knows that on this specific network, for specific IPv4 destinations,
   it should use some IPv4-to-IPv6 transition mechanism that the DNS64 doesn't
   know about.

At the moment I can't think of when this would happen, but even if it does,
it seems quite simple to solve: provide an API that the application can use
to find out the NAT64 prefix. That way the sophisticated application can
simply undo the synthesis, get the A record and do whatever it wants with
it.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Oct 2018 21:37:38 -0400

> Well, it means that there will be NAT64 between v6-only and v4-only

No, I think you are thinking about this wrong.
Consider an IPv4 *island* in the middle of an IPv6-only network.

A host inside the IPv4 island needs direct IPv4 connectivity to some RFC1918
numbered devices nearby, but if it has to talk to IPv4-only Internet host
(e.g. github.com), then it needs a NAT64 address.

Just being able to say

    > Well, this one looks a case for 464XLAT, no? You do not even need

The rest of the Enterprise has NAT64/DNS64, so setting up 464XLAT would seem
to be an extra hassle that would piss off the Enterprise IT people.

    > should not be using DNS64 => the network should not be sending Pref64

The network *does* send Pref64 out, because the majority of the hosts are not
intended to be dual-stacked.

    > Or am I missing something here?

You are thinking like the operator of a homogeneous network where all hosts
are expected to act identically.  I am speaking of Enterprises where 90% of
the hosts behave the same, but a small number have specific requirements, yet
manually configuring EVERYTHING on them is annoying and error-prone.

So, just to be clear, I think we are talking about this comment in the draft:

I think that as long as the host knows which prefixes are IPv4 (such as
because it is directly connected and/or has a route to those network), then
the host, knowing the NAT64 prefix, can intelligently avoid translating.

We don't describe this kind of behaviour, but it since we are facilitating
moving the DNS64 to the host (and I like this for DNSSEC reasons), I think
that the host can therefore decide.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Oct 2018 21:40:50 -0400

Lorenzo Colitti <[email-masked]> wrote:
    > doesn't have an IPv4 address, even if you give it an A record, it's not going
    > to be able to use that A record to actually connect to the thing it wants to
    > connect to.

Consider a desktop system in, or connected to, a lab environment.

It has two interfaces (or VLANs, I don't care).
One interface is on the enterprise LAN, and has IPv6-only.

The other interface is into the lab network, and has RFC1918, and/or IPv4-LL,
and/or ULA.  There is no default IPv4 route.  (The lab may well have GUA IPv6
as well, but many devices are legacy)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Oct 2018 11:05:55 +0900

> the host, knowing the NAT64 prefix, can intelligently avoid translating.

If the host is IPv6-only, then what is it going to do instead? It can't use
IPv4 because it doesn't have an IPv4 address.

We can certainly change this text, but we need to think very carefully
before we decide to make the option more complex unless that complexity is
useful to IPv6-only hosts which is the common case. Just because we *can*
add the ability to communicate complex policy to the host doesn't mean we
need to do so.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Oct 2018 13:37:18 +1100

> as well, but many devices are legacy)

It's not an IPv6-only scenario, again. Actually this is a multihomed
host, so it's covered in the section 6.

(In a real life I'd doubt that DNS - at least corporate ones,
reachable via v6-only link - would be used to resolve names for hosts
in that lab network).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Oct 2018 22:53:50 -0400

> host, so it's covered in the section 6.

I agree.

I think that, in the end, I'm arguing that the ID is fine as it is, and that
there is something lacking in the end-host design/architecture here.

    > reachable via v6-only link - would be used to resolve names for hosts

I agree that it's often the case that corporate DNS is often woefully empty.
A number of operating systems populate DNS from (active) directory contents,
we are discussing mechanism in DNS-SD (and Homenet) that would make populating DNS
easy,  and finally it's not unusual to convince it to delegate
"lab.example.com" to the lab, or for example.com to have an associated example-labs.com.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Oct 2018 11:54:56 +0900

> as well, but many devices are legacy)

I don't think this case is actually going to work in practice, since pretty
much all operating systems are PVD-aware and will treat these as two
separate networks by putting them into their own implicit PVD with or
without this draft. In this case you might think it's a bad thing, because
it will cause your hybrid setup not to work. But if you think about it some
more I think you'll agree that it is actually the right thing to do to put
the lab network in its own PVD. For example: it doesn't make sense for the
device to put the lab network in the same PVD as the mobile data
connection. It probably also doesn't make any sense for it to put the lab
network in the same PVD as the enterprise guest network, either. And so on.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Oct 2018 14:20:38 +1100

On Tue, Oct 9, 2018 at 12:37 PM Michael Richardson
<[email-masked]> wrote:
> Consider an IPv4 *island* in the middle of an IPv6-only network.>

I understand the scenario. I actually have to deal with it.
I just think that it's not an IPv6-only network when DNS64 should be used.
IMHO we have solutions for such scenario (464XLAT or placing those
resources behind NAT64).  Tweaking the tool designed for v6-only hosts
to make it work for dual-stack hosts might not be a really good idea.

> to be an extra hassle that would piss off the Enterprise IT people.

Quite possibly. The question is: is it a good reason to overload the
RA option with information which might not be ever used by 99.9% of
devices?

> manually configuring EVERYTHING on them is annoying and error-prone.

Well, I happen to operate such an enterprise network...;))
I totally agree that we can come up with tons of very creative
enterprise scenarios
when migrating to IPv6-only would be problematic.
I'm just not sure we shall over-engineer a simple tool to fit all sizes..

>    destinations without the NAT64.

That section clearly mentions IPv6-only networks.
Using DNS64 in dual-stack network is different story (and you have
given a number of examples when it could be tricky).

> the host, knowing the NAT64 prefix, can intelligently avoid translating.

Hmm..It's interesting. So are you saying that a dual-stack host which
has a route to 192.0.2.0/24 might choose not to translate addresses in
that network?  What if it has a route to 0/0?

Speaking of enterprise environment...
rfc6052 explicitly says '

The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].

Does it mean that hosts already have a way to know which prefixes are
not to be translated using the WKP?

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Oct 2018 09:12:13 +0000

> On 8 Oct 2018, at 14:16, Michael Richardson <[email-masked]> wrote:
> 

Isn't this the case for Chinese universities, where their CERNET2 backbone was deployed IPv6-only?

It's discussed in RFC6219.

Is there anyone on list from such a university, or who has experience there?  

Tim