Subject: Re: [v6ops] ipv6only-flag-02 security

From: Fred Baker <[email-masked]>
Date: Thu, 13 Sep 2018 14:29:41 -0700

Speaking strictly for myself, all one of me. However, I'm copying v6ops in case someone operational will dispute my viewpoint or support it.

I would expect that if an ISP is offering only IPv6 to the CPE, the CPE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 within the LAN. The ISP will never know whether there is actual IPv4 in the home/SOHO/Enterprise, other than that the PLAT it presumably implements will see traffic. If it's doing CGN, MAP-E, or MAP-T, it is implementing the overlay, will be aware of it, and will be paying for it; the 464XLAT model means that it doesn't have to think about it (or pay for it) beyond the PLAT and its prefix. I'm hearing rumblings from various operators to the effect that IPv4 is becoming operationally expensive - one that has been in the news recently was Aussie Broadband, but they are in no sense the only source of such rumblings.

From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is the best case currently on the table. If 6man agrees, I would suggest using draft-pref64folks-6man-ra-pref64 at PS to deprecate (make historic/NOT RECOMMENDED) RFCs 6147 and 7050. In that, there would be value in a plugfest, perhaps at IETF 103 or 104 during the Hackathon, to let various implementors demonstrate draft-ietf-v6ops-transition-ipv4aas using 464XLAT+draft-pref64folks-6man-ra-pref64 and state their roll-out plans.

I find myself thinking about https://www.youtube.com/watch?v=_y36fG2Oba0. Yes, I think a day something like that is coming. First they ignore you; then they laugh at you, ...

> On Sep 12, 2018, at 2:31 AM, Markku Savela <[email-masked]> wrote:
> 
> On 12/09/18 12:08, Ole Troan wrote:
>>>> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4
>>>> operations. The RA flag is incorrectly configured.  Barbara
>>> I don't agree.  If all the RAs have ipv6-only set, and there is still DHCPv4,
>>> I'd conclude that the IPv4 is fake.
>> Agree. From my perspective the whole point of this flag is to signal configuration information to hosts.
>> A compliant host receiving this flag, should disable all IPv4 processing on the relevant interface.
> 
> And if I have a home/site network
> 
> - connected to ISP offering IPv6 only,
> 
> - and internally using additional IPv4 addresses via local DHCP server (or via another ISP connection offering IPv4) to support locally IPv4 only legacy devices (printers, etc.).
> 
> As home/small site user (*), I may not have ANY control on RA's sent by the first ISP. If they were to set this ipv6-only flag and, if this would disable my IPv4 addressing, I would be a bit pissed off...
> 
> (*) though, if ISP provided "home router" is configurable, and the ipv6-only flag in RA would be controllable by home user. Then maybe acceptable...
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 14 Sep 2018 10:52:53 +1100

I fully agree with this point of view.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: viernes, 14 de septiembre de 2018, 8:31
Para: Markku Savela <[email-masked]>
CC: V6 Ops List <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: [v6ops] ipv6only-flag-02 security

    

    
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

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

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Sep 2018 13:10:38 +0200

Fred,

Did you post this on the wrong thread? I am not sure how this relates to the ip6only-flag draft.
Changed subject.

> I would expect that if an ISP is offering only IPv6 to the CPE, the CPE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 within the LAN. The ISP will never know whether there is…

Speaking as one of the editors of the MAP series documents, that’s a misrepresentation.
PLAT = stateful NAT64 has similar costs and scaling properties as a CGN. That is, significantly worse than stateless solutions.

> From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is the best case currently on the table. If 6man agrees, I would suggest using draft-pref64folks-6man-ra-pref64 at PS to deprecate…

I don’t know if 6man has a particular view on provisioining of a NAT64 prefixes. Nor do I know if we should.

If you mentioned the ipv6only-flag draft in the context 464XLAT. 464XLAT offers a native dual-stack service, and that’s not what the ipv6only-flag draft is about.
That’s about true IPv6 only links, where there is no IPv4 packets on the link.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Sep 2018 13:41:56 +0200

> That’s about true IPv6 only links, where there is no IPv4 packets on the link.

On 4G links of smartphones using CLAT and PDP type IPv6 (no IPv4 PDP 
type) there are no IPv4 packets.

I understand CLAT has to do with 464xlat.

So I suppose there is relevance of ipv6-only flag and 464xlat.

I may be wrong though.

Alex

---

From: Ca By <[email-masked]>
Date: Fri, 14 Sep 2018 06:00:24 -0700

On Fri, Sep 14, 2018 at 4:11 AM Ole Troan <mblings.

> PLAT = stateful NAT64 has similar costs and scaling properties as a CGN.
> That is, significantly worse than stateless solutions.
>

Citation?  I don’t believe it is true, but would like to see your market
rate analysis (not the stateless religion axiom).

In my own case, coming from nat44, we simply turned on nat64 on the same
box, added ipv6 to the user, and load has gone down on that combined
nat44/64 box due to most traffic going ipv6 e2e.   In this way, nat64 has
lowerd my load / bill with no new capex. That is my specific case.

That said, i have only seen MAP BR be spec’d to deployed on million dollar
cards in million dollar routers.  Also, map comes with a less efficient
static v4 allocation model and complex dhcpv6 deployment.  Both MAP and
NAT64 come as freeware, but that is less interesting than a commercial
solution a general telco could deploy, unless you have a freeware
deployment case study.

---

From: [email-masked]
Date: Fri, 14 Sep 2018 16:16:48 +0200

H Cameron,

> Citation?  I don’t believe it is true, but would like to see your market rate analysis (not the stateless religion axiom). 

We (DT) currently have customer deployments of both FOSS and commercial implementations of lw4o6 AFTRs in production. Compared to a stateful NAT44/64 based solution (where none was currently deployed), the business case was pretty simple to make.

Cheers,
Ian

---

From: Lee Howard <[email-masked]>
Date: Fri, 14 Sep 2018 12:52:54 -0400

> PLAT = stateful NAT64 has similar costs and scaling properties as a CGN. That is, significantly worse than stateless solutions.

I asked a vendor for performance numbers on NAT44, NAT64, and MAP, and 
their stateful solutions were faster. "We've had more time to tune and 
optimize."

> That’s about true IPv6 only links, where there is no IPv4 packets on the link.

The statement "464XLAT offers a native dual-stack service" is the 
complete opposite to my understanding of "native." What do you mean?

There are lots of ways IPv6-only links can carry IPv4 packets, and those 
ways comprise the set "transition technologies."

Lee

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Sep 2018 19:37:19 +0200

On 14 Sep 2018, at 18:52, Lee Howard <[email-masked]> wrote:

> The statement "464XLAT offers a native dual-stack service" is the complete opposite to my understanding of "native." What do you mean?

You are not trolling me?
All the IPv4aaS mechanisms have as their purpose to offer IPv4 service to hosts. In 464xlat, as the others they hosts on links behind one of these devices get native IPv4. IPv4 Ethernet 0x800. In the typical 464xlat case, triple NATted, but indistinguishable from any other IPv4 service. If that was carried over MPLS, Ethernet or PPP upstream. 

Ole

---

From: Lee Howard <[email-masked]>
Date: Fri, 14 Sep 2018 14:44:25 -0400

> All the IPv4aaS mechanisms have as their purpose to offer IPv4 service to hosts. In 464xlat, as the others they hosts on links behind one of these devices get native IPv4. IPv4 Ethernet 0x800. In t…

If I'm trolling, I swear it's unintentional.
A mobile handset with CLAT built in is a host that only has native IPv6, 
and is doing IPv4 in translation only, right? That host couldn't be 
considered "native dual-stack," could it? Even the bump that provides 
IPv4 to the application is faking it: it's not providing native IPv4, 
it's providing translated IPv4.

Then there's the much rarer case of CLAT in a home gateway (I'd love to 
find one that work well!).  Maybe you could say they have native IPv4 
access to hosts on the LAN, maybe even throughout the house, but they 
don't have native IPv4 Internet access, do they?

If your ISP provisioned your home with IPv6+464xlat and called it 
"native dual-stack," would you be satisfied with their representation of 
their service?

All of that was about the definition of "native."  In the original 
context, I agree that a device offering CLAT, such as a home gateway or 
mobile hotspot offering CLAT, should not use the ipv6only-flag. Maybe we 
need an "ipv4-sorta" flag? (okay, now I'm trolling)

Lee

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Sep 2018 21:17:07 +0200

Lee,

> If I'm trolling, I swear it's unintentional.

Good. ;-)

> A mobile handset with CLAT built in is a host that only has native IPv6, and is doing IPv4 in translation only, right? That host couldn't be considered "native dual-stack," could it? Even the bump that provides IPv4 to the application is faking it: it's not providing native IPv4, it's providing translated IPv4.

The host has an IPv4 enabled interface, and an IPv4 only application on that host sends IPv4 packets that appear just like they were sent (barring the “normal IPv4 NAT” to the destination.
By “native dual-stack”, I would consier both protocols delivered on “equal” terms, that’s not quite the case when the application runs on the CLAT as in this case. It’s certainly not an IPv6 only host.

> Then there's the much rarer case of CLAT in a home gateway (I'd love to find one that work well!).  Maybe you could say they have native IPv4 access to hosts on the LAN, maybe even throughout the house, but they don't have native IPv4 Internet access, do they?

This was the case I was mainly thinking about, and since this happens for all tethering cases I doubt it’s rare.
Anyway those hosts are certainly “native dual stack”, if you are lucky enough that the CLAT also gives you IPv6.
On that link you could put an unchanged IPv4 host from the 80s, and it would still work, right?

> If your ISP provisioned your home with IPv6+464xlat and called it "native dual-stack," would you be satisfied with their representation of their service?

Yes. There is nothing distinguishing the resulting IPv4 service from LW46, MAP-E/T or 464XLAT from IPv4 delivered if the upstream access was Ethernet, PPP or HDLC. Or more typically some sort of L2TP tunnelling.
> 
> All of that was about the definition of "native."  In the original context, I agree that a device offering CLAT, such as a home gateway or mobile hotspot offering CLAT, should not use the ipv6only-flag. Maybe we need an "ipv4-sorta" flag? (okay, now I'm trolling)

Native is from the perspective you are sitting.
A good measure I believe is if you can take an unchanged IPv4 host and connect it to the link, if that works, then you have native IPv4. Regardless of how the network delivers those packets in the network. If you disagree with that, then you couldn’t even fit header compression into the Internet architure.

The IPv6 only flag could have been applied on the CLAT up-link. Now, in the mobile network case, there is already support for that in the link-layer.

Cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2018 12:44:41 -0700

> On Sep 14, 2018, at 4:10 AM, Ole Troan <[email-masked]> wrote:
> 
> Fred,
> 

Well, it was in the context of a comment raised on that thread. But yes, after I sent it, I realized I should have changed the subject.

> PLAT = stateful NAT64 has similar costs and scaling properties as a CGN. That is, significantly worse than stateless solutions.

Agreed. But a stateless solution has the operator purchasing IPv4 address space and using it end to end for the IPv4 component. If the objective is to no longer need to purchase or manage IPv4 address space (Aussie Broadband's presentation at AUSNOG a couple of weeks ago being but one example of such a viewpoint), a solution that requires them to purchase and manage IPv4 in the ISP network fails the requirement.

---

From: Lencse Gábor <[email-masked]>
Date: Fri, 14 Sep 2018 21:55:41 +0200

Dear Ole,

I wonder how would you define native IPv6.

So far, I have been teaching to my students that if they use different 
IPv6 transition technologies, which carry their IPv6 packets over IPv4 
(like 6to4, teredo, 6rd, tunnel broker, etc.), then it is not native IPv6.

Best regards,

Gábor

---

From: Lee Howard <[email-masked]>
Date: Fri, 14 Sep 2018 15:59:15 -0400

> By “native dual-stack”, I would consier both protocols delivered on “equal” terms, that’s not quite the case when the application runs on the CLAT as in this case. It’s certainly not an IPv6 only h…
Okay, so if they're not quite equal, it's not native, but it's arguably 
dual-stack.
Why, oh why, didn't we get consensus to work on Jordi's vocabulary draft?

> On that link you could put an unchanged IPv4 host from the 80s, and it would still work, right?

Last I heard, it doesn't happen for tethering cases, because the 
tetherers were unable to allocate IPv6 addresses. I guess you'd argue 
that the clients behind the handset/AP were single-stack IPv4.
Maybe that's been updated.
And maybe I'm putting too fine a point on it, but are they being 
"delivered on 'equal' terms" if one is in translation?

Let me back up to pre-history:
Before I had IPv6 to my house, I had native IPv4 to my home, but 
translated (i.e., not native) IPv4 to the hosts in my home.
Natives speak the language. They don't require translation.

> Yes. There is nothing distinguishing the resulting IPv4 service from LW46, MAP-E/T or 464XLAT from IPv4 delivered if the upstream access was Ethernet, PPP or HDLC. Or more typically some sort of L2…

I'm not so sure. Layer 2 protocols never (for fairly high values of 
"never") touch any of the upper layer header fields. Some 
implementations of various transition technologies (including some 
NAT44) alter some header fields. I'm thinking of source port numbers or 
DF bits. In a native deployment, that would never happen.
> Native is from the perspective you are sitting.

I do agree with that, and is what I proposed for the terminology draft. 
You might have an IPv4-only application on a native-IPv6+v4-translated 
host on an IPv6-only link that is part of an IPv6-only+IPv4aaS network.
> A good measure I believe is if you can take an unchanged IPv4 host and connect it to the link, if that works, then you have native IPv4. Regardless of how the network delivers those packets in the…
What is the antecedent of "you" in the clause "you have native IPv4"? I 
agree that the host is provisioned with native IPv4, but I don't agree 
that it has native IPv4 Internet connectivity.

So I go back again, to the early days of deployment. We used to ask, 
"You have IPv6, but is it *native* IPv6?" I guess the only alternatives 
then were 6rd, 6to4, 6in4, Teredo, and every other version of tunneling. 
"Native IPv6" meant you had IPv6 end to end.

Is that not what we mean anymore?  Or is it a question of tunneling vs. 
translation? It would feel very strange to say that MAP-E is native IPv4 
and MAP-T is not.

> The IPv6 only flag could have been applied on the CLAT up-link. Now, in the mobile network case, there is already support for that in the link-layer.

Yes, as far as I understand from others on this list and 6man, that is 
the case.

Lee

---

From: Simon Hobson <[email-masked]>
Date: Fri, 14 Sep 2018 21:30:31 +0100

Lencse Gábor <[email-masked]> wrote:

> So far, I have been teaching to my students that if they use different IPv6 transition technologies, which carry their IPv6 packets over IPv4 (like 6to4, teredo, 6rd, tunnel broker, etc.), then it is not native IPv6.

I would suggest, as previously said in reference to native IPv4, it depends on what chair you are sitting in. Take my setup which (when I sort out the wiring after a house move) uses a GNU/Linux VM as a router doing PPPoE to my ISP for IPv4 and a tunnel to HE's TunnelBroker service for IPv6 :

If your seat is the router VM, then on the "outside" I don't have native IPv6 - it arrives via a tunnel. On the "inside" I am running native IPv6 as in "fire an IPv6 packet out of the ethernet port and it arrives at another host".
It could be argued that the external IPv4 service is not native either since external IPv4 traffic is tunnelled in a PPP connection.

For other devices on my LAN, it's native IPv6 (and IPv4) - they just fire out IP packets over the ethernet wire and they get routed.

So I'd use the definition also previously mentioned. If the device simply fires packets out of an ethernet (or wireless, or 4G, or ...) interface without any translation* or encapsulation beyond simply wrapping in a transport layer (eg PPP) then it's "native" - regardless of whether the packets get tunnelled in some manner upstream. But if the application or local host protocol stacks have to do some mangling (eg NAT46) then it's not native.

Analogy: We're all familiar with the Plain Old Telephone Service (POTS) where we have a socket on the wall, plug in an analogue phone, and get dial tone. We don't really care that in the exchange the signal gets digitised - it appears to us as an analogue service.
Now lets go VoIP ... Your provider sends you a terminal adapter with a POTS socket on it - and as far as your phone is concerned it's still a native POTS service even though the voice is now encapsulated in IP packets, but from the PoV of the adapter it's IP on the "outside". But if you get a VoIP phone, then it's not a native POTS service from the PoV of the phone as the phone is now talking IP packets.

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2018 13:55:44 -0700

> On Sep 14, 2018, at 12:59 PM, Lee Howard <[email-masked]> wrote:
> 
> And maybe I'm putting too fine a point on it, but are they being "delivered on 'equal' terms" if one is in translation?

Said without hats...

I'm sorry, IPv4 and IPv6 are not equals. If they were, there would be no argument for preferring one over the other. IPv6 gives you an end-to-end architecture, while IPv4 gives you a NAT-NAT architecture, with the issues raised in RFC 1993.

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 15 Sep 2018 08:17:32 +1100

Hi Ole,

I don't think you can compare CGN with NAT64.

NAT64 is doing a much better and dynamic (on demand) usage of the port of the IPv4 address pool. So, it scales much more than CGN. As a consequence, an ISP need much less IPv4 addresses for the same number of customers with NAT64 than CGN, and you don't have many of the problems that CGN poses because the restrictions in the number of ports.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: viernes, 14 de septiembre de 2018, 22:13
Para: Fred Baker <[email-masked]>
CC: V6 Ops List <[email-masked]>, 6man WG <[email-masked]>
Asunto: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 security)

    Fred,

    

    
    
    Ole

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Sep 2018 08:07:32 +1000

> On 15 Sep 2018, at 7:17 am, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Ole,
> 

There is nothing architecturally different between CGN and NAT64 w.r.t. IPv4 port allocation.  NAT64 may have less traffic going though it as we know there is a IPv6 service.  For CGN we don’t know if there is a IPv6 service to offload traffic or not.

		IPv6 + NAT64 vs IPv6 + CGN vs CGN

Both destination address selection rules and DNS64 (if in use) push traffic towards IPv6
if there is a choice in transports.  Even if you don’t have native IPv6 you can still move traffic off the CGN using 6rd where the BR is stateless.

	    IPv6 + NAT64 vs IPv6 + CGN vs CGN vs CGN + 6rd

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 15 Sep 2018 09:13:33 +1100

Hi Mark,

It may depend on the specific CGN implementation protocol, but in CGN you pre-allocate a given number of ports per user.

Is not relevant if that user actually uses all those ports or needs more. They aren't available for other users and each user has a specific limit on the number of ports.

In NAT64, the ports get allocated on the fly as needed for each user. So I think it is clear that it is much more efficient.

Regars,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mark Andrews <[email-masked]>
Fecha: sábado, 15 de septiembre de 2018, 9:09
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: 6man WG <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security)

    

    
    
    Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Sep 2018 09:21:16 +1000

> On 15 Sep 2018, at 8:13 am, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Mark,
> 

It’s definitely implementation specific.  You can do the same thing with a NAT64 box (IPv6 prefix to IPv4 <address,port-range>).  It’s all about logging trade offs.  There is nothing in the two technologies requiring it or prohibiting it.  In many cases those logging trade offs are driven by legislative requirements to be able to trace back to specific customers for traffic that is years old.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 15 Sep 2018 05:19:35 +0000

"native."  In the original context, I agree that a device offering CLAT, such as a home gateway or mobile hotspot offering CLAT, should not use the ipv6only-flag.

I agree. It would be very confusing to use such a flag.

XLAT, MAP etc. allow for both v6 and v4 to the end hosts (on LAN) or end applications (on the bump/fake LAN )

And a device implementing XLAT, MAP etc. must support both v6 and v4 aka dual-stack, even if restricted to a subset of interfaces.

Maybe we need an "ipv4-sorta" flag?

IMHO, we don’t. :-)

A mobile handset with CLAT built in is a host that only has native IPv6, and is doing IPv4 in translation only, right? That host couldn't be considered "native dual-stack," could it?

Let’s put it the other way - The hosts could NOT be considered IPv6-only for sure, If they were offered v4 and v6 prefixes.

Cheers,
Rajiv

On Sep 15, 2018, at 12:15 AM, Lee Howard <[email-masked]<mailto:[email-masked]>> wrote:

On 14 Sep 2018, at 18:52, Lee Howard <[email-masked]<mailto:[email-masked]>> wrote:

Lee

Ole

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 15 Sep 2018 05:36:07 +0000

Both NAT44 and NAT64 are types of CGN, as long as they satisfy the requirements outlined in RFC6888.

//

Carrier-Grade NAT (CGN):  A NAT-based [RFC2663<https://tools.ietf.org/html/rfc2663>] logical function used
      to share the same IPv4 address among several subscribers.  A CGN
      is not managed by the subscribers.

//

I somewhat agree with Mark.

Cheers,
Rajiv

On Sep 15, 2018, at 1:23 AM, Mark Andrews <[email-masked]<mailto:[email-masked]>> wrote:

On 15 Sep 2018, at 8:13 am, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mark,

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Sep 2018 17:47:41 +1200

> I agree. It would be very confusing to use such a flag.

It would be plain wrong. The flag (if the IETF chooses to standardise it)
would apply strictly to the link on which the RA arrives, and in this
case the link would provide IPv4 service, so the flag would be zero.
It's completely irrelevant how the IPv4 service is carried on the uplink.

>> Maybe we need an "ipv4-sorta" flag?

Definitely not.

   Brian

> On Sep 15, 2018, at 12:15 AM, Lee Howard <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>
>>
>>> On 14 Sep 2018, at 18:52, Lee Howard <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Sep 2018 08:58:44 -0500

On Wed, Sep 19, 2018 at 7:03 AM, Philip Homburg <[email-masked].
com> wrote:

>
> So we can assume that to the extent that mDNS and SSDP are chatty, the host
> operating system vendor is perfectly okay with the resulting battery
> consumption. I.e. that rate already needs to be tuned for IPv4-only or
> dual stack operation. IPv6-only doesn't make it worse.
>

I think this is an interesting observation. However, I note that at least
one of the solution using mDNS does provide a mechanism to mitigate the
amount of battery power used by these functions.

https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy

I think mDNS in IPv6-only networks is an issue that should be brought to
the DNSSD working group.

Also, I note that DNSSD is already working on at least some of the issues
of service discovery in large-scale WiFi and more generally multi-segment
campus networks.

Further multicast service discovery of all types is frequently partially or
completely blocked or at least highly controlled in most large-scale WiFi
systems.

So, maybe we shouldn't take these as issues we need to solve here in 6MAN
maybe they are better solved in other WGs.

I think V6OPS should own the identification of IPv6-only problems and
issues but maybe other WGs are better-suited to actually solve them, and
maybe we should not assume they are IPv6 protocol issues to be solved in
6MAN.

I think RFC2563 is a good mitigation strategy for the immediate issues in
our IPv6-only experiments. I think we need to do more of these experiments
to find all issues, I'll bet we haven't found them all yet. :)

I'd like to suggest we not completely drop the IPv6-only flag work, at
least yet. I like us to talk with the DNSSD WG and probably DHC WG too,
maybe they will think it is the way to solve these issues or maybe they
have better solutions.

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: Ole Troan <[email-masked]>
Date: Wed, 19 Sep 2018 20:16:12 +0200

> I'd like to suggest we not completely drop the IPv6-only flag work, at least yet. I like us to talk with the DNSSD WG and probably DHC WG too, maybe they will think it is the way to solve these issues or maybe they have better solutions. 

What’s the worst that can happen if we standardize this bit?

Given that it appears mostly harmless, I don’t see a big risk in standardizing it.

Ole

---

From: David Schinazi <[email-masked]>
Date: Wed, 19 Sep 2018 11:29:19 -0700

> On Sep 19, 2018, at 11:16, Ole Troan <[email-masked]> wrote:
> 

This is not harmless. It costs us a bit from a limited pool, and will cause issues when trying to deploy the next version of IP after 6.

This problem can be solved at other layers. If the authors want to bring a draft to DNSSD recommending that hosts do not send mDNS over IPv4 link-local when there is routable IPv6 present, that would be a welcome discussion.

David

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Sep 2018 21:02:14 +0200

David,

> This is not harmless. It costs us a bit from a limited pool, and will cause issues when trying to deploy the next version of IP after 6.

We have RFC5175 so this is hardly a scarce resource.
The next version after IPv6? I certainly hope that’s going to be something a little more creative than existing within this version space…

> This problem can be solved at other layers. If the authors want to bring a draft to DNSSD recommending that hosts do not send mDNS over IPv4 link-local when there is routable IPv6 present, that wou…

It’s not quite obvious how mDNS can be repaired. Or if it’s worth the effort, over something as simple as a single flag.
Disabling IPv4 link-local has more promise. (Although it would have been nice to able to disable mDNS for IPv6 too.)

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2018 10:51:12 +1200

> What’s the worst that can happen if we standardize this bit?

The bit would no longer be available for future assignment, and
since it's in a one-byte field, that is significant. For example,
if we ever decided to modify the semantics of the much discussed
M and O bits, we'd only have one more reserved bit to play with.

I take that argument quite seriously, so we do need to be 100% sure
of the value of standardizing the proposal.

> Given that it appears mostly harmless, I don’t see a big risk in standardizing it.

There are some missing security considerations in the draft, 
specifically about the bit being used as an attack on IPv4 services,
but (unlike some other people) I think that "mostly harmless" is
accurate. So "often useful" vs "mostly useless" is the big question
for me.

   Brian

---

From: <[email-masked]>
Date: Fri, 21 Sep 2018 13:45:34 +0000

Hi Jordi, 

No sure to understand your comment. 

At least, from an implementation standard, modern CGNs and NAT64 are following the same recommendations from the IETF. For example, https://tools.ietf.org/html/rfc7857 inspires from NAT64 (e.g., TCP state machine). 

The address sharing ratio (and ports to be assigned per device/customer) is deployment-specific.   

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de JORDI PALET MARTINEZ
> Envoyé : vendredi 14 septembre 2018 23:18
> À : Ole Troan; Fred Baker
> Cc : V6 Ops List; 6man WG
> Objet : Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02
> security)
> 
> Hi Ole,
> 
> NAT64 is doing a much better and dynamic (on demand) usage of the port of the
> IPv4 address pool. So, it scales much more than CGN. As a consequence, an ISP
> need much less IPv4 addresses for the same number of customers with NAT64
> than CGN, and you don't have many of the problems that CGN poses because the
> restrictions in the number of ports.
> 
> Regards,
> Jordi
> 
> 
> 
>     > Speaking strictly for myself, all one of me. However, I'm copying v6ops
> in case someone operational will dispute my viewpoint or support it.
>     >
>     > I would expect that if an ISP is offering only IPv6 to the CPE, the CPE
> might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 within
> the LAN. The ISP will never know whether there is actual IPv4 in the
> home/SOHO/Enterprise, other than that the PLAT it presumably implements will
> see traffic. If it's doing CGN, MAP-E, or MAP-T, it is implementing the
> overlay, will be aware of it, and will be paying for it; the 464XLAT model
> means that it doesn't have to think about it (or pay for it) beyond the PLAT
> and its prefix. I'm hearing rumblings from various operators to the effect
> that IPv4 is becoming operationally expensive - one that has been in the news
> recently was Aussie Broadband, but they are in no sense the only source of
> such rumblings.
> 
>     > From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is
> the best case currently on the table. If 6man agrees, I would suggest using
> draft-pref64folks-6man-ra-pref64 at PS to deprecate (make historic/NOT
> RECOMMENDED) RFCs 6147 and 7050. In that, there would be value in a plugfest,
> perhaps at IETF 103 or 104 during the Hackathon, to let various implementors
> demonstrate draft-ietf-v6ops-transition-ipv4aas using 464XLAT+draft-
> pref64folks-6man-ra-pref64 and state their roll-out plans.
> 
>     If you mentioned the ipv6only-flag draft in the context 464XLAT. 464XLAT
> offers a native dual-stack service, and that’s not what the ipv6only-flag
> draft is about.
> 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: <[email-masked]>
Date: Fri, 21 Sep 2018 13:54:58 +0000

Hi Fred, 

If the goal is to show 464xlat without 6147/7050, draft-ietf-v6ops-transition-ipv4aas provides only how to do that without requiring to modify access routers:

===
   464XLAT-6:  [RFC8115] MUST be implemented and a DHCPv6 Option
               "OPTION_V6_PREFIX64" ([RFC8115]), with zeroed
               ASM_mPrefix64 and SSM_mPrefix64, MUST also be considered
               as a valid NAT64 prefix (uPrefix64).

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

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Fred Baker
> Envoyé : jeudi 13 septembre 2018 23:30
> À : Markku Savela
> Objet : Re: ipv6only-flag-02 security
> 
> Speaking strictly for myself, all one of me. However, I'm copying v6ops in
> case someone operational will dispute my viewpoint or support it.
> 
> I would expect that if an ISP is offering only IPv6 to the CPE, the CPE might
> well implement both an IPv6 router and a 464XLAT CLAT for IPv4 within the
> LAN. The ISP will never know whether there is actual IPv4 in the
> From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is the
> best case currently on the table. If 6man agrees, I would suggest using
> I find myself thinking about https://www.youtube.com/watch?v=_y36fG2Oba0.
> Yes, I think a day something like that is coming. First they ignore you; then
> they laugh at you, ...
> 
> > - and internally using additional IPv4 addresses via local DHCP server (or
> via another ISP connection offering IPv4) to support locally IPv4 only legacy
> devices (printers, etc.).
> >
> > As home/small site user (*), I may not have ANY control on RA's sent by the
> first ISP. If they were to set this ipv6-only flag and, if this would disable
> my IPv4 addressing, I would be a bit pissed off...
> >
> > (*) though, if ISP provided "home router" is configurable, and the ipv6-
> only flag in RA would be controllable by home user. Then maybe acceptable...
> >
> >