Subject: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

From: Mark Smith <[email-masked]>
Date: Sat, 3 Jun 2017 13:23:07 +1000

On 3 June 2017 at 00:56, Job Snijders <[email-masked]> wrote:
> Dear Lorenzo,
<snip>
>
>> Please stop trying to make IPv6 be the same as IPv4. That will take
>> away our ability to make the Internet better once IPv4 is gone.
>
> I believe there to be tangible merit in making IPv6 feel and look more
> like IPv4. Perhaps this becomes more apparent when one shifts the
> innovation focus from layer-3 to higher layers.
>
> Making IPv6 look more like IPv4 (for instance through broader adoption
> of DHCPv6 w/ routing options, and classlessness like in IPv4) will
> positively impact IPv6 deployment.
>

I think that's the fundamental agenda here, although perhaps not
realised. It is to devolve IPv6's capabilities and features to the
point where IPv6 isn't really much more than IPv4 with a different
packet format, and so the IPv4 operational practices people are
comfortable with can be directly applied to IPv6 without change. This
is because of the common human trait of intolerance of or resistance
to change.

If this proposal is accepted, then I think /120s will become the
defacto subnet size, despite what the draft says about /64s being the
recommended default. Here's the clue for why - RFC1918 addressed
networks I've seen, where IPv4 address space doesn't need to be
conserved (i.e., unlike public IPv4 address space), always use /24s as
the defacto subnet size. "Same-same" is easier for us humans than
"Same-different."

Why do I have a different perspective? My first networking protocol
was a more modern one than IPv4, Novell's IPX, derived from Xerox's
XNS. Learning and operating IPv4 networks after operating IPX networks
was a backwards step. The only major advantage that IPv4 provided over
protocols designed in the 1980s and 1990s, such as IPX, Appletalk and
CLNS, was that it provided organisations with Internet connectivity.
On many other criteria, IPv4 was far inferior - entirely
understandable, because it was fundamentally designed in the 1970s,
and then adapted over time to cope with being used to build a global
Internet work. It was never intended to be used to build a global
internetwork connecting billions of devices -

https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

IPv6 is actually the first true protocol designed to suit the global
"Internet" problem.

I have a few horrible stories of seeing IPv4 routers with 4 x /24s or
25 x /26s on the same interface because renumbering and changing
subnet masks of hosts into a single large enough subnet was more far
expensive than sub-optimal forwarding across the same link. An
impossible problem to have when the default subnet address space size
far exceeds the practical link-layer node attachment limits (and in
some cases impractical link-layer limits because of link layer
"excessive" addressing - does an Ethernet really need 48 bit MAC
addresses? Who's going to go close to attaching 2^46 nodes to one of
them? The ND cache resource exhaustion type of problem also exists at
layer 2 with switch tables ...)

I don't want to experience or see people experience those sorts of
IPv4 "right-sizing subnet" types of problems in IPv6.

Regards,
Mark.

---

From: Chris Morrow <[email-masked]>
Date: Fri, 2 Jun 2017 23:48:20 -0400

please read david farmer's message.​ really I think he's on point here.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 13:14:26 +0900

What he said.

---

From: David Conrad <[email-masked]>
Date: Sat, 3 Jun 2017 09:29:38 +0300

> is because of the common human trait of intolerance of or resistance

In most large scale environments, change of "operational practices" implies cost. In this context, I believe there is a perception that the additional cost is for minimal benefit -- customers don't care (and are unwilling to pay a differential) if their cat pictures come over IPv4 or IPv6. As such, the resistance here is more about not wanting to spend more money than it is some sort of psychological roadblock associated with a common human trait.

Regards,
-drc

---

From: Simon Hobson <[email-masked]>
Date: Sat, 3 Jun 2017 11:45:13 +0100

> is because of the common human trait of intolerance of or resistance

I think that's over stating it a bit.
Part of "the problem" with IPv6 is (as David Conrad says) that it's "too different" and that means a lot of unlearning and relearning - and that implies cost. In an environment where the majority still see no problem because "it's OK, NAT works" then cost is a difficult thing to get people to buy into.

I see the point in fixing stuff that people don't realise is broken - but the risk is that people see that "it's too complicated" and "they're changing stuff for the sake of change" - and resist adopting it". I've heard both these criticisms.

> the defacto subnet size. "Same-same" is easier for us humans than

I've worked with different sized subnets.
But I do see your point, I've come across lots of situations where "nothing exists other than a /24" seems to have been the mindset. In one case, I recall a Netgear router refusing to allow a valid IP4 address in one GUI page because of an assumption of "/24 everywhere" that made it a network address. And another model of router that did not support any subnet size greater than /24. and ...
And at my previous employer, I recall being involved in a project to link all the businesses together with one global WAN (we were one of a couple of dozen companies in the group). It was soon clear to me that I was working with "professional IT people" who could not grasp the concept that 172.16.1.1/23 was not in the range of ".1 to .10 reserved for routers" in their addressing plan - and nor could they see that ".1-.10, .11-.30, and so on" wasn't an easy addressing plan to work with in terms of filtering traffic for diagnostic purposes !
That was dealing with people who did IT at a sufficiently high level that they should not have had any excuse. In the general case, once you get outside of large corporates, the level of skill is much much lower - to the extent that I have to wonder just how on earth some of these people can call themselves IT professionals. Down to the level of knowledge where it comes down to "if the plug physically fits in the socket then it should just work, right ?"

ISPs colour code the sockets and cables with their routers for a reason. They NEED to be able to say "use the YELLOW cable, and plug it into the YELLOW socket ..." or customers simply won't be able to connect stuff properly. I've had people plug a phone (RJ11) plug into a network port (RJ45) and express surprise that it doesn't do anything !

> Internet work.

I cut my first networking teeth with AppleTalk. I can still just about remember how easy it was - and how darned complicated that IP stuff was back then.

> expensive than sub-optimal forwarding across the same link.

You've explained that in one - the cost of renumbering. At work I want to renumber our office LAN, since being 192.168.1.0/24 it clashes with so many customer LANs which causes issues when using VPNs (and ditto for a couple of the clients as well who have the same issue). It's not happened because of the cost involved - all those IP addresses (often uneditable) embedded in systems - not least, the IP Port printers configured on Windows desktops.

> does an Ethernet really need 48 bit MAC addresses? Who's going to go close to attaching 2^46 nodes to one of
> them?

I suspect you already know the answer to that already. No, no-one is going to connect more than a few thousand nodes to one network, but if you don't have globally unique MAC addresses, how can you guarantee local uniqueness while still providing a stable interface identifier ?

I assume you have never had to diagnose a problem with duplicate MAC addresses ? I haven't personally, but I've heard first hand from a friend who has ! He was managing a university site, and they bought a batch of new desktops for a refresh. Turns out that Dell had a provisioning system bug while meant that there were MAC address duplicates - every 256 block of addresses got allocated to 257 machines (ie one address got duplicated).
Normally, this is unlikely to be a problem - not many customers buy more than 256 machines in one batch, and few of those will put them on one segment. But this university did, and they found the bug - eventually !

> In most large scale environments, change of "operational practices" implies cost. In this context, I believe there is a perception that the additional cost is for minimal benefit -- customers don't…

Indeed.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Jun 2017 15:15:52 +0200

On Jun 3, 2017, at 12:45, Simon Hobson <[email-masked]> wrote:
> 
> unlearning and relearning

Reminds me of the story where a kid learns how to roast a duck and the mother explains that to roast a duck, you have to cut off a bit at the ends before roasting.  Kid asked ma why, and she didn’t know; her grandma had always told her so.  Long story compressed, it turned out grand-grandma had an oven that was too short for a whole duck, and the cutting routine survived through the family even though today’s ovens are larger.

But the whole discussion here is backwards, because we stopped cutting our ducks a long time ago.
Changing the established IPv6 operational practices so they look more like duck-cutting for IPv4 doesn’t make sense.

Grüße, Carsten

---

From: Job Snijders <[email-masked]>
Date: Sat, 3 Jun 2017 17:25:00 +0200

On Sat, Jun 03, 2017 at 03:15:52PM +0200, Carsten Bormann wrote:
> Reminds me of the story where a kid learns how to roast a duck and the
> mother explains that to roast a duck, you have to cut off a bit at the
> ends before roasting.  Kid asked ma why, and she didn’t know; her
> grandma had always told her so.  Long story compressed, it turned out
> grand-grandma had an oven that was too short for a whole duck, and the
> cutting routine survived through the family even though today’s ovens
> are larger.
> 
> But the whole discussion here is backwards, because we stopped cutting
> our ducks a long time ago.  Changing the established IPv6 operational
> practices so they look more like duck-cutting for IPv4 doesn’t make
> sense.

I too have a story: Snow White and the Seven Dwarfs. The fairy tale's
lesson is that it's OK to make mistakes; just make sure you learn from
them.

When the wicked step-mother offered Snow White the silver IP protocol
for her corset, Snow White quickly realised it was a mistake when it
magically tightened at the /64 boundary, restricting her breathing.
Luckily Grumpy [draft-bourbaki-6man-classless-ipv6] got scissors and was
able to cut the laces. The color quickly came back to Snow White's face.

However, it should be noted that Snow White still bought the poison
apple the following day! So let's not be like Snow White.

Back to the topic: Nobody is talking about deprecation of IPv6, it is
insincere to pretend we are. We're improving an aspect of the
specification to further the adoption and deployment of IPv6.

Kind regards,

Job

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 3 Jun 2017 19:54:31 +0200

totaly agree - but look at the world today, all the proposals over the
years, operators don't care, they have their well known IPv4 world,
all they lack is more address and IPv6 provide that.

--- Roger J ---

On Sat, Jun 3, 2017 at 5:23 AM, Mark Smith <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Jun 2017 08:43:31 +1200

On 03/06/2017 15:23, Mark Smith wrote:
...
> recommended default. 

Predicting the future of complex systems is hard, but I think this
prediction is wrong. There are some very strong arguments against
prefixes that long, and it is the IPv6-over-foo specs that prevent
such long prefixes being used.

The IPv6 routing architecture has always been CIDRised. Please
remember that "ID" in CIDR stands for "inter-domain". So there
is nothing new there; even BCP198 was nothing new.

IMNSHO we made a basic mistake by including the value of n in the addressing
architecture.

That's the n in
>    |          n bits               |           128-n bits            |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+

All this draft really does is observe that n is a parameter. It could
be said in many fewer words, I suppose.

If we'd been able to agree on simply removing n=64 from 4291bis,
I wouldn't have put my name on this draft.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Jun 2017 08:56:02 +1200

> Changing the established IPv6 operational practices so they look more like duck-cutting for IPv4 doesn’t make sense.

Indeed not. But we might well want to change IPv6 operational practices to meet future requirements, and having a magic boundary prevents that. Having a parameter n that can be modified at some point in the future gives us a more flexible duck.

BTW exactly the same story was in the NZ Herald newspaper a few days ago, but the victim was a leg of lamb.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 4 Jun 2017 13:50:54 +1000

Hi Brian,

On 4 June 2017 at 06:43, Brian E Carpenter <[email-masked]> wrote:
> prediction is wrong.

Thinking about it more, I'll lessen that - I think this draft
increases the likelihood of it occurring.

If you know IPv4, and you don't want to or don't have time to properly
learn IPv6 (which seems to be one of the motivations for this draft),
then here is the easiest way to deploy IPv6 without understanding
IPv6:

1. Take your IPv4 address in IPv4 format, leveraging your existing
IPv4 addressing plan
2. Prepend it with the IPv6 GUA or ULA 96 bit prefix
3. Subtract the IPv4 host bits from 128 and append

e.g., the resulting IPv6 addresses for 1.2.3.4/24 would be

2001:db8::1.2.3.4/120

That format address is accepted on loopback when I use the Linux 'ip'
and 'ifconfig' utilities and I can ping it, so it has passed the first
"can I even configure it" test. If it works on other IPv6
implementations, this way of deploying IPv6 while avoiding learning
IPv6 could easily become popular because of its simplicity.

> There are some very strong arguments against

I agree, however I don't think this draft is discussing and
emphasising them enough.

For example, here is how I interpret a piece of the text in the
Recommendations section (which is going to be the section people in a
hurry will jump to)

"For historical reasons, when a prefix is needed on a link, barring
   other considerations, a /64 is recommended [RFC7136]."

"For historical reasons" implies the only reason to continue with /64s
is tradition, as though the situation has changed so much such that
all of the past reasons for having /64s/64 bit IIDs now don't apply.

"barring
   other considerations"

That might seem to be the warning to make sure you understand the
decision you're making, however there is no brief description or
reference to those considerations. Initially I thought RFC7136 was the
"why-64" RFC you and others put together, which does outline those
sorts of considerations in a 64 bit IID context, however that is
RFC7421. RFC7421 isn't referenced by this proposal anywhere, yet it is
the key document that describes many things about 64 bit IIDs and
their benefits as well as mentioning some of their drawbacks.

The next paragraph text is further narrowing the scope of advice to
just SLAAC. What about address assignment via stateful DHCPv6? Do
general privacy and security concerns about IPv6 addresses go away
entirely if stateful DHCPv6 is used?

(Actually, stateful DHCPv6 can introduce them - OpenWRT supports it
and uses the same sized IID range for DHCPv6 as it does for DHCPv4
addresses. Until I recently worked out how to turn it off (because
that isn't obvious either), my Fedora hosts with wonderful RFC4941 and
EUi-64 global addresses via SLAAC also had global IPv6 stateful DHCPv6
addresses from within a range of 100 addresses.)

Another example is in the Security Considerations section:

"Assuming that nodes employ unpredictable interface identifiers
   [RFC7721], the subnet size may have an impact on some security and
   privacy properties of a network.  Namely, the smaller the subnet
   size, the more feasible it becomes to perform IPv6 address scans
   [RFC7707] [RFC7721].  For some specific subnets, such as point to
   point links, this may be less of an issue."

This paragraph leads with a broad statement about security and privacy
concerns, of which there are more than one as detailed in RFC7421, and
then dismisses them all ("Namely,")  to only describe the one threat
of unsolicited inbound address probes.

What about host or end-user security and privacy impacts when RFC4941
temporary address and RFC7217 stable opaque addresses operate with
much smaller IIDs, or a caution against using IIDs smaller than e.g.,
48 bits if end-users are to have RFC4941 addresses? These issues now
need to be addressed because of they're all based on assumption of 64
bit IIDs.

I think I can summarise the situation, and this draft and my view on it:

- RFC4291, although not using RFC2119 capitalised words, is saying
that IIDs MUST be 64 bits other than addresses that start with 000.
Some people are objecting to the MUST.

- This draft is commonly leading with text that reads or can easily be
interpreted that this 64 bit MUST is being turned into a MAY on nearly
equal terms with any other prefix length e.g., the Recommendations
text above. I find further following advice in the text to understand
the consequences of doing so is somewhat casual, and doesn't spend
much time explaining and doesn't reference what those consequences and
considerations are.

- I don't think the "default" recommendation is strong enough. I read
the default recommendation (in the Recommendations section) here to be
saying something close to, "If you've read the text and don't already
have chosen size, use a /64", because of use of soft expressions such
as "For historical reasons". It reads like the fallback advice if you
reach a point where you don't already have a preferred or chosen
answer you're happy with (like,"I'll use that simple IPv4 to IPv6
scheme Mark Smith wrote about that saves me properly learning IPv6.").

- If the /64 isn't going to be a MUST, I think /64 needs to be a
universal SHOULD level and better emphasised at that level because of
the code, privacy, security, etc. reasons that are well known and
described in RFC7421. The text is currently reading more that its
perspective and position is that a /64 is a MAY with some minor
cautions due to either casual text or omission.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 12:38:07 +0900

> such long prefixes being used.

None of which the people deploying /120s will understand or even be aware
of. Seriously: I've seen premier-grade IT departments - even in
well-funded, very technical companies with a very high hiring bar - deploy
NAT66 in their corporate networks without understanding that it would break
applications.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 12:43:17 +0900

> IPv6 could easily become popular because of its simplicity.

Exactly. Realistically, the only reason this is not a widespread practice
is that some OSes do not support DHCPv6.

> addresses from within a range of 100 addresses.)

That sounds *really* bad for privacy and security. With end-to-end
connectivity, it's trivial to scan the first 255 addresses and find all
hosts on the subnet very quickly. Steven, are you the DHCPv6 maintainer for
openwrt? Were you aware of this?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Jun 2017 16:13:31 +1200

> NAT66 in their corporate networks without understanding that it would break

I don't doubt it. But nothing today stops them using DHCPv6 exclusively
and deploying /120s - just too bad for any users of an o/s that doesn't
support DHCPv6, right?

I don't mean I like this. Actually I see no reason today to deploy
anything other than /64. I just want to see a correct architectural
description of what we have.

    Brian

---

From: Matthew Petach <[email-masked]>
Date: Sun, 4 Jun 2017 21:57:17 -0700

Many of the arguments against this draft seem to
be of the form "this is bad because it might allow
uninformed people to make bad decisions which
could have bad outcomes."  I find this line of reasoning
to be somewhat disturbing.

Imagine, if you will, early man, out hunting for food
using his typical tool, a blunt club.  Along comes Thag,
with a sharpened stick, ready to join the hunt.  Early
man looks at it and says "wait...that looks dangerous;
someone could use that the wrong way, and hurt
themselves, or potentially hurt me.  Rather than
take that risk, and potentially learn new, more
efficient ways of getting food, let's just ban it
now, before anyone gets any new ideas."
We could still be out on the plains, beating
our meat with blunt clubs instead of learning
new ways of hunting.  We shouldn't fear progress,
even if it comes with a few roadbumps and bruises.

This draft isn't saying you *have* to use a bit boundary
other than /64; it's simply saying you have the *option*
to do so, if you like.  It's giving people the flexibility to
try new combinations out; some of them may be ill-advised;
a few warriors may come back with one less limb, having
discovered the _pointy_ end goes towards the prey.  But
on the whole, the potential for advancement would seem
to outweigh the risks of people maybe doing something
stupid here and there.

I support this draft for its ability to look beyond the
classful box, to a world in which creative new possibilities
open up before us, enabling new and unusual addressing
models and the potential for discovering new network
topologies we'd never considered before.
We shouldn't let ourselves be ruled by the fear of what
someone *might* do, and hold ourselves back from the
chance to progress and expand outside of our current
box.

Let's bring innovation back to the Internet.

Thanks!

Matt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 5 Jun 2017 08:35:25 +0200 (CEST)

On Sun, 4 Jun 2017, Brian E Carpenter wrote:

> If we'd been able to agree on simply removing n=64 from 4291bis, I 
> wouldn't have put my name on this draft.

My take on this (and I don't think I am alone) is that this is a slippery 
slope down to where when I in 10 years connect to a wifi, I'll get an RA 
with PIO /128 with A=1, because the ISP decided they only wanted devices 
have single address, because that's what the product people wanted 
because then people wouldn't be able to have more than a single device per 
subscription (which is false, but some people believe this can be 
achieved).

Down that /128 path leads NAT66 and all kinds of complexity to work around 
these problems, and we'll have gained very little by introducting IPv6.

I am totally fine in Job statically configures his devices with /126:es, 
but how do we make sure that device/applicaton developers don't have to 
spend a lot of time in the future handling NAT66 traversal and hiding 
multiple services behind a single address?

I don't believe in people saying that the IETF is powerless to stop this. 
We have technical means to at least make it a lot harder for people to get 
away with that.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 15:46:38 +0900

> and deploying /120s - just too bad for any users of an o/s that doesn't

Today there's little penalty, because those users will be IPv4-only and
still have connectivity. Not sure what they would decide when they start
thinking about turning off IPv4. I suppose it would depend on how many of
their users use OSes that don't support DHCPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 15:59:43 +0900

On Mon, Jun 5, 2017 at 1:57 PM, Matthew Petach <[email-masked]>
wrote:

> Along comes Thag,
> now, before anyone gets any new ideas.

While we're in the realm of not-directly-applicable analogies, would note
that if you substitute "sharpened stick" for "rocket launcher" most people
would agree that they should be banned.

> to do so, if you like.

You have this option today. As Job will tell you, you can manually
configure a /117 and it will work on pretty much any implementation. What
you don't have are the ability to claim that others should support your
/117 network, and the ability to define automatic configuration mechanisms
for your /117 network.

---

From: Randy Bush <[email-masked]>
Date: Mon, 05 Jun 2017 14:21:21 +0600

sorry, but i have neither time, energy, ... to talk about pointed
sticks, horrible things which stupid people might do (which they can
do today anyway), and other hyperbole.  i am just trying to deal with
the reality of running networks.  and i will admit to being biased to
the opinions of those who actually run networks.  so can we focus on
the actual document?  in particular

---

4.  Recommendations

   For historical reasons, when a prefix is needed on a link, barring
   other considerations, a /64 is recommended [RFC7136].

   The length of the Interface Identifier in Stateless Address
   Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
   sufficient for effective randomization for privacy reasons.  For
   example, a /48 might be sufficient.  But operationally we recommend,
   barring strong considerations to the contrary, using 64-bits for
   SLAAC in order not to discover bugs where 64 was hard-coded, and to
   favor portability of devices and operating systems.

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identfier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hardcoded value.

---

the above are actual reality today; the draft just tries to clarify
subtle confusions caused by existing and proposed ipv6 addressing
documents.  as the draft says, this is to prevernt mismatches between

   formal specification and long-standing field deployment practices are
   never wise, not least because of the strong risk of mis-
   implementation, which can easily result in serious operational
   problems.

in talking to operators here, at home, and ripe, i heard some desire
to say something to clarify that /128s (or /80s or whatever) to end
sites/customers etc. are not being recommended.  can we do this
without overly-prescribing how operators run their networks or
stepping into the RIR allocation policy swamp?

randy

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 05 Jun 2017 11:20:47 +0200 (CEST)

Hi,

a tangential remark related to the wording in the draft:

>    example, a /48 might be sufficient.

I think the "a /48 might be sufficient" part is not the best way
to express it.  When you talk about a /48 in IPv6, that's usually
interpreted to correspond to an address space which contains 2^16
/64s.

Suggestions for other ways of expressing what I think is intended
would be "For example, a 48 bit long suffix might be sufficient"
or "For exmple, 48 bits of address space might be sufficient".

Regards,

- Håvard

---

From: Randy Bush <[email-masked]>
Date: Mon, 05 Jun 2017 15:28:03 +0600

hi havard,

> a tangential remark related to the wording in the draft:

i would not call actually talking about the draft's wording to
tangential. :)

> or "For exmple, 48 bits of address space might be sufficient".

thanks for actually suggesting useful text.  beat us up if something
reasonable addressing this is in not the next version.

randy

---

From: james woodyatt <[email-masked]>
Date: Mon, 5 Jun 2017 11:47:46 -0700

On Jun 4, 2017, at 23:35, Mikael Abrahamsson <[email-masked]> wrote:
>> If we'd been able to agree on simply removing n=64 from 4291bis, I wouldn't have put my name on this draft.
> 
> My take on this (and I don't think I am alone) is that this is a slippery slope down to where when I in 10 years connect to a wifi, I'll get an RA with PIO /128 with A=1, because the ISP decided they only wanted devices have single address, because that's what the product people wanted because then people wouldn't be able to have more than a single device per subscription (which is false, but some people believe this can be achieved).
> 
> Down that /128 path leads NAT66 and all kinds of complexity to work around these problems, and we'll have gained very little by introducting IPv6.

Now is as good a time as any to repeat that I’m working on delivering *basically* this now. Not in ten years. Now.

The only difference between what I’m working on now and what Mikael describes is that I’m dealing with the situation where I’m a 6LoWPAN border router connecting to a home Wi-Fi™ LAN segment, and I can’t get a DHCPv6 prefix because either a) the router isn’t capable of DHCPv6-PD as RFC 7084 recommends, b) the router doesn’t have any more subnet prefixes to delegate (because other routers have consumed them all, usually by cascading one or more RFC 7084 routers behind the ISP border), or c) the router will never have enough subnet prefixes to delegate because the ISP didn’t delegate the CPE border router enough space.

We are already on the path to IPv6/NAT w/ address amplification. We had a chance to stop it, and we blew it. It’s time to move on from that mistake.

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

---

From: Erik Kline <[email-masked]>
Date: Tue, 6 Jun 2017 12:57:27 +0900

On 6 June 2017 at 03:47, james woodyatt <[email-masked]> wrote:

> have single address, because that's what the product people wanted because
> then people wouldn't be able to have more than a single device per
> subscription (which is false, but some people believe this can be achieved).
>
> Now is as good a time as any to repeat that I’m working on delivering
> *basically* this now. Not in ten years. Now.
>
> The only difference between what I’m working on now and what Mikael
> describes is that I’m dealing with the situation where I’m a 6LoWPAN border
> router connecting to a home Wi-Fi™ LAN segment, and I can’t get a DHCPv6
> prefix because either a) the router isn’t capable of DHCPv6-PD as RFC 7084
> recommends, b) the router doesn’t have any more subnet prefixes to delegate
> (because other routers have consumed them all, usually by cascading one or
> more RFC 7084 routers behind the ISP border), or c) the router will never
> have enough subnet prefixes to delegate because the ISP didn’t delegate the
> CPE border router enough space.
>
> We are already on the path to IPv6/NAT w/ address amplification. We had a
> chance to stop it, and we blew it. It’s time to move on from that mistake.
>

Consider ND proxy or application/CoAP proxying.

We are in fact missing some APIs on host operating systems whereby
userspace can request the kernel to get an address for its use.  This would
be the companion piece to 7934's recommendations.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Jun 2017 14:09:20 +0900

> *basically* this now. Not in ten years. Now.

Here's a solution that works now: ND proxying.

OpenWRT has had code to do it for a few years now. IIRC they're on to their
second implementation, the first one was here
<https://wiki.openwrt.org/doc/uci/6relayd>.

IIRC when I wrote my own proof-of-concept implementation it wasn't too
hard. It's particularly easy when you don't need to support autoconf on the
southbound interface, which you presumably don't need to support since
6LoWPAN has IPv6 addresses that are known in advance. AIUI this is similar
to what the Android on ChromeOS does: the Android code runs in a separate
namespace (equivalent role to the 6LoWPAN network), and gets an IPv6
address. There's a daemon on the root namespace (equivalent role to the BR)
runs ND proxy for that address. That code may be open sourced under a
license that would allow you to use it as is.

Running ND proxying on Linux is pretty easy even without writing any packet
handling code using the IPV6_JOIN_ANYCAST socket option. Apache licensed
code (running on production Android devices) is here
<https://android.googlesource.com/platform/external/android-clat/+/master/setif.c>,
look for do_anycast_setsockopt.

> chance to stop it, and we blew it. It’s time to move on from that mistake.

You may be on that path at the moment, but I don't think you were obliged
to take it. You could have (and maybe still can) implement ND proxying.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 11:25:06 +0200

Le 06/06/2017 à 07:09, Lorenzo Colitti a écrit :
> On Tue, Jun 6, 2017 at 3:47 AM, james woodyatt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Now is as good a time as any to repeat that I’m working on
>     delivering *basically* this now. Not in ten years. Now.
>
>

But it's EXPERIMENTAL.  And the technique does not scale.

Alex

>
> OpenWRT has had code to do it for a few years now. IIRC they're on to
> their second implementation, the first one was here
> hard. It's particularly easy when you don't need to support autoconf on
> the southbound interface, which you presumably don't need to support
> since 6LoWPAN has IPv6 addresses that are known in advance. AIUI this is
> similar to what the Android on ChromeOS does: the Android code runs in a
> separate namespace (equivalent role to the 6LoWPAN network), and gets an
> IPv6 address. There's a daemon on the root namespace (equivalent role to
> the BR) runs ND proxy for that address. That code may be open sourced
> under a license that would allow you to use it as is.
>
> Running ND proxying on Linux is pretty easy even without writing any
> packet handling code using the IPV6_JOIN_ANYCAST socket option. Apache
> licensed code (running on production Android devices) is here
>     We are already on the path to IPv6/NAT w/ address amplification. We
>     had a chance to stop it, and we blew it. It’s time to move on from
>     that mistake.
>
>
> You may be on that path at the moment, but I don't think you were
> obliged to take it. You could have (and maybe still can) implement ND
> proxying.
>
>

---

From: james woodyatt <[email-masked]>
Date: Tue, 6 Jun 2017 12:06:02 -0700

On Jun 5, 2017, at 20:57, Erik Kline <[email-masked]> wrote:
> On 6 June 2017 at 03:47, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Now is as good a time as any to repeat that I’m working on delivering *basically* this now. Not in ten years. Now. […]We are already on the path to IPv6/NAT w/ address amplification. We had a chance to stop it, and we blew it. It’s time to move on from that mistake.
> 

p1. Power conservative ND Proxy isn’t possible with Thread™ 1.1 (and earlier) networks. It may never be possible in future versions of Thread™.

p2. Thread™ is not an application layer. It is an IPv6 mesh network layer. There is no single application layer to proxy.

The war against IPv6/NAT is over. It’s time to go home and nurse our wounds.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Jun 2017 17:53:30 +0900

On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt <[email-masked]> wrote:
>
> p1. Power conservative ND Proxy isn’t possible with Thread™ 1.1 (and
> earlier) networks. It may never be possible in future versions of Thread™.
>

Can you explain to us why it doesn't work? One might naively think that if
the BR is doing NAT for hosts behind it, it has to process a similar
packets as it would have to process if it were doing ND.

---

From: [email-masked]
Date: Wed, 7 Jun 2017 11:43:56 +0200

> Let's bring innovation back to the Internet.

I believe that innovation in the IP layer hinders innovation other places in the stack (aka the Internet).
A core principle of the Internet architecture is to keep the waist of the hourglass/wineglass narrow to allow for Innovation above and below.

Best regards,
Ole

---

From: "Leddy, John" <[email-masked]>
Date: Wed, 7 Jun 2017 10:44:50 +0000

Innovation at the Network layer created the Internet.
Innovation at the Network layer has let it grow to the point it is at – including things we may not like, ex. NAT.
The Internet leveraged/adopted/re-architected innovation at the Network layer that occurred even outside of IP – all the other Networking protocols that existed – Appletalk, XNS/Banyan Vines, DECnet…

Without the innovation, we’d still be talking about SONET, X.25, ATM, FrameRelay – very narrow hourglasses/wineglasses.

How narrow of a waist spurs innovation at the layers above and below the Network layer?  
Should we regress in order to spur even more innovation?  
Perhaps IP itself limits innovation at the layers above and below IP?  Ex. Dual Stack – a difficult migration and operational state.

There are “no” Network protocols other than IP today – it is very hard to justify innovation outside of IP and IPV6 is the only platform where change is even possible and worth the effort.  It takes too long and migrations are expensive.

When there was a soup of networking protocols and no clear consensus about how Networking consolidates around a standard set of protocols for systems to communicate – “A core principle of the Internet architecture is to keep the waist of the hourglass/wineglass narrow” - because ubiquity was a major goal.  IP itself was the Major Innovation.

I don’t think there is a basis to say that that principle is correct in today’s Internet, my belief.

John Leddy

    
    
    Best regards,
    Ole

---

From: [email-masked]
Date: Wed, 7 Jun 2017 13:35:49 +0200

John,

> I don’t think there is a basis to say that that principle is correct in today’s Internet, my belief.

Of course both of us are paid to put smarts into the network layer (:-)), but if you look at it from an Internet-wide perspective, can you name any innovations at the network layer that has been successful?

- IP multicast -> fail
- IPsec -> fail
- Mobile IP -> fail
- Fragmentation -> partly fail
- Path MTU discovery -> partly fail

The only thing I can think of are the various forms of tunnelling that are a raging successes.
And NAT. I guess you can say that the network layer's territorial dispute with the transport layer, where network has permanently occupied the first 8 bytes of the transport header have been successful.

The network layer is the only thing ubiquitous among all nodes on the Internet. Thereby making incredibly difficult to change.

The fact that you have near infinite address space does perhaps allow for innovation.
Some good some horrid. E.g. semantic addresses (put the MTU value in the address), or giving individual chunks in a video individual addresses. But the address space is part of the tussle. Where we as a community has decided that the left-most 64 bits are given to the network and the rightmost 64 bits are given to the hosts. Both groups are going to invent stuff that requires more than 64 bits for themselves. If the IETF decided to reset the playing field and withdraw from participating setting the ground rules. Where would that tussle play out?

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 7 Jun 2017 08:03:03 -0700

> - Path MTU discovery -> partly fail
Ole,

If you look at it from a protocol perspective the above are
successful. Several of these are productively used in private networks
some of which are quite large. The fact that multicast of extension
headers aren't usable in the Internet is no justification to remove
them from the protocol.

> The fact that you have near infinite address space does perhaps allow for innovation.

I would hardly call 2^128 infinite and certainly wouldn't call 2^64
infinite. Like any numbering space it's likely the hierarchical
divisions will exhaust the space long before the number of actual
addressed objects hits the maximum.

Tom

---

From: james woodyatt <[email-masked]>
Date: Wed, 7 Jun 2017 11:41:23 -0700

On Jun 7, 2017, at 01:53, Lorenzo Colitti <[email-masked]> wrote:
> On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> Can you explain to us why it doesn't work? One might naively think that if the BR is doing NAT for hosts behind it, it has to process a similar packets as it would have to process if it were doing ND.

Thread™ 1.1 doesn’t even use RFC 4861 much less RFC 6775. A proxy for RFC 4861 at the Thread™ 1.1 border router would require DAD and NUD to be translated into prohibitively expensive multicast floods into the mesh. Use of IPv6/NAT allows the border router to make an entire Thread™ mesh reach the public Internet via the one stable IPv6 address that is reliably available on all residential networks with IPv6 providers.

For years, we have been hoping that HOMENET would address the basic problem here, but now that it's clear the forthcoming update to RFC 7084 will not recommend adoption of the HOMENET protocol suite in IPv6 CPE residential gateways, Thread™ has no other option than to recommend IPv6/NAT to cope with operational reality.

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Jun 2017 12:41:32 -0700

I'm struggling here. Thread is one adaptation of 6LowPAN etc; OCF (formerly OIC) describes and network "on IPv6" and treats 6LowPAN as an encoding of IPv6. For reasons that remain inscrutable to me, Thread acts as if the only link layer in the world were IEEE 802.15.4; OCF is extensible to (gasp) Ethernet, 802.11, ITU G.hn/G.9960 or IEEE 1901, and whatever else.

IPv6, and 6LowPAN, is the dog. The industry associations that use them are the tail. Why is the tail wagging the dog?

https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/thread_overview/
https://workspace.openconnectivity.org/apps/org/workgroup/technology_sc_open/download.php/8950/Technology-Discussion-v3.pptx

On Jun 7, 2017, at 11:41 AM, james woodyatt <[email-masked]> wrote:
> --james woodyatt <[email-masked]>
> 
> 
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 7 Jun 2017 13:21:21 -0700

On Jun 7, 2017, at 12:41, Fred Baker <[email-masked]> wrote:
> 
> Thread is one adaptation of 6LowPAN etc; OCF (formerly OIC) describes and network "on IPv6" and treats 6LowPAN as an encoding of IPv6.

See "OCF Will Run Over Thread" <https://www.infoq.com/news/2016/07/ocf-thread <https://www.infoq.com/news/2016/07/ocf-thread>>. They’re not operating at comparable levels in the stack.

> The industry associations that use them are the tail. Why is the tail wagging the dog?

I see no dogs wagging. From my perspective, I see a wagging tail on a dog that doesn’t even know it has one.

---

From: james woodyatt <[email-masked]>
Date: Wed, 7 Jun 2017 13:43:03 -0700

> I see no dogs wagging. From my perspective, I see a wagging tail on a dog that doesn’t even know it has one.

Furthermore, I should clarify that I’m taking no position whatsoever against what I view to be an effort to update IPv6 Address Assignment to End Sites [RFC 6177] to drop the following reaffirmation on page 3:

      A key principle for address management is that end sites always be
      able to obtain a reasonable amount of address space for their
      actual and planned usage, and over time ranges specified in years
      rather than just months.  In practice, that means at least one
      /64, and in most cases significantly more.  One particular
      situation that must be avoided is having an end site feel
      compelled to use IPv6-to-IPv6 Network Address Translation or other
      burdensome address conservation techniques because it could not
      get sufficient address space.

I no longer feel this must be avoided. It’s too late to stop that from happening. It now seems perfectly acceptable that end sites should feel compelling to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it cannot get sufficient address space.

---

From: Ca By <[email-masked]>
Date: Wed, 07 Jun 2017 22:41:18 +0000

On Wed, Jun 7, 2017 at 1:43 PM james woodyatt <[email-masked]> wrote:

> Furthermore, I should clarify that I’m taking no position whatsoever
> against what I view to be an effort to update IPv6 Address Assignment to
> End Sites [RFC 6177] to drop the following reaffirmation on page 3:
>
> I no longer feel this must be avoided. It’s too late to stop that from
> happening. It now seems perfectly acceptable that end sites should feel
> compelling to use IPv6-to-IPv6 Network Address Translation or other
> burdensome address conservation techniques because it cannot get sufficient
> address space.
>

I am unfamiliar with thread () in the real world and don't yet feel
compelled to believe a widely deployed ietf standards track specifications
should bend due some niche design choices that may or may not achieve a
significant deployment.

Thread () makes design choices and they deal with them.  Same for ietf.

I believe i am agreeing with Fred

---

From: james woodyatt <[email-masked]>
Date: Wed, 7 Jun 2017 16:42:12 -0700

On Jun 7, 2017, at 15:41, Ca By <[email-masked]> wrote:
> 
> I am unfamiliar with thread () in the real world and don't yet feel compelled to believe a widely deployed ietf standards track specifications should bend due some niche design choices that may or may not achieve a significant deployment. 

As far as I know, nobody associated with Thread™ apart from me is even listening to IETF much less offering anything to say. And the only thing I’m saying is that IETF should stop pretending that IPv6/NAT in end site addressing plans is preventable. It’s inevitable.

I’m not asking IETF to bend its standards accordingly. I’m actually expecting that IETF will not bend, and that it will continue promoting standards that leave end sites compelled to use IPv6-to-IPv6 Network Address Translation to conserve address space (despite the contrary statement in RFC 6177). The only thing I would prefer to see here is for 6MAN discussions to recognize the operational reality about IPv6/NAT and stop using discussion points about how this or that draft should be opposed because its adoption might lead to the widespread deployment of IPv6/NAT, which I now believe to be impossible to stop. Indeed, I don’t think there is any desire among service providers and equipment vendors to prevent it.

Therefore, in the context of discussions around this particular draft, I-D.bourbaki-6man-classless-ipv6, I would say that arguments about how subnet prefixes longer than /64 could leave end sites feeling compelled to use IPv6/NAT for address conservation are not technically strong arguments. They are already feeling compelled, even at the existing /64 boundary.

There may be other good arguments for retaining the fixed /64 subnet prefix length in the IPv6 address architecture, but I would say that preventing the rise of ubiquitous IPv6/NAT should not be one of them. That ship sailed when RFC 6177 was passed, and it went over the horizon when HOMENET didn’t receive any significant uptake among service providers.

---

From: Don Sturek <[email-masked]>
Date: Wed, 07 Jun 2017 17:20:03 -0700

Hi James,

I have not participated in Thread at all and this is mostly hearsayŠ..

However, isn¹t the source of the problem that Thread went down the path of
using a Layer 2 routing scheme that they need to harmonize?  I don¹t see how
IETF is the source of the addressing issues if that is the case.

Don Sturek

From:  ipv6 <[email-masked]> on behalf of james woodyatt
<[email-masked]>
Date:  Wednesday, June 7, 2017 at 4:42 PM
To:  Ca By <[email-masked]>
Cc:  6man <[email-masked]>
Subject:  Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

On Jun 7, 2017, at 15:41, Ca By <[email-masked]> wrote:
> 
> I am unfamiliar with thread () in the real world and don't yet feel compelled
> to believe a widely deployed ietf standards track specifications should bend
> due some niche design choices that may or may not achieve a significant
> deployment. 

As far as I know, nobody associated with Thread apart from me is even
listening to IETF much less offering anything to say. And the only thing I¹m
saying is that IETF should stop pretending that IPv6/NAT in end site
addressing plans is preventable. It¹s inevitable.

I¹m not asking IETF to bend its standards accordingly. I¹m actually
expecting that IETF will not bend, and that it will continue promoting
standards that leave end sites compelled to use IPv6-to-IPv6 Network Address
Translation to conserve address space (despite the contrary statement in RFC
6177). The only thing I would prefer to see here is for 6MAN discussions to
recognize the operational reality about IPv6/NAT and stop using discussion
points about how this or that draft should be opposed because its adoption
might lead to the widespread deployment of IPv6/NAT, which I now believe to
be impossible to stop. Indeed, I don¹t think there is any desire among
service providers and equipment vendors to prevent it.

Therefore, in the context of discussions around this particular draft,
I-D.bourbaki-6man-classless-ipv6, I would say that arguments about how
subnet prefixes longer than /64 could leave end sites feeling compelled to
use IPv6/NAT for address conservation are not technically strong arguments.
They are already feeling compelled, even at the existing /64 boundary.

There may be other good arguments for retaining the fixed /64 subnet prefix
length in the IPv6 address architecture, but I would say that preventing the
rise of ubiquitous IPv6/NAT should not be one of them. That ship sailed when
RFC 6177 was passed, and it went over the horizon when HOMENET didn¹t
receive any significant uptake among service providers.

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

---

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

> IPv6, and 6LowPAN, is the dog. The industry associations that use them are the tail. Why is the tail wagging the dog?

Well said. Also, the fact that rfc7084-bis might or might not require HNCP support doesn't prevent any vendor (or ISP procuring CE routers) requiring HNCP. In any case, it hasn't even reached WGLC yet so its content is all open for discussion.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Jun 2017 22:26:43 -0700

> As far as I know, nobody associated with Thread™ apart from me is even listening to IETF much less offering anything to say. And the only thing I’m saying is that IETF should stop pretending that I…

That's not LACNIC's experience. They have been testing to see what the real story is - put an ad in a web page that accesses a STUN server, and reports whether the addresses are the same or different. What they find is that, in Latin America, IPv4 hosts have a 94% probability of being behind a NAT, but IPv6 hosts have only a 0.6% probability.

Just saying... Last I checked data trumps opinion.

https://natmeter.labs.lacnic.net/

---

From: Simon Hobson <[email-masked]>
Date: Thu, 8 Jun 2017 08:19:41 +0100

> Just saying... Last I checked data trumps opinion.

Well said.
I also can't see how anything good can come of an attitude that "people will do it, so lets drop any standards/best practice statements saying it shouldn't be done". Taking that to an extreme, you could say that [CG]NAT solves the IPv4 addressing problem so why do IPv6 at all !

I can well believe that most IPv4 traffic involves NAT. NAT is the band-aid that's kept IPv4 going for the last decade or two, and without it, most users would not get online at all.
As others have said, there's no need for any form of address translation in IPv6 **other than due to operator shenanigans**. If there are established standards that say "thou shalt do xxx" and "thou shalt not do yyy" then there is something for customers to beat up the more idiotic service providers and give them some incentive to fix things. It might help if software developers, instead of spending time on workarounds, simply (or at least, start with) put up a warning to the user that their IPv6 network is broken according to RFCblah and only then offer to carry on with a "best effort" attempt to work around it.

If support forums for packages have threads which come down to "complain to your ISP that they don't comply with RFCblah" then that will get a support loading for the ISP that the bean counters will see as a cost they can remove. Ie, make it more expensive for them to try the sort of tricks (like "you only get a nobbled IP allocation unless you pay us business rates") so there's a commercial incentive for them to do the right thing.

My very limited experience with ISP provided IPv6 is that so far, what I've seen is sensible allocations (eg a /56 for a home user). If the majority do the right thing, then the exceptions can stand out and get a reputation for "broken". I know in the real world there will be cases where there's an effective monopoly (for some group of users) allowing the ISP to do what they want, but that's not an excuse to just throw in the towel and give the rest carte blanch.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Jun 2017 13:32:01 +0200 (CEST)

On Wed, 7 Jun 2017, james woodyatt wrote:

> mesh. Use of IPv6/NAT allows the border router to make an entire 
> Thread™ mesh reach the public Internet via the one stable IPv6 address 
> that is reliably available on all residential networks with IPv6 
> providers.

Why does it have to be just one? Why can't it be one per thread device, so 
you can do 1:1 NAT and not PAT?

I know we have discussed this before. Why was DHCPv6-PD out of scope? 
Because you needed stable addresses internally? Did you decide to use ULA?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Jun 2017 20:35:17 +0900

On Thu, Jun 8, 2017 at 3:41 AM, james woodyatt <[email-masked]> wrote:

> Thread™ 1.1 doesn’t even use RFC 4861 much less RFC 6775. A proxy for RFC
> 4861 at the Thread™ 1.1 border router would require DAD and NUD to be
> translated into prohibitively expensive multicast floods into the mesh. Use
> of IPv6/NAT allows the border router to make an entire Thread™ mesh reach
> the public Internet via the one stable IPv6 address that is reliably
> available on all residential networks with IPv6 providers.
>

If thread doesn't use RFC 4861, then it probably uses address registration?
If so it's trivial: have the BR do the work of replying to DAD and NS, for
only the addresses that exist in the mesh.

> For years, we have been hoping that HOMENET would address the basic
> problem here, but now that it's clear the forthcoming update to RFC 7084
> will not recommend adoption of the HOMENET protocol suite in IPv6 CPE
> residential gateways, Thread™ has no other option than to recommend
> IPv6/NAT to cope with operational reality.
>

That sounds like a false dichotomy to me.

---

From: james woodyatt <[email-masked]>
Date: Thu, 8 Jun 2017 10:25:47 -0700

> On Jun 8, 2017, at 04:35, Lorenzo Colitti <[email-masked]> wrote:
> 
> If thread doesn't use RFC 4861, then it probably uses address registration? If so it's trivia[...]

It does not. The problem is not trivial.

You're invited to have a look at the Thread 1.1 mesh protocol. If you think you can devise a power conservative method for making a Thread 1.1 border router efficiently join a home Wi-fi network using IPv6 Neighbor Discovery, then I'm sure the Thread engineering team would be happy to consider your ideas.

—sent from my phone

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Jun 2017 11:11:06 +1000

In message <[email-masked]>, Simon Hobso
n writes:
> >> listening to IETF much less offering anything to say. And the only thing
> >> I'm saying is that IETF should stop pretending that IPv6/NAT in end site
> >> addressing plans is preventable. It's inevitable.
> >
> > That's not LACNIC's experience. They have been testing to see what the
> > real story is - put an ad in a web page that accesses a STUN server, and
> > reports whether the addresses are the same or different. What they find
> > is that, in Latin America, IPv4 hosts have a 94% probability of being
> > behind a NAT, but IPv6 hosts have only a 0.6% probability.
> >
> I also can't see how anything good can come of an attitude that "people
> will do it, so lets drop any standards/best practice statements saying it
> shouldn't be done". Taking that to an extreme, you could say that [CG]NAT
> solves the IPv4 addressing problem so why do IPv6 at all !
>
> I can well believe that most IPv4 traffic involves NAT. NAT is the
> band-aid that's kept IPv4 going for the last decade or two, and without
> it, most users would not get online at all.
> As others have said, there's no need for any form of address translation
> in IPv6 **other than due to operator shenanigans**. If there are
> established standards that say "thou shalt do xxx" and "thou shalt not do
> yyy" then there is something for customers to beat up the more idiotic
> service providers and give them some incentive to fix things. It might
> help if software developers, instead of spending time on workarounds,
> simply (or at least, start with) put up a warning to the user that their
> IPv6 network is broken according to RFCblah and only then offer to carry
> on with a "best effort" attempt to work around it.
>
> If support forums for packages have threads which come down to "complain
> to your ISP that they don't comply with RFCblah" then that will get a
> support loading for the ISP that the bean counters will see as a cost
> they can remove. Ie, make it more expensive for them to try the sort of
> tricks (like "you only get a nobbled IP allocation unless you pay us
> business rates") so there's a commercial incentive for them to do the
> right thing.
>
> My very limited experience with ISP provided IPv6 is that so far, what
> I've seen is sensible allocations (eg a /56 for a home user). If the
> majority do the right thing, then the exceptions can stand out and get a
> reputation for "broken". I know in the real world there will be cases
> where there's an effective monopoly (for some group of users) allowing
> the ISP to do what they want, but that's not an excuse to just throw in
> the towel and give the rest carte blanch.

And 256 prefixes very quickly become too few as we develop new
technologies to take advantage that you can get prefixes easily.
ISP's have been short sighted here.  The IETF started out saying
/48 to give every site enough prefixes that they shouldn't have to
go back and get more except in exceptional circumstances.

Note: the rule always has been "if you don't have enough prefixes
ask your ISP for more".  DHCP-PD allows for this, you can us DHCP-PD
to request additional blocks.  RIR's allow ISP's to get more addresses
to support this.

Mark

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Jun 2017 15:53:13 +0900

On Fri, Jun 9, 2017 at 2:25 AM, james woodyatt <[email-masked]> wrote:

> You're invited to have a look at the Thread 1.1 mesh protocol. If you
> think you can devise a power conservative method for making a Thread 1.1
> border router efficiently join a home Wi-fi network using IPv6 Neighbor
> Discovery, then I'm sure the Thread engineering team would be happy to
> consider your ideas.
>

Is it publicly documented? If not, I'd be happy to sit down with you and
debate this :-)

---

From: Simon Hobson <[email-masked]>
Date: Fri, 9 Jun 2017 11:01:33 +0100

> go back and get more except in exceptional circumstances.

I disagree - at least for home users.
Most home users simply unpack the ISP router, plug it in, and connect their devices to it.
They plug in their webcams https://www.theregister.co.uk/2017/06/08/whitebox_webcam_scatters_vulnerabilities_through_multiple_oems/
plug in their "smart" lightbulbs https://www.theregister.co.uk/2016/07/27/osram_smart_lightbulbs/
plug in their "smart" doorbell & locks https://www.theregister.co.uk/2016/01/12/ring_doorbell_reveals_wifi_credentials/
http://www.theregister.co.uk/2016/08/08/using_a_smart_bluetooth_lock_to_protect_your_valuables_youre_an_idiot/
connect their kids toys http://www.theregister.co.uk/2015/02/19/hello_barbie/ and their own "toys" http://www.theregister.co.uk/2016/08/07/your_sec_toy_is_spying_on_you_hackers_crack_our_plastic_pals/

I could go on (kettles, fridges, bathroom scales, ... all with reported security flaws), but I think you get the idea !
All of this will be on one network, one subnet/prefix. The majority of users (some small rounding error below 100%) will have no idea at all about networking, they won't have any clue about setting up multiple networks - and the way much of the kit works, it won't work anyway if the device isn't on the same network/subnet/prefix and the users phone/tablet.

I recall a few years ago visiting my alma mater and found that ethernet ports had appeared in the rooms. When I plugged into one, I could see all the security cameras etc were on the same segment and even the same subnet ! If a university college can't get simple things like this right, what makes you think home users will do any better ?

As I sit here (as part of that rounding error of users), to be frank, I am struggling to think what I could (practically) use 10 separate networks for, let alone 100 or 200 or 256 !

> ask your ISP for more".

At which point you come up against the technically illiterate beancounters running (some of) the ISPs who figure that if you want more IPs then you must be a customer worthy of paying them more. The same ones who, in the IPv4 world want a significant amount extra just to have a single fixed IP rather than a dynamic one, and even more if you want more than one address.

---

From: "Leddy, John" <[email-masked]>
Date: Fri, 9 Jun 2017 10:09:57 +0000

“    I disagree - at least for home users.
    Most home users simply unpack the ISP router, plug it in, and connect their devices to it.
    They plug in their webcams… “

This is what Homenet was supposed to solve – an easy, automatic way to segment networks at Layer 3.
Assign prefixes where at least there is a chance at Policy/Security between them and avoid very dissimilar Layer 2 subnets being bridged together – requiring ever growing sets of Application and Protocol proxies between them.

John

On 6/9/17, 6:01 AM, "ipv6 on behalf of Simon Hobson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Jun 2017 22:58:52 +1000

In message <[email-masked]>, Simon Hobso
n writes:
> They plug in their webcams https://www.theregister.co.uk/2017/06/08/whitebox_
> webcam_scatters_vulnerabilities_through_multiple_oems/
> plug in their "smart" doorbell & locks https://www.theregister.co.uk/2016/01/
> 12/ring_doorbell_reveals_wifi_credentials/
> connect their kids toys http://www.theregister.co.uk/2015/02/19/hello_barbie/
>  and their own "toys" http://www.theregister.co.uk/2016/08/07/your_sec_toy_is
> _spying_on_you_hackers_crack_our_plastic_pals/
> 
> I could go on (kettles, fridges, bathroom scales, ... all with reported secur
> ity flaws), but I think you get the idea !
> All of this will be on one network, one subnet/prefix. The majority of users 
> (some small rounding error below 100%) will have no idea at all about network
> ing, they won't have any clue about setting up multiple networks - and the wa
> y much of the kit works, it won't work anyway if the device isn't on the same
>  network/subnet/prefix and the users phone/tablet.

Just because you are not used to home routers that configure multiple
subnets doesn't mean they don't exist.

> I recall a few years ago visiting my alma mater and found that ethernet
> ports  had appeared in the rooms. When I plugged into one, I could see
> all the security cameras etc were on the same segment and even the same
> subnet ! If a university college can't get simple things like this right,
> what makes you think  home users will do any better ?

Because we will ship routers that do multiple subnets by default
because that is what is needed to deal with situations like you
describe above.

> As I sit here (as part of that rounding error of users), to be frank, I
> am struggling to think what I could (practically) use 10 separate networks
> for, let alone 100 or 200 or 256 !

Uses will come up.  I use 3 subnets today for the home.  I would
expect that I'll use more in the future.  Once more than one becomes
common people will design stuff that can make use of additional
subnets.

> At which point you come up against the technically illiterate
> beancounters running (some of) the ISPs who figure that if you want more
> IPs then you must be a customer worthy of paying them more. The same ones
> who, in the IPv4 world want a significant amount extra just to have a
> single fixed IP rather than a dynamic one, and even more if you want more
> than one address.

A /48 costs a cent.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 20:26:41 +0300

> common people will design stuff that can make use of additional

(you || me || we) != users

network_knowledge(users) == NULL

(and that's the way it should be)

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

---

From: Simon Hobson <[email-masked]>
Date: Fri, 9 Jun 2017 21:55:49 +0100

>> because that is what is needed to deal with situations like you

And conversely, just because they exists doesn't mean that any ISP will ship them - or ship them configured to anything more than a basic single network.

Besides, for this to work properly it's going to require VLANs and multiple wireless SSIDs unless you limit the network to the ports on the router. Good luck getting that to work with the average user.

>> common people will design stuff that can make use of additional

I can see uses for about 3 or 4 segments - note, segments rather than subnets ! You are not clear whether you are talking about multiple segments or a single network with multiple subnets. If it's the latter then it adds almost zero security, if the former than it's beyond the average user to deal with.

> network_knowledge(users) == NULL

Thanks - you've expressed it better than I would have.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Jun 2017 23:01:54 +0200

> Besides, for this to work properly it's going to require VLANs and multiple wireless SSIDs unless you limit the network to the ports on the router. Good luck getting that to work with the average u…

Apple has had these in their “Airport” product line for about a decade.
(Of course, “average users” aren’t taught about VLAN tags; it “just works™” :-)

Grüße, Carsten

---

From: Mark Andrews <[email-masked]>
Date: Sat, 10 Jun 2017 08:10:29 +1000

In message <[email-masked]>, Simon Hobso
n writes:
> And conversely, just because they exists doesn't mean that any ISP will
> ship them - or ship them configured to anything more than a basic single
> network.
>
> Besides, for this to work properly it's going to require VLANs and
> multiple wireless SSIDs unless you limit the network to the ports on the
> router. Good luck getting that to work with the average user.

People can handle multiple SSIDs quite easily.  We have had routers
shipping with 2 SSIDs for many years now. Usually the second one in
labeled "Something Guest".

> I can see uses for about 3 or 4 segments - note, segments rather than
> subnets! You are not clear whether you are talking about multiple
> segments or a single network with multiple subnets. If it's the latter
> then it adds almost zero security, if the former than it's beyond the
> average user to deal with.

The home user is quite capable of doing multiple segments.  It
really isn't hard.

Have a couple of cars that each do PD requests for a couple of /64s
each when they arrive home as they connect over WiFi rather than
using LTE possibly using a distinct WiFi SSID in the garage (another
/64). The LTE border router in the car becomes a interior router
when it connects to the WiFi.  This is really no different to coming
home with your mobile phone except you are connecting multiple
subnets rather than individual addresses.

What other equipement will request /64s as it comes into range or
just request /64s when it connects?  I don't know yet but I do know
it will happen.  256 subnets is going to look very small when that
happens.

> Thanks - you've expressed it better than I would have.

Actually we are all users.  Adding WEP passwords was once "too hard"
for the ordinary user.  There used to be a dozen parameters presented
to users of WiFi networks.  Now you choose from a simple list of
SSIDs.

Anything we do today will be common in a few years time.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 10 Jun 2017 11:15:10 +0100

> (Of course, “average users” aren’t taught about VLAN tags; it “just works™” :-)

Really ?
If you connect an airport to ${random_switch} and ${random_router} then all the VLANs will work without any intervention ? It might work if every piece of kit is from the same manufacturer (ie what Apple would have you do), but in the general case there's a long way to go !

> labeled "Something Guest".

Most chipsets only support 4 SSIDs, a few handle 16. I've never come across one, but I could believe that some enterprise manufacturer might handle more - at a price. That's a loooooong way from exceeding the 256 segments possible with a /56 from your ISP.

And there's the other issue - people will really really hate you if all these SSIDs do materialise. I've already read comments in another list where users in densely populated places (think these high-density apartment blocks with gigabit connectivity we hear about in parts of Asia) where they already struggle to select a WiFi network because the list takes so long to display and scroll down that it refreshes (and resets the scroll) before they can select their network. Now you propose to multiply that by a few hundred ?

> The home user is quite capable of doing multiple segments.  It

I don't think you've dealt with the average home user, you wouldn't say that otherwise. As I;ve said before, there's a reason ISPs use colour coded sockets and cables for their routers - it's so they can say things like "connect the yellow cable to ..." The average home user really is incapable of doing this.

> when it connects to the WiFi.

And there's no security in that method.
If I have ${random_IoTat_hub}, I don't want (and wouldn't allow) it to connect to anything but it's own isolated segment and then control what traffic it is allowed to send where. If it connects to the users general WiFi then the IoT thing has full access to the rest of what's on that segment and I don't have control of what it can and cannot do on it. So as I read it, you are proposing to build a network system that gives the false appearance of security - and thus is worse that no security at all.
Whether it requests it's own /64 is another matter - it's really not the same as it having an isolated network segment.

> Actually we are all users.

OK, change that to (you || me || we) != average users. I've dealt with them, really, no-one on this list is anything whatsoever like an average user - and I strongly suspect that some on this list just don't understand what a real average user is like !