Subject: ipv6only-flag-02 security

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 11 Sep 2018 15:28:30 +0000

> ... the security implications of this flag give me the heebie-jeebies

I think the current draft has already done some mitigation of potential DoS attack on hosts by saying that if at least 1 RA has the bit *not* set, the host SHOULD NOT assume IPv6 only. Another possible mitigation that occurred to me is the host could try DHCPv4 for a minute before shutting down IPv4 operations (if no DHCPv4 response). If there is a DHCPv4 response, then the router is lying. If there is no DHCPv4 response within a minute, then either the router is correct and not malicious, or there is a malicious router that has so much control over the network that it can prevent all other router Ras from arriving at the host and it can prevent DHCPv4 messages from succeeding. If the latter, then this flag is the least of the network's worries.

If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 operations. The RA flag is incorrectly configured.
Barbara

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Sep 2018 15:39:23 +0000

> On 11 Sep 2018, at 16:28, STARK, BARBARA H <[email-masked]> wrote:
> 

Or there is a rogue DHCPv4 server?  I'll see your heebie and raise you a jeebie ;)

Tim

---

From: tom petch <[email-masked]>
Date: Tue, 11 Sep 2018 16:47:49 +0000

---- Original Message -----
From: "STARK, BARBARA H" <[email-masked]>
To: "'Ole Troan'" <[email-masked]>; "Nick Hilliard"
<[email-masked]>
Cc: "6man WG" <[email-masked]>
Sent: Tuesday, September 11, 2018 4:28 PM
Subject: ipv6only-flag-02 security

> I think the current draft has already done some mitigation of
potential DoS attack on hosts by saying that if at least 1 RA has the
bit *not* set, the host SHOULD NOT assume IPv6 only. Another possible
mitigation that occurred to me is the host could try DHCPv4 for a minute
before shutting down IPv4 operations (if no DHCPv4 response). If there
is a DHCPv4 response, then the router is lying. If there is no DHCPv4
response within a minute, then either the router is correct and not
malicious, or there is a malicious router that has so much control over
the network that it can prevent all other router Ras from arriving at
the host and it can prevent DHCPv4 messages from succeeding. If the
latter, then this flag is the least of the network's worries.
>
> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4
operations. The RA flag is incorrectly configured.

Or a bad actor has access to the link and has injected a malicious
DHCPv4 response in order to deceive those who would rather not bother
with IPv4..

I think that the current Security Considerations spell out the
possibility of bad actors quite well and do not understand what other
threats the instigators of this thread have in mind.

Tom Petch

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 14:14:34 -0400

> I think the current draft has already done some mitigation of potential
    > DoS attack on hosts by saying that if at least 1 RA has the bit *not*
    > set, the host SHOULD NOT assume IPv6 only.

    > Another possible mitigation
    > that occurred to me is the host could try DHCPv4 for a minute before
    > shutting down IPv4 operations (if no DHCPv4 response). If there is a
    > DHCPv4 response, then the router is lying.

Or, an attacker is running a rogue DHCPv4 server, and is planning to
examine all the traffic that passes through.

Since the IPv6-only network probably has NAT64 somewhere, the rogue can
easily arrange to do stateless translation and make the connection look
good.  (remember, this can be configured by mistake on a number of desktop OSs by
mistake, rather than malicious intent and it's rather common in many
networks)

Is it likely that an attacker would be aware of the NAT64, and yet not aware
that they can spoof the RA ipv6-only=0?  That seems to dumb to me, but then
script kiddies often make such mistakes.

    > If there is no DHCPv4

Agreed.

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

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

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 11 Sep 2018 18:30:42 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Michael Richardson

> examine all the traffic that passes through.

Going back to the filter at layer 2 option, blocking all internal ARP and IPv4 in the internal switch solves that problem. As to rogue DHCPv4 servers or even rogue routers, I think you cannot ultimately get away from having to do security the right way, if things are that bad. Which means, encryption and authentication. Anyone can add such rogue devices in a network, no matter flag or no flag, or layer 2 blocking or no.

Bert

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Sep 2018 06:07:03 +1000

> Or there is a rogue DHCPv4 server?  I'll see your heebie and raise you a jeebie ;)

As observed, this is really just another example of a rogue packet
that can disrupt other hosts' operation. People are already tolerating
and accepting this type of risk already when they attach multiple
untrusted hosts to a mutual trust multi-access link layer.

Point-to-point physical or logical link and IPv6 prefix per individual
host, isolating them entirely from all other hosts, is the only way to
fully mitigate all these issues.

There could be some specific mitigations for this risk, however it it
is not a new risk.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 17:05:20 -0400

>>>>> ipv6  <<[email-masked]> On Behalf Of Michael Richardson> writes:
Manfredi (US), Albert E <[email-masked]> wrote:
    >>> Another possible mitigation that occurred to me is the host could try
    >>> DHCPv4 for a minute before shutting down IPv4 operations (if no
    >>> DHCPv4 response). If there is a DHCPv4 response, then the router is
    >>> lying.
    >>

    > Going back to the filter at layer 2 option, blocking all internal ARP
    > and IPv4 in the internal switch solves that problem.

Yes, it does, provided you can control block every single layer-2 device.
If not, you get islands where IPv4 LL continues to work, and people might
not even know that IPv4 was turned off, or that their printer is obsolete.

The feature to block specific ethertypes is rare among comodity APs that you
find in coffee shops, or homes.  Plain old unmanaged ethernet switches are
found in quite a number of unexpected places, and they aren't going to block
things, because they can't.

(I'm thinking university campuses, labs in enterprises, and pretty much any
government department I know of where IT is totally outsourced, and people
resort to under-the-desk ethernet switches because getting a new drop
takes 1-2 years)

And, pretty much every single laptop and desktop PC running Windows, Linux or
MacOS has an unmanaged ethernet switch in it thanks to the fact that we
pretty much all have the ability to run virtual machines.  And those bridges
exist even though the "front" internet is wireless...

    > As to rogue DHCPv4
    > servers or even rogue routers, I think you cannot ultimately get away
    > from having to do security the right way, if things are that bad. Which
    > means, encryption and authentication. Anyone can add such rogue devices
    > in a network, no matter flag or no flag, or layer 2 blocking or no.

As I said, it doesn't have to be malicious.
Three clicks in the wrong place and many laptops start bridging between wired
and wireless.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 11 Sep 2018 21:56:07 +0000

-----Original Message-----

> Three clicks in the wrong place and many laptops start bridging between wired

I think we're going off in too many directions at the same time.

The purpose of this flag was for things like wireless devices saving energy, by not attempting to acquire IPv4 addresses. Or really any device, saving time by avoiding looking for IPv4 service. Filtering at layer 2, and then adjusting timers in these devices, could also achieve this type of purpose.

In addition to enterprise nets, home modem/router/WiFi access points are, or can be, managed by your ISP. So this type of layer 2 filtering could be done, by the guy who is saying "no IPv4 in your net." Today these devices incorporate unmanaged switches? Maybe some of them do. New ones could be designed differently.

Sure, the user can always add his own Ethernet switch, to run his own old printer or what have you, but that switch would probably not be a DHCP server or the router to the WAN. So for these battery operated hosts that you're worried about, let's say they are not the ones who are trying to use the ancient printer, nothing would change, necessarily. They would still know that IPv4 is not routed.

And finally, if someone innocently connects a DHCPv4 server and perhaps an IPv4 router, not maliciously, what harm is done? Not much! At most, devices in that local net will be wasting energy and time, waiting on IPv4 services.

In short, for the purposes mentioned, I think the IPv6-only flag, or layer 2 filtering, could pretty much do the same automatic job.

Bert

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Sep 2018 17:07:36 -0500

On Tue, Sep 11, 2018 at 3:07 PM, Mark Smith <[email-masked]> wrote:

> potential DoS attack on hosts by saying that if at least 1 RA has the bit
> *not* set, the host SHOULD NOT assume IPv6 only. Another possible
> before shutting down IPv4 operations (if no DHCPv4 response). If there is a
> DHCPv4 response, then the router is lying. If there is no DHCPv4 response
> within a minute, then either the router is correct and not malicious, or
> there is a malicious router that has so much control over the network that
> it can prevent all other router Ras from arriving at the host and it can
> prevent DHCPv4 messages from succeeding. If the latter, then this flag is
> the least of the network's worries.
> > >

One of the reasons I like this strategy, adding a flag to the RA, is we
already mostly understand the risks involved and have developed tools to
mitigate many of those risks. If we build a new mechanism to signal this as
has been suggested, we may have to develop those mitigation tools from
scratch.

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: Rob Evans <[email-masked]>
Date: Tue, 11 Sep 2018 23:41:52 +0100

> One of the reasons I like this strategy, adding a flag to the RA, is we already mostly understand the risks involved and have developed tools to mitigate many of those risks. If we build a new mechanism to signal this as has been suggested, we may have to develop those mitigation tools from scratch.

I agree. We do appear to be obsessed with corner cases with this draft.

Cheers,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Sep 2018 15:09:21 +1200

> I'd conclude that the IPv4 is fake.

It's either fake, or it's a mistake. Either way, it's a heuristic choice for
the host stack to make: trust the unexpected DHCP server, or don't. If a
bad actor has enough access to the link to bring up a DHCP server, she's got
enough access to do many other evil things, so does it really matter?

> I agree. We do appear to be obsessed with corner cases with this draft.

Thank you.

     Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Sep 2018 11:08:27 +0200

> On 11 Sep 2018, at 20:14, Michael Richardson <[email-masked]> wrote:
> 
> 

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.

“Let the host figure it out itself is where we are today”. And they can’t do a very good job at it, e.g. they do very poorly for noisy protocols like MDNS.

Cheers,
Ole

---

From: Markku Savela <[email-masked]>
Date: Wed, 12 Sep 2018 12:31:08 +0300

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Sep 2018 19:35:12 +1000

Then you ring the ISP and give them hell for being idiots.

-- 
Mark Andrews

> On 12 Sep 2018, at 19:31, Markku Savela <[email-masked]> wrote:
> 
> - 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...
> 
>

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Sep 2018 09:19:01 -0500

On Wed, Sep 12, 2018 at 4:31 AM, Markku Savela <[email-masked]> wrote:

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

The default for this flag is cleared for a reason, only someone with
knowledge of the devices attached to the LAN should set this flag. My ISP
has no idea what devices are attached to my home network, therefore it is
wholly inappropriate for an ISP to set this flag for the LAN in my house.
It could be reasonable for them to set the flag on a public WiFi network,
if it is clear it is an IPv6-only WiFi network, such as if it has "IPv6" in
the SSID or this is made clear in some other way. Furthermore, the flag is
not intended to signal anything about the WAN or upstream service provided
to an ISP's customers, it is about the local LAN. A local LAN can have IPv4
routing with an IPv6-only uplink, using 464xlate, DS-Lite, etc....

Maybe someday in the future, it will be reasonable to change the default
for this flag to be set. That is when it is reasonable to expect that LANs
don't have IPv4, that is not the normal expectation today and it will be
sometime before that changes.

Something like the following should be added to the draft;

It is only appropriate for someone, an administrator, to set this flag if
they have a reasonable knowledge that the devices attached to a network
don't need IPv4 routing services or are not intended to have these services.

Thanks
--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Sep 2018 10:11:29 +1200

> ipv6-only flag in RA would be controllable by home user. Then maybe 

Well yes. The scope is managed networks. We can make that clearer
in the Applicability section.

    Brian

---

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

> don't need IPv4 routing services or are not intended to have these services.

Plus: The flag must be cleared by default.

   Brian

---

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

--------------------------------------------------------------------------------
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: 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: 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: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: Nick Hilliard <[email-masked]>
Date: Sun, 16 Sep 2018 18:11:35 +0300

> untrusted hosts to a mutual trust multi-access link layer.

It's troubling to see this casually waved away as "just another example 
of a rogue packet", because of the extent to which rogue control plane 

 > There could be some specific mitigations for this risk, however it it

... is incorrect: there is a new risk here, namely that the flag opens 
up a disruption risk relating to protocol incongruence.

The helicopter view of ipv6only-flag is as follows: the control plane 
signalling mechanism for protocol stack type A issues a directive aimed 
at protocol stack type B, namely that as far as it's concerned, stack B 
should be completely shut down on the interface that the signal is received.

There are plenty of examples in IETF documents which provide mechanisms 
for stacks running protocol X to signal to other stacks running the same 
protocol X to take action on the basis of non-authenticated single 
datagrams.  Examples of this would include RIP, DHCP (v4 and v6), ND and 
so on.  DHCPv4 doesn't signal DHCPv6 protocol behaviour and ND doesn't 
specify how ipv4 should operate.

Historically, these "rogue packet" protocol specs have caused a great 
deal of trouble and the operational community learned over time that we 
needed external mechanisms to protect users from undesirable 
side-effects.  RIP ended up being turned off completely - lots of people 
in this WG will remember "routed" being enabled by default on bsd unix 
derivatives, and then disappearing over time as vendors woke up to the 
fact that it was a terrible idea to have it enabled on end hosts.

DHCP, arp and ND spoofing continued to be a problem until l2 forwarding 
devices (switches, etc) became smarter and allowed us to create layer 2 
filters to handle them.  By-and-large, we are now forced to live with 
this sort of threat and - rightly or wrongly - the IETF writes off the 
security concerns by saying that if a network operator wants to provide 
support for a protocol stack, that they have an obligation to do clever 
stuff at layer 2 to ensure that that particular protocol stack is 
protected against rogue packet injection abuse.

Conversely, there are other examples of authenticated or negotiated 
protocols which allow protocol stack type A to influence protocol stack 
type B, e.g. you can send ipv6 NLRIs in an ipv4 transport stream in bgp, 
or use ISIS to transmit both ipv4 and ipv6 routes.  These work ok 
because the protocol negotiation mechanisms are bi-directional and 
negotiated communication generally has the side effect of providing 
primitive, low-level security for the data stream by virtue of there 
being state identifiers on both sides which can be used to determine 
whether packets received are legitimate.  No-one will claim that this is 
strong security, but injecting a single rogue packet will usually not 
break something.

The ipv6only flag is different in this respect because the proposal is 
for ipv6 packets to be used to signal that ipv4 services be shut down on 
an interface.  This creates a requirement for operators of ipv4-only 
networks to implement protection against ipv6 on their networks in order 
to ensure that their ipv4 network continues to function reliably in the 
situation that someone starts injecting spoofed ND packets with the 
ipv6only flag set.  In other words, IPv6 will become a protocol that 
will be actively harmful to networks where the underlying infrastructure 
is intended only to support ipv4.  This is new territory for the IETF.

As a general comment from the point of view of security architecture, 
adding extra security complexity to what is already an unsafe-by-default 
flag is a terrible idea.

Nick

---

From: Simon Hobson <[email-masked]>
Date: Sun, 16 Sep 2018 17:54:49 +0100

Nick Hilliard <[email-masked]> wrote:

> The ipv6only flag is different in this respect because the proposal is for ipv6 packets to be used to signal that ipv4 services be shut down on an interface.  This creates a requirement for operators of ipv4-only networks to implement protection against ipv6 on their networks in order to ensure that their ipv4 network continues to function reliably in the situation that someone starts injecting spoofed ND packets with the ipv6only flag set.  In other words, IPv6 will become a protocol that will be actively harmful to networks where the underlying infrastructure is intended only to support ipv4.

I agree that this is an attack vector, however I disagree that it's **significant additional** risk over and above those already faced by IPv4 only networks.

Consider the typical IPv4 only network - IPv4 is configured by the admin (or by default, via the ISP provided router), typically using DHCP. However, most modern hosts* will be running dual stack by default. What happens when a rogue device starts sending IPv6 RAs ?
That is not going to be much less disruptive without the IPv6 only flag as it will be with it. While some services (particularly internal ones) will continue to work, many will suffer from "random" delays and failures while their systems attempt to use IPv6 to access external services. In some ways I'd suggest that a hard failure (devices honouring the rogue IPv6 only flag) is better than a random soft failure when it comes to finding the culprit.
So either RA packets (or even all IPv6 packets) need to be filtered at L2, or they (with or without the IPv4 only flag) need to be treated as another risk to be detected and dealt with if they occur - just like rogue IPv4 DHCP servers, loopbacked cables creating broadcast storms, accidental competing default gateways, etc, etc.

* OK, we know that there's a lot of IoTat etc rubbish that will never support IPv6 - but they'll also be immune to the issue.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Sep 2018 08:49:49 +1200

On 2018-09-17 03:11, Nick Hilliard wrote:
...
> This creates a requirement for operators of ipv4-only 
> ipv6only flag set. 

You're saying that an IPv4-only network (pretty close to being a thing
of the past, but never mind that) needs to ignore IPv6 packets in case
they are malicious.

Yes, I have no problem with that.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2018 08:38:32 +1000

> up a disruption risk relating to protocol incongruence.

The risk is a rogue RA packet disrupting host operation. That is not a new risk.

Layer 2 filters beyond the layer 2 headers are a hack and a layer
violation. However, as RA Guard exists, it will mitigate this. (It
would have been fortunate if RAs were sent to an "router clients"
multicast group rather than an "all hosts" group so that there was an
RA specific layer 3 and layer 2 multicast address to simplify
filtering.)

SEcure Neighbor Discovery (SEND) would be another option to
specifically prevent the impact of rogue RAs.

As I said, if the more general risk of attaching untrusted hosts to a
mutual-trust multi-access link, and specifically the RA guard/SEND
mitigation for this is unacceptable or undeployable, then complete
layer 2 isolation of untrusted hosts from each other is necessary.

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2018 09:03:56 +1000

> Yes, I have no problem with that.

And it is also not a new risk. The rogue IPv6 risk has existed since
hosts became capable of IPv6 and enabled it by default. For Windows,
that has been since Vista was released in January 2007, Linux hosts
much earlier in my experience, since iOS 4 for iPhones in 2010 etc.

Networks can layer 2 filter 0x86dd frames if they consider rogue IPv6
a risk. Or they could instead spend that time properly enabling it.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Sun, 16 Sep 2018 18:12:11 -0500

> On Sep 16, 2018, at 17:38, Mark Smith <[email-masked]> wrote:
> 

Rogue DHCPv4 servers poses a similar risk for IPv4-only networks, with similar mitigations. By the way, IPv6-only networks should have at least this IPv4 mitigation, just like IPv4-only networks should have IPv6 RA-Guard and DHCPv6 filters to prevent rogue IPv6.

> specifically prevent the impact of rogue RAs.

SEND is a mitigation for IPv6-only networks, an IPv4-only network would need RA-Guard, since there isn’t suppose to be IPv6, configuring SEND on IPv4-only hosts seems even more unlikely than for IPv6-only hosts. In most untrusted networks the practicality of deploying SEND even for IPv6-only is extremely limited, and it is entirely unrealistic for IPv4-only.

> layer 2 isolation of untrusted hosts from each other is necessary.

Same for DHCPv4 snooping or filters.

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2018 10:24:34 +1000

On Mon., 17 Sep. 2018, 09:12 David Farmer, <[email-masked]> wrote:

> Rogue DHCPv4 servers poses a similar risk for IPv4-only networks, with
> similar mitigations. By the way, IPv6-only networks should have at least
> this IPv4 mitigation, just like IPv4-only networks should have IPv6
> RA-Guard and DHCPv6 filters to prevent rogue IPv6.
>
> SEND is a mitigation for IPv6-only networks, an IPv4-only network would
> need RA-Guard, since there isn’t suppose to be IPv6, configuring SEND on
> IPv4-only hosts seems even more unlikely than for IPv6-only hosts.

Enabling SEND and having no SEND authenticated default routers will prevent
unauthenticated rogue RAs having any effect to the IPv4 only dual stack
hosts.

I agree its unlikely to be commonly deployed, however SEND is the formal
solution to protect against spoofed or rogue unauthenticated ND messages,
which is why I mentioned it.

Of course, SEND doesn't eliminate all the risks of attaching untrusted
hosts to a mutual-trust multi-access link.

In most untrusted networks the practicality of deploying SEND even for
> IPv6-only is extremely limited, and it is entirely unrealistic for
> IPv4-only.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Sep 2018 09:50:38 +0300

Simon Hobson wrote on 16/09/2018 19:54:
> What happens when a rogue device starts sending IPv6 RAs ?

That would depend on the host config for ipv6 but at least ipv4 will 
continue to work.

It’s the fact that ipv4 is unilaterally being blown away that’s the 
problem.  Not quite sure why you're saying that this is not a 
significant additional risk.  Really, it is.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Sep 2018 09:56:32 +0300

> of the past, but never mind that) needs to ignore IPv6 packets in case

A network consists of host devices and the network infrastructure. 
These are two discrete entity sts, and they would often use different 
management and management policies.

What I'm saying is that if the network infrastructure doesn't protect 
against ipv6, not only will the hosts be subject to attacks against ipv6 
(as before), they will also be subject to attacks against ipv4, 
regardless of any ipv4 spoofing protection mechanisms in the network 
infrastructure.

Nick

---

From: Simon Hobson <[email-masked]>
Date: Mon, 17 Sep 2018 11:26:17 +0100

Nick Hilliard <[email-masked]> wrote:

> Undefined re: ipv6 but at least it won’t trash ipv4.  It’s the fact that ipv4 is being blown away that’s the problem.

Yes it will trash IPv4 for some hosts - and it'll be rather arbitrary and appear "random" in appearance to the user when the host tries to use the not-working IPv6 route(s) advertised. I'd suggest that such "random" faults will be harder to pin down than a hard fault, consider what's likely to happen :

a) Rogue IPv6 RA triggers hosts to attempt to use IPv6 which isn't working. Call to helldesk: finds IPv4 configured, finds pings work, and struggles to understand why (eg) browsing has become slower and unreliable. Problem continues for some time before anyone notices IPv6 is now configured - the helldesk person isn't likely to ask the user to read that when it's an "IPv4 only" network. It's possible that the cause "never" gets noticed and the users just get used to the poorer performance - cue calls to the ISP complaining of packet loss since that's going to be one of the possible explanations that comes up.

b) Rogue IPv6 RA triggers shutdown of IPv4. Call to helldesk quickly results in finding no IPv4 configured - a hard fault that at least can be addressed as actually existing. As it's such a hard fault, the presence of IPv6 address(es) is more likely to be noticed, and the "fix" may be to turn off IPv6 on that device - not ideal but it would mitigate the attack.
Before long, the problem and solution is likely to start appearing in searches for "IPv4 not working, IPv6 present" type of searches. Don't forget that the time taken for the helldesk person to get some details from you is actually to allow them to do a few searches for the problem !

---

From: Sander Steffann <[email-masked]>
Date: Mon, 17 Sep 2018 13:10:09 +0200

Hi,

> Op 17 sep. 2018, om 08:50 heeft Nick Hilliard <[email-masked]> het volgende geschreven:
> 
> It’s the fact that ipv4 is unilaterally being blown away that’s the problem.  Not quite sure why you're saying that this is not a significant additional risk.  Really, it is.

+1
Sander

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2018 23:21:38 +1000

> significant additional risk.  Really, it is.

If IPv4 stops working because of a rogue RA with this flag switched
on, the host end-users will contact their network operator to
troubleshoot the issue. Their network operator will determine there is
a malignant device on the link sending rogue RAs and remove it.

The malignant device must be the only device on the link sending RAs
for hosts to obey the IPv6 Only flag in the rogue RA. If there are any
other legitimate emitter of RAs, with just one of their legitimate RAs
having this flag switched off, hosts will not switch off IPv4.

It is also possible that the malignant device may also be executing
other types of attacks, and therefore the integrity of the network has
been compromised. IPv4 ceasing to work in this situation, triggering
network operator investigation, is a useful security fail safe.

As all distinct RAs in the set received by hosts have to set this IPv6
Only flag for IPv4 to be switched off, IPv4 can easily be switched
back on on the effected hosts by sending another RA with the IPv6 only
flag switched off.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Sep 2018 16:06:45 +0200

> troubleshoot the issue. Their network operator will determine there
> is a malignant device on the link sending rogue RAs and remove it.

I don't like this draft at all. Conceptually I consider it wrong for one
protocol version to try to disable another. What's wrong with IPv4 on this 
network? Well there is the weird IPv6 packet that you never heard off. 
That's not a good way to design network protocols.

That said, the amount of damage that can be done by unfiltered RA packets
seems large enough to me, that the extra flag that disables IPv4 doesn't
seem to make the potential much worse.

Assuming a rogue device that sends RAs with an IPv6 default route that points
to itself and some DNS resolvers also pointing to the rogue device, then
it can insert itself in just about all traffic (or just sink it).

In my opinion the only sensible option to get this right is to have a trivial
DHCPv4 server that just tells hosts there is no IPv4 on this network. It is
possible that some kind of BCP is required to get host operating systems to
reduce IPv4 connection attempts in a context where they have global IPv6
addresses and no IPv4 address.

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Sep 2018 12:36:22 -0500

> addresses and no IPv4 address.

This solution is incompatible with the idea of layer2 filtering of
Ethertypes 800 and 806. Well maybe you could still filter Ethertype 8006,
but that seems weird. Further, I'm not aware of a DHCPv4 message that says
there is no IPv4. So, this also requires hosts to be updated to interpret
this new message.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Sep 2018 20:00:15 +0200

>there is no IPv4. So, this also requires hosts to be updated to interpret

RFC 2563 (DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients)

You can still filter 0x806. 

If this would be a L2 feature (just like IGMP snooping). Then you can also
filter all other 0x800 packets.

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Sep 2018 14:40:10 -0500

> filter all other 0x800 packets.

Ok, this is the first workable alternative I've heard brought up.

My understanding of most DHCPv4 servers or relay agents is the server or
router acting as DHCPv4 server or relay agent will need an address but it
is the only thing that needs an IPv4 address for that link. So, I think it
needs to be a unique /32. I say unique because if the server or router were
attached to multiple links each link would need a unique address just so
the server or router can keep its interfaces strait. I not aware of any IP
stacks that would not have issues with the same address on multiple links.

Anyone aware a DHCPv4 server that lets you respond with option 116 value 0
and nothing else? Any router based DHCPv4 servers?

I assume a router implementing a DHCPv4 relay would work with a DHCPv4
server that responds with option 116 value 0 and nothing else?

When clients get a DHCPv4 Offer with option 116 value 0 and nothing else,
do they keep sending DHCPv4 discoveries? Even if they do, as long as it's
not too frequent that is probably not an issue.

So think this solution looks something like;

1. Configure a unique /32 IPv4 on the router or server link interface.
2. Configure DHCPv4 server to respond with option 116 value 0 and nothing
else.
3. Configure Relay Agent on the router if DHCPv4 server isn't local or on
the router or link.
4. Filter ARP Ethertype 806 on client port or at AP
5. Permit DHCPv4 (UDP port 68), Deny all other IPv4 traffic on client port
or at AP.

This should work even for most legacy IPv4-only clients, anyone know what
clients support this? IPv4-only clients won't have any usable service but
they won't generate too much noise either. However, I think that no service
is the intended result for IPv4-only clients on IPv6-only links.

This could be a better solution than draft-ietf-6man-ipv6only-flag for the
WiFi use case that is the primary justification for it.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2018 08:45:28 +1200

On 2018-09-18 07:40, David Farmer wrote:
> 
> On Mon, Sep 17, 2018 at 1:00 PM, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
> 

Yes, but by definition out of scope for 6man. The basic idea here was
to update dual-stack nodes but leave the legacy nodes untouched. That
seems realistic. Unless RFC 2563 is widely supported in IPv4 stacks already,
I'm not sure it helps. Does anybody know about that?

It also requires the router to contain an IPv4 stack. In the long term,
that might not be what we want.

    Brian
 
> 
> My understanding of most DHCPv4 servers or relay agents is the server or router acting as DHCPv4 server or relay agent will need an address but it is the only thing that needs an IPv4 address for that link. So, I think it needs to be a unique /32. I say unique because if the server or router were attached to multiple links each link would need a unique address just so the server or router can keep its interfaces strait. I not aware of any IP stacks that would not have issues with the same address on multiple links. 
> 
> Anyone aware a DHCPv4 server that lets you respond with option 116 value 0 and nothing else? Any router based DHCPv4 servers? 
> 
> I assume a router implementing a DHCPv4 relay would work with a DHCPv4 server that responds with option 116 value 0 and nothing else?
> 
> When clients get a DHCPv4 Offer with option 116 value 0 and nothing else, do they keep sending DHCPv4 discoveries? Even if they do, as long as it's not too frequent that is probably not an issue.
> 
> 2. Configure DHCPv4 server to respond with option 116 value 0 and nothing else.
> 3. Configure Relay Agent on the router if DHCPv4 server isn't local or on the router or link.
> 5. Permit DHCPv4 (UDP port 68), Deny all other IPv4 traffic on client port or at AP.
> 
> This should work even for most legacy IPv4-only clients, anyone know what clients support this? IPv4-only clients won't have any usable service but they won't generate too much noise either. However, I think that no service is the intended result for IPv4-only clients on IPv6-only links.
> 
> This could be a better solution than draft-ietf-6man-ipv6only-flag for the WiFi use case that is the primary justification for it.
> 
> Thanks.
> 
> -- 
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2018 08:50:34 +1200

> regardless of any ipv4 spoofing protection mechanisms in the network 

Yes. And I'm saying: so what? The operator of this network needs to
police it against malicious or accidental IPv6. There's an Ethertype
for that.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2018 08:53:30 +1200

> back on on the effected hosts by sending another RA with the IPv6 only

Yes, but if the *only* IPv6 device on the network is the one sending
the IPv6-only flag maliciously, there's nobody to send that corrective RA.
But as I just said to Nick, such a network could choose to filter the
IPv6 Ethertype to be safe.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Sep 2018 00:25:27 +0300

Brian E Carpenter wrote on 17/09/2018 23:50:
> And I'm saying: so what?

It breaks existing protocols on existing network deployments, because of 
a design weakness in the protocol mechanism.  This is not good protocol 
development practice.

It's also unnecessary because there are other ways to do what you want 
to do.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Sep 2018 00:51:54 +0300

Mark Smith wrote on 17/09/2018 16:21:
> troubleshoot the issue.

This is not a responsible approach for the IETF to take towards network 
security.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2018 11:27:08 +1200

> It's also unnecessary because there are other ways to do what you want 

I still haven't seen a suggestion for how else an IPv6-only router
can signal "I don't do IPv4" to a dual-stack node.

> This is not a responsible approach for the IETF to take towards network 

I agree. But the same applies to any kind of rogue RA or any kind of
rogue router, or to any kind of DoS attack, so I don't find this
particularly relevant to the current proposal. Almost anything we
design can be misused.

If we were the v4ops WG, I'd support a proposal that on a network
intended to be IPv4-only, many Ethertypes, including 0x86DD, should
be filtered. For that matter, I'd support a v6ops draft saying
that on a network intended to be IPv6-only, 0x800 and 0x806 should
be filtered.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Sep 2018 15:17:11 +0300

> can signal "I don't do IPv4" to a dual-stack node.

yes, but is this really necessary?  I'm not convinced it is.  But I am 
convinced that the mechanism being proposed is deeply ill advised from 
an operational point of view and that it ignores basic design principals 
such as ensuring secure-by-default operation, fail-safe mechanisms and 
not breaking existing stuff.

 From an engineering point of view, the combination of "not compelling 
to start with" and "will cause serious operational problems if 
implemented" is something that raises red flags.  I don't see any way of 
fixing the proposal mechanism either :-(

Nick

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Sep 2018 15:11:39 +0200

Nick,

> yes, but is this really necessary?  I'm not convinced it is.  But I am convinced that the mechanism being proposed is deeply ill advised from an operational point of view and that it ignores basic design principals such as ensuring secure-by-default operation, fail-safe mechanisms and not breaking existing stuff.
> 
> From an engineering point of view, the combination of "not compelling to start with" and "will cause serious operational problems if implemented" is something that raises red flags.  I don't see any way of fixing the proposal mechanism either :-(

I have a hard time seeing how the mis-configuration potential / attack surface is any different than normal RA or DHCP.
Can we agree the security properties are the same?

The “principle" you are referring to, is that “not let one protocol configure another’?
I am not sure that’s a principle we have, although I’m quite sympathetic to it.

Cheers,
Ole

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 18 Sep 2018 10:43:31 -0500

> Can we agree the security properties are the same?

On an ipv4-only network today, if there is a rouge RA modern hosts 
typically can mitigate the impact through happy-eyeballs and life 
goes on for the user.

If there is a rouge RA with the flag set, happy-eyeballs can not
mitigate it because the host turned off the v4 stack.  

I believe that this flag as defined risks reverting the progress we 
have had in the end-user experience.  If I were an OS vendor I would 
not risk implementing this draft.

Dale

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Sep 2018 17:59:05 +0200

> typically can mitigate the impact through happy-eyeballs and life 

Hmm… not if the rogue RA is actually rogue, makes IPv6 appear to work and sits there modifying traffic.
I think this is something you want to detect, and quickly, rather than having the hosts mask it.

> not risk implementing this draft.

If you have a L2 shared link of untrusted devices, there is a million things that can be exploited.
ND, ARP, DHCP are all fundamentally insecure.

Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 18 Sep 2018 14:01:29 -0500

On Tue, Sep 18, 2018 at 10:43 AM, Dale W. Carder <[email-masked]> wrote:

> convinced that the mechanism being proposed is deeply ill advised from an
> operational point of view and that it ignores basic design principals such
> as ensuring secure-by-default operation, fail-safe mechanisms and not
> breaking existing stuff.
> > >
> to start with" and "will cause serious operational problems if implemented"
> is something that raises red flags.  I don't see any way of fixing the
> proposal mechanism either :-(
> >
> > I have a hard time seeing how the mis-configuration potential / attack
> surface is any different than normal RA or DHCP.

This is probably true for rogue by misconfiguration, which probably has
broken IPv6 and then happy eyeballs can do its thing. However, a malicious
rogue to be successful would have functional IPv6 and might not trigger
happy eyeballs to go back to IPv4.  However, it is still a valid point.

---

From: Simon Hobson <[email-masked]>
Date: Tue, 18 Sep 2018 20:20:50 +0100

Nick Hilliard <[email-masked]> wrote:

> ... and not breaking existing stuff.

If you think about it, the whole point of this flag is to "break stuff" - ie make IPv4 stop working !

> From an engineering point of view, the combination of "not compelling to start with" and "will cause serious operational problems if implemented" is something that raises red flags.  I don't see an…

TBH, I don't completely disagree with that - I'm not completely swayed by the arguments put forward in the flag's requirement.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 18 Sep 2018 12:33:01 -0700

> On Sep 18, 2018, at 8:59 AM, Ole Troan <[email-masked]> wrote:
> 

I agree.  As I think someone pointed out earlier, there are better ways to break IPv4 on the link that are harder to detect than using the ipv6only-flag.

I think it better to protect against misconfiguration, than bad actors on untrusted links who have unlimited ability to disrupt IPv4 and/or IPv6.

Bob

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Sep 2018 05:50:07 +1000

> This is not a responsible approach for the IETF to take towards network

Your sweeping statement emails that don't provide any explanation
aren't very much value to this discussion. You seem to believe that we
should just accept them,

They're appeals to authority. You're implying that only you know how
to operate and secure networks.

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Sep 2018 06:35:40 +1000

> It's also unnecessary because there are other ways to do what you want

Please explain.

How are you going to remotely tell dual stack hosts that IPv4 won't
work on this particular link, so they don't need to waste their and
the link's resources sending useless DHCPv4 requests? How is your
solution going to be more efficient than a single bit flag in packets
that are already required to be sent to the hosts in question?

It seems your only proposed solution is to layer 2 filter IPv4
packets. That doesn't solve all of the problems this flag is aiming to
solve. Host and link capacity resources are still being spent on
packets hosts send that will have no value.

Instructing the hosts to do nothing when IPv4 won't work is always
going to be more efficient than having them persistently send packets
that are universally dropped. Doing nothing is always more efficient
than persistently doing something that is then entirely ignored.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2018 08:32:00 +1200

> happy eyeballs to go back to IPv4.  However, it is still a valid point.

Absolutely it's valid and will definitely be added to the Security
Considerations.
 
>> not risk implementing this draft.

That's a matter of judgment and it depends on the host. If the host is
constrained by battery power considerations, the tradeoff might be very
different from a typical happy-eyeballs host. That's why all the
recommendations on host behavior in the draft are SHOULD. I wouldn't
really care if they were MAY instead - the host can decide.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Sep 2018 00:00:44 +0200

>packets hosts send that will have no value.

Long term filtering 0x800 and 0x806 together with a BCP that describes how
to do IPv4 in such an environment seems to me the best option.

There is a only a limited amount of unsolicited traffic that can be 
expected from an unconfigured IPv4 stack. Of course, current stacks are 
not tuned for operation in an IPv6-only environment, so they probably generate
way more traffic then needed.

Short term, there is a DHCPv4 option to shutdown IPv4. So no new protocol
action is required. 

This draft should only be introduced if it clear that filtering 0x800 cannot
work. Instead of handwaving that it probably won't work.

---

From: David Farmer <[email-masked]>
Date: Tue, 18 Sep 2018 18:53:59 -0500

On Mon, Sep 17, 2018 at 3:45 PM, Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> Yes, but by definition out of scope for 6man.

Yes, but why does the issue have to be solved in 6man anyway. And it might
not be out of scope for v6ops.

The basic idea here was
> seems realistic.

I'm sorry I don't agree, I don't want to update anything if that is
possible, especially on hosts. Further, I want something effective for dual
stack and legacy IPv4-only hosts if possible.

> Unless RFC 2563 is widely supported in IPv4 stacks already,

RFC2563 seems to be widely supported going back to Win98 and Win2K, I'm
still researching newer stacks, but;

>From RFC2563, section 2.2;

   Clients that have auto-configuration capabilities MUST add the Auto-
   Configure option to the list of options included in its initial
   DHCPDISCOVER message.

So if you support IPv4 link-local you are required to support this. But if
you don't support IPv4 link-local you won't configure an IPv4 link-local
address anyway and you won't create IPv4 link-local service discovery
background radiation on the IPv6-only network anyway.

> that might not be what we want.

Well, it doesn't have to be the router, there are a lot of switches that
can be a DHCP server or relay. It could be built into the wifi system or
APs. It could be done on a local server, heck it probably could be done on
a raspberry pi. A minimally configured router stack with DHCP relay is just
a convenient way to do it until you get around to turning off IPv4 on all
your routers. Even though I'm willing to do IPv6-only on some link
networks, I have to support IPv4 on my routers for a long time yet.

I need to do more research, but I think this is a more effective route, if
nothing else it shouldn't require any client changes. I can no longer
support draft-ietf-6man-ipv6only-flag at least until I run into a dead end
with RFC2563, which based on what I've seen so far I'm more optimistic
about RFC2563 than getting hosts updated to support
draft-ietf-6man-ipv6only-flag.

Futhermore, for the forssable future IPv6-only networks are mostly just a
stunt anyway, I'm not sure a new protocol feature is justified when even
the IETF won't go IPv6-only for its main WiFi network.

Sorry to change sides on you!

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2018 13:47:33 +1200

> way more traffic then needed.

I was looking for the final report on the trials at IETF100, and failed to find
it, but I don't know about "way more". However, there certainly was pointless
IPv4 traffic in measurable amounts (about 1.5%, against 98.5% of IPv6 traffic).
Almost all of it was multicast.

The IETF switches are presumably capable of Ethertype filtering, but afaik
that wasn't in use.
 
> Short term, there is a DHCPv4 option to shutdown IPv4. So no new protocol

If we want an IPv6-only router to be able to signal this fact, an IPv6
feature is required. And yes, I agree that this is a long-term requirement,
ready for the epoch when IPv6-only becomes a useful scenario.

> work. Instead of handwaving that it probably won't work.

No hand-waving involved. The draft is specific that Ethertype filtering will
work in many cases. But what it will not do is signal to dual stack hosts
that there is no IPv4 routing available, so they will still waste battery
and air time. That air time is taken from everybody, even if the packets
are discarded by the switch. Those are the target hosts for this proposal.

    Bfrian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2018 13:57:57 +1200

> not be out of scope for v6ops.

If we decide there needs to be a solution available to an IPv6-only router,
it becomes a protocol extension, i.e. 6man. The other aspects are indeed
suitable for v6ops.

> stack and legacy IPv4-only hosts if possible.

Well yes, if there is a solution that works with existing DHCPv4 servers
and legacy hosts, I'm all for it.

> networks, I have to support IPv4 on my routers for a long time yet.

Sure.
 
> the IETF won't go IPv6-only for its main WiFi network.

As I said in my immediately previous message, yes, this is clearly
a long-term play. I've been a strong defender of the dual stack model
since RFC
 
> Sorry to change sides on you!

Don't be, the idea is to find the best way forward.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Sep 2018 12:47:53 +0200

>Almost all of it was multicast.

So the first step should be to figure out if that amount can be reduced.

>ready for the epoch when IPv6-only becomes a useful scenario.

As far as I know there are no IPv4 options to signal the lack of IPX, DECnet,
AppleTalk, NetWare and what have you. And for good reasons.

For all practical purposes, IPv4 and IPv6 are completely separate protocols.
So it doesn't make a lot of sense to add features to IPv6 that try to control
IPv4. It is trivial for an IPv6 router to have a tiny DHCPv4 module that just
sends a canned response to an incoming DISCOVERY message.

>are discarded by the switch. Those are the target hosts for this proposal.

If a host sends one redundant packet per day, it is still wasting air time.
But I doubt anyone would go out to change specs and implementations to avoid
that one packet from being sent.

If we can reduce unnecessary IPv4 traffic to a small fraction of a percent
of total traffic, then there is no need to go beyond that.

By carefully defining how timers for DHCP and mDNS should back off that should
be easily reachable.

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Sep 2018 13:00:39 +0200

> AppleTalk, NetWare and what have you. And for good reasons.

Because they were largely manually configured?

> sends a canned response to an incoming DISCOVERY message.

So much for independence?
Neither do we have configuration protocols to disable IPX, DECnet or AppleTalk.

> that one packet from being sent.

Right, if hosts hadn’t come with mDNS, SSDP etc enabled by default I doubt we would have had to have this discussion.

> of total traffic, then there is no need to go beyond that.

Please write up a proposal for how that can be done.

> By carefully defining how timers for DHCP and mDNS should back off that should

mDNS (and a couple of other service discovery protocols) are incredibly chatty, with mostly useless information.
I guess it serves us as a community right, never managing to get service discovery successfully specified.
I can’t see an obvious way for an mDNS host to detect that it’s on an IPv6 only link. Apart from disabling it with configuration.
But I’m all ears.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Sep 2018 14:03:02 +0200

>Please write up a proposal for how that can be done.

I wonder what good it would do to write about IPv4 in 6man, but here it goes:

If host a has an interface with no IPv4 addresses other than IPv4 link local
addresses and the interface does have one or more global IPv6 addresses then
the host should rate limit IPv4 multicast packets from protocols such
as DHCP, mDNS, SSDP to at most 10% of the total outgoing multicast traffic.

> mDNS (and a couple of other service discovery protocols) are
> incredibly chatty, with mostly useless information.  I guess it
> serves us as a community right, never managing to get service
> discovery successfully specified.  I cant see an obvious way for
> an mDNS host to detect that its on an IPv6 only link. Apart from
> disabling it with configuration.  But Im all ears.

Looking at the problem at a slightly higher level.

Let's assume we have L2 switches that drop packets with ethernet type 0x800.
We can also assume that wired ethernet is not interesting. So the interesting
case is a battery powered host connected to a wifi ethernet.

As far as I know the only difference between a network has supports IPv4 and
one that doesn't is that the DHCP protocol fails to obtain an address.
It has no effect on mDNS, SSDP, etc.

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.

So the only thing that remains to be done is to make sure that DHCP backs 
off to a level that is on par or below the multicast rate of mDNS and SSDP.

>From a network point of view, a multicast message on wifi is sent
point-to-point from the host to the AP. We can assume that stacks already
limit the rate of unsolicited multicast messages to not overload the network.

The costly part of a multicast message on wifi is in delivering the message
to the wifi recipients. Now, if we filter 0x800 on the AP, then that step
doesn't happen. So the cost to the network of unsolicited IPv4 multicast 
packets is very low.

---

From: tom petch <[email-masked]>
Date: Wed, 19 Sep 2018 12:08:24 +0000

----- Original Message -----
From: "Ole Troan" <[email-masked]>
Sent: Wednesday, September 19, 2018 12:00 PM

> Neither do we have configuration protocols to disable IPX, DECnet or
AppleTalk.

Because we never needed it, we had a LAN that was so fast compared to
what we had previously that the capacity seemed infinite and could be
use with abandon (apart from the odd broadcast storm).

I see the use case for this as mobile, where bandwidth is limited and
battery life is paramount and IPv6 can be taken for granted, in which
case this flag is an excellent idea giving a clear benefit.  The only
counter argument would be if we lose some other dimension, such as the
ability to manage, to fault find, to enforce an SLA ... or security.

For me, the benefits outweigh any disadvantage that has been described
here, given the existing loopholes in the IPv6 configuration protocols
that could be found by a misconfigured or rogue device, ones that have
been mentioned several times already.

Tom Petch

> Right, if hosts hadn’t come with mDNS, SSDP etc enabled by default I
doubt we would have had to have this discussion.
> mDNS (and a couple of other service discovery protocols) are
incredibly chatty, with mostly useless information.
> I guess it serves us as a community right, never managing to get
service discovery successfully specified.
> I can’t see an obvious way for an mDNS host to detect that it’s on an
IPv6 only link. Apart from disabling it with configuration.

---

From: Wilco Baan Hofman <[email-masked]>
Date: Wed, 19 Sep 2018 14:37:09 +0200

> as DHCP, mDNS, SSDP to at most 10% of the total outgoing multicast traffic.

Even having IPv4 link-local is harmful, because of ARPing for
0.0.0.0/0..  Disabling IPv4 LL would help tons. So if no real IPv4
address is configured, do not ARP, do not mDNS, do not SSDP. Maybe do
DHCP, but keep it down?

-- Wilco

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Sep 2018 15:05:41 +0200

>address is configured, do not ARP, do not mDNS, do not SSDP. Maybe do

Historically, IPv4 implementations are sloppy with what they consider onlink.
In my opinion, a host should not consider 0.0.0.0/0 onlink without explicit
configuration. 

IPv4 LL is useful in the case that you don't have a local router. I can
easily see that in the future people may have an IPv6-only connection to the
internet but still have an IPv4-only printer or other device they may
want to use.

In that case, IPv4 LL with mDNS/SSDP could come in handy. As long as the
rate of mDNS/SSDP traffic is low enough, it would not hurt to keep it on.

And if you want to disable IPv4 LL, there is a DHCP option for that.

---

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

> 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

---

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: Nick Hilliard <[email-masked]>
Date: Wed, 19 Sep 2018 21:19:07 +0100

Ole Troan wrote on 18/09/2018 14:11:
> I have a hard time seeing how the mis-configuration potential /
> attack surface is any different than normal RA or DHCP.

They're similar, but not the same. The difference relates to the fact
that previously if you wanted to protect your network against ipv4 
attacks, you needed to configure only ipv4 mitigation mechanisms.  With 
this draft, if you want to protect your ipv4 network, you need to 
configure ipv4 + ipv6 mitigation mechanisms. I.e. a new attack surface 
has been opened.

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Sep 2018 15:43:54 -0500

On Wed, Sep 19, 2018 at 3:19 PM, Nick Hilliard <[email-masked]> wrote:

> this draft, if you want to protect your ipv4 network, you need to configure
> ipv4 + ipv6 mitigation mechanisms. I.e. a new attack surface has been
> opened.
>

If you are nieve enough to believe that an IPv4-only network doesn't need
IPv6 protections too, then ok.  But if an IPv4-only network doesn't also
have IPv6 protections, It will still be impacted or compromised by rogue
RAs just the same as if it doesn't have IPv4 protections. All network need
both basic IPv4 and IPv6 protections.

I buy the argument that philosophically it is a bad idea to intermix the
controls of IPv4 and IPv6, but you continue to overblow the security issue.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Sep 2018 23:00:03 +0200

Hi,

> I buy the argument that philosophically it is a bad idea to intermix the controls of IPv4 and IPv6, but you continue to overblow the security issue.

He is really not… This flag is a horrible idea.
Sander

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Sep 2018 07:28:40 +1000

> Because they were largely manually configured?

That's correct. IPv4 replaced IPX and Appletalk once IPv4 was commonly
deployed (because people wanted email and Internet access), and Novell
and Apple then provided the option to run their file-and-print and
related protocols over UDP and TCP. Once it was possible to run
everything over IPv4, IPX and Appletalk were slowly migrated away
from. During that transition period, IPX link-layer broadcasts and
Appletalk link-layer multicasts were still present on the link, even
though they weren't necessary or useful.

My position on why this is needed is not because of any experience
with large Wifi and IPv4/IPv6, but my experience with multi-protocol
LANs using those protocols in the 1990s.

> Neither do we have configuration protocols to disable IPX, DECnet or AppleTalk.

An IPv4 out-of-band protocol is being used to switch off IPv4.

That out-of-band protocol could have been a number of things, it
happens to be IPv6 because dual stack hosts will always talk it, and
it is the protocol replacing IPv4.

Using the current version of something to ease transition from the
previous version of something is common (e.g., major new software
version updates the data format or configuration used by the former
version). Using IPv6 as an out-of-band protocol to disable IPv4 on a
dual stack host is fine.

> I can’t see an obvious way for an mDNS host to detect that it’s on an IPv6 only link. Apart from disabling it with configuration.

At a minimum, IPv4 hosts have to be prevented from getting or
generating IPv4 addresses to use to send upper layer traffic( e.g.
mDNS). Even better is to suppress the IPv4 hosts attempting to acquire
addresses via link-layer broadcast DHCPv4 DISCOVERY.

A host that will never succeed in sending an IPv4 packet to another
node on a link should never waste resources even attempting to send
one. Packets and frames are cheap and will always be getting cheaper
to send. However, no matter how cheap they get to send, they'll never
be as cheap as not sending one.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Sep 2018 23:37:43 +0200

Hi, 

> be as cheap as not sending one.

A single DISCOVER is still cheaper than adding complexity by adding flags in one protocol to signal that another protocol should be disabled. IPv4 and IPv6 have co-existed on many networks for years, and one of the huge advantages was that problems in one protocol wouldn’t affect the other one. Sure, a dual-stack application using the broken one would suffer (which led to happy eyeballs) but the protocol itself would keep running just fine. This flag breaks that “don’t hurt other protocols on the same wire”. Suddenly having to start debugging IPv6 when IPv4 fails will be a nightmare for operators. 

Please stop this madness.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Sep 2018 07:38:15 +1000

On Thu, 20 Sep 2018 at 06:44, David Farmer <[email-masked]> wrote:
>> that previously if you wanted to protect your network against ipv4 attacks, you needed to configure only ipv4 mitigation mechanisms.  With this draft, if you want to protect your ipv4 network, you need to configure ipv4 + ipv6 mitigation mechanisms. I.e. a new attack surface has been opened.
>
>
> If you are nieve enough to believe that an IPv4-only network doesn't need IPv6 protections too, then ok.  But if an IPv4-only network doesn't also have IPv6 protections, It will still be impacted or compromised by rogue RAs just the same as if it doesn't have IPv4 protections. All network need both basic IPv4 and IPv6 protections.
>

If Nick and others really cared about the rogue packet risk like they
say they do, there'd be no risk to this flag for them, because their
single hosts would be individually isolated at layer 2.

In that scenario, the only risk of a rogue RA would only be from the
individual host to itself (an own goal) or the router or routers it
uses to reach literally every other host they communicate with. If the
routers are a threat of sending rogue RAs, you've got bigger problems,
because your router is pwned.

Regards,
Mark.

---

From: James R Cutler <[email-masked]>
Date: Wed, 19 Sep 2018 18:10:46 -0400

James R. Cutler
[email-masked]
PGP keys at http://pgp.mit.edu

> On Sep 19, 2018, at 5:37 PM, Sander Steffann <[email-masked]> wrote:
> 
> ... IPv4 and IPv6 have co-existed on many networks for years, and one of the huge advantages was that problems in one protocol wouldn’t affect the other one. Sure, a dual-stack application using the broken one would suffer (which led to happy eyeballs) but the protocol itself would keep running just fine. This flag breaks that “don’t hurt other protocols on the same wire”. Suddenly having to start debugging IPv6 when IPv4 fails will be a nightmare for operators. 
> 

+1 * 2^128 

I am a veteran of “ships in the night” multiprotocol networking, including DECNet, AppleTalk, IPX/SPX, and TCP/IP on a large multi-company network.  My experience leads to say that Sander Steffann correctly has the core argument for letting Layer 3 Protocols continue to be independent.
========

Further exposition:  A host on an IPv6-only network which has only a manually configured IPv4 address will receive no help from the proposed flag — and may not see it due to lack of an IPv6 configuration; while a host on an IPv6-only network attempting to autoconfigure using DHCP will receive no IPv4 address. The proposed flag would enable yet another DDOS vector.

Conclusion: There is no demonstrated need or benefit for the proposed flag.

James R. Cutler
[email-masked]
PGP keys at http://pgp.mit.edu

---

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: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2018 11:09:09 +1200

On 2018-09-20 10:10, James R Cutler wrote:
> I am a veteran of “ships in the night” multiprotocol networking, including DECNet, AppleTalk, IPX/SPX, and TCP/IP on a large multi-company network.  

FWIW, so am I. I wish we'd had Wireshark in those days.

> My experience leads to say that Sander Steffann correctly has the core argument for letting Layer 3 Protocols continue to be independent.

The only case of the "nightmare" that Sander mentions is when all the IPv6
routers on what is intended to be a dual stack network simultaneously start
sending the IPv6-only flag. Adding rogue senders is harmless by design.
The operational IPv6 routers would all have to be successfully attacked,
or misconfigured, simultaneously.

> Further exposition:  A host on an IPv6-only network which has only a manually configured IPv4 address will receive no help from the proposed flag — and may not see it due to lack of an IPv6 configu…

Sorry, I don't see a DDOS vector. I do see a minor increase in the risk from
rogue RAs.
 
> Conclusion: There is no demonstrated need or benefit for the proposed flag.

The draft describes the problems and benefits.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Sep 2018 21:06:14 -0300

> police it against malicious or accidental IPv6. There's an Ethertype

I agree to some extent, but this is a different thing. This is the first
mechanism I know of that binds the two protocols together, and allows
one protocol to have an explicit effect over the other.

-- 
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: Wed, 19 Sep 2018 21:12:12 -0300

> that on a network intended to be IPv6-only, 0x800 and 0x806 should

FWIW, been there, done that, and dodged the bullets: RFC7123.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Sep 2018 21:16:48 -0300

> I have a hard time seeing how the mis-configuration potential / attack surface is any different than normal RA or DHCP.

This creates a new attack vector to DoS an IPv4 network. In fact I'm not
sure you could perform the same complete-IPv4-DoS with any other
mechanism, at such low cost.

FWIW, not an argument against the proposal, but rather a response to
your comment.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2018 15:46:55 +1200

> FWIW, been there, done that, and dodged the bullets: RFC7123.

Ah, thanks. We can mention that in the Security Considerations.

This RFC shows that there are lots of ways that IPv6 can impact
IPv4. We would add one more, but it needs to be assessed in the
context of all the other impacts.

Please feel free to start work on "Security Implications of IPv4 on
IPv6 Networks" :-).

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 10:19:32 +0200

Le 19/09/2018 à 23:28, Mark Smith a écrit :
> from.

But, at that time, there was no such agreed expandable RA that takes on 
L2 (and others) functionalities like it is now.

Back then, ethertypes were sufficient to distinguish between these IPv4, 
IPX and AppleTalk.

Second, on links w/o Ethertypes (e.g. some cellular) RA could help make 
the distinction.

Alex

  During that transition period, IPX link-layer broadcasts and

---

From: Simon Hobson <[email-masked]>
Date: Thu, 20 Sep 2018 10:25:47 +0100

> FWIW, so am I. I wish we'd had Wireshark in those days.

Tes, one of those tools that once used, leave you wondering why it took so long. AppleTalk was my first networking protocol, with a passing acquaintance with IPX.

> or misconfigured, simultaneously.

That's true on a dual protocol network - if you have one genuine IPv6 router then the flag is "safe". But on networks with no IPv6 configured (which is a lot), just one rogue device can kill IPv4 on devices that support the flag.
As pointed out, it provides a very easy DoS vector - but IMO not really much harder than many others that are already in the wild.

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Sep 2018 09:09:12 -0500

> controls of IPv4 and IPv6, but you continue to overblow the security issue.

I've been thinking about this a bit more, the only scenario I can come up
with where a rogue IPv6 RA will not disrupt or compromise an IPv4-only
network is when all hosts on the network either have their IPv6 stacks
administratively disabled or the hosts don't have an IPv6 stack at all.
However, any host on an IPv4-only network that has its IPv6 stack enabled
is susceptible to disruption by rogue IPv6 RAs.

Therefore, it might be obvious, but this flag MUST NOT be evaluated if the
IPv6 stack is administratively disabled.

In my opinion, with this caveat, the security danger posed by this flag is
the same as any rogue IPv6 RA, even to IPv4-only networks.

Thanks

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2018 10:14:11 -0400

Simon Hobson <[email-masked]> wrote:
    >> The only case of the "nightmare" that Sander mentions is when all the
    >> IPv6 routers on what is intended to be a dual stack network
    >> simultaneously start sending the IPv6-only flag. Adding rogue senders
    >> is harmless by design.  The operational IPv6 routers would all have to
    >> be successfully attacked, or misconfigured, simultaneously.

    > That's true on a dual protocol network - if you have one genuine IPv6
    > router then the flag is "safe". But on networks with no IPv6 configured
    > (which is a lot), just one rogue device can kill IPv4 on devices that
    > support the flag.  As pointed out, it provides a very easy DoS vector -
    > but IMO not really much harder than many others that are already in the
    > wild.

Does it help if dual-stack hosts are told to do a connectivity check on the
IPv6 before disabling IPv4?
(And it doesn't affect single-stack hosts of either type at all)

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Sep 2018 22:36:14 +0100

> IPv6 before disabling IPv4?

Sadly not.  "Connectivity" is a very subjective concept.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Sep 2018 14:10:22 +1200

> Sadly not.  "Connectivity" is a very subjective concept.

True. But a rule of thumb in the real world is "if whatever
I've been given as a DNS resolver returns some addresses, I can
try any of those addresses and expect connectivity". What a host
should do if it gets back only A records but has no IPv4 address
is an interesting question. In any case, a network which provides
no DHCPv4 but provides A records via DNS/IPv6 is misconfigured or
under attack. That's orthogonal to the IPv6-only flag.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Sep 2018 11:35:24 +0200

>What a host

I don't understand this statement.

1) If I have a real IPv6-only network (i.e. no IPv4 connectivity at all) then
some DNS requests may return A records. This is beyond the control of the
network. As far as I know, there is no requirement that a network should 
filter A records nor is it necessary for such a network to function.

2) If I have a 464XLAT implementation, then the IPv4 part may be on a tunnel
interface. In this case the 'real' interface does't get an IPv4 address from
DHCP (and the node should avoid trying to use IPv4 on that interface), but
the node as a whole still has IPv4 connectivity, therefor A records are to
be expected.

---

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

Brian E Carpenter <[email-masked]> wrote:

> What a host should do if it gets back only A records but has no IPv4 address is an interesting question.

Well it's much the same question as to what a host should do if it gets back only AAAA records but doesn't have IPv6 connectivity - it has to fail the connection attempt.

> In any case, a network which provides no DHCPv4 but provides A records via DNS/IPv6 is misconfigured or under attack.

NO
As Philip has already pointed out, it's not the job of the network to filter DNS responses - *THAT* would be broken.
In addition to those 2 possibilities Philip has mentioned, I can see a couple more :

1) The device itself has an IPv4 tunnel - perhaps it has a VPN running.

2) The device isn't actually going to connect, but is looking up information. While a TXT record would be more normal, there are lookups where the information required is only "does this FQDN resolve to an IP address (A record)" and the question may still be valid on an IPv6 only network.

Trying to filter the DNS based on what you *THINK* the clients actually require is a recipe for frustration !

---

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Sep 2018 10:10:48 +1200

> filter A records nor is it necessary for such a network to function.

I'm sorry; I forgot state an assumption: that such a network, to be any
use, supports NAT64/DNS64.
> the node as a whole still has IPv4 connectivity, therefor A records are to

Sure. Obviously, the whole argument changes if there is any mechanism
in place that presents dual stack support to the host above the socket
API. I understood that we were talking about IPv6-only links.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Sep 2018 10:20:47 +1200

> 1) The device itself has an IPv4 tunnel - perhaps it has a VPN running.

If the link provides NAT64/DNS64, that's going to need a different DNS server
and resolver anyway. If the link doesn't support NAT64/DNS64, yes. (But what
a weird setup that would be.)

> Trying to filter the DNS based on what you *THINK* the clients actually require is a recipe for frustration !

That's exactly what DNS64 does, though.

Look, I hate NAT and all its doings, including NAT64/DNS64. But I don't
see how an IPv6-only LAN connected to the Internet is going to be
useful in the next 10 or 20 years without NAT64/DNS64, or some solution
such as 464XLAT that simulates a good old dual stack as far as the hosts
are concerned.

   Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 22 Sep 2018 20:02:29 +0200

> On Sep 19, 2018, at 2:08 PM, tom petch <[email-masked]> wrote:
> 
> From: "Ole Troan" <[email-masked] <mailto:[email-masked]>>
…

> use with abandon (apart from the odd broadcast storm).

Nah, appletalk was bridged and routes quite widely, broadcast domains got so large and noisy that the end-stations couldn’t handle it. It became unusable in many campus scale networks around 1994/5.

Multiprotol routers stopped being able to support it. We filtered even in large l2 cores and users moved on to to using IP and dns for resource sharing / discovery.

> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>