Subject: Tussles in IPv6 Land

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 13:33:17 +1200

Hi,

I wrote the text below a couple of months ago, but then got distracted.
However, I do think it's important that as we argue about (for example)
/64, to remember what's going on behind the apparent argument.

Regards
   Brian

Tussles in IPv6 Land

Today (April 2017) we seem to have three very active tussles in the IPv6 technical
community.

1. Is header insertion on the fly OK, or is it the work of the devil?

2. Is the fixed interface identifier length of 64 bits OK, or is it the work of the devil?

3. Which is the work of the devil: getting the DNS server address via Router Advertisments,
or getting the DNS server address via DHCPv6?

Each of these issues has generated several hundred emails recently. Clearly, they matter
to some part of the community. Why? And why now? None of them are exactly new.

Why they matter *now* seems clear. IPv6 is on the march. Although there are still IPv6
'deniers' it's become a bit like climate change denial: the temperature is up, the waters 
are rising. More and more operators are being forced to consider IPv6 not as a remote
possibility, but as a requirement that will directly impact how they operate and how
much it costs to operate successfully.

To a significant extent the above three issues are tussles between operational needs
and conceptual purity. To be specific:

1. Large data centres need to achieve throughput and parallelism. To do that they
need to chain services together across very large numbers of nodes. The large
address space of IPv6 is potentially very valuable for that, if it can be brought
to bear: and an attractive way of doing so is segment routing. An attractive way
of doing segment routing is using an IPv6 routing header. An attractive way of doing
that within the data centre is by having the first-hop router insert the IPv6
routing header, so that the application servers don't need to know about it. So
data centre operators like this idea. So router vendors like this idea too. Unfortunately,
many people involved in the IPv6 design think it's a terrible idea (and a misreading
of the IPv6 standard). That's because inserting stuff (any stuff, not just this header)
in a packet changes its length and thereby breaks all known methods of determining
the maximum packet size allowed on a given path across the Internet.

So, header insertion is the work of the devil across the Internet and also the goose
that might lay the golden egg inside a data centre.

2. The interface identifier length was fixed at 64 bits about 20 years ago. It
was not an arbitrary choice then - it was designed to match the hardware address
size of FireWire, then expected to be the network of the future. (It actually
turned out that the network of the past, Ethernet, became the network of the
future. But if we'd fixed on 48 bits for that reason, we'd be having the same
tussle about 80+48 that we're having today about 64+64.) Network operators have
two complaints about the boundary at 64 bits. Firstly, although in theory it could
be different for different media (for example, 64 for FireWire and 48 for Ethernet)
in practice it's been set at 64 for everything. Secondly, bitter experience with
IPv4 25 years ago taught everybody (we thought) that routing should always be
"classless" with no rigid rules about the length of routing prefixes. But the de
facto rule in IPv6 is that leaf subnet prefixes MUST be 64 bits long. ISP operators
would like that 64-bit boundary to float. Unfortunately, many people involved
in the IPv6 design think it's a terrible idea (and a change to the IPv6 standard).
There are several reasons for that - though the main one seems to be that having
a 64 bit boundary everywhere makes portability (of code, and of computers) easier.
Also, much software blindly assumes the 64 bit rule. But this has its own downside:
suppose an ISP follows bad practice and gives a retail subscriber exactly one
64 bit prefix. If the subscriber needs to operate more than one subnet in their
home or office, they simply can't do so unless the 64 bit rule is relaxed. That
wastes considerable potential for IPv6 deployment. But - again, but - if the
64 bit rule was made flexible, perhaps some ISPs would decide to go further -
say give a retail subscriber exactly one 80 bit prefix. This could generate
a race to the bottom, where the really cheap and nasty ISPs give a subscriber,
say, exactly one 120 bit prefix, wasting even more of IPv6's potential. On this
argument, sticking to the 64 bit rule seems safest.

So, the 64 bit boundary is the well-understood solution that works everywhere,
or the spawn of the devil that blocks future flexibility for both routing
and address space conservation.

3. An IPv6 host can get its DNS server's IPv6 address in two ways (let's
call them Alpha and Omega). Therefore, a router can supply a DNS server's
IPv6 address in two ways (also Alpha and Omega of course). So some host
operating systems support Alpha or Omega alone; some routers support
both, but others support either Alpha or Omega alone. So it is entirely
possible for a host that only supports Alpha to roam to a network that
only supports Omega (or vice versa), in which case the host can't get
DNS service over IPv6 at all. Believe it or not, the fallback is then
DNS service over IPv4, even to retrieve IPv6 addresses.

Alpha is the work of the devil if you (a network operator) prefer to
assign host addresses using Omega. And vice versa. However, some operators
are pragmatic enough to support both Alpha and Omega in their routers,
regardless of whether they prefer Alpha or Omega for assigning addresses
to hosts.

So this is an interesting tussle, because operators don't agree among themselves
about the best approach; neither do router vendors; neither do host operating
system developers.

Feel free to assign the values "RA/RDNSS" and "Stateless DHCPv6" to Alpha and
Omega either way round. It makes equal sense.

--

---

From: Richard Hartmann <[email-masked]>
Date: Sat, 10 Jun 2017 03:52:59 +0200

Thank you for this write-up.

I lost hope that any of these discussions will be resolved, or compromised
on, at any point in the near to medium future, but if nothing else, this is
a good place to point people to when they ask why we can't have nice things.

Richard

---

From: [email-masked]
Date: Sat, 10 Jun 2017 16:01:13 +0200

Brian,

[...]

> and conceptual purity. To be specific:

By this labelling of the players in the tussle, you leave no doubt on which side of the tussle you have taken. I don't know if that was intended.

It is of course not as simple as a conflict between operational need and "ivory tower idealists".
You want to ensure end-users get enough address space, you want that operators can aggregate routing well, allow for innovation like identifier, locator split... Content providers, applications writers, lots of players have a stake in this.

But it essentially boils down to the matter of control, power and money.

> and address space conservation.

"ISP operators would like the 64-bit boundary to float". Is that a true statement?
The draft we are discussing is clarifying that it within the architecture to manually configure addresses with arbitrary length of the onlink prefix. Some people definitely want the 64 bit boundary to float. I'm unsure what the arguments are for that. And what problems it solves.

Now we do have real problems.
- "Permission-less extension of the network. Where I want to extend a network I do not control, where I connect to a network with /64 SLAAC, or /64 to the host. The "natural" inclination then is to subnet the /64. But this problem has many other solutions too. Unfortunately we haven't made any of them stick. Perhaps we should restart the work on MLSR.
- The assumption that on a multi-access link a host can use as many addresses as it likes. Every address a host grabs has a real cost for the network. TCAM space is limited. It's understandable that network operators (and vendors) get cautious how this will play out. Perhaps ARO would have been a better trade-off between the interests of operators and hosts.
- Multi-prefix multi-homing. The idea that the host by choosing source address controls the exit circuit in a network doesn't sit well with most operators. Neither is it possible to make it work without essentially a session layer...

Ole

---

From: [email-masked]
Date: Sat, 10 Jun 2017 16:02:32 +0200

> I lost hope that any of these discussions will be resolved, or compromised on, at any point in the near to medium future, but if nothing else, this is a good place to point people to when they ask why we can't have nice things.

It might be that the impasse is the best outcome there can be.
Enumerate "nice things"?

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 17:29:47 +1200

> By this labelling of the players in the tussle, you leave no doubt on which side of the tussle you have taken. I don't know if that was intended.

No. I might even be on different sides for different tussles. But yes, the
language is editorial, not objective. And I don't claim it's a complete
or correct analysis. Sorry, no time today to write more.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Jun 2017 08:41:08 +0000

> On 11 Jun 2017, at 06:29, Brian E Carpenter <[email-masked]> wrote:
> 

While there’s one or two points/claims that could be debated improved, your email comes across overall as a nice neutral write-up of the tussles. 

I’d suggest (3) is a sub-case of “operate through DHCPv6 only”, including the lack of a DHCPv6 default gateway option, though that’s perhaps not so much a current hot topic but one that’s been bubbling under for many years. Or at least the RFC8106 vs stateless DHCP debate is polarised and perhaps jammed because of that underlying tussle.

I’d also say that case (3) is made more critical in an IPv6-only environment, where you can’t fall back on IPv4 (DHCPv4) to get configuration information.

Tim

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 12 Jun 2017 20:05:06 +0900

> and conceptual purity. To be specific:

By this labelling of the players in the tussle, you leave no doubt on which
side of the tussle you have taken. I don't know if that was intended.

Ole is right. To me it is especially telling that this description of the
tussle did not even mention functionality at all.

Brian, please don't forget that networks are built to serve customers, not
operators. Those customers are using hosts that are connected to the edge
of the network. The /64 boundary has nothing to do with purity and
everything to do with functionality. It is a way to ensure that networks
will always have enough space for the edges of the network to use IPv6
addresses in new and innovative ways.

/64 subnets are - I'd argue, deliberately - large enough to ensure that any
number of schemes can be developed to use them in the future. Any
limitation to subnet size, even to something that looks absurdly huge
compared to IPv4, such as 32 bits, will remove that ability. Today's
operational needs would have to be very pressing indeed for it to make
sense for us to give up that future ability.

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 12 Jun 2017 14:44:38 +0200

> tussle did not even mention functionality at all.

The problem statement is still valid.

Also, it _does_ make sense to take motivations and sentiments into
account. We can argue about technical merit all day long; if we're not
somewhat aware of the intrinsic motivations of all/most involved, we
might be arguing past each other for years. Blocking DHCPv6 (in part)
to protect the /64 boundary as SLAAC can't do anything else is
logically consistent, but if it's not stated publicly, becomes harder
to engage on the technical level.

Finally, sometimes, there is just no middle ground for consensus,
leading to a stand-off.

> operators. Those customers are using hosts that are connected to the edge of
> the network. The /64 boundary has nothing to do with purity and everything
> to do with functionality. It is a way to ensure that networks will always
> have enough space for the edges of the network to use IPv6 addresses in new
> and innovative ways.
>
> number of schemes can be developed to use them in the future. Any limitation
> to subnet size, even to something that looks absurdly huge compared to IPv4,
> such as 32 bits, will remove that ability. Today's operational needs would
> have to be very pressing indeed for it to make sense for us to give up that
> future ability.

This is a cyclic point as we're merely moving the "edge" around. It's
not unlikely to assume that a user will have have a /64 on their
device but need to subnet so their health data is not accessible from
their social life live stream or a music player. Now they have space
large enough to ensure that any number of schemes can be developed,
but can not develop any such schemes as their hosts rely on, or even
mandate, a fixed boundary of /64.

And yes, the logical conclusion is a race to the bottom of sorts,
arriving at a /128 in the end. But this is already possible with a
/64: Simply disallow traffic from more than one IP per
user/device/whatever and they have a /128 for all intents and
purposes. This works with SLAAC as well as DHCPv6 so nothing is, in
theory, stopping operators from doing this today.

All cases above lead to NAT if you push them to the max. This, in turn
means that even if we only have NAT on a small-but-substantial part of
end user devices, everything else would need to adapt to this. While
it's possible to hold end users systems and thus their users hostage
by disallowing technologies, the users would become pawns in a proxy
war.

But if this could work today and it's not implemented this way, I
would argue that /64 and SLAAC are not the only things which stand in
between nice things and NAT; there seem to be other considerations in
play which work towards good functionality and they are not all
purity.

But again, sometimes, there is just no middle ground for consensus,
leading to a stand-off.

Richard

---

From: Tom Herbert <[email-masked]>
Date: Mon, 12 Jun 2017 08:20:56 -0700

> have enough space for the edges of the network to use IPv6 addresses in new
Lorenzo,

ILA is an innovative way to use IPv6 addresses, but as I described it
can't use this in a mobile network if every UE gets a /64. In this
case too much space is given the end host which probably a low end
device like a smart phone that really doesn't need it.

> have to be very pressing indeed for it to make sense for us to give up that
But that begs the question, why is /64 the one size fits all answer?
What if in the future that number proves to be the wrong choices?
Flexibility seems like a better way to future proof this.

Tom

---

From: "Raymond Burkholder" <[email-masked]>
Date: Mon, 12 Jun 2017 12:31:13 -0300

> ILA is an innovative way to use IPv6 addresses, but as I described it
can't use
> this in a mobile network if every UE gets a /64. In this case too much
space is
> given the end host which probably a low end device like a smart phone that
> really doesn't need it.

Out of curiosity, when a smartphone is used in tethered mode, ie, devices
are hanging off it via the built in hot-spot, do the devices get an address
out of the smartphone /64, or should the phone have a /60 or maybe /56 to
handoff to those devices?  Say, as LTE gets more predominant, powerful, and
bandwidth capable, maybe with rural/farming areas getting into more IoT
stuff, maybe have a router hanging off that tethered hotspot?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: John Leslie <[email-masked]>
Date: Mon, 12 Jun 2017 11:55:53 -0400

Lorenzo Colitti <[email-masked]> wrote:
> 
> Brian, please don't forget that networks are built to serve customers,
> not operators.

   I choose not to argue about the design.

   But please understand that networks MUST be managed by operators.

   It is inevitable that operators will modify the design to suit their
needs (as they perceive them).

   If you wish to change the behavior of operators, this is the wrong
list to reach them.

--
John Leslie <[email-masked]>

---

From: Lee Howard <[email-masked]>
Date: Mon, 12 Jun 2017 13:22:55 -0400

From:  ipv6 <[email-masked]> on behalf of Lorenzo Colitti
<[email-masked]>
Date:  Monday, June 12, 2017 at 7:05 AM
To:  Ole Troan <[email-masked]>
Cc:  IETF IPv6 Mailing List <[email-masked]>
Subject:  Re: Tussles in IPv6 Land

> operators. 

What networks?

Enterprise operators build networks to do business.
Mobile network operators build networks to serve people using mobile
devices.
Residential access providers build networks to serve people at home.
Community network operators build networks to serve the community.
Universities build networks to enable students and faculty to do research,
and also to attract students to the university.
Content delivery network operators build networks to serve companies.
Transit network operators build networks to transit and connect other
networks.

As Brian points out, these operators may have different needs.

Lee

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Jun 2017 10:47:02 -0700

On Jun 12, 2017, at 10:22, Lee Howard <[email-masked]> wrote:
>> 
>> Brian, please don't forget that networks are built to serve customers, not operators.
> 
> 
> What networks?
> 
> Mobile network operators build networks to serve people using mobile devices.
> Universities build networks to enable students and faculty to do research, and also to attract students to the university.
> Transit network operators build networks to transit and connect other networks.

Home networks are designed using ad-hoc methodologies by people without any understanding or skill in network operations.

> As Brian points out, these operators may have different needs.

For one very crucial category of network, calling the people who build them “operators” is an abuse of the technical language.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Jun 2017 13:14:27 -0500

On Mon, Jun 12, 2017 at 10:20 AM, Tom Herbert <[email-masked]> wrote:

> not
Tom, please don't forget that UE in 3GPP network (not even in 5G) can act
as delegating router and delegate prefixes, check RFC 6459. Cameron
describes a place where this is used in practice in RFC 7278.

So do not underestimate UE :)

Behcet

> limitation

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 12 Jun 2017 18:50:09 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya

> Tom, please don't forget that UE in 3GPP network (not even in 5G)
> can act as delegating router and delegate prefixes, check RFC 6459.
> Cameron describes a place where this is used in practice in RFC 7278.

But this involves the ISP, when the ISP need not be involved. A smartphone that has been assigned a /64 would have to either use IPv4, or beg the ISP for more prefixes (with consequences to IPv6 message routing), if it wants to become a WiFI hotpot.

Why should it be easier, for a user, to create WiFi hotspots in IPv4 than it is in IPv6?

Bert

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Jun 2017 14:17:57 -0500

On Mon, Jun 12, 2017 at 1:50 PM, Manfredi, Albert E <
[email-masked]> wrote:

> But this involves the ISP, when the ISP need not be involved. A smartphone
> that has been assigned a /64 would have to either use IPv4, or beg the ISP
> for more prefixes (with consequences to IPv6 message routing), if it wants
> to become a WiFI hotpot.
>
In my mail, I said, 3GPP network which regulates smart phone's LTE
interface, not an ISP network. I guess you are talking about Wi-Fi
interface.

Regards,

Behcet

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jun 2017 13:13:17 -0700

> On Jun 12, 2017, at 10:47 AM, james woodyatt <[email-masked]> wrote:
> 

You might benefit from reading https://medium.com/@SeanBlanda/the-other-side-is-not-dumb-2670c1294063. I would actually recommend it to each of us.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 09:08:37 +1200

> For one very crucial category of network, calling the people who build them “operators” is an abuse of the technical language.

True. In SOHO networks we need everything to happen under the covers, and the users
will not have the slightest interest in subnet sizes or interface identifier lengths.
As far as I can tell, HNCP only treats /64 as a default, so it's already set up
for future flexibility. So while I agree with your (James's) comment, I think
it actually strengthens the argument that Lee was making.

And so we've morphed this thred into another thread about /64...

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Jun 2017 17:17:16 -0700

> And so we've morphed this thred into another thread about /64...

I’d rather not. My point is complementary to Lorenzo’s point in <[email-masked]>, where he implored the group to remember that the other side of the tussle involving operators and their needs to manage their networks, i.e. the network engineers, is the side comprising the users of the network and the designers of human interfaces for machines and applications that communicate via the network, i.e. the host engineers.

All three of the major tussles you mentioned in the message that kicked off this thread involve tensions between these two groups with often conflicting interests. It’s not just the /64 issue.

The DNS server address configuration issue is contentious because different human interface designers are concerned with different problems than network engineers, and we therefore have two methods of configuring host operating systems because operating systems are designed by different developers with different objectives in mind. The tussle between network engineers and host engineers here is about which side must carry more of the burden of ensuring interoperability between hosts and the network.

Likewise, from my perspective (which is quite far away from the heat of the action), the tussle between network engineers and host engineers with regard to header insertion seems to revolve around the effect of header insertion on path MTU discovery, which has implications for network application design. I, for one, am skeptical about plans to admit header insertion not because I have some commitment to theoretical purity, but precisely because I’m concerned about ever, some day, in our glorious future, having any kind of decent expectation that path MTU can be resolved over the Internet with any reliability, because that has serious implications for application design.

The point I wanted to add over and beyond the one that Lorenzo was making is that we are not all just network engineers here. Enumerating a list of all the possible types of network operator and putting forward the view that all the important tussles in IPv6 Land are between operators of different kinds of networks, neatly and conveniently erases a whole other class of people with networks for which there are no operators at all, a class of people who number orders of magnitude more than the operators, and who have a stake in the tussle represented by a whole other category of engineer, the host engineers, whose interests diverge more significantly from the interests shared among all the disparate subclasses of network engineer.

Maybe erasing them from the discussion was an accident, and my point was to try to correct what I hoped was merely an oversight and not an active deliberate effort to shut them out.

--james woodyatt <[email-masked]>

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 13 Jun 2017 11:10:29 +0200

On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert <[email-masked]> wrote:
<snip>
> Flexibility seems like a better way to future proof this.

What I seem to remember, read or heard somewhere is that it went
something like this:

IPv6 need more address space than IPv4 which is 32.
64 was just double, let's double that again and we should be safe?
They end up with 128bit, and slice it in two half, /64. One for LAN
and one for network.
Why not?

end of story.

-- 

Roger Jorgensen
[email-masked] / [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jun 2017 18:29:52 +0900

> device like a smart phone that really doesn't need it.

Again, that's the perception from the network operator side of the tussle.
The perception from the other side is, "these bits belong to hosts, go and
do mobility in the top 64 bits". It's really not hard to do mobility in the
network layer. Just build a low-overhead tunneling mechanism that maps /64
prefixes belonging to nodes to base station IP addresses. We have lots of
those, GTP being one. The overhead doesn't need to be 40 bytes, either -
you could

Because if you don't have a one-size-fits-all answer, you end up with not
enough space. Your assertion above is "a mobile device doesn't need /64".
Even if your assertion were true today (which I think it isn't - a full /64
is necessary to ensure that all devices behind the mobile node can run
SLAAC, for example), whatever address space you think a mobile device will
"need" is going to be based on how much you think a mobile device needs
today, and that's going to constrain future usage.

---

From: Mark Smith <[email-masked]>
Date: Tue, 13 Jun 2017 20:50:29 +1000

> or getting the DNS server address via DHCPv6?

<snip - EH insertion>

>That's because inserting stuff (any stuff, not just this header)

I think it is more significant than that.

It's

(A) ignoring statements in a very widely implemented and deployed
protocol specification that has existed for more than 20 years.
RFC1883 contains the text about not processing EHs in the network.

(B) ignoring the interoperability goal of protocol specifications,
meaning that new implementations' features interoperate with existing
implementations without significantly impacting their operation.
Inserting EHs contradicts Postel's "Be conservative with what you
send" because existing implementations aren't expecting in-flight
inserted EHs, and that is because that action is not specified as a
possibility in RFC2460.

(C) ignoring the fundamental and foundation principles of layers and
encapsulation/de-encapsulation to add or remove information to
existing protocol data units

(D) ignoring the operational consequences of making protocols and
devices harder to troubleshoot and rectify because it breaks source
address field semantics while the inserted EH is present. Despite
theoretical claims, in practice the inserted EH may not be removed at
the edge of the insertion domain because of device misconfiguration,
implementation bugs or partial device failures, so troubleshooting may
be occurring outside of the domain that inserted the EH. The operator
who decided to insert the EH may not be the operator dealing with its
consequences and having to troubleshoot and rectify it.

Excepting (A) all of the above can operational impacts to end-user
devices. They also will have financial impacts, both in terms of the
cost of downtime, and

I think creating technology that doesn't have as a priority trying to
leverage existing proven methods and deployed implementations is
creating unnecessary costs for end users. I think maximising
robustness and availability for minimum cost for the Internet and its
technologies' end-users should be the primary goal.

That's a purely operational view, based on trying to provide the best
and cheapest network service to end-users. All of a network operators
actions and decisions should be traceable back to end-user needs, and
be the action and decision that best meets those end-user needs.

<snip - /64s - 64 bit IIDs>

> a 64 bit boundary everywhere makes portability (of code, and of computers) easier.

Not in my case. To me it is to avoid network operational costs that
would have to be borne by end-users that were unavoidable in IPv4 due
to it's constrained number of addressing bits.

At two separate large hospitals in the late 1990s I saw a router with
4 x /24s on its interface and another router with 25 x /26s on its
interface (PCs were being used as routers before the subnets were
collapsed down to a "proper" router). In each case, the cost of
renumbering the >1000 hosts into a single large subnet were going to
be so high that the hospitals avoided it and put up with sub-optimal
routing. They had the money, however it was better spent on resources
to help and heal patients.

A large default subnet size makes this an impossible problem to have.
Nobody ever ran out of addresses in IPX subnets.

Network capital and operational costs are also opportunity costs to
the network's owners and end-users.

We should try minimise the technology's capex and opex so that we
maximise the money network end-users can spend on their real goals and
purposes for existence - healing patients, providing food, reducing
opportunity costs for customers by making cheaper yet more effective
products etc.,

I also care about the end-user privacy and security properties that
have emerged from IPv6's much larger address space.

I don't think this is a conceptual purist view. It is one of trying to
look after the end-users of the Internet and its technologies, by
reducing operational costs and enhancing privacy and security.

><snip - RDNS vs DNS via DHCPv6>

I think this is where RFC1958 should have been followed:

"3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

I'd describe the IETF's approach to multiple effectively equivalent or
near equivalent technologies to be Darwinian - survival of the
fittest. Let them be invented, possibly implemented and then possibly
deployed, and see which one or ones survive.

However, the drawback of the theory of natural evolution is that it
places no or very little cost on failure or factors what was learned
from failure into future evolution.

The costs of the IETF's Darwinian approach are now being incurred.
There is no clear winner between RA/RDNSS and Stateless DHCPv6, at
least in the eyes of the people who have to deploy it. Some developers
or vendors of them do have a preference, however they also have an
obligation to consider and possibly accommodate what the majority of
their customers want.

I have no specific preference for DHCPv6 for DNS, except that it
existed before RA/RDNSS, would work and would achieve the outcome.

While I wouldn't think it would totally avoid controversy, I think it
would be useful if the IETF came up with a set of actions and criteria
to try to judge and evaluate new proposals that are equivalents or
near equivalents to existing methods. Certainly a problem statement is
a requirement and one that is probably always being satisfied.
However, I think there should be others such as

- an independent evaluation of the problem statement to see whether
what it says about the problems with the existing method stands up to
scrutiny

- how widely has the existing method been implemented

- how widely has the existing method been deployed into production
environments and on what scale

- are the advantages of the new method compelling enough that those
with existing deployments would be willing to utilise both in
parallel, or replace the former method with the new method

- from those who have deployed the existing method, what are the
unexpected drawbacks they've discovered if any, and what have been the
unexpected benefits they've discovered, if any

We are wasting human resources if we allow new technologies to come
into existence and be developed when the existing solution could be
adequate or could have comparatively minor changes to be made
adequate.

If we believe network operator's needs are the most important, we'll
have forgotten who network operators exist to serve and more broadly,
who IPv6, the IETF and the Internet exists to serve.

Regards,
Mark.

---

From: Lee Howard <[email-masked]>
Date: Tue, 13 Jun 2017 07:35:52 -0400

On 6/13/17, 6:50 AM, "ipv6 on behalf of Mark Smith" <[email-masked]

>inserted EHs, and that is because that action is not specified as a

If you only insert and process EHs inside your network, then you can
reasonably assume that they are expected. Strip EHs at your borders and
everyone’s happy.

>existing protocol data units

You think?
Is routing information the same layer as the network layer, or higher or
lower? Adding headers outside the IP headers seems to me to preserve the
spirit of layering.
An alternative would be to formalize a path layer, using MPLS as one model.

>address field semantics while the inserted EH is present.

Yet operators are doing this now. Sounds like a tussle.

> Despite

Yes, that could be a problem. Do we have a documented BCP to drop packets
with unexpected EH outbound and inbound? *IS* that the BCP?

>who IPv6, the IETF and the Internet exists to serve.

To summarize a point I made yesterday:
The network serves whoever pays for the network. Not all networks are for
individual consumers.

Lee

---

From: Sander Steffann <[email-masked]>
Date: Tue, 13 Jun 2017 14:03:01 +0200

Hi,

> address field semantics while the inserted EH is present.

Should we define that "insertable" EHs have an "inserted by" field to ease traceability, filtering and debugging?

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 16:06:46 +0200

> They end up with 128bit, and slice it in two half, /64. One for LAN

Because IPv4 Classes were removed.

(a 64 boundary makes it a 'Class E' address, like 8 made it a Class A).

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Jun 2017 00:10:17 +1000

On 14 Jun. 2017 00:07, "Alexandre Petrescu" <[email-masked]>
wrote:

Why were they removed?

Why were they added?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 16:11:13 +0200

Le 13/06/2017 à 11:29, Lorenzo Colitti a écrit :
> On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Again, that's the perception from the network operator side of the 
> tussle. The perception from the other side is, "these bits belong to 
> hosts, go and do mobility in the top 64 bits". It's really not hard to 
> do mobility in the network layer. Just build a low-overhead tunneling 
> mechanism that maps /64 prefixes belonging to nodes to base station IP 
> addresses. We have lots of those, GTP being one. The overhead doesn't 
> need to be 40 bytes, either - you could

Deployed GTP-based mobility of a /64 still does not solve the need of 
multiple such /64s in a single moving network.  Unless cellular 
operators provide mobility of a /56 - it's not the case.

Alex

> Because if you don't have a one-size-fits-all answer, you end up with 
> not enough space. Your assertion above is "a mobile device doesn't need 
> /64". Even if your assertion were true today (which I think it isn't - a 
> full /64 is necessary to ensure that all devices behind the mobile node 
> can run SLAAC, for example), whatever address space you think a mobile 
> device will "need" is going to be based on how much you think a mobile 
> device needs today, and that's going to constrain future usage.
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 13 Jun 2017 19:13:49 +0200

>device like a smart phone that really doesn't need it.

Long prefixes are supported by DHCPv6 IA_NA today. Don't wait for SLAAC to
change. Just use DHCPv6.

SLAAC inherently wastes a lot of bits. In the past because of modified
EUI-64, today because of pseudo randomness.

If you want to free up bits for other purposes, increase allocation efficiency
and use DHCPv6.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 13 Jun 2017 19:22:29 +0200

>stuff, maybe have a router hanging off that tethered hotspot?

There are enough /48 prefixes that we will never run out if we give every
paying customer a /48.

There are enough /64 prefixes that we can give every link its own /64
and we will never run out.

So whenever you find yourself subdividing a /64, look at where in the
hierarchy bits are left unused. And then fix it at that level.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 13 Jun 2017 19:25:57 +0200

>Not everyone supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

It is not a good position to let one OS vendor lock up a large part of the
IPv6 protocol.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Jun 2017 13:30:20 -0500

> today, and that's going to constrain future usage.

I also have some comments on this.
But more importantly this discussion belongs to 5gangip list because it is
where it started.

Behcet

---

From: David Farmer <[email-masked]>
Date: Tue, 13 Jun 2017 16:21:41 -0500

> hierarchy bits are left unused. And then fix it at that level.

Yes, I agree with everything you are saying, but if I don't control the
allocation of the bits but I need bit where am I suppose to get them?
Sub-dividing a /64 is ugly, but if your stuck between a rock and a hard
place, you scratch at which ever is the softer substance.  In my view the
/64 is that softer substance.

-- 
===============================================
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: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 08:43:32 +0900

On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg <[email-masked].

> I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best
practices, for precisely the reason that they don't provide enough address
space.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Jun 2017 20:23:47 -0400

> On Jun 13, 2017, at 7:43 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg <[email-masked]> wrote:
> Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best practices, for precisely the reason that they don't provide enough address space.

Can you explain this statement, please?  I don't understand the connection between DHCPv6 and the size of the available address space.

- Ralph

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Jun 2017 17:25:02 -0700

On Tue, Jun 13, 2017 at 2:29 AM, Lorenzo Colitti <[email-masked]> wrote:
> those, GTP being one. The overhead doesn't need to be 40 bytes, either - you
> could
>
Lorenzo,

The _whole_ point of ILA is to eliminate encapsulation. This is an
example "to use IPv6 addresses in new and innovative ways" as you
phrased it. If we continue using encapsulation then that's just
business as usual and no different than IPv4. There's no innovation
there. Actually, the situation is worse since IPv6 incurs more
overhead than IPv4, so maybe carriers should just continue using IPv4
in their underlay network to avoid the 20 bytes overhead...

Tom

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Jun 2017 10:29:02 +1000

>From the ISP.  Every ISP that is only handing out a /64 knows or
should know that they are expected to handout more that one /64
when requested.

If the ISP is a cell provider ask them why they don't support
DHCP-PD.  The initial single /64 was only ever ment to be a stop
gap solution and 3GPP rev X does specify how to do DHCP-PD.

Every access technology supports more than a single /64.  Your ISP
is capable of delivering more.

Mark

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

---

From: David Farmer <[email-masked]>
Date: Tue, 13 Jun 2017 19:38:51 -0500

Sent from my iPhone
>> On Jun 13, 2017, at 18:43, Lorenzo Colitti <[email-masked]> wrote:
>> 

I assume you're talking about RFC7934, but where does it say that?  Nothing normatively says that, it does suggest that you use SLAAC to meet the normative recommendations, there is a warning about potential limits with DHCPv6, but it doesn't specifically recommend against DHCPv6, especially normatively. Furthermore, a recommendation for SLAAC isn't a recommendation against DHCPv6 in any way.

---

From: David Farmer <[email-masked]>
Date: Tue, 13 Jun 2017 19:58:15 -0500

Sent from my iPhone
> On Jun 13, 2017, at 19:38, David Farmer <[email-masked]> wrote:
> 

In fact nothing in RFC7934 overrides section 5.9.5 of RFC6434 which explicitly recommends all nodes implement DHCPv6 for address configuration.

So treating devices that don't support DHCPv6 as IPv4 only devices seems as reasonable to me as the decision for a device to not implement DHCPv6.

Basically, those in glass houses shouldn't cast stones.

David Farmer

---

From: Ca By <[email-masked]>
Date: Wed, 14 Jun 2017 01:23:54 +0000

On Tue, Jun 13, 2017 at 5:25 PM Tom Herbert <[email-masked]> wrote:

> tussle.
> you

I agree with this approach of "no change" since ILA does meet the
requirements to replace the existing 3gpp mobility system, let alone offer
a compelling benefit.

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Jun 2017 11:55:30 +1000

> reasonably assume that they are expected. Strip EHs at your borders and

So in theory, practice and theory are the same. In practice they're not.

Here's a scenario. This is packet's path over the Internet. You're at
AS8, providing OTT video services to 50 000 end-users at AS0.

[AS0 pkt src]--[AS1]--[AS2]--[AS3]--[AS4]--[AS5]--[AS6]--[AS7]--[AS8 pkt dst]

Imagine both AS2 and AS5 are inserting EHs and theoretically always
removing them, for their own local purposes. Now AS5 is not actually
removing them because of any of an implementation bug,
misconfiguration or a partial device failure.

Will this fault be constrained to AS5? No, not at all.

Will this fault be visible to AS5? No, not at all. They'll see no
signs of failure such as drops on egress of their AS, as they're not
performing any processing of the packets after they've left the AS.

How will you at AS8 go about identifying from the broken packets
you're receiving which of the ASes along the path is inserting the EH
and then not removing the EH that is breaking your service?

How long will it take? I'd estimate a minimum of a week to contact all
of the ASes in the path, ask them if they're inserting EHs, work to
overcome their scepticism that their equipment is misbehaving (because
it is always initially assumed somebody else's equipment that is
misbehaving when there are no local effects), organise a packet
capture on their egress link etc., etc.

How are you going to recover your the lost revenue from AS5 once
you've identified them as the cause. How are you going to get back the
customers who've cancelled their subscription to your OTT video
service because it took a week or more to resolve this?

What if AS2 is inserting but not removing EHs too? The complexity of
troubleshooting this scenario increases even more.

Or AS2 is in inserting EHs but not removing them, but AS5 is inserting
and removing them. AS5 might accept AS2's inserted EHs, and then have
AS2s inserted EHs interfere with AS5's use of them.

Unless the cause of AS2 not removing EHs is obvious (e.g.,
misconfiguration), you'll now have to have both AS2 and AS5 tap their
traffic to determine if their EH removal is being performed correctly.
Again, this is after you've spent a lot of time contacting all ASes to
determine who is inserting EHs in flight.

> lower? Adding headers outside the IP headers seems to me to preserve the

It is.

Encapsulation treats the to-be-encapsulated PDU as an atom.

Inserting EHs is not adding headers and is not treating the PDU as an
atom. It is splitting the original PDU apart to insert the EH.

i.e.,

before:

IPv6 Pkt - [Orig. IPv6 Hdr][Orig. IPv6 Payload]>

after:

IPv6 Pkt - [Orig. IPv6 Hdr][New EH][Orig. IPv6 Payload]

> An alternative would be to formalize a path layer, using MPLS as one model.

We already have a way to do that. IP-in-IP tunnelling.

In the IPv6 EH insertion draft, that is being proposed for the SR
domain transit case but not when the packet is originated in the SR
domain. So there are two different mechanisms being proposed that
achieve the exact same outcome (segment routing) based on where the
packet originates, either internally or externally.

As the only distinction between internal and external packet origins
is the value in the source address field, I don't think there is
anything to prevent a single method being used for all packets,
regardless of their origin. That would be simpler to implement and
troubleshoot. The IP-in-IP tunnel method is conventional, proven and
far easier to troubleshoot than the EH insertion method.

I think IPsec provides a proven model of adding information to packets.

transport mode - packet origin host to packet final destination host -
insert AH and/or ESP EH in the host's stack during the construction of
the IP(v6) header, remove it when the IP(v6) header is deconstructed
and the payload handed up to the transport layer implementation

tunnel mode - host to gateway (router) or gateway to gateway - add AH
and/or ESP EH by encapsulating the original packet in a new IP(v6)
packet.

> Yet operators are doing this now. Sounds like a tussle.

I don't think it is widespread enough to have uncovered how hard
troubleshooting will be.

People assume things they've put in place are working if they
themselves don't see any consequences. The domain of the EH insertion
mechanism is local, the potential fault domain for it extends to any
packet destination that is beyond the AS that inserted but didn't
remove the EH.

The closer to the source of the packet the EH insertion occurs, the
greater the the potential fault domain, which could include all
destinations on the Internet. In the above example, imagine AS1 is the
EH insertion domain failing to remove them, and [AS2] through [AS8] is
just one of the paths across which the AS0 subscribers are sending
packets across.

> with unexpected EH outbound and inbound? *IS* that the BCP?

I don't think high speed IPv6 routers are likely to be able to perform
any form of exhaustive EH validation. It would be a new requirement,
and one that router vendors have never had before.

Doing so is of course also a direction contradiction to

"extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header."

so RFC2460 can't be pointed to as a reason why routers should be
expected to perform EH validation.

Expecting all AS operators on the Internet to upgrade their devices to
perform EH validation just to protect against the case of EHs not
being removed is putting the cost of prevention of failure onto the
potential victims, not onto the party who chose to insert the EH that
then didn't end up removing it.

A better mechanism will localise mechanism failures to the domain
where the decision to use and implement the mechanism was made. It is
better avoid or minimise the possibility of the local mechanism
failure consequences being externalised.

> The network serves whoever pays for the network. Not all networks are for

I think you've misunderstood what an "end-user" is. It is the end or
final user or consumer of the service. It could be an individual, a
group of individuals, an organisation or a device. Whether or not the
entity identified as the service end-user is making a direct financial
payment or not doesn't distinguish whether they're a service end-user.

A network's service end-user is the hosts attached it, with the
service being carrying of packets to and from the hosts. If an IPv6
network doesn't provide better service to hosts than an IPv4 network
does, because of either the network operator's decisions or IETF
decisions, then there is no need for an IPv6 service over an IPv4 one.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 11:22:03 +0900

On Wed, Jun 14, 2017 at 9:25 AM, Tom Herbert <[email-masked]> wrote:

> The _whole_ point of ILA is to eliminate encapsulation.

I know what you're trying to do with of ILA is to eliminate encapsulation.
I just disagree it's the right tradeoff, because it deprives hosts of the
ability to innovate, and that's not worth saving a few bytes of
encapsulation overhead.

Actually, the situation is worse since IPv6 incurs more overhead than IPv4,
> so maybe carriers should just continue using IPv4 in their underlay network
> to avoid the 20 bytes overhead...

Technically you don't even have to use IPv4 or IPv6. You could use
something else like MPLS.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 11:25:59 +0900

On Wed, Jun 14, 2017 at 9:38 AM, David Farmer <[email-masked]> wrote:

> I assume you're talking about RFC7934, but where does it say that?
>

It says so here:

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see Section 4), it is RECOMMENDED that the network
   give the host the ability to use new addresses without requiring
   explicit requests.

You can't meet that recommendation on a network that only supports address
assignment via DHCPv6 IA_NA/IA_TA. As the document says, you can certainly
do it if you provide the host with a prefix using DHCPv6 PD, or some future
DHCPv6 option that does not have those limitations.

---

From: Erik Kline <[email-masked]>
Date: Wed, 14 Jun 2017 12:03:19 +0900

> (a 64 boundary makes it a 'Class E' address, like 8 made it a Class A).

Arguments about address space issues that proceed from an analogy to IPv4
make no logical sense to me.

A 2-seater sports car and 18-wheel truck are both technically
"automobiles", but it absolutely /does not/ follow that they should be
operated in exactly the same way.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 12:12:29 +0900

On Wed, Jun 14, 2017 at 9:23 AM, Ralph Droms <[email-masked]> wrote:

> Can you explain this statement, please?  I don't understand the connection
> between DHCPv6 and the size of the available address space.
>

The answers are in RFC 7934.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Jun 2017 20:36:41 -0700

On Tue, Jun 13, 2017 at 7:22 PM, Lorenzo Colitti <[email-masked]> wrote:
> I know what you're trying to do with of ILA is to eliminate encapsulation. I
> just disagree it's the right tradeoff, because it deprives hosts of the
Can you tell me what the killer app is on a smartphone that require
2^64 addresses?

Tom

>> Actually, the situation is worse since IPv6 incurs more overhead than
>> IPv4, so maybe carriers should just continue using IPv4 in their underlay
>> network to avoid the 20 bytes overhead...
>
>
> Technically you don't even have to use IPv4 or IPv6. You could use something
> else like MPLS.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 16:11:22 +0900

> Can you tell me what the killer app is on a smartphone that require

I don't have one for you today, and I don't think I will have one for you
tomorrow either. I want to preserve the ability for someone else to give
you the answer during the expected multi-decade year lifetime of the
protocol. If you take the bits for your own use, we will never get that
answer.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 14 Jun 2017 11:28:37 +0200

> It is not a good position to let one OS vendor lock up a large part of the

I would like Android backers to make DHCPv6-PD work.

At work, the compilation of ISC software on Android is a very difficult 
task (impossible?), whereas the same software on other IoT platforms 
like Sierra goes very smoothly.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 14 Jun 2017 08:09:25 -0700

On Wed, Jun 14, 2017 at 12:11 AM, Lorenzo Colitti <[email-masked]> wrote:
> tomorrow either. I want to preserve the ability for someone else to give you
> the answer during the expected multi-decade year lifetime of the protocol.

If such an application never materializes then all you've done is
waste half of the bits in IPv6 addresses and inhibit potential and
tangible innovation. IMO, arbitrarily allocating half the bits to
hosts with the justification that some day it might be useful is a
poor justification for a protocol requirement.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 15 Jun 2017 00:28:43 +0900

> poor justification for a protocol requirement.

Agreed. I'm pretty sure the next 30 years will produce something better
than the ability to do mobility without encapsulation. And ILA isn't the
only way to do mobility without encapsulation, anyway - all you need is a
way to update correspondent nodes with your current address when it changes.

---

From: "Leddy, John" <[email-masked]>
Date: Wed, 14 Jun 2017 15:43:46 +0000

You could use V6 Segment Routing and insert an SR header on entrance to the domain with the V6 Location of the End User device.  Outbound isn’t really an issue.

Then we can stay with the hard /64.

From: ipv6 <[email-masked]> on behalf of Lorenzo Colitti <[email-masked]>
Date: Wednesday, June 14, 2017 at 11:28 AM
To: Tom Herbert <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Subject: Re: Tussles in IPv6 Land

Agreed. I'm pretty sure the next 30 years will produce something better than the ability to do mobility without encapsulation. And ILA isn't the only way to do mobility without encapsulation, anyway - all you need is a way to update correspondent nodes with your current address when it changes.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jun 2017 12:14:47 +1200

>> Can you tell me what the killer app is on a smartphone that require

The question is slightly premature. Try:

"What is the killer use case on a smartphone that requires
many addresses that are essentially unguessable because
they include 64 pseudo-random bits?"

Lorenzo's answer below covers this case too, and he's right, if
we believe that miscreants in the far future may have enough
computing power to search a very large space, even if the use
case only needs a few thousand addresses.

(64 is only a parameter, even in this sub-sub-sub-thread, but it's
the right order of magnitude - privacy concerns require several
tens of bits even with today's computing power.)

BTW, I aoplogise to the WG for having provoked this thread. My
intention was only to remind people that these tussles are
a sign of success for IPv6.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Jun 2017 17:23:48 -0700

> On Jun 14, 2017, at 5:14 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Good point.  It’s not like current specification don’t work.  For example, Google is showing a peak of ~19% of their traffic is IPv6.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Jun 2017 13:04:22 -0700

Brian,

If there is a killer app then it may well be in security, however I
would think that to justify /64 as the standard, one would have to
demonstrate that such security can't be comprised and ubiquity is
required. I'd also point out that giving the host more bits for
entropy means the the network side gets less. So while it might be
hard to guess a host address, if it's easy to guess the prefix
assigned to the device which can then that could be an avenue to for
DOS attack on the device. It seems like for security we would want
both network and host contribution and the address to be unguessable,
so it might make sense to give them an equal number of bits of entropy
and hence something longer than /64 would be needed.

Tom

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Jun 2017 20:20:25 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert

> I'd also point out that giving the host more bits for entropy
> means the the network side gets less. So while it might be
> assigned to the device which can then that could be an avenue to
> for DOS attack on the device.

I agree with this general line of thinking, and I'd also point out that as computers become faster, this security benefit will decrease and then vanish. Really, to create a vast address space, and then after the fact, establish "rules" that require that vast address space to be only **very** sparsely used, is counterproductive? Why isn't is better to use real security measures, such as TLS?

The 17-year cicada has practically no defenses. The only way the species survives is through huge numbers, very short lifespans, and exceedingly long dormant periods buried underground. I would prefer having some defenses, given a choice.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Jun 2017 13:18:10 +1200

On 16/06/2017 08:20, Manfredi, Albert E wrote:
> I agree with this general line of thinking, and I'd also point out that as computers become faster, this security benefit will decrease and then vanish. Really, to create a vast address space, and then after the fact,

The /64 boundary was established by RFC2373 (July 1998). Hardly after the fact.

> establish "rules" that require that vast address space to be only **very** sparsely used, is counterproductive? Why isn't is better to use real security measures, such as TLS?

Because sparse addresses and e2e security solve very, very different security problems.

Sparse subnet prefixes might also have some value, as Tom implies. I'm not aware of any analysis of that, in RFC7707 or elsewhere.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2017 02:38:39 +0000

Brian, let me reconstruct my post as it was written:

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 

>> I agree with this general line of thinking, and I'd also point
>> out that as computers become faster, this security benefit will
>> decrease and then vanish. Really, to create a vast address space,
>> and then after the fact, establish "rules" that require that vast
>> address space to be only **very** sparsely used, is
>> counterproductive?
>

The 64-bit boundary is not the issue here. The issue is that this 128-bit address space was not initially intended to be forever very sparsely populated, for a security reason. In fact, when the IID was meant to consist of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were hardly any sort of security measure. We're now saying, in spite of the hype about this vast address space, that at least the bottom 64 bits of it, if not also the prefix 64 bits, must be very sparsely populated. So much for vast address space, right?

So, when I said "after the fact," I was talking about the security rationale. That definitely came after the fact.

>> Why isn't is better to use real security measures, such as TLS?
>

Well, I contend there's some intersection of sets there. Anonymity becomes less crucial if the content is encrypted. And there are other ways, probably better ways, of achieving anonymity, than sparse usage, such as short address lifetimes. Plus, as security measure, 64 bits becomes less and less believable, in a time when we must use 128 or preferably 256 bits for effective security keys. So we really need to put this one security aid in perspective, I think. It seems to be given more emphasis than it deserves?

Bert

---

From: Ca By <[email-masked]>
Date: Fri, 16 Jun 2017 03:09:37 +0000

On Thu, Jun 15, 2017 at 7:39 PM Manfredi, Albert E <
[email-masked]> wrote:

> The 64-bit boundary is not the issue here. The issue is that this 128-bit
> address space was not initially intended to be forever very sparsely
> populated, for a security reason. In fact, when the IID was meant to
> consist of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were
> hardly any sort of security measure. We're now saying, in spite of the hype
> about this vast address space, that at least the bottom 64 bits of it, if
> not also the prefix 64 bits, must be very sparsely populated. So much for
> vast address space, right?
>
> So, when I said "after the fact," I was talking about the security
> rationale. That definitely came after the fact.
>
> Well, I contend there's some intersection of sets there. Anonymity becomes
> less crucial if the content is encrypted. And there are other ways,
> probably better ways, of achieving anonymity, than sparse usage, such as
> short address lifetimes. Plus, as security measure, 64 bits becomes less
> and less believable, in a time when we must use 128 or preferably 256 bits
> for effective security keys. So we really need to put this one security aid
> in perspective, I think. It seems to be given more emphasis than it
> deserves?
>
> Bert
>

Recently, on the internet, there was a very effective and harmful worm
called "wannacry". This worm was only on ipv4, and it's particular ilk will
only ever be on densely populated ipv4. And, it could never be effective on
sparsely populated ipv6. You see, it used a random number generator to feed
an ipv4 hunter function that would attempt to connect to computers on open
port 445.  In ipv6, that hunter is fruitlesss.  The wannacry story is very
instructive, from its CIA / NSA roots, to being dumped to the public, and
then maliciously operationalized against ... hospitals...and others.

Yes, there are ways to narrow the search for ipv6 hosts and key parties can
discover addresses.  Google probably knows most of the alive ipv6 address
on the 'net at any one time, Akamai has published some work in this space
(showing addresses are not very preditable) but a random worm does not and
will not be able to guess the space and feed a hunter function.

So, yes, imho, 64 random bits is a killer security app. Just like stripes
on a zebra or spots on a cheetah were not part of some grand design, the 64
bits value's security value is emergent.

I have personally been able to effectively use the sparse addressing as
part of a very large network's security posture for several years.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Jun 2017 20:31:12 -0700

Brian,

I believe both IPwave and the upcoming IDEAS BOF are discussing
methods to obfuscate addresses for the purpose to prevent tracking of
mobile devices (like tracking the location of a car as it drives down
the road). It's the device's prefix that needs to be obfuscated in
this case, so the host randomizing its addresses in a sparse space
doesn't help.

Tom

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Jun 2017 13:51:28 +1000

In message <[email-masked]>, "M
anfredi, Albert E" writes:
> consist of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs
> were hardly any sort of security measure. We're now saying, in spite of
> the hype about this vast address space, that at least the bottom 64 bits
> of it, if not also the prefix 64 bits, must be very sparsely populated.
> So much for vast address space, right?

The security properties of 48 bit mac addresses were very much
discussed when the prefix size was being choosen.  They still
prevented remote scanning of the subnet space to find the hosts in
the subnet.  Random assignmemt just improved on that by removing
clustering effects.  So no it wasn't after the fact, it was part
of the rational for the original assignment size.

> That definitely came after the fact.

No.

> Well, I contend there's some intersection of sets there. Anonymity
> becomes less crucial if the content is encrypted. And there are other
> ways, probably better ways, of achieving anonymity, than sparse usage,
> such as short address lifetimes. Plus, as security measure, 64 bits
> becomes less and less believable, in a time when we must use 128 or
> preferably 256 bits for effective security keys. So we really need to put
> this one security aid in perspective, I think. It seems to be given more
> emphasis than it deserves?

Anonymity isn't the only possible benefit.  You only get anonymity
when you share the subnet with lots of other people which isn't the
case most of the time.  This was well known when the /64 decision
was made.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 16 Jun 2017 12:57:18 +0900

> this case, so the host randomizing its addresses in a sparse space

How are they planning to solve the mobility problem if the device's prefix
changes all the time?

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Jun 2017 10:36:07 +0100

----- Original Message -----
From: "Ca By" <[email-masked]>
Sent: Friday, June 16, 2017 4:09 AM

<snip>

> part of a very large network's security posture for several years.

Until the criminals find a large enoough target to be worth attacking,
when, skilful as they are, they will find a way around it.

Early reports of  "wannacry" said that it targeted Windows XP, which
seemed unlikely to me as so few systems now run that, perhaps 5%.  (I
would also have been sceptical if they had said Windows 8:-). Later
reports said the target was Windows 7 which made sense, since that is
what I see organisations using.

If and when IPv6 with sparse addressing becomes a big enough target to
be worth attacking, then it will be attacked.  Until then, people may
believe in security by obscurity.

Tom Petch

---

From: Mark Smith <[email-masked]>
Date: Fri, 16 Jun 2017 20:28:02 +1000

On 16 Jun. 2017 19:40, "t.petch" <[email-masked]> wrote:

----- Original Message -----
From: "Ca By" <[email-masked]>
Sent: Friday, June 16, 2017 4:09 AM

<snip>

There's nothing actually wrong with security by obscurity as a defence in
depth measure.

If you already prevent ICMPv4 echo requests inbound, you're using it. As
are zebras, giraffes, cheetahs and many (probaby all) armies around the
world, namely camouflage.

The meme of there is no security in obscurity is a distortion of
Kerckoffs'principle, and there is still an obscurity - the (secret) key.

https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle?wprov=sfla1

So, in this context, if you're relying on not being discovered by packet
probing, it's a single point of failure. However, if you have other
measures in place, such as host based firewalls, authentication at the IP
or higher layers, meaning transport or application layers, then obscurity
adds another level of defence.

That wasn't possible in IPv4 because of its much smaller address space.
Wannacry demonstrates a this. It is an emergent property of IPv6 addresses
as long as we give IPv6 hosts enough addresses to have it.

Regards,
Mark.

---

From: Lee Howard <[email-masked]>
Date: Fri, 16 Jun 2017 08:30:55 -0400

From:  ipv6 <[email-masked]> on behalf of Ca By <[email-masked]>
Date:  Thursday, June 15, 2017 at 11:09 PM
To:  Brian E Carpenter <[email-masked]>, "Manfredi, Albert E"
<[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: Tussles in IPv6 Land

> 
> On Thu, Jun 15, 2017 at 7:39 PM Manfredi, Albert E
> <[email-masked]> wrote:
>> populated, for a security reason. In fact, when the IID was meant to consist
>> of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were hardly
>> any sort of security measure. We're now saying, in spite of the hype about
>> this vast address space, that at least the bottom 64 bits of it, if not also
>> the prefix 64 bits, must be very sparsely populated. So much for vast address
>> space, right?
>> 
>> less crucial if the content is encrypted. And there are other ways, probably
>> better ways, of achieving anonymity, than sparse usage, such as short address
>> lifetimes. Plus, as security measure, 64 bits becomes less and less
>> believable, in a time when we must use 128 or preferably 256 bits for
>> effective security keys. So we really need to put this one security aid in
>> perspective, I think. It seems to be given more emphasis than it deserves?
>> 
>> Bert
> 
> 
> Recently, on the internet, there was a very effective and harmful worm called
> "wannacry". This worm was only on ipv4, and it's particular ilk will only ever
> be on densely populated ipv4. And, it could never be effective on sparsely
> populated ipv6. You see, it used a random number generator to feed an ipv4
> hunter function that would attempt to connect to computers on open port 445.
> In ipv6, that hunter is fruitlesss.

Don’t overestimate the power of hiding in large numbers. It has been shown
that it’s not too hard to reduce the available numbers to a more easily
guessable set:  

https://tools.ietf.org/html/rfc7707 Network Reconnaissance in IPv6 Networks
http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-security-myth-4-i
pv6-networks-are-too-big-to-scan/

> 
> So, yes, imho, 64 random bits is a killer security app. Just like stripes on a
> zebra or spots on a cheetah were not part of some grand design, the 64 bits
> value's security value is emergent.

I agree that a bit of randomization can slow down an attacker. Like a
cheetah, you also need to outrun the attacker, or like a zebra, you need to
make it harder to find a specific attack point. As somebody else said,
there’s nothing wrong with it as a complement to a sound defense in depth
plan.

Lee

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Jun 2017 08:06:51 -0700

> If you already prevent ICMPv4 echo requests inbound, you're using it. As are
> zebras, giraffes, cheetahs and many (probaby all) armies around the world,
> namely camouflage.
>
Mark,

Zebras are still in the main diet of lions. Camouflage is not the same
thing as armor or weapons. Credit cards have long numbers that aren't
guessable, but that is little comfort every time I get a letter from a
merchant about a breach and how my number was stolen.

> Kerckoffs'principle, and there is still an obscurity - the (secret) key.
There is no secret key in address randomization.

> https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle?wprov=sfla1
Kerckhoff's principle is "a cryptographic system should be designed to
be secure, even if all its details, except for the key, are publicly
known." Since IP addresses are sent in the clear, they are essentially
public knowledge. If somehow the IID is set to a cryptographic hash
over the rest of the IP addresses then maybe Kerckoff's principle
would be applicable.

Tom

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Jun 2017 04:00:50 +1000

On 16 June 2017 at 22:30, Lee Howard <[email-masked]> wrote:
>> the prefix 64 bits, must be very sparsely populated. So much for vast
>> address space, right?
>>
>> better ways, of achieving anonymity, than sparse usage, such as short
>> address lifetimes. Plus, as security measure, 64 bits becomes less and less
> port 445.  In ipv6, that hunter is fruitlesss.
>
>
> http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-security-myth-4-ipv6-networks-are-too-big-to-scan/
>

They're why RFC7212, " A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Autoconfiguration
(SLAAC)", is now the recommended default (per RFC8064) for SLAAC
stable addresses.

>
>
> So, yes, imho, 64 random bits is a killer security app. Just like stripes on
> a zebra or spots on a cheetah were not part of some grand design, the 64

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2017 19:42:54 +0000

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 

> The security properties of 48 bit mac addresses were very
> much discussed when the prefix size was being choosen.
> They still prevented remote scanning of the subnet space
> to find the hosts in the subnet.  Random assignmemt just
> improved on that by removing clustering effects.

Well, clearly. In the original EUI-64, it would have been easy enough to identify all hosts from a given vendor, or down to the device itself, on a given subnet. If you randomize those 48 bits for all hosts, then that technique won't work. And if you shorten the lifespan of IIDs, even as infrequently as a new IID every time you reboot the host, that does the same thing.

Which only says to me, at least that one security rationale for long IIDs can be trivially met in /80 networks. Compared with the original EUI-64 IID, even such things as collision likelihood are no worse in an /80 implementation.

> So no it wasn't after the fact, it was part of the
> rational for the original assignment size.

To be overly pedantic, didn't the IID randomization idea come well after the decision to adopt an IPX-like address structure?

> Anonymity isn't the only possible benefit.

And it won't work with DNS anyway.

Operators and equipment vendors may have motivations I'm not aware of. But to me, the best outcome of sticking to "default" or "mandatory" or "the only easy option" /64 is mostly to try to prevent the race to the bottom. I suppose there's something to that.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Jun 2017 08:59:04 +1000

In message <[email-masked]>, "Manfredi, Albert E" writes:
> Well, clearly. In the original EUI-64, it would have been easy enough to
> identify all hosts from a given vendor, or down to the device itself, on
> a given subnet. If you randomize those 48 bits for all hosts, then that
> technique won't work. And if you shorten the lifespan of IIDs, even as
> infrequently as a new IID every time you reboot the host, that does the
> same thing.

As I said, we were well aware of all of this when we went with /64
in the first place.  Nothing prevented operators choosing addresses
for hosts randomly then assigning those addresses manually.

> Which only says to me, at least that one security rationale for long IIDs
> can be trivially met in /80 networks. Compared with the original EUI-64
> IID, even such things as collision likelihood are no worse in an /80
> implementation.

Only if you believed that 64 bit macs would not eventually be in use.

> To be overly pedantic, didn't the IID randomization idea come well after
> the decision to adopt an IPX-like address structure?

It came after to prevent tracking of machines from one subnet to
another.  It also improved the ability to not be discovered from
~48 bits to 64 bits of randomness.

> And it won't work with DNS anyway.

Having the name of the machine does not identify the user of the
machine.  In the networks where you get anonymity due to there being
lots of people you quite often don't have PTR records.  This is
true even if you add AAAA records for the machine so that it can
be reached if you know the name.

> Operators and equipment vendors may have motivations I'm not aware of.
> But to me, the best outcome of sticking to "default" or "mandatory" or
> "the only easy option" /64 is mostly to try to prevent the race to the
> bottom. I suppose there's something to that.

There is a lot to that.  There is also a lot to say for giving each
site a /48 regardless of if it is a home, a cell phone or a business.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2017 23:23:52 +0000

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

> There is also a lot to say for giving each site a /48 regardless
> of if it is a home, a cell phone or a business.

Exactly. So here's today's question. Is this remotely likely to happen? No, from what I've been able to determine.

So what's the next best thing, which is (IMO) considerably more likely to happen, without incurring any significant penalties compared with that /48 possibility?

My answer is, /64 from the operator, which can locally be increased to /80, with no credible downside. I don't know how the IETF can force operators to do anything, but I have to believe it's more realistic to hope for /64s to every subscriber, given how prevalent that has become?

And then parenthetically, if local nets want to increase the prefix even more, they can, and they know the security issues, which may be a big who cares for them.

Now we can sleep better knowing that the IPv4 address length has effectively been doubled at least. As opposed to only increased in length by 50%.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 Jun 2017 12:07:17 +1000

In message <[email-masked]>, "M
anfredi, Albert E" writes:
> From: Mark Andrews [mailto:[email-masked]]=20
> 
> Exactly. So here's today's question. Is this remotely likely to happen?
> No,  from what I've been able to determine.

We have ISPs that hand out /48s to anyone on the planet just by
requesting one.  There are ISP's that handout /56s.  There ISPs
that handout /64s though most of them are only doing so because
they are dealing with limitations on existing hardware and they
intend to offer short prefixes in the future.  So yes, I do believe
shorter than /64 prefixes will become the norm.

> So what's the next best thing, which is (IMO) considerably more likely to
> happen, without incurring any significant penalties compared with that
> /48 possibility?
>
> My answer is, /64 from the operator, which can locally be increased to
> /80, with no credible downside. I don't know how the IETF can force
> operators to do anything, but I have to believe it's more realistic to
> hope for /64s to every subscriber, given how prevalent that has become?

And then the operator will just hand the consumer a /80 because they can
and someone like you will come along and argue "We can make it a /96 for
the user, thats more than enough address space".

> And then parenthetically, if local nets want to increase the prefix even
> more, they can, and they know the security issues, which may be a big who
> cares for them.
>
> Now we can sleep better knowing that the IPv4 address length has
> effectively been doubled at least. As opposed to only increased in length
> by 50%.

So what?  Increasing the prefix to 48 bits results in more than
enough sites per person on the planet.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Jun 2017 11:43:11 +0900

> the user, thats more than enough address space".

Exactly.

---

From: George Michaelson <[email-masked]>
Date: Mon, 19 Jun 2017 14:50:09 +1000

I'm not a believer in the reification of the H/D ratio. I feel it was
a pragmatic observance of practices which applied at the time it was
defined, and doesn't represent a reality (to me at least) in how we
structure address plans, or deploy networks at scale (I hasten to add,
I do neither. I only believe this based on what little I understand of
how other people describe what they do)

I just wanted to come here and say that nothing, absolutely nothing we
do in address policy, drives to /80 or /96. N O T H I N G.

Its arguable in RIR policy world, the /56 thing was a mistake. If so,
I apologize, although its a community consensus position, not my own.

Its true that some aspects of RIR policy took TLA, tore it up, and
replaced it with OTHER magic numbers (of course, this is a partisan
and fragmented take on a conversation which involved many fine
meetings and differences of opinion) like /48 and /56. But thats in a
context where completely other people took 128 and turned it back into
8+8 for entirely fine, pragmatic reasons and many fine meetings and
lunches lie in that decision too.

Do we have an exhaustion problem in IPv6? No. We're in a tiny fragment
of 512 goes inside the /3 we decided to play in. We have no lack of
ability to give out /64s for everyone and /56s for everyone, and very
probably /48s for everyone sensibly able to control their destiny, if
thats what we want.

Do we have a deployment problem on the edge with IPv6? Yes. We have
people who seem to think we have to be super prudent and only give a
single instance to a single device, and who don't chose to reflect on
what a /56 or a /48 is capable of, because it doesn't suit their
mental model. We have people who don't want to have to think about how
to manage intermediary devices which have to do PD. We have people who
want to operate choke points, or not allow things, Who want the IMEI
and APN to imply a contract of limitations. Price and Cost disfunction
is huge here. Why does one bit of silicon and plastic magically allow
an iPad to do wondrous things, and prevents a MiFi from doing these
wondrous things? Because money.

But nothing, N O T H I N G in address policy globally drives them
there. We don't say "give each customer a /128" and we don't want to
be taken to saying it, the 3GPP and other bodies not withstanding.

The decision about "how much" is a pretty odd question really.

Why are we having this conversation? I totally don't get it.

-G

---

From: Sander Steffann <[email-masked]>
Date: Mon, 19 Jun 2017 15:01:11 +0200

Hi George,

> The decision about "how much" is a pretty odd question really.

Thank you for stating this, I concur.

Sander Steffann
RIPE Address Policy Working Group co-chair

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Jun 2017 14:31:21 +1000

Hi Tom,

> merchant about a breach and how my number was stolen.

So what I think you're doing here is adding and mixing up threats, and
then using those to evaluate the security measure. Once you do that,
the measure may be completely ineffective and entirely inappropriate.

The specific threat where large IIDs and random addresses is an
effective mitigation is device discovery via brute force unsolicited
packet probing.

It is not going to be an effective mitigation to addresses discovery
by somebody in a position to discover addresses by tapping the traffic
flow, or somebody who can use service log entries that recorded
service clients that connected to the service. They are different
threats and require different mitigations, because large and random
IIDs are not effective against them.

Unsolicited inbound packet probing has been successfully used to
discover unknown IPv4 devices on the Internet since at least 2009.

https://en.wikipedia.org/wiki/Shodan_(website)

DerbyCon 2012: The Wild West by HD Moore
https://speakerdeck.com/hdm/derbycon-2012-the-wild-west

Also in 2012, a 420 000 node botnet was created using unsecured home
CPE and then that was used to scan the entire IPv4 address space:

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

And we've recently seen the Wannacry malware leverage the same
technique to exploit the SMBv1 vulnerability.

Given how long that Internet wide IPv4 address sweeps have been
occurring and have been successful at discovering unsecured services
(e.g., "The Wild West by HD Moore") I still get surprised how insecure
devices are that are likely to have been bought and deployed within
the last 5 years:

"Practical ways to misuse a router"
http://blog.ptsecurity.com/2017/06/practical-ways-to-misuse-router.html

If the above devices had Internet addresses that couldn't be
successfully discovered via brute force scanning, it would have
provided them with a base level of protection from further inspection.
Other techniques would have to be used to discover these devices, and
that means the specific threat - discovery by brute force unsolicited
packet probing - has been mitigated successfully. Those other
techniques will not be as easy to execute compared to brute force
address scanning, otherwise they'd have been used instead and in the
first place.

People have been using guessable IPv6 IIDs has been used recently to
discover open DNS resolvers. I think that demonstrates that people
aren't considering the consequences of picking guessable IIDs when
using GUA addresses. If the were, then they'd be securing the DNS
resolver itself too.

https://blog.apnic.net/2017/06/15/open-resolvers-ipv6-not-hidden-think/

It would have been better if these DNS resolvers had random 64 bit
IIDs rather than easily guessable ones like ::53. To be able to use
them as an open resolver, you'd have to successfully discover it
first.

I understand the convenience of using significant IID values, however
I don't think they're justified by saying they should be easy for
end-users to remember or type. Network engineers or host operators are
a different audience, and should be willing to put up with some
operational inconvenience if it results in a more available and secure
service for their end-users.

In this DNS example, I think end-users having to remember or write
down and then enter IPv6 service address such as DNS server addresses
is about as user friendly as hand cranking cars with a handle was to
start them. You can buy retail cars that can drive themselves on
public roads, yet we can't manage to successfully and reliably
automatically configure routers and hosts with DNS resolver addresses,
such that we need to make them easy remember, write down or type?

Regards,
Mark.

---

From: [email-masked]
Date: Wed, 21 Jun 2017 08:40:12 +0200 (CEST)

> them as an open resolver, you'd have to successfully discover it

Some of us are using easily guessable IPv6 resolver addresses very
much on purpose - primarily because this is one of the few addresses
that may need to be specified manually, given to customers over the
phone, etc.

At least in our case these IPv6 resolver addreseses are *not* open
resolvers: The DNS service is only reachable within our AS.

> service for their end-users.

You may want use difficult-to-guess IID values in your network. You
shouldn't expect all operators to agree.

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Jun 2017 18:24:18 +1000

On 21 June 2017 at 16:40,  <[email-masked]> wrote:
> that may need to be specified manually,

On those rare occasions, cut-and-paste works fine.

> given to customers over the
> phone, etc.

Been there, done that, I don't think it is a good idea.

In my residential ISP experience, helpdesk staff don't apply much
intelligence to troubleshooting because they're incentivised to
increase their phone call/hour throughput. So they try random things
until one of them works, and don't reverse other ineffectual changes
they made. So you end up having to punch a couple of old DNS resolver
/32s out of a /24 (which pretty much prevents you from using the /24
as a /24 anywhere else) you want to use somewhere else because
customers now have them set manually rather than using the reliable
and proven autoconfiguration method/system.

Again, self driving cars, yet ISP customers have to be exposed to
under the hood/bonnet settings?

If people aren't getting DNS settings set correctly by the
autoconfiguration system, which is better - the helpdesk band-aiding
over it using manual settings, or the fault being fixed properly by
the operations teams?

I've had the experience of a helpdesk band-aiding over a problem on me
for 6 months, and only found out about it 2 weeks before we were going
to be launching a product that the hidden fault was going to cause
catastrophic problems to, which it did, because there was too much
inertial against stopping the product launch.

Making DNS server addresses hard to type increases the chances of the
proper team being able to fix the problem properly because it'll be
escalated.

> shouldn't expect all operators to agree.

I don't think I said anything about seeking agreement.

What I'm highlighting is that even for manually configured addresses
e.g., server interfaces or router interfaces, there is a security
value in having a large IID space available. I'm pointing it out to
make sure it is recognised by those who are lobbying for arbitrary
IPv6 prefix/IID sizes.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Jun 2017 14:54:44 +0100

> effective mitigation is device discovery via brute force unsolicited

While you quote specific examples of how easy it is to scan the entire
ipv4 address space, you also omit to mention that scan + connect worm
behaviour is not how the lion's share of vulnerabilities are spread
these days, and also you don't mention that a single compromised device
on an ipv6 network is enough to be able to spread to all other devices
on the network due to being able to get other local addresses via ipv6
LL traffic, ND and all that.  There are multiple references to this on
the web which I'm not going to going to go to the effort of looking up
right now, but they exist and the problem is real.

You also don't acknowledge that many hosts are dual-stacked and
compromise via ipv4 is just the same as compromise via ipv6, nor that
there are plenty of other mechanisms which provide name to address
mapping (dynamic dns, etc) or address lists (existing neighbor caches).

So when you have:

- single stack, ipv6 only
- scan + connect worm threat only
- no host level or network level firewalling
- all addresses fully randomised on network
- no other way of guessing addresses
- no way of trapping LL traffic

... it is true that large address spaces with truly random addressing
selection schemes can provide a modicum of security through obscurity.

In pretty much all other situations, long mask lengths with random
addresses have no impact whatever on security.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Jun 2017 07:04:09 -0700

> IIDs are not effective against them.
Right, that's exactly the crux of the argument that the measure is not
worth it. Address randomization is only effective against one form of
attack, but as you point out there are other ways  an attacker can
accomplish the same goal of discovery. It might be worth it if we got
this mechanism for free, but dedicating half of the bits in the IP
address space to this one deterrent for a single narrow attack vector
is too high a price.

Tom

---

From: Philip Homburg <[email-masked]>
Date: Wed, 21 Jun 2017 16:31:10 +0200

>address space to this one deterrent for a single narrow attack vector

In the context of SLAAC, if you want your pseudo random IIDs to be essentially
collission free, then you need enough bits that it also protects against
scanning.

DHCPv6 can handle way longer prefixes, so there the trade-off becomes real.

Though it is not clear if we have a better use for those bits. It would
require serious specs and experiments to see how those bits can be used and
how the revised address archtecture interacts with existing assumptions
about IPv6.

---

From: Ca By <[email-masked]>
Date: Wed, 21 Jun 2017 07:55:04 -0700

Acknowledging the state of the world where discussing security in public is
very much needed, yet arch of the conversation here is just about as
muddled as a have anticipated, inline

> - no way of trapping LL traffic
Yes, you have exactly described 56 million of my 70 million mobile users.

Not kidding. And this  proportion of ipv6-only users will grow in my
network and other networks as well.

I understand this is perhaps not a network architecture many are  highly
familiar with, but it has been present to the IETF by several people
several times, it has also been presented in several *NOGs.

I am not saying all the other stuff is going away, but i am saying the
picture you painted is alive and well and growing and benefiting from long
random addresses.

CB

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Jun 2017 16:31:27 +0100

> Yes, you have exactly described 56 million of my 70 million mobile users.

two sides to this:

1. you are describing a specific and - despite the enormous numbers
involved - atypical use case.  When you scale up to those numbers, the
issues and constraints you run into are not typical of the rest of the
world.  I don't get the impression that I'm alone in thinking that the
sort of solutions required to fix the problems that cellular networks
run into with IPv6 assignment are different to the solutions required
for many other categories of ipv6 networks, and suspect that a good deal
of the angst going on in v6ops relates to cellular ipv6 deployment
viewpoints vs non cellular.

2. out of curiosity, i'd be interested to see the output of smart
application of a hash collision algorithm.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jun 2017 00:50:29 +0900

On Thu, Jun 22, 2017 at 12:31 AM, Nick Hilliard <[email-masked]> wrote:

> involved - atypical use case.

I don't see how you can possibly argue that the case is atypical given that
3GPP networks are where the majority of IPv6 hosts are.

I don't get the impression that I'm alone in thinking that the
> the sort of solutions required to fix the problems that cellular networks

On the contrary, the /64-per-host model is so attractive that operators are
starting to use it on non-celluar deployments as well. See
draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects the
current state of a very large public wifi deployment.

> application of a hash collision algorithm.

Collision between what and what? You're looking for one random number in a
sea of 2^64.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Jun 2017 17:01:30 +0100

Lorenzo Colitti wrote:
> I don't see how you can possibly argue that the case is atypical given
> that 3GPP networks are where the majority of IPv6 hosts are.

atypical in terms of the number of deployments, not by host count of
specific deployments.  How many 3GPP networks are there in the world?
How many other network deployments are there in the world?

Once again: the sort of solutions required to fix the problems that
cellular networks run into with IPv6 assignment are different to the
solutions required for many other categories of ipv6 networks.

> On the contrary, the /64-per-host model is so attractive that operators
> are starting to use it on non-celluar deployments as well. See

"a" very large public wifi deployment.

> Collision between what and what? You're looking for one random number in
> a sea of 2^64. 

you're looking at the birthday paradox.  The output from this can be
surprising.

Nick

---

From: Ca By <[email-masked]>
Date: Wed, 21 Jun 2017 09:02:46 -0700

> address space to this one deterrent for a single narrow attack vector
Tom, not worth it to  an ILA booster, perhaps.

TLDR version: As a network operator, the opportunity mitigate (make it more
expensive for a hacker) a portion of the network level attacks is very
"worth it" to network operators.

Allow me to expound on the business and technology death spiral around the
world of host network attack surface mitigation

1.  The state of information security is horrible, especially network
security.  The industry is filled with charlatans using FUD to sell magic
boxes that are a silver bullet against all manner of real and fake
threats.  This is frequently known unified threat management of defense in
depth (TM) (spare me the link to military history)

2.  The most pervasive and invasive form of snake oil is the inline
stateful network firewall that will cloak your domain in invincibility
 from worms such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers
(?) / Snowden (?)  .... and other REAL named scars on our collective
operational memory.

3.   Stateful firewalls, just like NAT, break the e2e principle.  Spare me
the esoteric views about what e2e really means ... Firewalls break real
things, and create the need for ALGs, and ALGs break... other things... and
we get into robustness to fragile downward spiral

4.  Network firewalls are impossible to scale, especially at 10s of
millions of users ... there are technical and money issues.  Yet, various
large firewall vendors  like to pitch to CxOs about terrible threats that
are just around the corner, and only their  firewall can solve it.  What is
a CxO to do?

5.  The brokeness introduced by middle boxes has spun up multiple working
groups and BoFs in the IETF (quic, dots, plus, ideas...) , so firewalls and
related middleboxes remain good for the business of all those involved in
the arms race .

6.  I could provide you a list of public scenarios where network firewalls
as well as end-point security measures have introduce major
vulnerabilities, very often the infosec medicine is worse than the disease,
they made the situation worse.

7.  As a real person in a real network, i have been able to sidestep this
complexity nose dive and grow my network with IPv6 /64 per host. I am hear
to tell that story and how sparse addressing achieves many of the goals of
limiting network viability of a host (make it more expensive for hackers)
while re-instating the e2e principle (make it cheaper for me, and better
for the  internet)

In summary, network level threat mitigation is very expensive because the
network level threats mitigation is hard to do and there is money to be
made by charlatans.  Threats against the network stack are a huge cost to
network operators (wannacry infections are expensive, firewalls are also
expensive -- spare me about how patching is cheaper, you dont always have
that option), while phishing and social engineering remains the real way
hacking gets done.  We are literally posed with (1, 10, 100) millions of
dollars for network firewall gear to match every packet to a permitted
session with DPI (blah blah blah) , or end point protection solution...
mind you both network firewalls and end point solutions introduce very real
 high value vulnerabilities.

---

From: Ca By <[email-masked]>
Date: Wed, 21 Jun 2017 09:18:17 -0700

> you're looking at the birthday paradox.  The output from this can be

Nick,

Dave Plonka has done a some work in this space, and he is uniquely
positioned to have very good data

https://www.akamai.com/us/en/multimedia/documents/technical-publication/entropy-ip-uncovering-structure-in-ipv6-addresses.pdf

"5.6 Predicting IPv6 Client Prefixes
The addresses in the sample client networks (C1-C5)
extensively use pseudo-random interface identifiers, and
thus there is no point in trying to guess the full address."

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jun 2017 01:20:20 +0900

> How many other network deployments are there in the world?

I see. So you're saying that because these networks are very common and
widely used, the practices they use should be less influential less than
ones that are less rarely-used? That argument rings pretty hollow to me.

> solutions required for many other categories of ipv6 networks.

Actually, they very well on other types of networks as well. Certainly if
you decide to deploy on /120 subnets and DHCPv6, then you can't enjoy the
benefits of those solutions (or of IPv6 in general really), but that
doesn't mean that the solutions are different. It just means you chose not
to use them.

> "a" very large public wifi deployment.

I'd suggest that the way to think of it as a model that others will follow,
just like Cameron's network is a model that others have followed.

> you're looking at the birthday paradox.  The output from this can be

You're not looking at the birthday paradox at all. The birthday paradox
would be applicable if you had lots of hosts on the network. Here you only
have one, and given that the IIDs are random (yes, random - not RFC7217. I
can point you at the code if you want), then the chance is one in 2^64 per
attempt.

---

From: Ross Chandler <[email-masked]>
Date: Wed, 21 Jun 2017 17:52:43 +0100

> On 21 Jun 2017, at 17:01, Nick Hilliard <[email-masked]> wrote:
> 

There is a very small deployment of it Ireland and I’ve heard of others elsewhere. 

Ross

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Jun 2017 09:57:02 -0700

On Wed, Jun 21, 2017 at 9:02 AM, Ca By <[email-masked]> wrote:
> boxes that are a silver bullet against all manner of real and fake threats.
> This is frequently known unified threat management of defense in depth (TM)
> (spare me the link to military history)
>
> 2.  The most pervasive and invasive form of snake oil is the inline stateful
> network firewall that will cloak your domain in invincibility  from worms
> such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers (?) /
> Snowden (?)  .... and other REAL named scars on our collective operational
> memory.
>
> 4.  Network firewalls are impossible to scale, especially at 10s of millions
> of users ... there are technical and money issues.  Yet, various large
> firewall vendors  like to pitch to CxOs about terrible threats that are just
> around the corner, and only their  firewall can solve it.  What is a CxO to
> do?
>
> as well as end-point security measures have introduce major vulnerabilities,
> very often the infosec medicine is worse than the disease, they made the
> situation worse.
>
> while re-instating the e2e principle (make it cheaper for me, and better for
> the  internet)
>
> network level threats mitigation is hard to do and there is money to be made
> by charlatans.  Threats against the network stack are a huge cost to network
> operators (wannacry infections are expensive, firewalls are also expensive
> -- spare me about how patching is cheaper, you dont always have that
> option), while phishing and social engineering remains the real way hacking
> gets done.  We are literally posed with (1, 10, 100) millions of dollars for
> network firewall gear to match every packet to a permitted session with DPI
> (blah blah blah) , or end point protection solution... mind you both network
> firewalls and end point solutions introduce very real  high value
> vulnerabilities.
>
Ca,

You'll get no argument from me about stateful firewalls being state
oil. But, it's not clear to me that IID randomization isn't expensive
snake oil also.

As I mentioned IP address are sent in the clear, so from a host
perspective, the second we send a packet we need to assume our address
is now known to the whole world. I cannot base a host security model
in the premise that my network provider and every node in the path are
going to keep my address secret. If a host wants secure communications
the only answer right now is to encrypt with a sufficiently strong
key.

Another aspect of security with addresses that is popping up is device
tracking. For instance, if a mobile device always uses the same device
prefix then it's trivial to correlate connections of the device and
possibly even its geo location. This is another motivation for address
obfuscation, but randomizing just the IID portion of an address does
nothing to prevent device tracking. More of the address needs to be
obfuscated. I believe we are going to look at this problem in IDEAS.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Jun 2017 18:31:45 +0100

> ones that are less rarely-used? That argument rings pretty hollow to me.

No, what I'm saying is that the sort of solutions required to fix the
problems that cellular networks run into with IPv6 assignment are
different to the solutions required for many other categories of ipv6
networks.  Say, did I mention that before?

Nick

---

From: Ca By <[email-masked]>
Date: Wed, 21 Jun 2017 12:41:05 -0700

On Wed, Jun 21, 2017 at 9:57 AM, Tom Herbert <[email-masked]> wrote:

> >> >>> There's nothing actually wrong with security by obscurity as a
> defence
> >> >>> in
> >> >>> depth measure.
> >> >>>
> >> >>> If you already prevent ICMPv4 echo requests inbound, you're using
> it.
> >> >>> As are
> threats.
> stateful
> millions
> vulnerabilities,
> for
> made

On-path is a substantial attack surface reduction from the whole world.
Just because it is not perfect , does not make it not useful / valuable.
If fact, in infosec, nothing is perfect. We simply try to implement
features that raise of cost of an attacker being successful.

> the only answer right now is to encrypt with a sufficiently strong

Agreed, encryption is a good tool for maintaining confidentiality of a
message.  This is different from reducing the attack surface / likelihood
of attack / discoverability  of the network stack, which is what  64 bits
of entropy in the lower 64 is about.

> obfuscated. I believe we are going to look at this problem in IDEAS.

Agreed, device tracking may be an issue for some.  In my particular
deployment the first 64 seldom stays with a user for more than 24 hours
since they detach and reattach to the network (move to wifi, lose signal,
...), causing a new first 64 bits to get assigned.  The last 64 bits is
generally pseudo-random.

CB

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Jun 2017 08:13:00 +0300

[...]
> 1. Is header insertion on the fly OK, or is it the work of the devil?

Quite a bit of the discussion about EH insertion wasn't even at this
level, but rather at how the proposal was made: rather than proposing it
as a change to RFC2460, it was trie to be sold as something that could
be done while remaining compliant with RFC2460... eventually getting to
a point in which we were supposed to stall progression of rfc2460bis to
standard until the whole EH insertion thing was cooked.

There were certainly sensible technical objections at some point, but
most of the recent discussion had to do with trying to push this
idea/proposal the wrong way.

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