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

From: Ole Troan <[email-masked]>
Date: Wed, 5 Dec 2018 21:16:34 +0100

This message starts a two week 6MAN call on adopting:

   Title     : Discovering PREF64 in Router Advertisements
   Authors   : L. Colitti, E. Kline, J. Linkova
   Filename  : draft-pref64folks-6man-ra-pref64-02
   Pages     : 8
   Date      : 2018-10-01

   https://datatracker.ietf.org/doc/draft-pref64folks-6man-ra-pref64

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing
list. Editorial suggestions can be sent to the authors.  This adoption
call will end on December 19, 2018.

Could those who are willing to work on this document,
either as contributors, authors or reviewers please notify the list.
That gives us an indication of the energy level in the working group
to work on this.

Regards,
Bob and Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 05 Dec 2018 22:09:42 +0100

Hi Ole,

As indicated several times, I think this document is needed and I will be able to continue providing inputs, review, or whatever may be needed.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: miércoles, 5 de diciembre de 2018, 21:17
Para: 6man WG <[email-masked]>
CC: 6man Chairs <[email-masked]>
Asunto: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

    

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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: Fred Baker <[email-masked]>
Date: Wed, 5 Dec 2018 19:09:47 -0600

I, for one, am in favor.

> On Dec 5, 2018, at 2:16 PM, Ole Troan <[email-masked]> wrote:
> 

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 06:49:59 +0000

Hi all,

I don't support this document for the following reasons: 

* There are already three (3) existing standardized IETF solutions to solve the problem, including DHCP as discussed in https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-11#section-3.2.1.  

* If none of the three above solutions can fit the requirements of a deployment, specific provisioning mechanisms supported by those networks can be used instead of using RA. Typically, a dedicated PCO object can be defined to provision whatever information to a 3GPP UE (if needed). 

* Requiring updates to access routers to convey an information that can be passed by other channels is not justified and not appropriate.  

I don't see a new problem that needs to be fixed.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Ole Troan
> Envoyé : mercredi 5 décembre 2018 21:17
> À : 6man WG
> Cc : 6man Chairs
> Objet : Adoption call for <draft-pref64folks-6man-ra-pref64-02>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Dec 2018 22:10:39 +0900

On Thu, Dec 6, 2018 at 3:50 PM <[email-masked]> wrote:

> * There are already three (3) existing standardized IETF solutions to
> solve the problem, including DHCP as discussed in
> https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-11#section-3.2.1
> .

None of these mechanisms is capable of providing complete L3 configuration
of an IPv6-only node in a single packet.

>  * If none of the three above solutions can fit the requirements of a
> deployment, specific provisioning mechanisms supported by those networks
> can be used instead of using RA. Typically, a dedicated PCO object can be
> defined to provision whatever information to a 3GPP UE (if needed).

PCO is the wrong place for this kind of thing. In 3GPP networks, IP address
configuration is carried by RA.

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 13:30:26 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 6 décembre 2018 14:11
À : BOUCADAIR Mohamed TGI/OLN
Cc : Ole Troan; IETF IPv6 Mailing List; 6man Chairs
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

On Thu, Dec 6, 2018 at 3:50 PM <[email-masked]<mailto:[email-masked]>> wrote:
I don't support this document for the following reasons:

None of these mechanisms is capable of providing complete L3 configuration of an IPv6-only node in a single packet.
[Med] That’s not the point. The problem is about how to discover NAT64 prefixes, not about IPv6 configuration. The fact is that the IETF has already three ways to achieve that. I still don’t see a valid technical argument for adding another tool to that, already long, list.

PCO is the wrong place for this kind of thing.
[Med] Really? DNS and other useful information are carried in PCOs. What is good with PCO is you don’t need another channel for conveying configuration data to a UE.

In 3GPP networks, IP address configuration is carried by RA.

[Med] I’m very familiar with that but still I don’t see what new problem you are trying to solve.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Dec 2018 22:44:07 +0900

On Thu, Dec 6, 2018 at 10:30 PM <[email-masked]> wrote:

> [Med] That’s not the point. The problem is about how to discover NAT64
> prefixes, not about IPv6 configuration. The fact is that the IETF has
> already three ways to achieve that. I still don’t see a valid technical
> argument for adding another tool to that, already long, list.
>

The NAT64 prefix *is* a IPv6 configuration parameter. It is required for
address synthesis, DNSSEC support, and 464xlat provisioning.

The ability to provide atomic configuration of all IPv6 parameters in one
single packet is a valid technical argument for at least two reasons:

   1. It makes behaviour much more consistent and predictable because it
   removes the possibility for incomplete configuration states and race
   conditions arising from events handling in different orders.
   2. It's much faster than all the other mechanisms because it requires no
   round trips in addition to the RS/RA exchange which must always happen.

> [Med] Really? DNS and other useful information are carried in PCOs. What
> is good with PCO is you don’t need another channel for conveying
> configuration data to a UE.
>
>
>

I'm just pointing out that for IPv6 configuration, 3GPP specs usually
delegate to IETF specs. I suspect they would have done this for DNS too if
RDNSS had been available at the time the 3GPP standard for IPv6
configuration was written.

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 14:10:44 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : jeudi 6 décembre 2018 14:44

On Thu, Dec 6, 2018 at 10:30 PM <[email-masked]<mailto:[email-masked]>> wrote:
None of these mechanisms is capable of providing complete L3 configuration of an IPv6-only node in a single packet.
[Med] That’s not the point. The problem is about how to discover NAT64 prefixes, not about IPv6 configuration. The fact is that the IETF has already three ways to achieve that. I still don’t see a valid technical argument for adding another tool to that, already long, list.

The NAT64 prefix *is* a IPv6 configuration parameter. It is required for address synthesis, DNSSEC support, and 464xlat provisioning.
[Med] It is a parameter for a service provided over IPv6, if you will. That service is not a mandatory IPv6 feature. Moreover, requiring all access routers to be upgraded to support IPv4 service continuity is not a good plan from a deployment standpoint.

The ability to provide atomic configuration of all IPv6 parameters in one single packet is a valid technical argument for at least two reasons:
[Med] I fully agree with this and I’m working on cases making use of this powerful feature! That’s said, the discussion is not about RA in general but whether the piece of information discussed in your draft is worth to be conveyed in RAs. My take is that we do already have enough standards, no need to add another yet one.

  1.  It makes behaviour much more consistent and predictable because it removes the possibility for incomplete configuration states and race conditions arising from events handling in different orders.
  2.  It's much faster than all the other mechanisms because it requires no round trips in addition to the RS/RA exchange which must always happen.

I'm just pointing out that for IPv6 configuration, 3GPP specs usually delegate to IETF specs. I suspect they would have done this for DNS too if RDNSS had been available at the time the 3GPP standard for IPv6 configuration was written.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Dec 2018 23:25:38 +0900

On Thu, Dec 6, 2018 at 11:10 PM <[email-masked]> wrote:

> [Med] It is a parameter for a service provided over IPv6, if you will.
> That service is not a mandatory IPv6 feature. Moreover, requiring all
> access routers to be upgraded to support IPv4 service continuity is not a
> good plan from a deployment standpoint.
>

Access to the IPv4 Internet is not a mandatory IPv6 feature? That's a bold
statement. Try deploying a truly IPv6-only network without IPv4 and see how
many of your customers complain :-)

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 16:03:29 +0000

Lorenzo,

I’m clear in what I said: IPv4aas “is not a mandatory IPv6 feature”. You misinterpreted this as: “it is not a mandatory to provide service”, which isn’t what I said!

As far as I know, IPv4 service continuity is not considered as mandatory feature in any IPv6 profile documents endorsed by the IETF:

·         No mention in RFC6434

·         Idem for draft-ietf-6man-rfc6434-bis-09<https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-09>

·         SHOULD is used for DS-Lite in RFC7084

·         SHOULD is used in draft-ietf-v6ops-transition-ipv4aas

·         No mention in the 3GPP IPv6 profile RFC7066 (but a prefix discovery is a SHOULD in RFC7849).

My initial set of issues are still unanswered, Lorenzo.

Cheers,
Med

Envoyé : jeudi 6 décembre 2018 15:26

On Thu, Dec 6, 2018 at 11:10 PM <[email-masked]<mailto:[email-masked]>> wrote:
The NAT64 prefix *is* a IPv6 configuration parameter. It is required for address synthesis, DNSSEC support, and 464xlat provisioning.
[Med] It is a parameter for a service provided over IPv6, if you will. That service is not a mandatory IPv6 feature. Moreover, requiring all access routers to be upgraded to support IPv4 service continuity is not a good plan from a deployment standpoint.

Access to the IPv4 Internet is not a mandatory IPv6 feature? That's a bold statement. Try deploying a truly IPv6-only network without IPv4 and see how many of your customers complain :-)

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 6 Dec 2018 18:10:47 +0000

Lorenzo Colitti wrote on 06/12/2018 13:44:
> The ability to provide atomic configuration of all IPv6 parameters in 
> one single packet is a valid technical argument for at least two reasons:
> 
>  2. It's much faster than all the other mechanisms because it requires
>     no round trips in addition to the RS/RA exchange which must always
>     happen.

it's a valid technical argument in the sense that it's a "nice-to-have" 
feature.  But that doesn't seem to add enough value to justify creating 
yet another mechanism for determining nat64 prefixes, in addition to the 
three we already have.

Nick

---

From: 神明達哉 <[email-masked]>
Date: Thu, 6 Dec 2018 11:46:31 -0800

At Wed, 5 Dec 2018 21:16:34 +0100,

> call will end on December 19, 2018.

I've already read draft-pref64folks-6man-ra-pref64-02 and provided
comments.

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.

Note that it does not necessarily mean this proposal itself is a bad
one.  I'm not a fan of making RA more and more kitchen-sink
configuration protocol, but it looks like the game about this is now
over, so I won't argue about it.  But if we want to adopt this work,
I'd like the wg to seriously consider the tradeoff of introducing one
more "way of doing the same thing".  Then, ideally, this proposal will
other be abandoned or deprecate others.

> That gives us an indication of the energy level in the working group

Anyway, if it's adopted, I'm willing to review future revisions.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Dec 2018 15:45:14 -0500

> On Dec 6, 2018, at 2:46 PM, 神明達哉 <[email-masked]> wrote:
> 

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.

---

From: <[email-masked]>
Date: Fri, 7 Dec 2018 06:34:26 +0000

Hi Fred, 

I disagree.

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.

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Fred Baker
> Envoyé : jeudi 6 décembre 2018 21:45
> À : 神明達哉
> Cc : IPv6 IPv6 List; 6man Chairs
> 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.
> 
> 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.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 18:16:35 +1100

> 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);
- signalling any changes are problematic;
- some devices basically do not support those mechanisms;

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.

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.

-- 
SY, Jen Linkova aka Furry

---

From: <[email-masked]>
Date: Fri, 7 Dec 2018 07:41:47 +0000

Jen,

Please see inline. 

Cheers,
Med

> De : Jen Linkova [mailto:[email-masked]]
> Envoyé : vendredi 7 décembre 2018 08:17
> Cc : Fred Baker; 神明達哉; 6man; [email-masked]
> > 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).
> >

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

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

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

> > > Putting the prefix in the RA on a given LAN reliably identifies the
> prefix
> > > that folks on that LAN should use.
> > >

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Dec 2018 17:47:54 +0900

> yet another mechanism for determining nat64 prefixes, in addition to the

We don't have three mechanisms. We have one mechanism which has security
issues, and two standards that were written down but were never widely
deployed across the ecosystem.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Dec 2018 17:51:30 +0900

>    router is supposed to be configured with the same information.

That text ignores the operational reality that in large networks router
configuration is largely either highly uniform, using tools such as
apply-groups, or entirely autogenerated (at scale, it's the only way to
ensure network configuration is correct).

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 19:56:20 +1100

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

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

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

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

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 07 Dec 2018 09:57:52 +0100

I think in fact we should adopt both solutions, a RA based and DHCPv6 one (https://www.ietf.org/archive/id/draft-li-intarea-nat64-prefix-dhcp-option-01.txt).

Many ISPs rely in DHCPv6 to provide all the parameters, same as in RA.

Each ISP should be able to choose.

However I’m fine if we just do RA (or we just do DHCPv6).

Regards,

Jordi

De: ipv6 <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: viernes, 7 de diciembre de 2018, 9:52
Para: "<[email-masked]>" <[email-masked]>
CC: IETF IPv6 Mailing List <[email-masked]>, 神明達哉 <[email-masked]>, 6man Chairs <[email-masked]>
Asunto: Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

That text ignores the operational reality that in large networks router configuration is largely either highly uniform, using tools such as apply-groups, or entirely autogenerated (at scale, it's the only way to ensure network configuration is correct).

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

---

From: <[email-masked]>
Date: Fri, 7 Dec 2018 09:29:32 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : vendredi 7 décembre 2018 09:56
> > > > The two other mechanisms in draft-ietf-v6ops-transition-ipv4aas-
> 11#section-
> > > 3.2.1 solve that issue anyway.
> > >
> > [Med] Not sure to understand this one. No one said that you need to deploy
> dhcp just because you need to learn pref64!!
> 

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

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

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

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

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

> to configure devices. I just need one more config option to be

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

> or they have to have a route in their routing table pointing to the NAT64

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

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

> > > > > From my perspective, the value in the "why this" domain is that it
> sorts
> > > out
> > > > > 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.
> > > > >
> > > > > I'd be very happy if the other mechanisms were deprecated, and
> software
> > > and

---

From: <[email-masked]>
Date: Fri, 7 Dec 2018 09:44:49 +0000

Hi Jordi,

Please see inline.

Cheers,
Med

De : JORDI PALET MARTINEZ [mailto:[email-masked]]
Envoyé : vendredi 7 décembre 2018 09:58
À : Lorenzo Colitti; BOUCADAIR Mohamed TGI/OLN
Cc : IETF IPv6 Mailing List; 神明達哉; 6man Chairs
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

Many ISPs rely in DHCPv6 to provide all the parameters, same as in RA.
[Med] Perhaps I missed your point, but I’m not aware of any provider who uses RA for all configuration purposes.

Each ISP should be able to choose.
[Med] This is a fair discussion but a separate one. The argument applies to any piece of configuration (SIP Proxy, DS-Lite AFTR, ..).

Regards,
Jordi

On Fri, Dec 7, 2018 at 4:42 PM <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 7 Dec 2018 10:41:18 +0000

> deployed across the ecosystem.

I can understand why this might be frustrating, but this isn't a 
compelling reason for proposing a new standard.  This is bordering on 
xkcd.com/927 territory.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Dec 2018 20:38:09 +0900

> compelling reason for proposing a new standard.  This is bordering on

Comics are all very well and good, but... if we want to fix the problems
with the deployed technology, what would you have us do? The DHCPv6 version
is not useful because most of the networks that use NAT64 are 3GPP networks
that don't use DHCPv6. That leaves the PCP version.

You think 3GPP network operators will deploy PCP just for this? They won't.
What will happen is that the industry will continue to use the insecure
slow version instead, because we (the IETF) weren't able to put solid
engineering ahead of process.

So in practice, you're advocating for keeping the problems with the
existing RFC7050 mechanism. You have a right to that opinion, but it would
be better if you stated more clearly that that is your preferred outcome.
:-)

---

From: Fernando Gont <[email-masked]>
Date: Sat, 8 Dec 2018 06:35:25 -0300

On 7/12/18 08:38, Lorenzo Colitti wrote:
> On Fri, Dec 7, 2018 at 7:41 PM Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     xkcd.com/927 <http://xkcd.com/927> territory.
> 
> 
> with the deployed technology, what would you have us do? The DHCPv6
> version is not useful because most of the networks that use NAT64 are
> 3GPP networks that don't use DHCPv6. That leaves the PCP version.

Every time we get on the path to duplicate stuff on SLAAC, I wonder why
we don't require the use of the DHCPv6 version, or why we simply don't
plan to e.g. close dhc wg. i.e., if we are not systematically not going
to use what they produce, why does the dhc wg exist in the first place?

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Sander Steffann <[email-masked]>
Date: Sat, 8 Dec 2018 14:09:11 +0100

Hi,

> to use what they produce, why does the dhc wg exist in the first place?

I'm still in favour of unifying RA and DHCPv6 options so that we have one set of options with two distribution mechanisms. As DHCPv6 options cover more than RA options do, I think it would be a good starting point. Once operating systems implement pushing those options from the RA to the DHCPv6 client (or to a generic network-option handling process) everybody can use the delivery mechanism of their choice. People like Lorenzo can do everything with RA, and enterprises that want DHCPv6 can do exactly the same with that.

One set of options, conceptually cleaner, ore flexibility, and all that is needed is a small bit of code that lets RA options be handled by a user space process...

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Sat, 8 Dec 2018 14:21:57 +0100

> On 8 Dec 2018, at 10:35, Fernando Gont <[email-masked]> wrote:
> 

There is a long history behind why we are were we are. The original IPv6 intention was that ND should be used to configure only the core network layer parameters, there would be no DHCP and all other options were services, and discovered through service discovery. 

Unfortunately we failed spectacularly in that vision. It’s never to late, if anyone has ideas for service discovery take #4. 

Cheers 
Ole

---

From: David Farmer <[email-masked]>
Date: Sun, 9 Dec 2018 14:34:32 -0600

I support this adoption of this document.

I wish to deploy IPv6-only with NAT64 in an enterprise BYOD environment
without requiring the use of enterprise DNS resolvers that support DNS64.
This is to allow the use of public DNS resolvers and/or host-based DNSSEC
validation. It means the hosts need to learn the NAT64 prefix somehow.

As to the controversy so far, RFC7050 doesn't meet my requirements, as it
effectively requires the use the enterprise DNS resolvers and further has
issues with DNSSEC validation. As this is not a cellular environment PCP
isn't a practical option. Leaving DHCPv6, theoretically, DHCPv6 would be
sufficient. However, not all host implementations do DHCPv6, at least to
date.

If all hosts implemented DHCPv6, providing the NAT64 prefix via RAs would
be completely redundant. However, this is a long-debated controversy that I
feel has no positive resolution. Therefore I support providing the NAT64
prefix via RAs for practical reasons, in addition to DHCPv6.

As to if NAT64 is a mandatory IPv6 feature, while theoretically and in the
long-term NAT64 is not mandatory. However, in the near to medium-term
either NAT64 or a functioning IPv4 address is required, be it provided by
NAT44, in the network CLAT, native IPv4, etc... Therefore, if you want to
deploy IPv6-only NAT64 is a mandatory IPv6 feature, at least in the near to
medium-term.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Jen Linkova <[email-masked]>
Date: Mon, 10 Dec 2018 09:23:51 +1100

On Fri, Dec 7, 2018 at 8:29 PM <[email-masked]> wrote:
> > > No one said that you need to deploy dhcp just because you need to learn pref64!!

> * If you are in a fixed network (likely a CPE), it is likely that you already support DHCP for other matters.

Here we are. I'm not sure where this assumption is coming from. What
about networks which do not have DHCP?
You are saying "if you are in a fixed network, you are supposed to
deploy DHCPv6 to get NAT64 prefix", aren't you?
That's exactly what I'm trying to avoid.
SLAAC is designed to configure IPv6 hosts (and by "configure" I mean
"provide all info which is required for the host to get network
connectivity").
Currently one critical bit of information is missing: NAT64 prefix and
it would be great to provide it to hosts by suing SLAAC (and SLAAC
only).

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

Sure, if you are using PCP you do not need this RA option, probably.
However 4 scenarios you've just described do not cover a fixed (e.g.
enterprise) network which does not have DHCP or SLAAC.

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

I'm not sure I understand how/why configuring multiple servers (+
potentially multiple routes) with site/context-specific information is
easier than configuring just routers.
> [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 pr…

Sorry, I should have been more clear. "Signalling changes back to
hosts", not "signalling the changes from the intent to routers".
SLAAC allows propagating changes much faster.

Again, I do not think this discussion is really relevant. Obviously,
if a network operator decided to go SLAAC-only, the problem of
configuring large number of routers with either same or site-specific
information is solved for them somehow.
SLAAC is the standard way to configure hosts. It's perfectly valid
operational decision to deploy SLAAC-only networks.

There is no way for devices in SLAAC-only non-cellular networks to
reliably discover NAT64 prefix.

You are saying that DHCPv6 and PCP could help with NAT64 prefix
discovery. If to deploy NAT64 network I need to deploy either DHCPv6
or PCP it would be a serious roadblock on the way of IPv6-only
deployments so we should not be suggesting this.

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

None of them are required for a host to get network connectivity.
NAT64 prefix is.

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

I'd not call it "access router", it's more "border router". What I'm
talking about is datacenter and enterprise networks.

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

I'm more and more confused. So, if I do not need to enable X (where X
seems to be DHCPv6 or PCP) how do you suggest my hosts iscover NAT64
prefix w/o having all those security issues RFC7050 has?

---

From: <[email-masked]>
Date: Mon, 10 Dec 2018 06:58:01 +0000

Hi Jen, 

Please see inline. 

Cheers, 
Med

> Envoyé : dimanche 9 décembre 2018 23:24
> Cc : 6man
> >* 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.
> >

[Med] Which ones? 

> deploy DHCPv6 to get NAT64 prefix", aren't you?

[Med] I'm referring to fixed broadband services relying on a CPE. DHCP is widely used in those networks.  

> it would be great to provide it to hosts by suing SLAAC (and SLAAC

[Med] I guess we already discussed this point. The same requirement apply for any information you may want to provide to a host. People who want to provision a DS-Lite AFTR, DOTS server, etc. may have the same requirement as you. 

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

[Med] I'm sure there are tools used in those networks to provision services/hosts. Those tools can be reused. 

> easier than configuring just routers.

[Med] That is not the point. The comment was about whether it is possible to provision distinct prefixes using DHCP. 

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

[Med] None? Really? 

Let's consider one sample as the intent is not to be exhaustive. 

Given that A+P is providing a similar service as NAT64, a IPv6-only host requires to be provisioned a similar information contained in DHCP options:

==
89 	OPTION_S46_RULE 	No 	No[2] 	[RFC7598]
90 	OPTION_S46_BR 	No 	No 	[RFC7598]
91 	OPTION_S46_DMR 	No 	Yes 	[RFC7598]
92 	OPTION_S46_V4V6BIND 	No 	Yes 	[RFC7598]
93 	OPTION_S46_PORTPARAMS 	No 	Yes 	[RFC7598]
94 	OPTION_S46_CONT_MAPE 	Yes 	No 	[RFC7598]
95 	OPTION_S46_CONT_MAPT 	Yes 	Yes 	[RFC7598]
96 	OPTION_S46_CONT_LW 	Yes 	Yes 	[RFC7598]
== 

> NAT64 prefix is.

[Med] See above. MAP-* or DS-Lite information is another example of required to provide IPv4 service continuity over an IPv6 network. 

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

[Med] What tool you are using to configure services in these networks?

---

From: <[email-masked]>
Date: Mon, 10 Dec 2018 07:27:25 +0000

Hi David,

I have some questions for clarification :

·         Why the enterprise will be advertising the RA with PREF64 at the first place rather than another channel? Why the enterprise has to upgrade its routers, while the same piece of information can be provided using other straightforward means?

·         Can you please clarify why using a public resolver is a requirement? Is it to avoid some “filtering”/”tracking” at the enterprise network, for example?

·         “if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature”: The same reasoning would apply for MAP-*, DS-Lite, Lw4over6. Why then define an option for only one alternate approach?

Thank you.

Cheers,
Med

De : ipv6 [mailto:[email-masked]] De la part de David Farmer
Envoyé : dimanche 9 décembre 2018 21:35
À : 6man WG
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

I wish to deploy IPv6-only with NAT64 in an enterprise BYOD environment without requiring the use of enterprise DNS resolvers that support DNS64. This is to allow the use of public DNS resolvers and/or host-based DNSSEC validation. It means the hosts need to learn the NAT64 prefix somehow.

As to the controversy so far, RFC7050 doesn't meet my requirements, as it effectively requires the use the enterprise DNS resolvers and further has issues with DNSSEC validation. As this is not a cellular environment PCP isn't a practical option. Leaving DHCPv6, theoretically, DHCPv6 would be sufficient. However, not all host implementations do DHCPv6, at least to date.

If all hosts implemented DHCPv6, providing the NAT64 prefix via RAs would be completely redundant. However, this is a long-debated controversy that I feel has no positive resolution. Therefore I support providing the NAT64 prefix via RAs for practical reasons, in addition to DHCPv6.

As to if NAT64 is a mandatory IPv6 feature, while theoretically and in the long-term NAT64 is not mandatory. However, in the near to medium-term either NAT64 or a functioning IPv4 address is required, be it provided by NAT44, in the network CLAT, native IPv4, etc... Therefore, if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature, at least in the near to medium-term.

Thanks.

On Wed, Dec 5, 2018 at 2:16 PM Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
This message starts a two week 6MAN call on adopting:

David Farmer               Email:farmer@umn..edu<mailto:[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Dec 2018 08:43:31 +0100

One thing I can’t quite grasp from reading the draft.
This decouples discovery of the NAT prefix from the DNS infrastructure.
How is the host meant to synthesize AAAA records in this solution?

Cheers,
Ole

> On 5 Dec 2018, at 21:16, Ole Troan <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 10 Dec 2018 20:22:21 +1100

> > about networks which do not have DHCP?

Which network? Well, one I'm writing this email from, for example.

> [Med] I'm referring to fixed broadband services relying on a CPE. DHCP is widely used in those networks.

I'm not sure I understand your point. There are networks out there
which decided to use DHCPv6 (or PCP). Well, that's OK.
There are networks out there which decided to utilize SLAAC. We need
solution for them (and that solution should not be 'enable DHCPv6').

> [Med] I guess we already discussed this point. The same requirement apply for any information you may want to provide to a host. People who want to provision a DS-Lite AFTR, DOTS server, etc. may h…

I do not think we have seen them coming to 6man@ with the proposal and use case.
For NAT64 RA option we have people who need it (and based on the
session recording from Bangkok I dare say it's not just me).

> [Med] I'm sure there are tools used in those networks to provision services/hosts. Those tools can be reused.

Provision == configure network stack? Yep, that tool is called SLAAC.

> Given that A+P is providing a similar service as NAT64, a IPv6-only host requires to be provisioned a similar information contained in DHCP options:

I'm not sure I understand why a host needs this but...Are we talking
about existing practical use cases people need and are going to
deploy,
or it's just an exercise?

> [Med] See above. MAP-* or DS-Lite information is another example of required to provide IPv4 service continuity over an IPv6 network.

Firstly I have to confess that I still do not understand what a host
is going to do with all that information.
Secondly I'm afraid I'm a bit lost what exactly is your argument
against having NAT64 prefix in RA... so let me try to summarize it
just to ensure I understand
it correctly and we are on the same page.

You've said that we should not have NAT64 RA option because there are
other mechanisms to provide hosts with NAT64 prefix. My answer is that
for cellular  networks which do not use DHCPv6 or PCP there is no
reliable way to do that. The approach of "they should deploy DHCPv6 or
PCP" is harmful for IPv6-only deployments.
Your second argument seems to be "we should not have NAT64 RA option
because there are a lot of other things which we can put in RA options
but we have not so far." Have I captured it right?
Well, the only thing I can say that if there are networks out there
which have use case for some other information which needs to be
carried in RA - well, I'm sure they could propose it and the group
would discuss the idea.

> [Med] What tool you are using to configure services in these networks?

Hosts are configured by SLAAC.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 10 Dec 2018 20:29:26 +1100

On Mon, Dec 10, 2018 at 6:27 PM <[email-masked]> wrote:
> ·         Why the enterprise will be advertising the RA with PREF64 at the first place rather than another channel?

Why would the enterprise will be advertising PREF64 via some
additional channels (which need to be created and maintained) at the
first place rather than using the mechanism which is already in place?

>Why the enterprise has to upgrade its routers,

Because it's a part of lifecycle management process, routers do get
upgraded periodically to fix bugs and get new features.

>while the same piece of information can be provided using other straightforward means?

Because they do not have those "other straightforward means" deployed
but they have SLAAC.

> ·         Can you please clarify why using a public resolver is a requirement? Is it to avoid some “filtering”/”tracking” at the enterprise network, for example?

- enterprise resolver might not be DNS64 enabled;
- enterprise might *already* use public resolver in some  parts of the network.

> ·         “if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature”: The same reasoning would apply for MAP-*, DS-Lite, Lw4over6. Why then define an option for only one alternate approach?

Baby steps. We have an use case - we define an option.

> David Farmer               Email:farmer@umn..edu

---

From: <[email-masked]>
Date: Mon, 10 Dec 2018 10:16:51 +0000

> solution for them (and that solution should not be 'enable DHCPv6').

[Med] I hear you but the argument is not specific to the pref64 discovery. The argument applies to any configuration piece of information let it be an NTP server, A+P mapping rules, etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Dec 2018 19:53:36 +0900

Not sure I understand the question. The option informs the host of the
NAT64 prefix that it can use to reach the IPv4 Internet. This is the prefix
that the network routes to the NAT64. The host can then synthesize AAAA
records as usual, by doing an A lookup and appending the result to the
NAT64 prefix.

Among other things, this allows the host to do AAAA synthesis even if it's
not using the DNS infrastructure provided by the network - for example, if
it's using DNS-over-TLS or DNS-over-HTTPS to a server that's not the
network-provided DNS server.

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Dec 2018 12:35:18 +0100

Hi Lorenzo,

> Not sure I understand the question. The option informs the host of the NAT64 prefix that it can use to reach the IPv4 Internet. This is the prefix that the network routes to the NAT64. The host can then synthesize AAAA records as usual, by doing an A lookup and appending the result to the NAT64 prefix.
> 
> Among other things, this allows the host to do AAAA synthesis even if it's not using the DNS infrastructure provided by the network - for example, if it's using DNS-over-TLS or DNS-over-HTTPS to a server that's not the network-provided DNS server.

Let me try to clarify my question.
With RFC7050 the host discovers a DNS64 it can use. With this proposal it does not.
If it is required or even if it is not, should the document not state that this solution requires host-local AAAA synthesis?
And if not, state how the host is expected to discover an external DNS64.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Dec 2018 21:19:40 +0900

On Mon, Dec 10, 2018 at 8:35 PM Ole Troan <[email-masked]> wrote:

> If it is required or even if it is not, should the document not state that
> this solution requires host-local AAAA synthesis?

I'm still confused. RFC 7050 doesn't discover a DNS64 server. It uses the
DNS server it already knows about (e.g, through RDNSS or PCO) to discover
the NAT64 prefix in use by the network. It does this by doing an AAAA
lookup for ipv4only.arpa and deducing the NAT64 prefix from that. For
example, if it gets 2001:db8:64::192.0.0.170 it concludes that the NAT64
prefix is 2001:db8:64::.

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Dec 2018 14:51:49 +0100

Lorenzo,

> I'm still confused. RFC 7050 doesn't discover a DNS64 server. It uses the DNS server it already knows about (e.g, through RDNSS or PCO) to discover the NAT64 prefix in use by the network. It does this by doing an AAAA lookup for ipv4only.arpa and deducing the NAT64 prefix from that. For example, if it gets 2001:db8:64::192.0.0.170 it concludes that the NAT64 prefix is 2001:db8:64::.

A solution based on RFC7050 ties the NAT64 and the DNS64 functions together (although not in the NAT-PT way) in the sense that you discover both, and they both would essentially be operated by the same site.

NAT64 via RA doesn’t do that. To me that reads like something is missing. Are you going to ask for a DNS64 RA option to be standardized next?
If not, the draft needs to say how this is supposed to work.

Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 10 Dec 2018 15:18:52 +0100

> There is a long history behind why we are were we are. The original
> IPv6 intention was that ND should be used to configure only the
> core network layer parameters, there would be no DHCP and all other
> options were services, and discovered through service discovery.
> 
> Unfortunately we failed spectacularly in that vision. Its never to
> late, if anyone has ideas for service discovery take #4.

I find this a weird argument.

First, by and large, DHCP works in IPv4 networks. Of course it is not perfect,
but there is no reason to assume it would not work for IPv6. Large scale
deployment of DHCP-PD suggests that it works perfectly fine.

So there may be a vision of a new way of doing service discovery, but 
until that time, it makes perfect sense to use DHCP.

But then comes the really weird part, because this final ultimate solution
to service discovery has not arrived yet, we are now putting everything
and the the kitchen sink in RAs.

And the argument is not, DHCPv6 is really broken, can't be fixed, so we have
to use RA. No the argument is that some device vendors refuse to support
DHCPv6, therefor we have to put new options in RA.

The really nice feature of DHCP is that you can easily tailor responses to
individual hosts. Somehow alternatives to DHCP (DNS-SD, RA) manage to lose 
that feature.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Dec 2018 23:30:11 +0900

On Mon, Dec 10, 2018 at 10:51 PM Ole Troan <[email-masked]> wrote:

> > I'm still confused. RFC 7050 doesn't discover a DNS64 server. It uses
> the DNS server it already knows about (e.g, through RDNSS or PCO) to
> discover the NAT64 prefix in use by the network. It does this by doing an
> AAAA lookup for ipv4only.arpa and deducing the NAT64 prefix from that. For
> A solution based on RFC7050 ties the NAT64 and the DNS64 functions
> together (although not in the NAT-PT way) in the sense that you discover
> both, and they both would essentially be operated by the same site.
>

As explained in RFC 6147 section 2, DNS64 supports multiple modes of
operation, one of which is:

   The last option is to place the DNS64 function in the end hosts,
   coupled to the local (stub) resolver.  In this case, the stub
   resolver will try to obtain (real) AAAA RRs, and in case they are not
   available, the DNS64 function will synthesize AAAA RRs for internal
   usage.  This mode is compatible with some functions like DNSSEC
   validation in the end host.  The main drawback of this mode is its
   deployability, since it requires changes in the end hosts.  This mode
   is called "DNS64 in stub-resolver mode".  This is the second type of
   DNS64 resolver.

The pref64 RA option is useful in this mode of DNS64. In this option, the
end hosts performs all A queries and AAAA synthesis itself using whatever
DNS server it uses to resolve hostnames. That server doesn't need to be a
DNS64 and doesn't need to know what the NAT64 prefix is. This mode is more
secure because it supports DNSSEC validation in the host and DNS-over-TLS
to a recursive resolver that the user of the trusts.

> NAT64 via RA doesn’t do that. To me that reads like something is missing.
> Are you going to ask for a DNS64 RA option to be standardized next?

Would it clarify to say that the RA option is useful for "DNS64 in
stub-resolver mode as defined in RFC 6147"?

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Dec 2018 15:37:49 +0100

> On 10 Dec 2018, at 15:30, Lorenzo Colitti <[email-masked]> wrote:
> 
> As explained in RFC 6147 section 2, DNS64 supports multiple modes of operation, one of which is:
> 
> The pref64 RA option is useful in this mode of DNS64. In this option, the end hosts performs all A queries and AAAA synthesis itself using whatever DNS server it uses to resolve hostnames. That server doesn't need to be a DNS64 and doesn't need to know what the NAT64 prefix is. This mode is more secure because it supports DNSSEC validation in the host and DNS-over-TLS to a recursive resolver that the user of the trusts.
>  
> Would it clarify to say that the RA option is useful for "DNS64 in stub-resolver mode as defined in RFC 6147"?

Yes, very much so. You could even include the paragraph above. 

Thank!
Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 10 Dec 2018 15:42:47 +0100

Actually, I think there is one more case where it helps.

CPE has a CLAT, but the user changed the DNS. If the CPE is getting the NAT64 prefix with RA, it can the also use it if he is acting as the DNS-proxy for the LANs, or even autoconfigure the same NAT64 in the RAs being sent to the LANs.

Regards,

Jordi

De: ipv6 <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: lunes, 10 de diciembre de 2018, 15:30
Para: Ole Troan <[email-masked]>
CC: IETF IPv6 Mailing List <[email-masked]>, 6man Chairs <[email-masked]>
Asunto: Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

   DNS64 resolver.

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Dec 2018 16:57:06 +0100

Philip,

> I find this a weird argument.

But of course.

> individual hosts. Somehow alternatives to DHCP (DNS-SD, RA) manage to lose 

Please let’s not turn this into an emacs versus vi debate, sorry I meant DHCP versus SLAAC.

There is a fundamental tussle here, that we just have to accommodate.

On one side, the network where the operator expects to be able to configure any set of parameters on hosts that are allowed to connect and expects hosts to trust the network

vs

The autonomous host that connects to a network, detects and discovers the services it is interested in, and uses those. And does not trust the network.

Cheers,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 10 Dec 2018 17:12:05 +0000

Hi Sander,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Sander Steffann
> Sent: Saturday, December 08, 2018 5:09 AM
> To: Fernando Gont <[email-masked]>
> Cc: IETF IPv6 Mailing List <[email-masked]>; Suresh Krishnan <[email-masked]>; 6man Chairs <[email-masked]>;
> Lorenzo Colitti <lorenzo=[email-masked]>
> Subject: Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>
> 
> Hi,
> 
> I'm still in favour of unifying RA and DHCPv6 options so that we have one set of options with two distribution mechanisms. As DHCPv6
> options cover more than RA options do, I think it would be a good starting point. Once operating systems implement pushing those
> options from the RA to the DHCPv6 client (or to a generic network-option handling process) everybody can use the delivery
> mechanism of their choice. People like Lorenzo can do everything with RA, and enterprises that want DHCPv6 can do exactly the same
> with that.
> 

You may be interested to know that there is a proposal for combining IPv6ND
and DHCPv6 into a single unified service:

https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

It works by having IPv6ND RS/RA messages include an embedded DHCPv6
message. So, all messages on the wire are RS/RA, but DHCPv6 messages
are carried as payload. It is backwards-compatible and requires only the
standardization of a single new IPv6ND option. It would also eliminate
the need to clone existing DHCPv6 options as new IPv6ND options and
vice-versa. Does it satisfy the requirements?

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Dec 2018 11:40:47 -0600

On Mon, Dec 10, 2018 at 1:36 AM <[email-masked]> wrote:

> ·         Why the enterprise will be advertising the RA with PREF64 at
> the first place rather than another channel?
>
Just as we do for DNS today we will advertise PREF64 both via DHCPv6 and
the RA, again DHCPv6 isn't supported by all host OSes. I don't feel like
arguing this issue any more, I take it as a fact I need to live with. We
will probably also implement RFC7050, I just don't feel I can rely on it,
because of public DNS use and DNSSEC validation issues, but it will work
for some good percentage of BYOD users, just not all.

> Why the enterprise has to upgrade its routers, while the same piece of
> information can be provided using other straightforward means?
>
Sorry, but I have to upgrade my routers on a regular basis, otherwise, my
security folks would go apoplectic. We don't run centralized DHCPv6 we run
Stateless DHCPv6 in our routers anyway, so from my perspective adding
PREF64 to the RA isn't that big of a deal.

> Can you please clarify why using a public resolver is a requirement? Is it
> to avoid some “filtering”/”tracking” at the enterprise network, for example?
>
As I said this is an enterprise BYOD environment, I can't definitively
speak to why my BYOD users have chosen to configure public DNS, but they
have and are configuring it. I suspect it is a combination of privacy and
they had some kind of issue once, configured public DNS as an attempt to
fix it, and have simply left it configured. I'll bet many of them don't
even realize that have a public DNS configured.

> ·         “if you want to deploy IPv6-only NAT64 is a mandatory IPv6
> feature”: The same reasoning would apply for MAP-*, DS-Lite, Lw4over6. Why
> then define an option for only one alternate approach?
>
If those options were implemented in most hosts then I would support that,
but as far as I know most of those are not implemented in hosts, but only
implemented in CPE or other network infrastructure.

Most hosts, or at least their browsers, are implementing some mechanism
that uses PREF64, either happy eyeballs 2, in the host CLAT, bump-in stack,
IPv4 literals, etc...
If some host are willing to get that via an RA I'm willing to support that.

> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* ipv6 [mailto:[email-masked]] *De la part de* David Farmer
> *Envoyé :* dimanche 9 décembre 2018 21:35
> *À :* 6man WG
> *Objet :* Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>
>
>
>
> David Farmer               Email:farmer@umn..edu <[email-masked]>

---

From: Sander Steffann <[email-masked]>
Date: Mon, 10 Dec 2018 18:41:50 +0100

Hi Fred,

> vice-versa. Does it satisfy the requirements?

Not completely. I know that Lorenzo wants to push new options/values whenever the network wants the clients to update their settings, and this seems to require the client to send a new RS after it receives an RA with the Reconfigure option. At that point we're back at normal DHCPv6 behaviour, just with an extra layer of encapsulation. To make this useful for both Push (RA) and Pull (DHCPv6) scenarios there is a need to include DHCPv6 options in unsolicited multicast RA messages as well.

I don't see the need to replace stateful DHCPv6 with RA options, but I do see the wish to use RA in the same way that stateless DHCPv6 is used. What you describe has almost exactly the same behaviour as a client that sends a DHCPv6 Solicit without waiting for the first RA to arrive. What your proposal does is:

Client: send RS with DHCPv6 Solicit inside it
Router: extract DHCPv6 message from RS
Router: relay DHCPv6 message
Router: wait for DHCPv6 Reply to come back
Router: combine RA and DHCPv6 Reply
Client: receive RA and DHCPv6 Reply

Combining the RA and DHCPv6 messages means that the client will only get a reply when the slowest of the two is completed, which will usually mean that the RA is delayed to wait for the DHCPv6 reply. It also means that the router has to keep more state while waiting for DHCPv6 to complete. Normal DHCPv6 relaying can be implemented stateless.

I'd rather see the client send an RS and a DHCPv6 Solicit in parallel. It can then receive the RA as quickly as possible. So for stateful or per-client specific configuration I think the existing DHCPv6 mechanisms works better than combining it with RA as you propose.

What I would prefer to see is to be able to include all the generic (non client-specific) options in the RA. There are all kinds of options that could benefit from this: DNS options in RA are an obvious example, because they already have an RA specific option. But that could be extended to much more options, like the DS-Lite AFTR, MAP-E and MAP-T mappings, timezone info, NTP servers, etc. It shouldn't be necessary that every option is defined multiple times like RFC7710 does. Such a mapping should be there by default.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Dec 2018 06:28:38 +1100

On Tue, 11 Dec 2018 at 04:42, Sander Steffann <[email-masked]> wrote:
> I don't see the need to replace stateful DHCPv6 with RA options, but I do see the wish to use RA in the same way that stateless DHCPv6 is used.

I don't.

That would mean that to deploy a newly IETF "DHCPv6 option in RA"
option, a new version of router firmware would need to be deployed to
each and every network segment where the hosts want to run the new
"DHCPv6 option in RA" option application.

This would be changing the application/service model from
"applications over the top of the network" - the Internet model, to
"applications within the network" - the traditional PSTN/telephone
network model (i.e. smart network, dumb hosts). Shifting or
replicating DHCPv6 options into RAs would really be that fundamental a
change. We shouldn't have to possibly "upgrade the network", meaning
upgrade routers, to deploy a new application.

The problem with stateless DHCPv6, and DHCP in general is that it was
designed when hosts weren't very mobile. Now they are, so there is a
new requirement that DHCPv6 doesn't satisfy very well. However, I
don't think putting DHCPv6 options in RAs is the answer.

There's been a fairly recent trend to provide access to services over
the Internet regardless of the point of attachment while also also
avoiding the need to update host settings when the host moves using
another method - well known anycast addresses that work to reach the
service (DNS most visibly, however also NTP from Google, Microsoft and
Apple). PCP mentioned earlier also has a well known IANA allocated
anycast address.

Regards,
Mark.

>What you describe has almost exactly the same behaviour as a client that sends a DHCPv6 Solicit without waiting for the first RA to arrive. What your proposal does is:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 10 Dec 2018 20:40:59 +0000

Hi Sander,

See below for responses:

> Not completely. I know that Lorenzo wants to push new options/values whenever the network wants the clients to
> update their settings, and this seems to require the client to send a new RS after it receives an RA with the Reconfigure
> option. At that point we're back at normal DHCPv6 behaviour, just with an extra layer of encapsulation. To make this
> useful for both Push (RA) and Pull (DHCPv6) scenarios there is a need to include DHCPv6 options in unsolicited
> multicast RA messages as well.

Push behavior can be accomplished by having the router's RA include an unsolicited
DHCPv6 Reply message, i.e., as if a client had issued an Information-Request. The
Reply would include any stateless info the DHCPv6 service is configured to include.

> I don't see the need to replace stateful DHCPv6 with RA options, but I do see the wish to use RA in the same way that
> stateless DHCPv6 is used. What you describe has almost exactly the same behaviour as a client that sends a DHCPv6
> Solicit without waiting for the first RA to arrive. What your proposal does is:
>

Right - the relaying process is per "Lightweight DHCPv6 Relay Agent (LDRA)" as
specified in RFC6221.

> Combining the RA and DHCPv6 messages means that the client will only get a reply when the slowest of the two is
> completed, which will usually mean that the RA is delayed to wait for the DHCPv6 reply.

I don't know of anything in RFC4861 that guarantees fast delivery of RA responses
to RSes. Plus, the client would include the DHCPv6 option only in RS messages that
need to explicitly request DHCPv6 information meaning that the client would be
willing to wait for a reply.

> It also means that the
> router has to keep more state while waiting for DHCPv6 to complete. Normal DHCPv6 relaying can be implemented
> stateless.

No, that is not true. The router does not need to maintain state while the
DHCPv6 service is processing the message. The router is simply a stateless
LDRA relay agent.

> I'd rather see the client send an RS and a DHCPv6 Solicit in parallel. It can then receive the RA as quickly as possible.
> So for stateful or per-client specific configuration I think the existing DHCPv6 mechanisms works better than
> combining it with RA as you propose.

Again, RFC4861 offers no guarantee of timely delivery of RA responses to RSes
and the DHCPv6 process is not going to take forever - certainly no more than a
few 10's of msecs. But, if a faster response is somehow desired the client can
send two RS messages; one with a DHCPv6 option and one without.

Thanks - Fred

> What I would prefer to see is to be able to include all the generic (non client-specific) options in the RA. There are
> all kinds of options that could benefit from this: DNS options in RA are an obvious example, because they already
> have an RA specific option. But that could be extended to much more options, like the DS-Lite AFTR, MAP-E and
> MAP-T mappings, timezone info, NTP servers, etc. It shouldn't be necessary that every option is defined multiple
> times like RFC7710 does. Such a mapping should be there by default.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 10 Dec 2018 20:51:30 +0000

Hi Mark,

> don't think putting DHCPv6 options in RAs is the answer.

We are using the IPv6ND/DHCPv6 service on hosts that are very mobile
(e.g., enterprise mobile devices such as cellphones, airplanes, unmanned
air vehicles, etc.). The code is freely available here:

http://linkupnetworks.org/aero/AERO-OpenVPN-2.0.tgz

Thanks - Fred

> From: Mark Smith [mailto:[email-masked]]
> Sent: Monday, December 10, 2018 11:29 AM
> To: Sander Steffann <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; Lorenzo Colitti <lorenzo=[email-masked]>; Suresh Krishnan
> <[email-masked]>; 6man WG <[email-masked]>; Fernando Gont <[email-masked]>; 6man Chairs <6man-
> [email-masked]>
> > Not completely. I know that Lorenzo wants to push new options/values whenever the network wants the clients to update their
> settings, and this seems to require the client to send a new RS after it receives an RA with the Reconfigure option. At that point we're
> back at normal DHCPv6 behaviour, just with an extra layer of encapsulation. To make this useful for both Push (RA) and Pull (DHCPv6)
> scenarios there is a need to include DHCPv6 options in unsolicited multicast RA messages as well.
> >
> > Combining the RA and DHCPv6 messages means that the client will only get a reply when the slowest of the two is completed, which
> will usually mean that the RA is delayed to wait for the DHCPv6 reply. It also means that the router has to keep more state while
> waiting for DHCPv6 to complete. Normal DHCPv6 relaying can be implemented stateless.
> >
> > I'd rather see the client send an RS and a DHCPv6 Solicit in parallel. It can then receive the RA as quickly as possible. So for stateful or
> per-client specific configuration I think the existing DHCPv6 mechanisms works better than combining it with RA as you propose.
> >
> > What I would prefer to see is to be able to include all the generic (non client-specific) options in the RA. There are all kinds of options
> that could benefit from this: DNS options in RA are an obvious example, because they already have an RA specific option. But that
> could be extended to much more options, like the DS-Lite AFTR, MAP-E and MAP-T mappings, timezone info, NTP servers, etc. It
> shouldn't be necessary that every option is defined multiple times like RFC7710 does. Such a mapping should be there by default.
> >
> > Cheers,
> > Sander
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Dec 2018 08:31:34 +1100

+1 to adoption noting that it need work.

> On 10 Dec 2018, at 9:53 pm, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 

It provides *some* of the information required for the host to perform DNS64 synthesis itself.  A host also needs to know what IPv4 addresses that should/should not be mapped and what IPv6 addresses to exclude from the determination of whether their are IPv6 addresses
present at the name.

Go read

* RFC 6174, 5.1.4.  Special Exclusion Set for AAAA Records
* RFC 6174, 6.3.3.  Intentional Dual-Stack DNS64 Use

Below is the grammar for configuring DNS64 in BIND. The are three acls, two of which
a host *needs* to perform its own DNS64 synthesis.  “exclude” which is the AAAA records
which are to be ignored and “mapped” which are the set of A addresses that will be
mapped (defaults to any;).

        dns64 <netprefix> {
                break-dnssec <boolean>;
                clients { <address_match_element>; ... };
                exclude { <address_match_element>; ... };
                mapped { <address_match_element>; ... };
                recursive-only <boolean>;
                suffix <ipv6_address>;
        }; // may occur multiple times

Now if you are a cell phone then you have the information to determine what to have in these acls.

	mapped { !<tethered-ipv4-prefix>; !127.0.0.1; any; };

If you are a host sitting on the tethered link you only have a incomplete picture.  You know the directly connected IPv4 prefixes but you don’t know what else is reachable via the router (cell phone) over IPv4 as all you have is a IPv4 default route.

	mapped { !<interface-prefix>; !127.0.0.1; ?what-else-here?; any; };

The same is true for hosts in a enterprise, home, etc. where the router may have more than just a single upstream and downstream interface.

Mark

> One thing I can’t quite grasp from reading the draft..

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

---

From: Sander Steffann <[email-masked]>
Date: Mon, 10 Dec 2018 23:11:25 +0100

Hi Fred,

> Reply would include any stateless info the DHCPv6 service is configured to include.

If that's allowed then that would indeed cover the user case.

> willing to wait for a reply.

True, it would be the choice of the client to ask.

> DHCPv6 service is processing the message. The router is simply a stateless

It would need to know that it should reply with RA instead of DHCPv6 though, so there must be something in the relay reply from the DHCPv6 server that triggers that. I guess we'd need an option that we can use with ERO (RFC 4994). Shouldn't be too hard.

> send two RS messages; one with a DHCPv6 option and one without.

True. The only (in my eyes quite big) problem is in that case we complicate the IPv6 landscape even further than it already is. I foresee that trying to explain to new net admins that they have to consider RA, stateless-DHCPv6, stateful-DHCPv6, stateless-DHCPv6-over-RA and stateful-DHCPv6-over-RA. Because when clients need to consider doing both RA and RA-DHCPv6-SOLICIT in parallel I really prefer the DHCPv6-SOLICIT without the RA encapsulation...

Cheers!
Sander

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 10 Dec 2018 23:00:36 +0000

Hi Sander,

> It would need to know that it should reply with RA instead of DHCPv6 though, so there must be something in the
> relay reply from the DHCPv6 server that triggers that. I guess we'd need an option that we can use with ERO
> (RFC 4994). Shouldn't be too hard.

Thanks for the constructive idea. That is one way of doing it; perhaps a better
way is by including a coded Interface ID option.

> True. The only (in my eyes quite big) problem is in that case we complicate the IPv6 landscape even further than
> it already is. I foresee that trying to explain to new net admins that they have to consider RA, stateless-DHCPv6,
> stateful-DHCPv6, stateless-DHCPv6-over-RA and stateful-DHCPv6-over-RA.

There would not be a need for a network admin to differentiate between
DHCPv6 and DHCPv6-over-RA if the implementation is correctly coded. In
particular, the network admin would not be required to maintain multiple
configurations.

> Because when clients need to consider
> doing both RA and RA-DHCPv6-SOLICIT in parallel I really prefer the DHCPv6-SOLICIT without the RA encapsulation...

I did not say that doing both RS and RS/DHCPv6 in parallel would be the
normal case - I think it would be quite rarely done, and even then only
by curious network engineers. Can you think of cases where it is important
for an average user to measure the raw turnaround time between the
client and the router's radvd process (using linux only as an example)?

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Dec 2018 10:25:09 +0900

Ack. There's also another use case: 464xlat on device. That doesn't require
AAAA synthesis.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Dec 2018 02:34:12 -0300

On 8/12/18 10:21, Ole Troan wrote:
>> Every time we get on the path to duplicate stuff on SLAAC, I wonder
>> why we don't require the use of the DHCPv6 version, or why we
>> simply don't plan to e.g. close dhc wg. i.e., if we are not
>> systematically not going to use what they produce, why does the dhc
>> wg exist in the first place?
> 
> IPv6 intention was that ND should be used to configure only the core
> network layer parameters, there would be no DHCP and all other
> Unfortunately we failed spectacularly in that vision. It’s never to

Well, we do have DHCPv6 for non core network layer parameters. But
whenever there's something that's useful, we push it into SLAAC.

No matter how we got here, the question is: where do we want to go?

I don't mind deprecating DHCPv6, or at the very least stop any further
developments of it (say, close dhc wg). But if work on dhc is to
continue, we should probably use what they develop, rather than ignore
it, and redesign into SLAAC whatever is found to be useful from DHCPv6.
Otherwise, we're just wasting energy and human cycles.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Dec 2018 02:39:08 -0300

On 10/12/18 12:57, Ole Troan wrote:
[....]
> The autonomous host that connects to a network, detects and discovers the services it is interested in, and uses those. And does not trust the network.

In both cases you trust the network. e.g., you might pretend that with
SLAAC you autoconfigure your addresses and hence that's more
privacy-wise -- but the network might be advertising a prefix to you only.

---

From: <[email-masked]>
Date: Tue, 11 Dec 2018 06:28:34 +0000

Hi Dave,

Thank you for clarifying.

Please see inline.

Cheers,
Med

De : David Farmer [mailto:[email-masked]]
Envoyé : lundi 10 décembre 2018 18:41
À : BOUCADAIR Mohamed TGI/OLN
Cc : 6man WG
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

On Mon, Dec 10, 2018 at 1:36 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

•         Why the enterprise will be advertising the RA with PREF64 at the first place rather than another channel?
Just as we do for DNS today we will advertise PREF64 both via DHCPv6 and the RA, again DHCPv6 isn't supported by all host OSes. I don't feel like arguing this issue any more, I take it as a fact I need to live with. We will probably also implement RFC7050, I just don't feel I can rely on it, because of public DNS use and DNSSEC validation issues

[Med] DNSSEC validation can be solved by any solution to learn pref64, including 7050.

RFC7051 says the following:

Below is (an incomplete) list of various
   use cases where it is beneficial for a host or an application to know
   the presence of a NAT64 and the NSP/WKP:

   o  Host-based DNSSEC validation.  As is documented in DNS64
      [RFC6147], Section 5.5<https://tools.ietf.org/html/rfc6147#section-5.5>, Point 3, synthetic AAAA records cannot be
      successfully validated in a host.  In order to utilize NAT64, a
      security-aware and validating host has to perform the DNS64
      function locally, and hence, it has to be able to learn WKP or
      proper NSP.

, but it will work for some good percentage of BYOD users, just not all.

[Med] I guess the same issue is encountered if you want to configure a SIP server to the hosts, and so on. There is nothing fundamentally unique to the pref64.

Why the enterprise has to upgrade its routers, while the same piece of information can be provided using other straightforward means?
Sorry, but I have to upgrade my routers on a regular basis, otherwise, my security folks would go apoplectic.
[Med] The point is not about regular updates of routers but to ask your router vendors to support anther yet feature that is solved otherwise.

We don't run centralized DHCPv6 we run Stateless DHCPv6 in our routers anyway, so from my perspective adding PREF64 to the RA isn't that big of a deal.

[Med] OK, thanks.

Can you please clarify why using a public resolver is a requirement? Is it to avoid some “filtering”/”tracking” at the enterprise network, for example?
As I said this is an enterprise BYOD environment, I can't definitively speak to why my BYOD users have chosen to configure public DNS, but they have and are configuring it.
[Med] If the users have to configure explicitly a DNS server, then you may also provide them with how to instruct a host with the pref64 using a configuration knob.

I suspect it is a combination of privacy and they had some kind of issue once, configured public DNS as an attempt to fix it, and have simply left it configured. I'll bet many of them don't even realize that have a public DNS configured.

•         “if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature”: The same reasoning would apply for MAP-*, DS-Lite, Lw4over6. Why then define an option for only one alternate approach?
If those options were implemented in most hosts then I would support that, but as far as I know most of those are not implemented in hosts, but only implemented in CPE or other network infrastructure.
[Med] My point David is that your statement “if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature” is broken because there are many other mechanisms out there to provide v4 over IPv6 network. So, we cannot mandate that NAT64 is mandatory for deploying IPv6-only.

Most hosts, or at least their browsers, are implementing some mechanism that uses PREF64, either happy eyeballs 2, in the host CLAT, bump-in stack, IPv4 literals, etc...
[Med] This is fair, but IMHO you have this issue each time you want to configure a service because a host vendor does not support dhcp or pcp.

If some host are willing to get that via an RA I'm willing to support that.
[Med] Please note that one issue identified in RFC7051 is as follows:

   -  In some operating systems, it may not be trivial to transfer

      information obtained in the RA to upper layers.

Thank you.

Cheers,
Med

De : ipv6 [mailto:[email-masked]<mailto:[email-masked]>] De la part de David Farmer
Envoyé : dimanche 9 décembre 2018 21:35
À : 6man WG
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

Thanks.

David Farmer               Email:[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 11 Dec 2018 06:37:45 +0000

Ole,

These points are not specific to RA.

Existing text from RFCs can be used at will:

==
3.2.1<https://tools.ietf.org/html/rfc7225#section-3.2.1>.  AAAA Synthesis by the DNS Stub-Resolver

   The option defined in this document can be used for hosts with DNS64
   capability [RFC6147<https://tools.ietf.org/html/rfc6147>] added to the host's stub-resolver.

   PREFIX64 XXXX extension, the host's stub-resolver can learn the prefix

   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<https://tools.ietf.org/html/rfc6147#section-5.5>
   [RFC6147]<https://tools.ietf.org/html/rfc6147#section-5.5>, a security-aware and validating host has to perform the
   DNS64 function locally.

==

Cheers,
Med

De : ipv6 [mailto:[email-masked]] De la part de Ole Troan
Envoyé : lundi 10 décembre 2018 15:38
À : Lorenzo Colitti
Cc : IETF IPv6 Mailing List; 6man Chairs
Objet : Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

On 10 Dec 2018, at 15:30, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

   deployability, since it requires changes in the end hosts..  This mode
   DNS64 resolver..

NAT64 via RA doesn’t do that. To me that reads like something is missing.. Are you going to ask for a DNS64 RA option to be standardized next?
If not, the draft needs to say how this is supposed to work.

Thank!
Ole

---

From: Jen Linkova <[email-masked]>
Date: Tue, 11 Dec 2018 18:14:55 +1100

> [Med] DNSSEC validation can be solved by any solution to learn pref64, including 7050.

In theory - maybe. Practically speaking - in most scenarios the host
just can not validate the prefix if RFC7050 is used as it has to have
trust relationship with that DNS64 server (or establish a secure channel).

Therefore 7050 is not suitable for secure prefix discovery.

> [Med] I guess the same issue is encountered if you want to configure a SIP server to the hosts, and so on. There is nothing fundamentally unique to the pref64.

Could you please clarify why there should be smth fundamentally unique
with pref64 for us to have an RA option?
Isn't having a valid use case enough?

> [Med] The point is not about regular updates of routers but to ask your router vendors to support anther yet feature that is solved otherwise.

I think we are going circles. For the following conditions:
the networks which:
- non-cellular;
- prefer not to deploy DHCPv6 or PCP
and clients which need a *secure* way to discover a prefix

the problem is not solved. If you think it is solved otherwise for the
conditions listed above - I'm all ears, for I need the solution.

> [Med] If the users have to configure explicitly a DNS server, then you may also provide them with how to instruct a host with the pref64 using a configuration knob.

It's not that users are manually configure DNS server every time they
connect to that network, so they could as well configure pref64. No.
The scenario is:
- I statically configure my device with a public DNS server (e.g.
2001:4860:4860::8888) and keep that config - it works in any network.
- when I move from one network to another pref64 might change (or just
disappear if the network is not v6-only).

Think about phones which are using DNS over TLS to public resolver.

> [Med] My point David is that your statement “if you want to deploy IPv6-only NAT64 is a mandatory IPv6 feature” is broken because there are many other mechanisms out there to provide v4 over IPv6 n…

We are not mandating that "you MUST deploy NAT64 for deploying
IPv6-only". It's just an operational reality. If you are deploying
IPv6-only network (== the network where hosts are IPv6-only, so we are
NOT talking about DS-Lite or MAP here as they are for IPv6-only ISP
access networks, when end-hosts are actually dual-stacked) - you will
be using NAT64.
So it's mandatory because it's the only option we have currently.
Here is the formal logic exercise:
1) To deploy IPv6-only network I need NAT64/DNS64.
2) To use NAT64/DNS64 it's desirable for some hosts to know the NAT64 prefix.
3) Some hosts are using SLAAC.

"It's desirable to use SLAAC to send net64 prefix to hosts" - True or False?

> [Med] This is fair, but IMHO you have this issue each time you want to configure a service because a host vendor does not support dhcp or pcp.

I'm sorry if I've failed to make it clear: a network operator does not
necessary want to have dhcp or pcp. It's not about the hosts only.

>       information obtained in the RA to upper layers.

I suspect that systems which support RDNSS have managed to overcome
that limitation somehow.
Other systems would not work very well in IPv6-only networks.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 08:51:45 +0100

Fernando,

> privacy-wise -- but the network might be advertising a prefix to you only.

I might not have been clear.
You obivously have to trust the network both with the core networking parameters and with handling your traffic.

The difference in trust model is different.

In DHCP the premise is (largely) that the network configures attached hosts.
In SLAAC model, only core networking parameters are advertised. And it is up to the host to decide to use them or not.
A core idea behind that model, was that everything else was done through service discovery. ND RS/RA is not service discovery.

Ole

---

From: <[email-masked]>
Date: Tue, 11 Dec 2018 08:01:11 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 11 décembre 2018 08:15
> Cc : David Farmer; 6man

[Med] Please read https://tools.ietf.org/html/rfc7050#section-3.1 

> > [Med] I guess the same issue is encountered if you want to configure a SIP
> server to the hosts, and so on. There is nothing fundamentally unique to the
> pref64.
> 

[Med] David's initial argument is "DHCPv6 isn't supported by all host OSes". So each time he needs to pass some information to those hosts, he will have the issue we are discussing in this thread. In this regards, passing a pref64 does not expose unique requirements.   

> security folks would go apoplectic.
> >
> > [Med] The point is not about regular updates of routers but to ask your
> router vendors to support anther yet feature that is solved otherwise.
> 

[Med] My answer is use whatever tool you are using to supply an NTP server, a SIP proxy, etc. to these hosts. I would be OK if the information is about a core IPv6 connectivity function. Learning Pref64 is a service, no more than that. 

> 
> >>> Can you please clarify why using a public resolver is a requirement? Is
> it to avoid some “filtering”/”tracking” at the enterprise network, for
> example?
> >
> speak to why my BYOD users have chosen to configure public DNS, but they have
> and are configuring it.
> >
> > [Med] If the users have to configure explicitly a DNS server, then you may
> also provide them with how to instruct a host with the pref64 using a
> configuration knob.
> 
> > [Med] My point David is that your statement “if you want to deploy IPv6-
> only NAT64 is a mandatory IPv6 feature” is broken because there are many
> other mechanisms out there to provide v4 over IPv6 network. So, we cannot
> mandate that NAT64 is mandatory for deploying IPv6-only.
> 

[Med] You still don't answer to my question: how these hosts are configured with services? 

> > [Med] This is fair, but IMHO you have this issue each time you want to
> configure a service because a host vendor does not support dhcp or pcp.
> 

[Med] This is your perspective but what the issue I got from David is: "DHCPv6 isn't supported by all host OSes"

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 09:01:42 +0100

> Otherwise, we're just wasting energy and human cycles.

With regards to where we _want_ to go. Or perhaps I with a fundamental IP hat on would like to go.
I would not classify either DHCP or ND RS/RA as service discovery protocols.
ND allows for discovery of core parameters for the host’s L3.

If I were to be dictator:
- Deprecate DHCP (apart from PD)
 (per host behaviour can be done by putting hosts on separate links)
- Remove all non-L3 options from RAs
- Put everything else in service discovery.

But that assumes we have a functional service discovery protocol…

Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 09:06:31 +0100

Med,

> These points are not specific to RA.

Yes, my point was slightly different.
Is this mechanism restricted to only host synthesised addresses?
How do you detect the DNS64? Or do you just assume whatever local resolver the host finds supports it?
And how would you detect that it was using the same pref64?

I would be fine if the3 draft says this mechanism was restricted to local senthesis only.

Cheers,
Ole

PS: Your quoting is messed up in some emails, making it hard to discern your text.

> 3.2.1.  AAAA Synthesis by the DNS Stub-Resolver
>  
>    capability [RFC6147] added to the host's stub-resolver.
>

---

From: Ola Thoresen <[email-masked]>
Date: Tue, 11 Dec 2018 09:16:02 +0100

> But that assumes we have a functional service discovery protocol…

I completely agree, at least with the last point.  I do, however, see 
that in a lot of enterprise environments, _something_ like dhcp is 
required.  They might not be able to separate all theirs hosts into 
different l2-networks, but still need some way to uniquely identify each 
host.  This _could_ be achieved by enforcing something like dyndns or 
other services where the host registers itself after it has configured 
an IP-address, but at least something along those lines are needed.

When it comes to service discovery protocols, I would really like to put 
an effort into getting that working and deployed widely. The use of link 
local multicast and HL=1 (or HL=255 and refusing to accept packets with 
a lower HL) as a huge problem already today.  This should be fixed no 
matter what we end up doing with dhcp and RAs.

Rgds.

Ola Thoresen

---

From: <[email-masked]>
Date: Tue, 11 Dec 2018 09:20:03 +0000

Re-,

Like any other discovery solution, the discovered pref64 can be used:
* for addresses synthesis
* distinguishing native vs synthesized when both addresses are received in referrals, for example.

How a host detect a dns64 is implementation and deployment-specific: 
(1) There are devices that are sending only AAAA queries because they assume that a DNS64 is enabled upstream. Address synthesis will be required only for applications not relying on DNS or when address literals are used. This is the widely deployed model with 7050. 
(2) There are devices that are issuing both A and AAAA. Addresses synthesis is done exclusively on the host. We do have few millions of hosts with 7050 following this logic. DNS64 is only used to discover the pref64, then addresses synthesis is done on the host itself based on A responses. 

I would expect the same host's behavior with whatever discovery mechanism, including RA.  

A host can in theory detect that a DNS64 (if present) is using the same pref64 vs the one(s) it discovered. It can do so by comparing synthesized address against the locally discovered pref64. A potential issue with RA is the support of multiple pref64s/suffixes, though.

Cheers,
Med

> De : Ole Troan [mailto:[email-masked]]
> Envoyé : mardi 11 décembre 2018 09:07
> Cc : 6man WG; 6man Chairs
> DNS server it already knows about (e.g, through RDNSS or PCO) to discover the
> NAT64 prefix in use by the network. It does this by doing an AAAA lookup for
> ipv4only.arpa and deducing the NAT64 prefix from that. For example, if it
> gets 2001:db8:64::192.0.0.170 it concludes that the NAT64 prefix is
> 2001:db8:64::.
> >
> > A solution based on RFC7050 ties the NAT64 and the DNS64 functions together
> (although not in the NAT-PT way) in the sense that you discover both, and
> they both would essentially be operated by the same site.
> >
> end hosts performs all A queries and AAAA synthesis itself using whatever DNS
> server it uses to resolve hostnames. That server doesn't need to be a DNS64
> and doesn't need to know what the NAT64 prefix is. This mode is more secure
> because it supports DNSSEC validation in the host and DNS-over-TLS to a
> recursive resolver that the user of the trusts.
> >
> > NAT64 via RA doesn’t do that. To me that reads like something is missing..

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Dec 2018 09:28:22 +0000

> On 11 Dec 2018, at 07:51, Ole Troan <[email-masked]> wrote:
> 
> Fernando,
> 

Actually, when I surveyed some university network admins not long ago, they were generally only using DHCPv4 for "core networking parameters".  I wonder how common that is.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Dec 2018 11:12:13 +0100

>You obivously have to trust the network both with the core networking 
>parameters and with handling your traffic.
>
>In SLAAC model, only core networking parameters are advertised. And it 
>is up to the host to decide to use them or not.
>A core idea behind that model, was that everything else was done through 
>service discovery. ND RS/RA is not service discovery.

In my mind, NAT64 is a service that provides access to the IPv4 internet.
It is not a core IPv6 configuration parameter. So according to the SLAAC
model there should be no NAT64 parameters in RA. 

There may even be multiple NAT64 services, which can be discovered through
service discovery. Typically a NAT64 service will be offlink.

Whether a host accepts certain configuration parameters from DHCP always
depends on the configuration of the host. The most common example is people
who manually set the DNS resolvers to a public resolver.

What I find worrying in this discussion is the notion to not use DHCP because
something better may show up in the future. And because we have decided to not
use DHCP we have to put every possible parameter the host needs right now in
RAs.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 11:23:09 +0100

> use DHCP we have to put every possible parameter the host needs right now in

At least what I have bee talking about is how things were intended to turn out 20 years ago.
And likewise how I would have _liked_ the IPv6 configuration model to look like going forward.

That unfortunately has little bearing on where we are and what we do today. ;-)
We aren’t putting every option in RA that exists in DHCP. We might be getting there though.
In my view those options shouldn’t have existing in DHCP either.

What can we do to improve?

Cheers,
Ole

---

From: Jen Linkova <[email-masked]>
Date: Tue, 11 Dec 2018 21:26:11 +1100

> [Med] Please read https://tools.ietf.org/html/rfc7050#section-3.1

I had read it before I sent my last email and I've just read it again.
I might be still missing something but I still do not understand how a
host can securely discover the prefix
if that host does not have any trusted domains? My understanding is
that the algorith described in the section 3.1.2 would abort at Step
3.
Could you elaborate, pls?

Also I can not see how it could be used with public DNS64 and WKP?
In other words it looks like RFC7050 allows a secure prefix discovery
in very limited sets of scenarios.

> [Med] David's initial argument is "DHCPv6 isn't supported by all host OSes". So each time he needs to pass some information to those hosts, he will have the issue we are discussing in this thread.…

I'm sorry if I've said that before but let me try again...
Imagine an operator which runs a network, and uses SLAAC to configure
hosts. (We do not need to discuss why the decision for SLAAC-only has
been made - maybe it was because they do not want to run DHCPv6, or
because they have hosts w/o DHCPv6 support or both of the above).
Until recently SLAAC was sufficient for providing hosts with all
information to get the Internet access.
Then one day those crazy people decided that they are going to run
IPv6-only network so they have deployed NAT64 and DNS64.
Now it would be very desirable and beneficial for them if hosts could
be informed about NAT64 prefix in secure way.
So they looked at RA format and came up with idea that, in addition to
MTU and DNS information, it would fantastic if hosts could also get
NAT64 prefix, because otherwise some hosts might have some issues with
basic network connectivity.
So here we are, there is a proposal.

If (or when) one day those people come across an issue and would need
to to pass some information to those hosts again, maybe they would
have the same issue we discuss in this thread. Or maybe not - because
maybe they would never need to do it again. Who know?  The fact is
they do not need to pass any other information now.

What I still fail to understand is why we should not solve the problem
we have at our hands now based on your concerns that we *might* get
some similar problem later.
I'd appreciate if you could explain.

> [Med] My answer is use whatever tool you are using to supply an NTP server, a SIP proxy, etc. to these hosts.

For BYO unmanaged hosts I *do not* supply all those things. I provide
them with Internet connectivity - and currently I need to give them
NAT64 prefix.

>I would be OK if the information is about a core IPv6 connectivity function. Learning Pref64 is a service, no more than that.

It's a core connectivity function. W/o NAT64 hosts can not access
significant part of the Internet (and, possibly, part of the internal
network).

> [Med] You still don't answer to my question: how these hosts are configured with services?

Which services? I do not configure them with "services". I provide
them with the Internet/network connectivity.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Dec 2018 11:43:29 +0100

> That unfortunately has little bearing on where we are and what we
> do today. ;-) We arent putting every option in RA that exists in
> DHCP. We might be getting there though.  In my view those options
> shouldnt have existing in DHCP either.
> 

The problem I see is that alternatives to DHCP kill a lot of nice features
of DHCP:
- DHCP has the ability to store all configuration of all hosts in one place.
  (note ability, not a requirement)
- DHCP has the ability to provide hosts with unique per host configuration
- DHCP has an obvious way to supply information that is not an IP address or
  an address outside the local network.

Service discovery protocols tend to solve a different problem. So any
idea of 'lets replace DHCP with ...' loses a lot of existing functionality.

We have seen that problem explained many times by people who would like to
have a default router option in DHCPv6. And then they are just ignored.

---

From: James R Cutler <[email-masked]>
Date: Tue, 11 Dec 2018 09:10:02 -0500

> On Dec 11, 2018, at 5:12 AM, Philip Homburg <[email-masked]> wrote:
> 

Exactly - and not only that, the network designers and router maintenance crews must then also be end system managers. The business purposes driving host management are often orthogonal to this of managing connectivity.

Since DHCP services can be provided and managed as end system services making it relatively easy to separate the business driven end system change control from routing change control. My experience with large corporate networks taught me that there were enough problems with change control of router configurations without mixing in change control of end systems.

Consider the acronym ‘RA’ Router Advertisement. What does this mean? Advice about router presence.

Consider the acronym ‘DHCP’ Dynamic HOST Configuration Protocol. What does this mean? End system configuration involves many parameters, most not relating directly to routing packets.

Let the router management task not be cluttered with the much more fluid environment of end system management.

KISS(tm)

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Dec 2018 15:45:12 +0000

Hi Sander,

> way is by including a coded Interface ID option.

Actually, there is no coding of any kind needed. DHCPv6 is UDP-based whereas
IPv6ND is ICMP-based, meaning that the two services would use different first
hop relay agents. Only the IPv6 ND-based DHCPv6 directives travel through the
LDRA , so there is no ambiguity.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Dec 2018 06:12:15 +1100

> Exactly - and not only that, the network designers and router maintenance crews must then also be end system managers. The business purposes driving host management are often orthogonal to this of…

Philip isn't correct, "we" have not decided to not to use DHCP.

A vendor has decided to not use stateful DHCP for addressing a
particularly common end-user device. They've also not seen a need to
support stateless DHCP, because they're acquiring access to a name
resolution service and a wall clock/time of day time source via other
methods (anycast DNS; mobile network, anycast NTP).

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Dec 2018 11:48:27 -0800

> But that assumes we have a functional service discovery protocol…

How about DNSSD? It is as standard as it gets, it is widely deployed,
and it can certainly be used to discover printers, shared devices and
other services.

-- Christian Huitema

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 21:25:26 +0100

> and it can certainly be used to discover printers, shared devices and

DNS-SD is probably the only candidate we got.
I haven’t followed the DNSSD group lately, and if they have resolved all problems of making it easily deployable.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 21:28:49 +0100

Christian,

> and it can certainly be used to discover printers, shared devices and

I’m not quite sure how you would discover a NAT64 service with DNS-SD?
A NAT64 prefix encoded in the service record?

Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Dec 2018 15:01:36 -0600

> A NAT64 prefix encoded in the service record?

Since the NAT64 service probably isn't on that link and DNS-SD advertises
service on a single link, what is going to advertise the service? Is the
router going to proxy-advertise it? How different from an RA is that?

SLP might be a better option, at least it is designed to multicast across
multiple links, but wait most people don't actually configure their routers
for multicast routing.

Let's just realize despite what we would prefer, NAT64 isn't just any
service, it is a core function of IPv6 until IPv4 is dead and forgotten at
least on the public Internet

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Dec 2018 22:12:57 +0100

David,

> Since the NAT64 service probably isn't on that link and DNS-SD advertises service on a single link, what is going to advertise the service? Is the router going to proxy-advertise it? How different from an RA is that? 

DNS-SD is not single link. Which is why I alluded to the deployment issues.
mDNS is single link.

> SLP might be a better option, at least it is designed to multicast across multiple links, but wait most people don't actually configure their routers for multicast routing.
> 
> Let's just realize despite what we would prefer, NAT64 isn't just any service, it is a core function of IPv6 until IPv4 is dead and forgotten at least on the public Internet 

Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Dec 2018 15:56:12 -0600

On Tue, Dec 11, 2018 at 3:13 PM Ole Troan <[email-masked]> wrote:

> > Since the NAT64 service probably isn't on that link and DNS-SD
> advertises service on a single link, what is going to advertise the
> service? Is the router going to proxy-advertise it? How different from an
> RA is that?
>

Yes, I misspoke, mDNS is a single link, but you need mDNS proxies on every
link or you need dynamic DNS working and open to the devices that want to
register services. Securing DNS-SD is really complicated, especially in a
BYOD environment.  Even providing something like RA Guard is non-trivial,
unless you are willing to only allow known-infrastructure and not BYOD
clients to provide services.

> > SLP might be a better option, at least it is designed to multicast
> across multiple links, but wait most people don't actually configure their
> routers for multicast routing.
> >

NAT64 is an network infrastructure service provided by the network. It's
not a user level service like a printer or a sip phone, or even a
application level service.

So, I think NAT64 is a core service and I don't think DNS-SD has the right
trust model for it, I think putting it in the RA is the right place for it.

Thanks.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Dec 2018 14:28:40 -0800

On 12/11/2018 1:56 PM, David Farmer wrote:

> On Tue, Dec 11, 2018 at 3:13 PM Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     David,
>
>     advertises service on a single link, what is going to advertise
>     the service? Is the router going to proxy-advertise it? How
>     different from an RA is that?
>
> Yes, I misspoke, mDNS is a single link, but you need mDNS proxies on
> every link or you need dynamic DNS working and open to the devices
> that want to register services. Securing DNS-SD is really complicated,
> especially in a BYOD environment.  Even providing something like RA
> Guard is non-trivial, unless you are willing to only allow
> known-infrastructure and not BYOD clients to provide services.   
>  
>
>     > SLP might be a better option, at least it is designed to
>     multicast across multiple links, but wait most people don't
>     actually configure their routers for multicast routing.
>     >
>     > Let's just realize despite what we would prefer, NAT64 isn't
>     just any service, it is a core function of IPv6 until IPv4 is dead
>     and forgotten at least on the public Internet 
>
>
> NAT64 is an network infrastructure service provided by the network.
> It's not a user level service like a printer or a sip phone, or even a
> So, I think NAT64 is a core service and I don't think DNS-SD has the
> right trust model for it, I think putting it in the RA is the right
> place for it

The "server" mode of DNSSD finds services within a scope defined by a
domain name. If we start from there, we get a split between two kind of
information:

1) Network level information and DNSSD bootstrap: what is needed for
SLAAC, plus the local DNSSD prefix for discovering local services, and a
DNS server address. Absent DNSSD prefix, the local discovery will just
rely on local broadcast, i.e. MDNS.

2) Everything else that can be found looking up a local service.

That split has the nice property of limiting what would be candidate for
inclusion in the RA: basically, everything in the first category, and
none of the second category. In addition to the SLAAC prefix, that would
be local DNS server address, and local DNS prefix. The prefix is
actually a nice identifier of the network, so it is quite useful in
mobility scenarios.

The NAT64 prefix straddles that border. It is not a service in the same
sense as a printer. But it could still be discovered it using DNSSD, say
by looking for "_nat64._udp", and obtaining the prefix as a property of
the discovered server embedded in a TXT record. On the other hand,
discovering the prefix as part of network level configuration looks
simpler, with a small caveat. It is simpler to consume RA rather than
DNSSD in the IPv6 stack of a node, but for an application it may well be
simpler to use DNSSD rather than ask the system to provide a copy of the RA.

-- Christian Huitema

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Dec 2018 14:29:04 -0800

> trust model for it, I think putting it in the RA is the right place for it.

Right.  I think we really want to piggy back on the RA guard functionality
(presumed to be) in place.

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Dec 2018 10:15:05 +1100

> clients to provide services.

I think this is indirectly eluding to a more fundamental issue.

There are really two separate although similar problem spaces and scenarios:

- host configation and service discovery on and over the Internet i.e. a
public network e.g. residential Internet, public Wifi, mobile networks.

- host configation and service discovery within controlled and managed
environments like enterprise networks.

What both suits and is needed to work reliably in each scenario can
conflict with the alternative case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Dec 2018 15:56:09 +0900

> least on the public Internet

Exactly.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Dec 2018 16:01:56 +0900

On Wed, Dec 12, 2018 at 7:29 AM Christian Huitema <[email-masked]>
wrote:

> DNS server address. Absent DNSSD prefix, the local discovery will just rely
> on local broadcast, i.e. MDNS.
>
> inclusion in the RA: basically, everything in the first category, and none
> of the second category. In addition to the SLAAC prefix, that would be
> local DNS server address, and local DNS prefix. The prefix is actually a
> nice identifier of the network, so it is quite useful in mobility scenarios.
>
> sense as a printer. But it could still be discovered it using DNSSD, say by
> looking for "_nat64._udp", and obtaining the prefix as a property of the
> discovered server embedded in a TXT record. On the other hand, discovering
> the prefix as part of network level configuration looks simpler, with a
> small caveat. It is simpler to consume RA rather than DNSSD in the IPv6
> stack of a node, but for an application it may well be simpler to use DNSSD
> rather than ask the system to provide a copy of the RA.
>
The other important advantage of the RA is that it's atomic. All the
configuration to get onto the network and communicate at layer 3 is in a
single packet that is guaranteed to have been received (because you can't
get a working IPv6 configuration without getting an RA). That ensures clear
and predictable behaviour, and ensures that IPv4 is available and working
the instant that IPv6 is available.

All the other methods (RFC 7050, DHCPv6, PCP) have the disadvantage that
the pref64 is configured after IPv6 is up. That means that apps (and the
user) will think that the device is connected, but won't be able to reach
the IPv4 destinations they want to reach.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Dec 2018 09:20:07 +0100

Hi Lorenzo,

> 1) Network level information and DNSSD bootstrap: what is needed for SLAAC, plus the local DNSSD prefix for discovering local services, and a DNS server address. Absent DNSSD prefix, the local discovery will just rely on local broadcast, i.e. MDNS.
> 
> That split has the nice property of limiting what would be candidate for inclusion in the RA: basically, everything in the first category, and none of the second category. In addition to the SLAAC prefix, that would be local DNS server address, and local DNS prefix. The prefix is actually a nice identifier of the network, so it is quite useful in mobility scenarios.
> 
> The NAT64 prefix straddles that border. It is not a service in the same sense as a printer. But it could still be discovered it using DNSSD, say by looking for "_nat64._udp", and obtaining the prefix as a property of the discovered server embedded in a TXT record. On the other hand, discovering the prefix as part of network level configuration looks simpler, with a small caveat. It is simpler to consume RA rather than DNSSD in the IPv6 stack of a node, but for an application it may well be simpler to use DNSSD rather than ask the system to provide a copy of the RA.
> 
> The other important advantage of the RA is that it's atomic. All the configuration to get onto the network and communicate at layer 3 is in a single packet that is guaranteed to have been received (because you can't get a working IPv6 configuration without getting an RA). That ensures clear and predictable behaviour, and ensures that IPv4 is available and working the instant that IPv6 is available.

While that might be typical in practice, it is not an inherit property of the protocol.
RAs might be split across multiple messages, and it depends on periodic updates.

> All the other methods (RFC 7050, DHCPv6, PCP) have the disadvantage that the pref64 is configured after IPv6 is up. That means that apps (and the user) will think that the device is connected, but won't be able to reach the IPv4 destinations they want to reach.

The most convincing arguments I find are:
 - RFC7050 requires the host to use network provided resolvers
  (Now with the current text it has to do that anyway unless a local DNS64 is mandated)
 - PCP isn’t deployed
 - DHCP option. Hmm, don’t know.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Dec 2018 09:29:30 +0100

David,

> Let's just realize despite what we would prefer, NAT64 isn't just any service, it is a core function of IPv6 until IPv4 is dead and forgotten at least on the public Internet 

Let me disagree with you (for the sake of argument).
I do not want to make a NAT64 a mandatory function in every IPv6 only network.

Let’s assume the premises of an IPv6 only network is there. All applications are IPv6 enabled, and there are no IPv4 only nodes left in the local network.
Why should we put the burden of IPv4 reachability on the local network? That seems both unfair and it would also require us to keep an IPv4 Internet to connect the NAT64s on for a long time.

Wouldn’t a better approach be to put the burden on the remote IPv4 only destination? Then traffic would be carried as IPv6 as close the IPv4 only destination as possible. (Instead of with local NAT64, where it is locally translated to IPv4 and carried in the IPv4 Internet).

Something like:
 - IPv4 only network must have a NAT64 fronting it.
 - The NAT64 IPv6 addresses must be registered in DNS

This would also allow IPv4 private addresses to be represented in IPv6.

Sure, we might need the local NAT64 too, but that shouldn’t be the message we should send to the IPv4 only network operators.

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Dec 2018 21:02:48 +1100

On Wed., 12 Dec. 2018, 19:30 Ole Troan <[email-masked] wrote:

> Let’s assume the premises of an IPv6 only network is there. All
> applications are IPv6 enabled, and there are no IPv4 only nodes left in the
> local network.
> Why should we put the burden of IPv4 reachability on the local network?
> That seems both unfair and it would also require us to keep an IPv4
> Internet to connect the NAT64s on for a long time.
>
> Wouldn’t a better approach be to put the burden on the remote IPv4 only
> destination? Then traffic would be carried as IPv6 as close the IPv4 only
> destination as possible. (Instead of with local NAT64, where it is locally
> translated to IPv4 and carried in the IPv4 Internet).
>
> Something like:
> Sure, we might need the local NAT64 too, but that shouldn’t be the message
> we should send to the IPv4 only network operators.
>

I like the idea of trying to put the cost and pain of continuing to only
run IPv4 onto those who've made that choice.

Accomodating IPv4 only at the client end reduces the incentive to move to
native IPv6 at the server end.

"What you allow, you encourage." - Michael Josephson.

Regards,
Mark.

---

From: Lee Howard <[email-masked]>
Date: Wed, 12 Dec 2018 07:39:35 -0500

On 12/11/18 4:56 PM, David Farmer wrote:
> place for it.

What makes NAT64 more special than, say, MAP or DS-Lite?

Lee

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 14:56:23 +0000

Hi Ole, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 12 décembre 2018 09:20
> À : Lorenzo Colitti
> Cc : 6man WG; Suresh Krishnan; Lorenzo Colitti; Fernando Gont; Fernando Gont;
> Christian Huitema; 6man Chairs
> Objet : Re: IPv6 configuration model (was Re: Adoption call for <draft-
> pref64folks-6man-ra-pref64-02>)
> 
> Hi Lorenzo,
> 
> > 1) Network level information and DNSSD bootstrap: what is needed for SLAAC,
> plus the local DNSSD prefix for discovering local services, and a DNS server
> address. Absent DNSSD prefix, the local discovery will just rely on local
> broadcast, i.e. MDNS.
> >
> inclusion in the RA: basically, everything in the first category, and none of
> the second category. In addition to the SLAAC prefix, that would be local DNS
> server address, and local DNS prefix. The prefix is actually a nice
> identifier of the network, so it is quite useful in mobility scenarios.
> >
> the prefix as part of network level configuration looks simpler, with a small
> caveat. It is simpler to consume RA rather than DNSSD in the IPv6 stack of a
> node, but for an application it may well be simpler to use DNSSD rather than
> ask the system to provide a copy of the RA.
> >
> single packet that is guaranteed to have been received (because you can't get
> a working IPv6 configuration without getting an RA). That ensures clear and
> predictable behaviour, and ensures that IPv4 is available and working the
> instant that IPv6 is available.
> 
> user) will think that the device is connected, but won't be able to reach the
> IPv4 destinations they want to reach.
> 

[Med] Why is this problematic/critical? The main NAT64 deployments I'm familiar with are using the DNS server supplied by the network. 

>  - PCP isn’t deployed

[Med] PCP is a deployment reality in many fixed networks.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Dec 2018 16:03:18 +0100

Hi Med,

I think what you fail to see is that even if DNS is provided by the operator, users tend to change it, so the new DNS will not necessarily use the same NAT64 prefix, and then create troubles ...

The point here is to make sure that the provisioning of the NAT64 prefix is *independent* of the DNS being used.

We can choose using RA or DHCPv6 or both, but should be a different parameter than the DNS itself.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de <[email-masked]>
Fecha: miércoles, 12 de diciembre de 2018, 15:57
Para: Ole Troan <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Hi Ole, 
    
    Please see inline. 
    
    Cheers,
    Med

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 15:11:44 +0000

Re,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 12 décembre 2018 16:03
> À : BOUCADAIR Mohamed TGI/OLN; Ole Troan
> Cc : 6man WG
> I think what you fail to see is that even if DNS is provided by the operator,
> users tend to change it, so the new DNS will not necessarily use the same
> NAT64 prefix, and then create troubles ...

[Med] I said "NAT64 deployments I'm familiar" which is basically cellular networks. In those networks, the users do not change the DNS server. 

> *independent* of the DNS being used.

[Med] This is not a requirement for the typical networks I mentioned...and if this happens to be a requirement for other networks then the approach you defined in you draft draft-ietf-v6ops-transition-ipv4aas can be followed. 

> We can choose using RA or DHCPv6 or both, but should be a different parameter

[Med] That is already fixed and met with the approach in the v6ops draft. If there is a network which does not support DHCP, then it can use whatever service provisioning mechanism in place.   

> SLAAC,
> none of
> small
>     > While that might be typical in practice, it is not an inherit property
> of the
>     > protocol.
>     >   (Now with the current text it has to do that anyway unless a local
> DNS64 is
>     > mandated)
> 
>     [Med] Why is this problematic/critical? The main NAT64 deployments I'm
> familiar with are using the DNS server supplied by the network.
> 
>     >  - PCP isn’t deployed
> 
> 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Dec 2018 16:19:58 +0100

Even in cellular networks, there is tethering, and that means users may change the DNS ... Anyway, we can't forget other cases such as cellular broadband and wired broadband, using 464XLAT.

My point is that this is a broader problem. In out v6ops draft we have other choices, right, but they are more complex, or relying in RFC7050, which probes to be sub-optimal.

I've the feeling that is easier for the overall "market" to implement something new based in RA or DHCP, or even both, than implementing PCP (despite I'm in favor of it).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: miércoles, 12 de diciembre de 2018, 16:11
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Re,
    
    Please see inline. 
    
    Cheers,
    Med

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 12 Dec 2018 15:23:14 +0000

Hi Lorenzo - see below for response:

Thanks - Fred

>> Rolling up the IPv6ND and DHCPv6 information in a single message exchange (RS/RA)
>> would address this point.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Dec 2018 00:34:46 +0900

On Thu, Dec 13, 2018 at 12:12 AM <[email-masked]> wrote:

> [Med] I said "NAT64 deployments I'm familiar" which is basically cellular
> networks. In those networks, the users do not change the DNS server.
>

Not true.
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 15:40:24 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : mercredi 12 décembre 2018 16:20
> Even in cellular networks, there is tethering, and that means users may
> change the DNS ... Anyway, we can't forget other cases such as cellular
> broadband and wired broadband, using 464XLAT.

[Med] Do we have claims from the various operators deploying 7050?  

> 
> My point is that this is a broader problem. In out v6ops draft we have other
> choices, right, but they are more complex, or relying in RFC7050, which
> probes to be sub-optimal.

[Med] Sure. We all know it is sub-optimal. Nevertheless, RFC7050 is the IETF recommendation as per 7051. If the IETF decides to change that reco, so then people have to obsolete first 7051.  

I was for DHCP at that time in behave (see the pointers in 7051), and we had the opportunity when working on RFC8115 to define a separate dhcp option for unicast pref64 but we resisted to that because we wanted to be aligned with the IETF recommendation. This is why RFC8115 includes this text:    

   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've the feeling that is easier for the overall "market" to implement
> something new based in RA or DHCP, or even both, than implementing PCP
> (despite I'm in favor of it).

[Med] Then, go for DHCP as recently argued in v6ops by your document. No need to overload RA with service-specific parameters. 

>     > The point here is to make sure that the provisioning of the NAT64
> prefix is
>     > *independent* of the DNS being used.
> 
>     [Med] This is not a requirement for the typical networks I
> mentioned...and if this happens to be a requirement for other networks then
> the approach you defined in you draft draft-ietf-v6ops-transition-ipv4aas can
> be followed.
> 
>     >
>     > We can choose using RA or DHCPv6 or both, but should be a different
> parameter
>     > than the DNS itself.
> 
>     [Med] That is already fixed and met with the approach in the v6ops draft.
> If there is a network which does not support DHCP, then it can use whatever
> service provisioning mechanism in place.
> 
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     >
>     >     > Cc : 6man WG; Suresh Krishnan; Lorenzo Colitti; Fernando Gont;
> Fernando
>     > Gont;
>     >     > plus the local DNSSD prefix for discovering local services, and a
> DNS
>     > server
>     >     > address. Absent DNSSD prefix, the local discovery will just rely
> on
>     > local
>     >     > broadcast, i.e. MDNS.
>     >     > >
>     >     > > That split has the nice property of limiting what would be
> candidate
>     > for
>     >     > the second category. In addition to the SLAAC prefix, that would
> be
>     > local DNS
>     >     > > The NAT64 prefix straddles that border. It is not a service in
> the
>     > same
>     >     > sense as a printer. But it could still be discovered it using
> DNSSD,
>     > say by
>     >     > looking for "_nat64._udp", and obtaining the prefix as a property
> of
>     > the
>     >     > caveat. It is simpler to consume RA rather than DNSSD in the IPv6
> stack
>     > of a
>     >     > node, but for an application it may well be simpler to use DNSSD
> rather
>     > than
>     >     > configuration to get onto the network and communicate at layer 3
> is in
>     > a
>     >     > single packet that is guaranteed to have been received (because
> you
>     > can't get
>     >     > a working IPv6 configuration without getting an RA). That ensures
> clear
>     > and
>     >     > predictable behaviour, and ensures that IPv4 is available and
> working
>     > the
>     >     > RAs might be split across multiple messages, and it depends on
> periodic
>     >     > updates.
>     >     >
>     >     > > All the other methods (RFC 7050, DHCPv6, PCP) have the
> disadvantage
>     > that
>     >     > the pref64 is configured after IPv6 is up. That means that apps
> (and
>     > the
>     >     > user) will think that the device is connected, but won't be able
> to
>     > reach the
>     >     > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 15:49:21 +0000

Re-,

Thank you for the pointer, but frankly speaking I don’t see the link with what I said.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : mercredi 12 décembre 2018 16:35
À : BOUCADAIR Mohamed TGI/OLN
Cc : Jordi Palet Martinez; Ole Troan; IETF IPv6 Mailing List
Objet : Re: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

Not true. https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

---

From: Philip Homburg <[email-masked]>
Date: Wed, 12 Dec 2018 17:00:32 +0100

>    The other important advantage of the RA is that it's atomic.
>    All the configuration to get onto the network and communicate
>    at layer 3 is in a single packet that is guaranteed to have been
>    received (because you can't get a working IPv6 configuration
>    without getting an RA). That ensures clear and predictable
>    behaviour, and ensures that IPv4 is available and working the

There is no requirement that all config comes in a single RA packet.

One packet may have the SLAAC prefix, a second packet the default router,
a third DNS resolvers, a fourth some other config.

It is quite possible to end up with a situation where a network operator has a
router that doesn't support a new RA option and just installs a box next to
it that does nothing but advertise the needed information.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Dec 2018 18:56:45 -0800

On Dec 12, 2018, at 7:03 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

For the record, I know of at least one CPE router implementation (the one I use at my home) that by default uses OpenDNS rather than the ISP-provided DNS. It does that in order to provide a certain service to the user, which is that it discourages the use of sites that OpenDNS thinks might convey malware. The user, in this case, is changing it as a fact of having purchased that CPE.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Dec 2018 15:42:14 +0900

You said that in cellular networks users don't change the DNS server. The
link I sent you shows that they can and do.

On Thu, 13 Dec 2018, 00:49 <[email-masked] wrote:

> *De :* Lorenzo Colitti [mailto:[email-masked]]
> *Envoyé :* mercredi 12 décembre 2018 16:35
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Jordi Palet Martinez; Ole Troan; IETF IPv6 Mailing List
> *Objet :* Re: IPv6 configuration model (was Re: Adoption call for
> <draft-pref64folks-6man-ra-pref64-02>)
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Dec 2018 15:44:04 +0900

> There is no requirement that all config comes in a single RA packet.

Sure, there is no requirement that says it *has to be* this way. But it is
desirable, and only RA *allows* it to be this way

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 07:09:16 +0000

Lorenzo,

“Are not doing in the networks I’m familiar with” is not the same as “will do in the future”.

The link does not show the “do” part of your statement.

Please avoid using “not true” and the like.

Cheers,
Med

Envoyé : jeudi 13 décembre 2018 07:42

You said that in cellular networks users don't change the DNS server. The link I sent you shows that they can and do.

On Thu, 13 Dec 2018, 00:49 <[email-masked]<mailto:[email-masked]> wrote:
Re-,

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 07:16:45 +0000

Hi Fred,

I fully agree with that case for fixed networks.

In these networks, DHCP is widely in use. Following the behavior described in the v6ops-v4aas draft already fixed the issue of DNS dependency for those networks.

Cheers,
Med

De : ipv6 [mailto:[email-masked]] De la part de Fred Baker
Envoyé : jeudi 13 décembre 2018 03:57
À : JORDI PALET MARTINEZ
Cc : [email-masked]
Objet : Re: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Dec 2018 08:52:34 +0100

Med,

> In these networks, DHCP is widely in use. Following the behavior described in the v6ops-v4aas draft already fixed the issue of DNS dependency for those networks.

Are you proposing that hosts should follow the recommendations in draft-ietf-v6ops-transition-ipv4aas?

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 09:43:13 +0100

My take on this:

I think the CPE (fixed networks or cellular broadband) can learn it using v6ops-v4aas, then use RA for the hosts ...

If we want something such as v6ops-v4aas for the hosts, it should be part of host-requirements ...

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 8:53
Para: Mohamed Boucadair <[email-masked]>
CC: "[email-masked]" <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Asunto: Re: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Med,

    
    Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Dec 2018 17:46:46 +0900

I stand by that statement. Users can and do change their DNS servers on
mobile networks.

On Thu, Dec 13, 2018 at 4:09 PM <[email-masked]> wrote:

> *Envoyé :* jeudi 13 décembre 2018 07:42

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Dec 2018 09:50:56 +0100

Le 13/12/2018 à 03:56, Fred Baker a écrit :
> On Dec 12, 2018, at 7:03 AM, JORDI PALET MARTINEZ 
> <jordi.palet=[email-masked]> wrote:
>> I think what you fail to see is that even if DNS is provided by the 
>> operator, users tend to change it, so the new DNS will not 
>> necessarily use the same NAT64 prefix, and then create troubles ...
>
> For the record, I know of at least one CPE router implementation (the 
> one I use at my home) that by default uses OpenDNS rather than the 
> ISP-provided DNS. It does that in order to provide a certain service 
> to the user, which is that it discourages the use of sites that 
> OpenDNS thinks might convey malware. The user, in this case, is 
> changing it as a fact of having purchased that CPE.

Also for the record, in addition to CPE, I know of about some cars that 
connect on cellular and set to use other DNS server (not cellular's).   
In prototyping people I saw often use 8.8.8.8 or 2001:4860:4860:8:8:8:8 
from google.

That said I also agree with Med that on many cellular networks the 
majority of end users use the DNS server provided by that cellular 
operator.  Doing otherwise (use somebody else's DNS) was prohibited with 
firewall rules at some point, but have been removed.  Also, doing 
otherwise (use somebody else's DNS) means that the operator is not 
accountable for that Internet connection: the operator will not answer 
any support request.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Dec 2018 09:52:38 +0100

> I stand by that statement. Users can and do change their DNS servers on 

Yes, but they do so at their own risk.

Alex

> 
> On Thu, Dec 13, 2018 at 4:09 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Lorenzo, ____
> 
>     __ __
> 
>     “Are not doing in the networks I’m familiar with” is not the same as
>     “will do in the future”. ____
> 
>     __ __
> 
>     The link does not show the “do” part of your statement. ____
> 
>     __ __
> 
>     Please avoid using “not true” and the like. ____
> 
>     __ __
> 
>     Cheers,____
> 
>     Med____
> 
>     __ __
> 
>     *De :*Lorenzo Colitti [mailto:[email-masked]
>     <mailto:lorenzo@google..com>]
>     <draft-pref64folks-6man-ra-pref64-02>)____
> 
>     __ __
> 
>     You said that in cellular networks users don't change the DNS
>     server. The link I sent you shows that they can and do.____
> 
>     __ __
> 
>     On Thu, 13 Dec 2018, 00:49 <[email-masked]
>     <mailto:[email-masked]> wrote:____
> 
>         Re-,____
> 
>         ____
> 
>         Thank you for the pointer, but frankly speaking I don’t see the
>         link with what I said. ____
> 
>         ____
> 
>         Cheers,____
> 
>         Med____
> 
>         ____
> 
>         *De :*Lorenzo Colitti [mailto:[email-masked]
>         <mailto:lorenzo@google..com>]
>         *Objet :* Re: IPv6 configuration model (was Re: Adoption call
>         for <draft-pref64folks-6man-ra-pref64-02>)____
> 
>         ____
> 
>         On Thu, Dec 13, 2018 at 12:12 AM <mohamed.boucadair@orange..com
>         <mailto:[email-masked]>> wrote:____
> 
>             [Med] I said "NAT64 deployments I'm familiar" which is
>             basically cellular networks. In those networks, the users do
>             not change the DNS server. ____
> 
>         ____
> 
>         Not true.
>         https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html____
> 
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 09:14:40 +0000

Re-,

It depends. 

Hosts behind such CPE are likely to be dual-stack (this is similar to DS-Lite, MAP-*). The CLAT function in the CPE will be used, when required. These hosts do not require to support v6ops-transition-ipv4aas. 

If for some reason a host requires to be enabled in a IPv6-only mode, which I fail to see a motivation for it now, that host has to be compliant v6ops-transition-ipv4aas.

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 08:53
> Cc : Fred Baker; JORDI PALET MARTINEZ; [email-masked]
> > In these networks, DHCP is widely in use. Following the behavior described
> in the v6ops-v4aas draft already fixed the issue of DNS dependency for those
> networks.
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 09:20:15 +0000

Jordi, 

Why do you need to relay the information? 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 09:43
> À : Ole Troan; BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> I think the CPE (fixed networks or cellular broadband) can learn it using
> v6ops-v4aas, then use RA for the hosts ...
> 
> CC: "[email-masked]" <[email-masked]>, JORDI PALET MARTINEZ
> <jordi.palet=[email-masked]>
>     > In these networks, DHCP is widely in use. Following the behavior
> described in the v6ops-v4aas draft already fixed the issue of DNS dependency
> for those networks.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 10:38:58 +0100

In case the host want to do their own address synthesis, for example?

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 10:20
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Jordi, 

    Cheers,
    Med

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 09:44:44 +0000

Re-,

This can be avoided by following the current practices in the LAN side even if only an IPv6 prefix is delegated the CPE. That is:
* The LAN side can be dual-stack. 
* Address synthesis and translation can be handled by the CPE when required. 

No need to require any specific feature on the host side. 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 10:39
>     > If we want something such as v6ops-v4aas for the hosts, it should be
> part of
>     > host-requirements ...
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     >
>     >     Are you proposing that hosts should follow the recommendations in
> draft-
>     > ietf-v6ops-transition-ipv4aas?
>     >
>     >     Ole
>     >

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Dec 2018 10:45:33 +0100

Med,

> If for some reason a host requires to be enabled in a IPv6-only mode, which I fail to see a motivation for it now, that host has to be compliant v6ops-transition-ipv4aas.

If we want to have a constructive debate, I think we need to focus the discssion and understand the use case for this proposal.

The use cases:

Use case #1:
IPv6 only host(1) — IPv6 network — NAT64 — IPv4 Internet

Use case #2:
IPv4 application on IPv6 only host (2) — IPv6 network — NAT64 — IPv4 Internet

Use case #3
IPv4 only host — 464XLAT CE — IPv6 network — NAT64 — IPv4 Internet

1) IPv6 host, IPv6 only applications. Does not need IPv4 stack, but must be able to do local address synthesis
2) Host with IPv4 applications, IPv4 stack with stateul NAPT, and stateful NAT46

I think use case 2 and 3 are better solved with other options and that this document targetted use case 1.
Is that not the case?

Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 13 Dec 2018 10:58:59 +0100

>    Sure, there is no requirement that says it *has to be* this way.
>    But it is desirable, and only RA *allows* it to be this way

That statement doesn't seem technically correct. DHCPv6 can do this as well.

It is true that DHCPv6 does not currently have an option for a default router,
but RA currently doesn't have an option for the NAT64 prefix.

There are good reasons for adding a default router option to DHCPv6, but 
that has always been blocked by this group.

That doesn't change the fact that DHCPv6 also provide all configuration
information in one go.

We can go even further. These days hosts need to have some idea about 
the current time. For validation of TLS certificates, for DNSSEC local
validation.

So next up, we are going to add NTP servers to RA.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 11:09:26 +0100

If every vendor follows the best practice of having dual-stack support, we will not have many troubles ... but unfortunately is not the case!

If the hosts in the LAN is doing DNSSEC validation, the best way to ensure that a DNS64 is not in his way, is doing the synthesis, so needs to know the prefix.

I think there are many possible cases that can even escape our understanding right now, but we should support this.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 10:44
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Re-,

    
    Cheers,
    Med

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 10:14:09 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 10:46
> > Hosts behind such CPE are likely to be dual-stack (this is similar to DS-
> Lite, MAP-*). The CLAT function in the CPE will be used, when required. These
> hosts do not require to support v6ops-transition-ipv4aas.
> >
> > If for some reason a host requires to be enabled in a IPv6-only mode, which
> I fail to see a motivation for it now, that host has to be compliant v6ops-
> transition-ipv4aas.
> 
> If we want to have a constructive debate, I think we need to focus the
> discssion and understand the use case for this proposal.

[Med] Ole, your initial question was in the context of CPE-based "fixed networks" discussion. Evidently, the host in that case is what is located behind the CPE. No? Anyway, see below. 

> IPv4 only host — 464XLAT CE — IPv6 network — NAT64 — IPv4 Internet

[Med] The host can be DS as well + CE embeds CLAT. 

> I think use case 2 and 3 are better solved with other options

[Med] OK, let's put these two aside then. 

 and that this
> document targetted use case 1.
> Is that not the case?

[Med] I don't know what is the target of the document.

The main issues for which discovering the prefix is helpful for case#1 is IPv4 address literals and DNSSEC... which are also issues applicable in case 2. Given that you already said that other options are better for case 2, then the same conclusion applies for case 1 as well.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 13 Dec 2018 11:20:15 +0100

> If the hosts in the LAN is doing DNSSEC validation, the best way
> to ensure that a DNS64 is not in his way, is doing the synthesis,
> so needs to know the prefix.

One way to avoid DNSSEC issues is to have the DNS resolver only do NAT64 for
ipv4only.arpa.

If the host operating system stores the network provided resolvers in a 
special location. Then code that tries to discover the NAT64 prefix can
look in that location for the network provided resolvers, issue a lookup for
ipv4only.arpa and configure the local xlat module if a AAAA record is returned.

That shouldn't be hard to code, and still allows the user to override DNS
resolvers for normal DNS lookups.

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 10:21:00 +0000

Re-,

Do you see a problem to have dual-stack hosts ? 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 11:09
> If every vendor follows the best practice of having dual-stack support, we
> will not have many troubles ... but unfortunately is not the case!
> 
> If the hosts in the LAN is doing DNSSEC validation, the best way to ensure
> that a DNS64 is not in his way, is doing the synthesis, so needs to know the
> prefix.
> 
>     This can be avoided by following the current practices in the LAN side
> even if only an IPv6 prefix is delegated the CPE. That is:
>     >     > I think the CPE (fixed networks or cellular broadband) can learn
> it
>     > using
>     >     > Asunto: Re: IPv6 configuration model (was Re: Adoption call for
> <draft-
>     >     >     -------------------------------------------------------------
> ------
>     > -
>     >     >     -------------------------------------------------------------
> ------
>     > -
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > confidential. The information is intended to be for the exclusive
> use
>     > of the
>     >     > copying, distribution or use of the contents of this information,
> even
>     > if
>     >     > 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
>     >     > prohibited, will be considered a criminal offense, so you must
> reply to
>     > the

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 11:25:39 +0100

Vendors have a problem, not me ... There are many products in the market, new product every day, not supporting dual-stack.

My target is to solve the problem for users (and operators) even if those vendors are so stupid and don't do correctly their work.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 11:21
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Re-,

    Cheers,
    Med

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 10:33:58 +0000

Re-, 

Do you mean that there are products/hosts that are (1) IPv4-only? (2) IPv6-only?

If (1), then prefix discovery is not applicable to these hosts when an IPv6 connectivity is provided to the CPE. 
If (2), then these hosts are likely to be problematic when connected to CPE with an IPv4-only CPE. This is already broken. 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 11:26
> Vendors have a problem, not me ... There are many products in the market, new
> product every day, not supporting dual-stack.
> 
> My target is to solve the problem for users (and operators) even if those
> vendors are so stupid and don't do correctly their work.
> 
> Regards,
> Jordi
> 
> 
> 
>     > I think there are many possible cases that can even escape our
> understanding
>     > right now, but we should support this.
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     >
>     >     > Para: JORDI PALET MARTINEZ <[email-masked]>, Ole
> Troan
>     >     > <[email-masked]>
>     >     > Asunto: RE: IPv6 configuration model (was Re: Adoption call for
> <draft-
>     >     >     > Objet : Re: IPv6 configuration model (was Re: Adoption call
> for
>     > <draft-
>     >     >     > If we want something such as v6ops-v4aas for the hosts, it
> should
>     > be
>     >     > part of
>     >     >     > host-requirements ...
>     >     >     >
>     >     >     > Regards,
>     >     >     > Jordi
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     > In these networks, DHCP is widely in use. Following
> the
>     > behavior
>     >     >     > described in the v6ops-v4aas draft already fixed the issue
> of DNS
>     >     > dependency
>     >     >     > for those networks.
>     >     >     >
>     >     >     > individual(s) named above and further non-explicilty
> authorized
>     >     > disclosure,
>     >     >     > partially, including attached files, is strictly prohibited
> and
>     > will be
>     >     >     > information, even if partially, including attached files,
> is
>     > strictly

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 11:46:55 +0100

Combination of broken hosts/apps/Oss (which vendors I was referring to all the providers of those pieces).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 11:34
Para: JORDI PALET MARTINEZ <[email-masked]>, Ole Troan <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    Re-, 

    
    Cheers,
    Med

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Dec 2018 11:54:20 +0100

Med, Jordi,

Could you guys please hang on for a minute.
This isn’t ngtrans.
I am not convinced anything but use case #1 is in scope for 6man.

Cheers,
Ole

> On 13 Dec 2018, at 11:33, <[email-masked]> <[email-masked]> wrote:
> 
> Re-, 
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Dec 2018 07:45:24 -0300

> methods (anycast DNS; mobile network, anycast NTP).

Proposals to somehow do "prefix delegation" via RAs are the result of
being unwilling to do DHCPv6-PD, for example. And the IETF did publish
some of such documents.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Dec 2018 08:03:47 -0300

> I stand by that statement. Users can and do change their DNS servers on

There's no objection about "can". Regarding the "do" part, the
statement, as such, is so generic that it's rather irrelevant.

I'd argue that the average internet user does not do any manual
configuration or overrides. And in many cases, they don't even know what
the DNS is (nor should them).

Thanks,

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Dec 2018 12:16:32 +0100

I'm sorry, but many users (and even many ISPs), get easily instructions to change their DNS servers, and they do it, it is a fact.

Even if it is a small % of the global Internet, is relevant as a problem to solve.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Fernando Gont <[email-masked]>
Fecha: jueves, 13 de diciembre de 2018, 12:12
Para: Lorenzo Colitti <lorenzo=[email-masked]>, "<[email-masked]>" <[email-masked]>
CC: IETF IPv6 Mailing List <[email-masked]>
Asunto: Re: IPv6 configuration model (was Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>)

    
    Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Dec 2018 12:28:32 +0100

> the DNS is (nor should them).

YEs I agree: end user buying smartphone wont change DNS.

But some purpose-specific devices connecting on cellular networks are 
sold with a built-in DNS server whose IP address is distinct from that 
operator's.

(it's not the end user changing the DNS server, but it is the seller of 
these purpose-specific devices who does).

Alex

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 11:49:00 +0000

Ole, 

It is completely fine to make a call on what is in scope.

But, then all your three cases would not be in scope of 6man...all of them are about IPv4 service continuity not about native IPv6. Isn't it? 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 11:54
> À : BOUCADAIR Mohamed TGI/OLN; JORDI PALET MARTINEZ
> Cc : [email-masked]
> > If (2), then these hosts are likely to be problematic when connected to CPE
> with an IPv4-only CPE. This is already broken.
> >
> > Cheers,
> > Med
> >

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Dec 2018 12:59:47 +0100

Med,

> But, then all your three cases would not be in scope of 6man...all of them are about IPv4 service continuity not about native IPv6. Isn't it? 

The claim has been made that all IPv6 hosts must be able to communicate with an IPv4 host across a NAT64.
That puts use case #1 within scope of 6man in my mind.

It’s up to the working group to reach consensus if we want to work on this or not obviously.

Best regards,
Ole

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 12:06:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 13 décembre 2018 13:00
> Cc : JORDI PALET MARTINEZ; [email-masked]
> > But, then all your three cases would not be in scope of 6man...all of them
> are about IPv4 service continuity not about native IPv6. Isn't it?
> 

[Med] This is behave, not 6man. There is not such item in the 6man charter, BTW. 

> That puts use case #1 within scope of 6man in my mind.

[Med] How case#1 is then different from the case we were discussing with Jordi: IPv6/DS host---CLAT CE---NAT64?

> It’s up to the working group to reach consensus if we want to work on this or

[Med] Indeed.

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Dec 2018 13:11:15 +0100

Med,

> [Med] How case#1 is then different from the case we were discussing with Jordi: IPv6/DS host---CLAT CE—NAT64?

Jordi’s case is about how to deliver IPv4 in some form to the host.

Cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Dec 2018 08:18:54 -0600

I think you are probably both correct.

Most devices make it trivially easy to change DNS settings for WiFi and
Ethernet interfaces. Whereas on many if not most mobile devices the
cellular data interface doesn't easily allow users to change the DNS.  But
that doesn't mean it is impossible or that there are not many ways around
this.

So on cellular data networks, it is probably true that users changing DNS
is less likely than other network types, but it is still possible. Further,
there is a demand to do so, you just have to look at any user forum and you
will find questions about changing DNS for cellular data.

Finally, solutions that require the use of the provider's DNS have issues
in many environments, just because it is less of an issue on cellular data
networks, is irrelevant from a 6MAN perspective.

Thanks.

On Thu, Dec 13, 2018 at 2:47 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>> “will do in the future”.
>> *De :* Lorenzo Colitti [mailto:[email-masked] <lorenzo@google..com>]
>> *De :* Lorenzo Colitti [mailto:[email-masked] <lorenzo@google..com>]
>> <[email-masked]>> wrote:
>>
>> operator,

---

From: Christian Huitema <[email-masked]>
Date: Thu, 13 Dec 2018 07:31:22 -0800

> On Dec 13, 2018, at 3:03 AM, Fernando Gont <[email-masked]> wrote:
> 

Fernando, did you look at recent measurements? They show a large fraction of users using Google DNS, and a smaller fraction using Open DNS. Combined, we are speaking of tens of millions of users, maybe hundreds of millions.

-- Christian Huitema

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Dec 2018 09:52:23 -0600

> What makes NAT64 more special than, say, MAP or DS-Lite?
I think the difference is NAT64 is being pushed to hosts and even to
browser apps, MAP and DS-Lite seem to target the CPE and are only used at
that level as far as I know.  Devices that want to function on an IPv6-only
network and talk to the whole Internet need NAT64 or something equivalent.
I feel there is an emerging consensus that NAT6 is that something at least
at the host or app level. I like it because as a network operator with a
single piece of infrastructure I can provide users, their hosts, and apps
with many options; they can do DNS64 AAAA synthesis, 464-XLATE, IPv4
literal mapping, Happy Eyeballs 2, etc...
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Dec 2018 15:47:14 -0300

> Fernando, did you look at recent measurements? They show a large fraction of users using Google DNS, and a smaller fraction using Open DNS. Combined, we are speaking of tens of millions of users, m…

Does that necessarily mean that *users* are manually configuring DNS
servers?

I know of quite a few ISPs that announce Google DNS servers to clients
-- i.e., users end up using Google DNS servers not because users
override the ISP's automatic configuration, but because the ISP's
automatic configuration points to those DNS servers.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Dec 2018 06:10:14 +1100

> automatic configuration points to those DNS servers.

It's quite a while since I worked at a residential ISP, however one
problem we had was that after we deployed new anycast DNS servers with
knew addresses, and advertised them via IPCP, some of the helpdesk
staff when troubleshooting would eventually get customers to manually
set DNS addresses back to the old ones. Even if that didn't solve the
problem (it never would), that change wouldn't be reversed.

The perverse incentive is to get the customer working again and get
them off the phone, rather than fixing the actual problem. So don't
rely on helpdesks doing logical things, like e.g., leaving automated
DNS settings alone.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Dec 2018 08:30:49 +0100

Le 12/12/2018 à 17:00, Philip Homburg a écrit :
>> The other important advantage of the RA is that it's atomic. All
>> the configuration to get onto the network and communicate at layer
>> 3 is in a single packet that is guaranteed to have been received
>> (because you can't get a working IPv6 configuration without getting
>> an RA). That ensures clear and predictable behaviour, and ensures
>> that IPv4 is available and working the instant that IPv6 is
>> available.
> 
> One packet may have the SLAAC prefix, a second packet the default
> router, a third DNS resolvers, a fourth some other config.

In general yes, because prefix is in a PIO (O option), the def router is
the value of Lifetime, DNS is an option, and so on.  Each can be sent in
a distinct RA and by distinct routers.

However, there are exceptions.

By RA spec: some parameters are not optional, no atomic operation.

By implementations: odhcp is not able to just configure the More
Specific routes (even though it is an option - RIO); because the client
odhcp6c must first self-configure an address which requires PIO
presence, and only then can it use the Route Information Option.

Were the spec of RIO clear that RIO can work independently (atomic
operation) then such wrong implementation of RIO would not happen, and
we'd have the atomic operation in place.

Alex

> 
> It is quite possible to end up with a situation where a network
> operator has a router that doesn't support a new RA option and just
> installs a box next to it that does nothing but advertise the needed
> information.
> 
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 10:19:19 +0100 (CET)

> - DHCP option. Hmm, don’t know.

I'm getting into the game here a bit late.

My stance is that RA should contain basic information to get packets 
flowing. This involves both IPv6 and IPv4 if it's IPv4aaS in use. 
Addresses and DNS resolvers are central to this, and if IPv4 access 
requires NAT64 then I want that in RA as well.

I am also sitting here on my desktop with 3 VMs running, just because I 
need access to three different VPNs for three different use-cases, plus 
the fourth one that is just "regular Internet" for the host OS. That's a 
very heavy-handed approach. What I would prefer is of course PVD support 
in my host OS so it would have a bunch of addresses from these different 
PVDs (Internet + 3 VPNs) so it could intelligently choose between 
addresses for different applications etc.

So, this leads me to support the way of using 
draft-ietf-intarea-provisioning-domains to supply this PVD information. 
One can argue that the NAT64 prefix could be supplied using the PVD 
information instead, but that means IPv4 connectivity can't be used until 
the PVD information request has completed. I'd like it to be faster than 
that, which means I support the NAT64-prefix-in-RA approach.

My stance is that DHCPv6 stateless information mechanism can be replaced 
by the "PVD Additional Information" concept as described in 
draft-ietf-intarea-provisioning-domains and DHCPv6 stateful should be 
replaced in full by an equivalent PD mechanism using RA/ND. We check that 
we didn't miss anything DHCPv6 does, and if we did, enhance what is needed 
into ND/RA and PVD mechanism. After that we can deprecate the use of 
DHCPv6.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Fri, 14 Dec 2018 10:06:00 +0000

Mikael,

You said that receiving, in RAs, "DNS resolvers are centrals"...which I interpret as you will use the resolvers supplied by the network provider. 

This means also that you don't think that "requires the host to use network provided resolvers" quoted in the message you replied to is an issue. 

Did I missed something in your reasoning? 

Thank you. 

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Mikael Abrahamsson
> Envoyé : vendredi 14 décembre 2018 10:19
> À : Ole Troan
> Cc : 6man WG

---

From: Philip Homburg <[email-masked]>
Date: Fri, 14 Dec 2018 11:25:23 +0100

>draft-ietf-intarea-provisioning-domains 

I don't follow the discussion surrounding that draft, but did the authors
verify that indeed all DHCP stateless option can be replaced by this
proposal?

To give two examples:
1) This draft proposes that additional state is optained using HTTP over 
   TLS. Typically TLS requires the host to have some idea about the current
   time. So using this mechanism to find local NTP servers is not going to
   work.
2) DHCP is typically used for PXE (network) booting. Requiring the firmware
   of a host to properly support TLS to obtain the bootfile URL is likely
   going to be an issue.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 13:04:45 +0100 (CET)

> You said that receiving, in RAs, "DNS resolvers are centrals"...which I interpret as you will use the resolvers supplied by the network provider.

I want that to be an option to the host, yes.

> This means also that you don't think that "requires the host to use network provided resolvers" quoted in the message you replied to is an issue.

That is correct, I would like to avoid host having to use network provided 
DNS64, I want host to be able to discover NAT64 prefix from RA and itself 
do DNSSEC validation and DNS64 and/or 464XLAT while using whatever 
resolver it wants.

Now, this doesn't preclude RFC7050 style discovery of NAT64 prefix for 
that PVD, but I'd like to avoid having that as a requirement.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 13:08:17 +0100 (CET)

>   of a host to properly support TLS to obtain the bootfile URL is likely

Right, these are great examples of things that need to be fixed before 
deprecating DHCPv6.

Otherwise feel free to "steal" concepts from 
draft-ietf-netconf-zerotouch-25 where the "configlet" can be obtained from 
unencrypted sources in some circumstances. So for some devices it might be 
better to have a profile where no encryption is needed but instead you get 
information unencrypted from a proximity source (link-local perhaps?).

If we have a concept which is secure then it's easy to lessen the security 
requirements for some deployment scenarios. It's harder to go the other 
direction.

---

From: <[email-masked]>
Date: Fri, 14 Dec 2018 12:36:48 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Mikael Abrahamsson [mailto:[email-masked]]
> Envoyé : vendredi 14 décembre 2018 13:05
> Cc : Ole Troan; 6man WG
> Objet : RE: IPv6 configuration model (was Re: Adoption call for <draft-
> > You said that receiving, in RAs, "DNS resolvers are centrals"...which I
> interpret as you will use the resolvers supplied by the network provider.
> 

[Med] OK, you trust it then. Great! 

> 
> > This means also that you don't think that "requires the host to use network
> provided resolvers" quoted in the message you replied to is an issue.
> 

[Med] You can already do that with 7050! Millions of subscribers are already using this model. See slides 8 and 9 
https://www.ripe.net/participate/meetings/regional-meetings/ipv6-day-denmark/presentations/4-tomasz-ipv6_day_kopenhagen_v4.pdf 

In such model:
* DNS64 is used only for prefix discovery
* the hosts issues both A and AAAA
* address synthesis is done by the host. 

I'm puzzled why you need another way to discover the pref64 while existing tools already offer you how to satisfy your requirements, including DNSSEC validation.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 13:46:20 +0100 (CET)

On Fri, 14 Dec 2018, [email-masked] wrote:

> I'm puzzled why you need another way to discover the pref64 while 
> existing tools already offer you how to satisfy your requirements, 
> including DNSSEC validation.

I want to deprecate DHCPv6. I also don't want DNS64 to have to be used in 
resolvers at all, not even for ipv4.arpa.

I don't like the ships-in-the-night approach between DHCPv6 and RA/ND. I 
want network to timely be able to communicate to the device that things 
have changed. Please don't anyone tell me DHCPv6 reconfigure is an option, 
because it isn't.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 14 Dec 2018 13:52:52 +0100

>From the introduction of the draft, it is not clear to me what it provides
that DHCP cannot do. It seems to reinvent DHCP in a different way.

There are some small differences, that could easily be incorporated in DHCP.
(Multiple domains, using the same name for different networks)

At the same time, where DHCP has clear support for providing a host with 
unique, per host configuration, that doesn't seem to be the case for
provisioning domains.

In the end it very much reads as an attempt to reimplement DHCP for no
particular reason.

---

From: <[email-masked]>
Date: Fri, 14 Dec 2018 13:05:43 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : vendredi 14 décembre 2018 13:46
> I want to deprecate DHCPv6.

[Med] Okay. This is IMHO an argument that is not specific to this discussion. 

 I also don't want DNS64 to have to be used in
> resolvers at all, not even for ipv4.arpa.

[Med] Why? What is a problem with using DNS for service discovery?

> have changed.

[Med] RA may not be appropriate here. The only deterministic approach we have for this is to get directly the information from the NAT64 instance: PCP is your friend. 

 Please don't anyone tell me DHCPv6 reconfigure is an option,
> because it isn't.

[Med] I won't... because I do think that the DHCP discussion is out of scope.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 15:19:25 +0100 (CET)

> [Med] Why? What is a problem with using DNS for service discovery?

Because I think that using DNS64 with this well-known address is kind of a 
hack. I'd rather have this explicitly announced in for instance RA.

> [Med] RA may not be appropriate here. The only deterministic approach we 
> have for this is to get directly the information from the NAT64 
> instance: PCP is your friend.

How are you going to speak PCP until you've discovered the NAT64 prefix? 
You can't use PCP to discover the NAT64 prefix, right?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Dec 2018 23:42:06 +0900

> You can't use PCP to discover the NAT64 prefix, right?

There is a complex (its designers would say "feature-rich") way to discover
the NAT64 prefix using PCP. RFC 7225. I don't think it has any substantial
implementation in hosts, nor (IMO) is it likely to, given its complexity
and lack of advantages compared to RFC 7050.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 15:49:25 +0100 (CET)

On Fri, 14 Dec 2018, Lorenzo Colitti wrote:

> There is a complex (its designers would say "feature-rich") way to 
> discover the NAT64 prefix using PCP. RFC 7225. I don't think it has any 
> substantial implementation in hosts, nor (IMO) is it likely to, given 
> its complexity and lack of advantages compared to RFC 7050.

I just scanned RFC7225. I don't see how it can work unless you already 
know (a | the) NAT64 prefix.

So yes, you can discover if there are more NAT64 prefixes this way, but 
you can't discover the NAT64 prefix from scratch using PCP from what I can 
tell.

---

From: <[email-masked]>
Date: Fri, 14 Dec 2018 15:12:05 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 14 décembre 2018 15:19

[Med] DNS may be a hack, but this does not justify announcing service information in an RA.  

> How are you going to speak PCP until you've discovered the NAT64 prefix?

[Med] Native IPv6! 

> You can't use PCP to discover the NAT64 prefix, right?

[Med] This is explained in RFC7225.

---

From: <[email-masked]>
Date: Fri, 14 Dec 2018 15:31:43 +0000

Mikael, 

An implementation is described here: https://datatracker.ietf.org/meeting/85/materials/slides-85-pcp-6 

Cheers,
Med

> Envoyé : vendredi 14 décembre 2018 15:49
> À : Lorenzo Colitti
> Cc : BOUCADAIR Mohamed TGI/OLN; 6man WG

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2018 16:44:33 +0100 (CET)

>> How are you going to speak PCP until you've discovered the NAT64 prefix?

Right. What's the destination address of the PCP packet?

> [Med] This is explained in RFC7225.

I can't find it. Please help.

What is the destination address of the PCP packet you're going to send to 
discover the NAT64 prefix?

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Dec 2018 08:04:56 +1100

> On 15 Dec 2018, at 2:12 am, <[email-masked]> <[email-masked]> wrote:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 

It is a hack that does NOT work reliably.  It requires having *all* the DNS servers
in the resolution chain special case the handling of ipv4only.arpa to get the
answers from the ISP’s DNS servers.

See https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa-14 for
a list of the known ways ipv4only.arpa does not work well.

DNS64 was only ever a STOP GAP mechanism.  We have to do something that works
NOW (2011/2012)!  We have to do something that works with existing machines
without changing them (they have all basically been changed).  There were
lots of known flaws with DNS64 when it was proposed.  Those flaws are why
we are here now discussing alternative mechanisms for publishing the NAT64
prefix despite NAT64 also having known flaws above those of NAT44.

DNS64 worked well enough with cell phones and their limited DNS usage model.
DNS64 doesn’t work anywhere near as well with fixed lines where the ISP’s
DNS setting are often overridden.  The hacks fail in that environment.

Given the hacks that is DNS64 fails in too many scenarios we need to go
back to more conventional mechanisms to get traffic to go through the NAT64
and to do that we need to publish the NAT64 prefix in some way other than
RFC 7050.

---

From: Mark Smith <[email-masked]>
Date: Sat, 15 Dec 2018 08:22:40 +1100

> discover the NAT64 prefix?

Probably,

RFC7723, "Port Control Protocol (PCP) Anycast Addresses"

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 15 Dec 2018 07:27:21 +0100 (CET)

> RFC7723, "Port Control Protocol (PCP) Anycast Addresses"

Sigh, this means the local LAN router can't be configured to say "oh, use 
the NAT64 over there" without having to intercept packets to this special 
address, and then if it only wants to configure NAT64 and nothing else I 
guess it has to have some kind of forwarding behaviour to the "real" 
NAT64?

This is not a good way to provision NAT64 relay prefix to clients in 
several scenarios. I'm sure it's fine for a large operator running a 
mobile network or similar, but if I were to try to use this in my home 
that'd be quite advanced way to get this information into clients.

---

From: Mark Smith <[email-masked]>
Date: Sat, 15 Dec 2018 18:04:35 +1100

On Sat., 15 Dec. 2018, 17:27 Mikael Abrahamsson <[email-masked] wrote:

> address,

"Interception" of anycast addresses is easy, you just create a local
instance within the forwarding path before the next closest instance.

On occasion a number of devices at my house have found DNS resolution via
8.8.8.8 (and the IPv6 version) to be served within 5 or so milliseconds,
because I added that address to the loopback interface of my OpenWRT CPE.

and then if it only wants to configure NAT64 and nothing else I

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Dec 2018 12:43:22 +0100

for what is worth

Le 15/12/2018 à 08:04, Mark Smith a écrit :
[...]
> DNS resolution via 8.8.8.8 (and the IPv6 version) to be served within
> 5 or so milliseconds,

 From where I look the IPv6 DNS address of google has now a smaller RTT 
than the IPv4 address (8ms vs 10ms, or so).

4 years ago or so the difference was inverse and larger (200ms vs 10ms, 
or so).

I can now safely recommend my users to use the IPv6 DNS server of 
google, rather than the IPv4 one, because it is likely to be faster.

Alex

  because I added that address to the loopback
> interface of my OpenWRT CPE.
> 
> 
> 
> 
> and then if it only wants to configure NAT64 and nothing else I guess
> it has to have some kind of forwarding behaviour to the "real" 
> NAT64?
> 
> mobile network or similar, but if I were to try to use this in my
> home that'd be quite advanced way to get this information into
> clients.
> 
> -- Mikael Abrahamsson    email: [email-masked]
> <mailto:[email-masked]>
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Dec 2018 10:34:15 +0900

> instance within the forwarding path before the next closest instance.

If you want to intercept everything, sure. If you only want to intercept a
given port, then... good luck with getting that to work reliably. Network
stacks try really really hard not to forward packets that are bound to an
address that they already have. Solutions to that problem usually end up
being brittle, unreliable, and very ad-hoc.

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Dec 2018 13:32:36 +1100

On Mon, 17 Dec 2018 at 12:34, Lorenzo Colitti <[email-masked]> wrote:
>> "Interception" of anycast addresses is easy, you just create a local instance within the forwarding path before the next closest instance.
>
>
> If you want to intercept everything, sure. If you only want to intercept a given port, then...

Then there would not be an IANA assigned anycast address exclusively
for PCP, there would only be a well known reserved transport layer
port for PCP.

I think IANA reserving an anycast address exclusively for PCP is
implying that any and all transport layer protocol ports are allocated
and reserved at that address exclusively for the purposes of
performing the PCP function or service, possibly via different
protocols.

>good luck with getting that to work reliably. Network stacks try really really hard not to forward packets that are bound to an address that they already have.
> Solutions to that problem usually end up being brittle, unreliable, and very ad-hoc.

And would fail to comply with RFC8200, where the destination IP
address in a packet identifies the final network layer destination for
the packet. Packet forwarding stops after that destination is reached.

An anycast address assigned to a particular function or service is not
a unicast host or interface address anymore. I think it has instead
become a routeable service identifier.

I think the IP model has conflated services and protocols. A single
service could be provided over multiple different protocols, with the
different protocols suiting different needs or reflecting evolution.
The port numbers are the protocol identifiers once the packet has
reached the (or one of in the cast of anycast) service providing
device.

Some examples:

Traditional DNS protocol over UDP and TCP, DNS over TLS and DNS over
HTTP are all providing the same service with the same goal - a name
resolution service.

Both SSH and telnet protocols are providing a network virtual terminal
service, with the main difference being the protocols being SSH has
mandatory encryption. The outcome is the same though, the user ends up
with a remote terminal login/CLI session.

RF868 Time Protocol ("rdate"), SNTP and NTP protocols providing a real
time clock synchronisation service.

Anycast 8.8.8.8 providing a name resolution service via both
traditional port 53 UDP/TCP DNS and port 443 DoH is an example.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Dec 2018 06:39:26 +0100 (CET)

> the packet. Packet forwarding stops after that destination is reached.

Yes, and if the end user gateway device wants to check if the network has 
some nice autodetect responses it might give and at the same time 
intercept packets from its clients then you run into problems.

That's why I don't like the "send addresses to a well-known address to 
autodiscover" kind of solution, it becomes convoluted when a device might 
want to supply this service but also use this same service upstream for 
some reason, and needs to autodetect this itself.

Like if you're intercepting packets to 8.8.8.8 but you want your device to 
talk to 8.8.8.8, then all of a sudden things get complicated.

---

From: <[email-masked]>
Date: Mon, 17 Dec 2018 08:18:29 +0000

Hi Mark,

Please see inline. 

Cheers,
Med

> De : Mark Andrews [mailto:[email-masked]]
> Envoyé : vendredi 14 décembre 2018 22:05
> Cc : Mikael Abrahamsson; 6man WG

[Med] "conventional mechanisms" are discussed in draft-ietf-v6ops-transition-ipv4aas.  

> and to do that we need to publish the NAT64 prefix in some way other than

[Med] Yeah, alternative means exist already. Please read draft-ietf-v6ops-transition-ipv4aas.

---

From: <[email-masked]>
Date: Mon, 17 Dec 2018 08:58:02 +0000

Mikael, 

The procedure for selecting the PCP server for a single-homed PCP client is as follows: 

(1) use whatever server that is explicitly configured to the client. FWIW, standardized means for configuring PCP servers include both IETF ones (DHCP (RFC7291)) or BBF (https://www.broadband-forum.org/technical/download/TR-181_Issue-2_Amendment-8.pdf).

(2) if no server is configured: assume default router (LAN case) or DS-Lite AFTR (CPE in DS-lite mode) are the pcp server, or go for anycast PCP addresses. 

Cheers,
Med

> Envoyé : samedi 15 décembre 2018 07:27
> À : Mark Smith