Subject: SAILing LAPs

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2018 16:47:58 +1200

A new version with an additional term defined, following a suggestion
by Mark Smith.

Again: this draft doesn't discuss the issues. Its only goal is to give us
some better terminology.

    Brian

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-6man-lap-01.txt
Date: Tue, 19 Jun 2018 21:45:09 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : The Longest Acceptable Prefix for IPv6 Links
        Author          : Brian Carpenter
	Filename        : draft-carpenter-6man-lap-01.txt
	Pages           : 4
	Date            : 2018-06-19

Abstract:
   This document introduces the concepts of a Longest Acceptable Prefix
   (LAP) and a Shortest Acceptable Identifier Length (SAIL) for an IPv6
   link.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-lap/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-6man-lap-01
https://datatracker.ietf.org/doc/html/draft-carpenter-6man-lap-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-lap-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Jun 2018 08:57:34 +0200

Hi Brian,

RFC6164 doesn't mandate that p2p-links are /127, it mandates that routers support it.

So, it may be better if your example at section 2, shows both possibilities, which also provides you more examples of LAP for the same purpose in different networks.

Something in the line of:

A point-to-point link may have a LAP of /64, but also of /127 (according to [RFC6164]).

Regards,

Jordi

-----Mensaje original-----

De: ipv6 <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>

Organización: University of Auckland

Fecha: miércoles, 20 de junio de 2018, 6:48

Para: 6man <[email-masked]>

Asunto: SAILing LAPs

    by Mark Smith.

    some better terminology.

        Brian

    -------- Forwarded Message --------

    

    

            Author          : Brian Carpenter

    	Pages           : 4

    	Date            : 2018-06-19

    Abstract:

       link.

    

    [email-masked]

    --------------------------------------------------------------------

    IETF IPv6 working group mailing list

    [email-masked]

    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

    --------------------------------------------------------------------

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

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

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Jun 2018 12:27:34 +0200

> Again: this draft doesn't discuss the issues. Its only goal is to give us

While also being a political document with the implicit intention of changing the 64 bit boundary.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Jun 2018 20:51:49 +0900

> changing the 64 bit boundary.

And more importantly, reviving a discussion that fairly recently consumed
many many many hours of WG participants' time with no progress to show for
it.

Brian: why do you think making this a debate about terminology instead of
functionality will make that discussion any more likely to reach consensus?
I'd expect it to make it even less likely, not more. History is chock-full
full of examples where groups of people disagreed about terminology, even
when there was agreement on the actual issues.

war is peace
freedom is slavery
ignorance is strength

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jun 2018 14:23:04 +0200

I find this Internet Draft to be a little help in the right direction - 
encouraging.

We know BSD implements various lengths for IIDs, including 64 and 63, 
for SLAAC.

We also know linux kernel does not support any other length than 64.  An 
effort of a kernel programmer of approximately 3 days could not make 
linux kernel accept plen 65 and self-configure an address.  I am still 
looking for someone for help.

Alternatively, this IoT Router's Qualcomm modem does not _want_ to allow 
DHCPv6 Prefix Delegation outgoing UDP port number 547.  They are what 
can be qualified as stubborn :-)

For me, this is kind of an urgent matter.  We build a prototype onboard 
IoT Router to connect a car on cellular network.  It does 64share, and 
further down the car network there is L2 bridging too.  However, deeper 
inside there are further IP subnets - webcam and others.  IPv6 can not 
reach them.

If by end of July I dont get this 65plen and 63IIDlen working then my 
onboard IPv6 design definitely has a conceptual flaw.

I find this Internet Draft to be a little help in the right direction - 
encouraging.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jun 2018 14:41:12 +0200

Le 20/06/2018 à 13:51, Lorenzo Colitti a écrit :
[...]
> ignorance is strength

Id toes not follow.  I thought you meant ignorance is knowledge?  Or 
that weakness is strength?

> And more importantly, reviving a discussion that fairly recently consumed many many many hours of WG participants' time with no progress to show for it.

Lorenzo, I agree with you we spent much time on this. I agree with many
of your oppinions on this particular topics - for example recommendation
of bridging to get around the 64bit limit: I implement despite me being
vocal against it!

On another hand, in further detail, as more time goes by, I feel more
and more some unique yet strongly expressed oppinions block entire sets
of other numerous but more silent oppinions. This can only create problems.

The problem created is the following: blocking advancement of non-64bit
IID, makes IPv6 not get deployed deeper in some network. It is not
because _I_ dont want it to progress without 64bit limit removal; it's
because other people who put requirements on me do not accept this
bridging solution (they rather want to isolate with routing - it is a
common design in onboard networks to separate entertainment from emergency).

Because of this created problem, it can be possible that strange quirks
get developped that may be liked even less.

Alex

---

From: David Farmer <[email-masked]>
Date: Wed, 20 Jun 2018 13:50:36 -0500

On Wed, Jun 20, 2018 at 7:23 AM, Alexandre Petrescu <
[email-masked]> wrote:
...

> We know BSD implements various lengths for IIDs, including 64 and 63, for
> SLAAC.
>

Unfortunatly, this is not a good thing, this a rogue inplementation in my
opinion. However, this a symptom of a bigger problem as I see it; the
current way we IPv6 specifys this is not well understood by most
implementers or operators. SLAAC [RFC4862] and ND[RRFC4861] are seemingly
in conflic with the Addressing Archeture [RFC4291] and I belive because it
is not explaine well. Making the overall situation incomprehensible to most
people, this is what I want to fix, not changing the 64-bit boundry.

> effort of a kernel programmer of approximately 3 days could not make linux
> kernel accept plen 65 and self-configure an address.  I am still looking
> for someone for help.
>

This is partually becase how to intrupret staticly configure IPv6 addresss
was not clearly defined, BSD and other early implementations alloed any
prefix length to be statically configured, I think because thier
implementations began before 64-bit was landed on as the boundry, and most
implementations just coppied BSD.  This is why I wnat to see a clear
execption for staticlly defined addresses with any length of subnet and
therefore IID.  Otherwise many if not most implementations of not in
compliance with IPv6's specifications. Again part of the confusion people
have.

> DHCPv6 Prefix Delegation outgoing UDP port number 547.  They are what can
> be qualified as stubborn :-)
>

I think many of us have told you that design has conceptual flaws.

-- 
===============================================
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: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jun 2018 20:57:01 +0200

David,

I have read your email.

I agree with many points.

Le 20/06/2018 à 20:50, David Farmer a écrit :
[...]> I think many of us have told you that design has conceptual flaws.

Thank you for the remark.  I read it.

I stop here on this thread.

Alex
[...]

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Jun 2018 13:41:33 -0700

At Wed, 20 Jun 2018 14:23:04 +0200,

> I find this Internet Draft to be a little help in the right direction -

If this draft is really about terminology, this sub-thread is already
out of scope, but I'd like to clarify one thing as I believe it's

> We know BSD implements various lengths for IIDs, including 64 and 63,

[This statement is technically misleading in that this is
really about using different lengths of IIDs against the address
architecture rather than something about SLAAC (any RFC4862-compliant
SLAAC implementation should already support any lengths of IIDs for
years).  But that aside:]

"BSD" is a broad term and not really appropriate in this context.  In
this case we should be very specific to say "OpenBSD".  As far as I
can see, neither FreeBSD nor NetBSD, two other major BSD variants, has
this capability yet (and I've not even seen a discussion in their
developers' lists about porting the OpenBSD implementation).  In my
general understanding, OpenBSD is famous about 'doing "the right
thing" whatever the stupid IETF standard says', while others (perhaps
including Linux kernel developers) tend to be more keen on
protocol-conformance.  If my observation is correct, it's not
surprising to see only OpenBSD has this behavior even if it may not be
a big effort in terms of code lines or development time.  And it's
less likely to change soon.

So, if we want to see more widely adoption of a new behavior that is
currently a violation of the standards, I personally think there's no
easy short cut than revise the standard, or at least get a WG-level
consensus on it.  This draft might be a small first step towards that
goal for those who want it, but, to me, we're still way far from
there.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 08:58:53 +1200

> While also being a political document with the implicit intention of changing the 64 bit boundary.

No, I have no desire to see it change. I do however believe that it isn't
our job to constrain what people may find useful to do in 20 or 50 years
time, or what IoT designers may find useful to do in the relatively
near future. That means making only architectural statements in the
addressing architecture. That's the only policy issue I have.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 09:02:35 +1200

> when there was agreement on the actual issues.

Those are doublespeak. I don't see any doublespeak in my proposals.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 09:11:33 +1200

Correct! Thanks, Jordi.

Regards
   Brian

On 20/06/2018 18:57, JORDI PALET MARTINEZ wrote:
> .

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Jun 2018 23:32:55 +0200

> addressing architecture. That's the only policy issue I have.

If you don't have a desire to change something, it's difficult to understand what mission you are on.
The 64 bit boundary _is_ architectural. A fundamental one, exemplified by e.g. ILNP.
Future generations are taken care of, by reserving almost 7/8ths of the address space.

Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Jun 2018 15:23:42 -0700

At Wed, 20 Jun 2018 16:47:58 +1200,

> Again: this draft doesn't discuss the issues. Its only goal is to give us

I'm skeptical (or, perhaps more accurately, pessimistic) about whether
new terminology helps eventually resolve the /64 row, but I'm
providing some superficial feedback on the draft:

- Section 1

   Stateless Address Autoconfiguration (SLAAC) [RFC4862] requires a
   fixed prefix length for each Layer 2 medium, and for largely
   historical reasons [RFC7136] this has been fixed for all media as 64
   bits by the addressing architecture.

  This is not necessarily incorrect, but to be pedantic has some
  subtle issue: to be very accurate, RFC4862 requires a fixed IFID
  (not prefix) length for each layer 2 medium.  In the end, the prefix
  length should also effectively be fixed, but that's because of this
  requirement and another requirement that the sum of prefix length
  and IFID length be 128, so it's a "logical consequence of
  requirements", not a requirement in itself.

- Section 2 and 3

  The definitions of LAP and SAIL are not clear to me.  For example,
  the only seeming "definition" of LAP is this:

   However, for a given network, end site, or
   link, there always exists a Longest Acceptable Prefix (LAP), whose
   length is locally determined.

  But this doesn't really look like a "definition" to me - it just
  sounds like some observation given we already know what LAP is,
  i.e., the definition of LAP.  Essentially the same sense of comment
  applies to SAIL, too.  I can't suggest an alternative as I only
  vaguely sense how you are trying to define them.  But if we can make
  these more like a real definition, that may help address some of the
  concerns raised so far, such as it (seems to) have a political
  intent.

- Section 4: s/feasability/feasibility/ ?

   Additionally, the length of a SAIL has important implications for the
   feasability of network reconnaissance by scanning attacks [RFC7707].

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 11:02:49 +1200

> Future generations are taken care of, by reserving almost 7/8ths of the address space.

But that's the inconsistency right there. RFC4291 doesn't
delegate 2000::/3 and reserve the rest. (RFC3513 did that,
but it was deleted from RFC4291). So the current word imposes
/64 on all future IANA delegations too.

This is another thing we can fix by adopting and improving
David Farmer's proposal - put all these parameters in a separate
document that's easier to update than an Internet Standard.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Jun 2018 16:05:38 -0700

> The 64 bit boundary _is_ architectural. A fundamental one, exemplified by

Ole,

ILNP does not have IIDs, they have 64 bit locators and identifiers. The
choice to use 64 bits seems to be more out of convenience than based on
real analysis of what is needed. For ILA we started with the same 64/64
split, but it quickly became apparent that that is arbitrary and there are
valid reasons for a site to use alternative encodings.

Future generations are taken care of, by reserving almost 7/8ths of the
> address space.

That depends on how efficient address allocation is. If most end devices
end up getting a /64 assignment as suggested by RFC3314 that effectively
makes degrades IPv6 addresses to be 64 bit values so 1/2 of address _bit_
space is effectively lost.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 11:20:02 +1200

Jinmei-san,
>   requirements", not a requirement in itself.

Yes, if I update the draft (which may never happen) I will rephrase that.

>   i.e., the definition of LAP.  

Well, I was thinking a little bit like a mathematician, as
"let π be the ratio of the circumference of a circle to its diameter"
as the definition of π, which implies that such a constant exists.

I think the fact is that for a given network, such a constant must
exist, whether by default configuration or by human choice.

>   Essentially the same sense of comment

Ack!

Thanks,
    Brian

---

From: DY Kim <[email-masked]>
Date: Thu, 21 Jun 2018 09:33:50 +0900

inline…

---
DY

> On 21 Jun 2018, at 08:05, Tom Herbert <[email-masked]> wrote:
> 
> That depends on how efficient address allocation is.

Exactly.

> If most end devices end up getting a /64 assignment as suggested by RFC3314 that effectively makes degrades IPv6 addresses to be 64 bit values so 1/2 of address _bit_ space is effectively lost.

!!

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Jun 2018 18:17:18 -0700

At Thu, 21 Jun 2018 11:20:02 +1200,

> exist, whether by default configuration or by human choice.

I'm afraid my concern wasn't clear - it looks like you interpreted it
as whether the "definition" is well defined.  It was actually more
fundamental.

"let π be the ratio of the circumference of a circle to its diameter"
is clearly a "definition" to me since it states what π is clearly.
Whether it's well defined, i.e., whether the ratio is the same for any
circle, is a different question, but even if not, it's still a clear
definition.

To me, the current draft text doesn't explain what's LAP or what LAP
means for a given network, end site, or link.  If, for example, it
said:

   For a given network, end site, or link, there is a specific length
   of prefix so that longer prefixes than that are deemed to cause
   more harm than good for its user in the given network, end site, or
   link.  A Longest Acceptable Prefix (LAP) is a prefix which has such
   a specific length in the given context.

then it would look more like a "definition".  Whether it's
well-defined, i.e, whether there really always exists such a length of
prefixes, is a different question, but that's not my concern.

(Note: I'm not trying to speak for you and suggesting text for the
draft.  This example "definition" is an attempt to state my concern
more clearly and concretely).

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 14:17:52 +1200

> more clearly and concretely).

Fair enough. It isn't at all obvious whether I will update the draft again,
but I will save your comment.

Thanks
    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Jun 2018 17:53:50 +1000

On Thu., 21 Jun. 2018, 09:06 Tom Herbert, <[email-masked]> wrote:

>> The 64 bit boundary _is_ architectural. A fundamental one, exemplified by
>> e..g. ILNP.
>>
>
> Ole,
>

Except that IPv6's address space was originally only going to be 64 bits,
presumably enough bits to solve the lack of addresses problem of IPv4.

Simple Internet Protocol Plus White Paper

https://tools.ietf.org/html/rfc1710

(Also an interesting paper laying out expected use cases. Bob Hinden and co
were predicting IoT before it had a name, smartphones with Internet access
and other things that have since eventuated, all in 1994 and earlier.)

According to Christian Huitema in his IPv6 book (well worth a read for the
'whys'), the additional 64 bits where added because of Mike O'Dell's GSE
proposal.

GSE - An Alternate Addressing Architecture for IPv6

https://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00

Regards,
Mark.

---

From: DY Kim <[email-masked]>
Date: Thu, 21 Jun 2018 17:31:54 +0900

History might be educational, but it doesn’t mandate the actions we might take at this time of the era. It’s good that some had anticipated rough 20 years to come, but definitely they might not have possessed the vision to talk about 50+ more years to come from now. In fact, nobody knows what’s coming until it comes. Open door should be the best policy.

Anecdote: Ask Columbus what’s going to happen in the new world. An honest answer should be ‘I don’t know’.

And more… all these histories are not justifications to put implementation constants in the Architecture document. The whole texts of this Arch doc talks repeatedly, as it should, that n and m are variables and there’s no predefined boundary points…. and then suddenly in the paragraph of our concern states the boundary should be at /64. Even further down, the doc repeats the openness for the boundary.

The constants like /64 should be kept in a separate STD track document, and clean up the current Arch doc so that it really can be called an ‘Architecture’ document. As it is now, it’s an alleged arch doc contaminated with implementation constants.

The separate doc stating the /64 as an Internet Standard should more than satisfy the interest of the other camp.

---
DY

> On 21 Jun 2018, at 16:53, Mark Smith <[email-masked]> wrote:
> 
> Except that IPv6's address space was originally only going to be 64 bits, presumably enough bits to solve the lack of addresses problem of IPv4.
> 
> (Also an interesting paper laying out expected use cases. Bob Hinden and co were predicting IoT before it had a name, smartphones with Internet access and other things that have since eventuated, all in 1994 and earlier.)
> 
> 
> According to Christian Huitema in his IPv6 book (well worth a read for the 'whys'), the additional 64 bits where added because of Mike O'Dell's GSE proposal.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Jun 2018 17:38:27 +0900

> satisfy the interest of the other camp.

Perhaps, but it would almost certainly never get past the camp that wants
to see IPv6 addressing be variable length.

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Jun 2018 11:25:15 +0200

> That depends on how efficient address allocation is. If most end devices end up getting a /64 assignment as suggested by RFC3314 that effectively makes degrades IPv6 addresses to be 64 bit values so 1/2 of address _bit_ space is effectively lost.

That was the argument of the 64/64 split. If the future shows that it was wrong, then we could do something else with the other 7/8ths of the space.

I don't think an argument has been made yet, that "future" has shown us anything different. But feel free to provide that.

Now, the reserving of 7/8ths got changed in 4291. Ffrom the perspective of, well if it turns out that the current model is correct, we might want to be able to continue that model without having to change all the IPv6 nodes on the planet also into that address space. If 50 years from now, we want to use the 7/8th for something else, that door is still open.

It is still unclear to me what the problem to be solved here is.
And given that, I am not supportive of yet another reiteration of the same argument with the same outcome. I.e. no consensus to change anything.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 21 Jun 2018 11:30:57 +0200

>The 64 bit boundary _is_ architectural. A fundamental one, exemplified 

It seems to me that the 64 bit boundary is only to some extent technical.

The 64 bit boundary makes sense for SLAAC. Though with pseudo random IIDs
the actual value could just as well be 60 or 70, there doesn't seem to be
a compelling reason to change this value. As long as we have to pick one
value, we can just as well pick 64. Not picking any value, i.e., letting
the network operator decide can lead to serious trouble as described in
past discussions. 

For DHCPv6, static and manual configuration, there realistically is no need
for a restriction on IID length.

However, there is still a wide spread believe that bits precious. That somehow
you should provide customers with the longest prefix you can get away with,
and charge more for shorter prefixes. For example, in some regions, such as
the RIPE region, ISPs can get enough address space to give every customer
a /48 without any impact on how much they pay the RIR. And yet, plenty of
providers provide customers with way longer prefixes. But of course, at
most 64 bit.

For this political reason, not making any change would be best.

---

From: David Farmer <[email-masked]>
Date: Thu, 21 Jun 2018 16:06:47 -0500

> For this political reason, not making any change would be best.

I personally have no desire to change the 64-bit subnet boundary. What I
wish to change is our description of it, making it more understandable. In
section 2.5 of RFC4291, we clearly say it can be any length.  But, then we
abruptly define it as 64 bits in section 2.5.1, without any explanation of
why or defining what part of the ecosystem is responsible to ensure it is
64 bits, or what parts of the ecosystem must follow section 2.5 and assume
an IID could be any length.

What part of the ecosystem is obligated to ensure IIDs are 64 bits in
length? Network operators? Host software implementors? Router software
implementors? What happens if it is not?

None of this is clear within RFC4291. We have RFC7421 that helps explain
why 64, but even it is clear that it was a mostly arbitrary choice. There
is some real reasoning, especially around why one size, but other than that
most of it boils down to historical precedence or "because we said so",

If the 64-bit boundary is as fundamental as many are claiming, then it
would also seem important to define what part of the IPv6 ecosystem is
responsible for making it so.  It seems clear, at least to me, from RFC4861
that node implementations are not, nodes MUST assume subnets, and therefore
IIDs, could be any length. It is, in fact, the network and/or system
administrators that are responsible to configure routers, or possibly the
hosts directly, with global unicast subnets of /64 and therefore 64-bit
IIDs. The link-local subnet and IID length are defined by the appropriate
IPv6-over-FOO document. I think it would be useful to make this clear in
the IPv6 Addressing Architecture.

Also, if the 64-bit boundary is as fundamental as many are claiming, why is
it not an error condition to have subnet and IID length of other than 64?
I believe only SLAAC would think a prefix other than /64 with an A flag is
an error, and it just doesn't generate an address.  Further, even if it
doesn't generate an address it still supposed to treat the prefix as
on-link if that flag is set regardless of its length.

However, there are also exceptions to the 64-bit boundary, even beyond
addresses that begin with 000, especially now with RFC6164. Furthermore,
most node implementations allow the static configuration of prefixes, and
therefore IIDs, of any length. To me, all of this makes it abundantly clear
that, with the exception of SLAAC, the 64 bit IID is an operational dictum,
not a protocol requirement.

Please do not take these as arguments for changing the 64-bit subnet
boundary, I point them out as things that need better explanations.

Thanks

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Jun 2018 15:13:49 -0700

(changing the subject, as it has nothing to do with SAIL or LAP)

At Thu, 21 Jun 2018 16:06:47 -0500,

> on-link if that flag is set regardless of its length.

I have no comment about whether the 64-bit boundary in the address
architecture is fundamental, but the above statement seems to be based
on common confusion regarding various kinds of IPv6 prefixes.  I tried
to clarify these points in my own (now-expired) draft:
https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00

Hopefully it helps make your points more relevant and accurate.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2018 11:51:42 +1200

> to see IPv6 addressing be variable length.

I don't see why not. While variable length addressing was seriously
discussed for IPng, that argument didn't prevail. Variable length
subnet masks prevailed, however.

I suggest we try it and see. Maybe David Farmer can push a draft out in
the next few days?

   Brian

---

From: DY Kim <[email-masked]>
Date: Fri, 22 Jun 2018 09:40:08 +0900

While waiting for David’s input, please allow me to chip in with my own suggestion as follows: (already posted as a response to Jinmei’s email)

1. Remove the whole of the following 4th para of Sec. 2.4.1 (which are later to be documented as separate ISs):

  "Interface Identifiers are 64 bit long except if the first three bits
  of the address are 000, or when the addresses are manually
  configured, or by exceptions defined in standards track documents.
  The rationale for using 64 bit Interface Identifiers can be found in  [RFC7421].  An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links.”

2. Remove the following parenthesis in the last para of Sec. 2.4.4:

   "(and therefore having a 64-bit interface ID field)”

Otherwise, the current text of 4291bis-09 may remain intact.

---
DY

> On 22 Jun 2018, at 08:51, Brian E Carpenter <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Thu, 21 Jun 2018 20:42:29 -0500

> I suggest we try it and see. Maybe David Farmer can push a draft out in

Working on it, hope to have someting out early next week.

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Jun 2018 15:53:51 +0900

On Fri, Jun 22, 2018 at 6:07 AM David Farmer <[email-masked]> wrote:

> abruptly define it as 64 bits in section 2..5.1, without any explanation of

David, what makes you think that any clarification of the 64 bit boundary
as it stands is going to reach consensus of any sort?

Think about it: RFC 4291bis was virtually identical to RFC 4291. It
proposed *no change* in the standard. It simply repeated the same text that
had been a standard since 2006. And yet we couldn't agree on even that.

Why do you feel that this time will be different?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Jun 2018 10:55:59 +0200

>implementors? What happens if it is not?

What currently locks it in place is that many software implementation support
only IIDs of length 64 on ethernet in the context of SLAAC.

So network operators are prevented from deploying longer prefixes, because
that simply doesn't work.

To the extent that we want to keep this unchanged, we should uncourage 
software implementation to continue to hardcode 64 as the IID length for
ethernet.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 22 Jun 2018 17:17:48 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg

> What currently locks it in place is that many software implementation
> support only IIDs of length 64 on ethernet in the context of SLAAC.
>
> So network operators are prevented from deploying longer prefixes,
> because that simply doesn't work.

Well then, there is no immediate problem of a "race to the bottom," and that's great. Everyone can relax some.

> To the extent that we want to keep this unchanged, we should
> uncourage software implementation to continue to hardcode 64 as the
> IID length for ethernet.

I again really disagree. Experience will dictate what has to be done. As others have explained recently, situations such as car networks have already shown that subnetting with longer prefixes is desirable. Pretending that everyone is getting /48s allocated is not reality, and it seems unlikely to become more true in the future.

The only good solution today, for those of us who need flexibility, is liberal use of ULAs, and then dealing with some special nodes to interface with the Internet. This is in part also for security purposes. Still, security can be implemented in many ways, and I honestly do not think the future is, or should be, one of a rigid boundary. Let experience decide, without preconceived notions.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jun 2018 17:43:36 +0300

> For this political reason, not making any change would be best.

What do you do if all you got is a /64, and you want/need to subnet?

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jun 2018 18:05:37 +0300

Hello, David,

On 06/22/2018 12:06 AM, David Farmer wrote:
[....]
> wish to change is our description of it, making it more understandable.
> In section 2.5 of RFC4291, we clearly say it can be any length.  But,
> then we abruptly define it as 64 bits in section 2..5.1, without any
> explanation of why or defining what part of the ecosystem is responsible
> to ensure it is 64 bits, or what parts of the ecosystem must follow
> section 2.5 and assume an IID could be any length.
> 
> why 64, but even it is clear that it was a mostly arbitrary choice.
> There is some real reasoning, especially around why one size, but other
> than that most of it boils down to historical precedence or "because we
> said so",  
> 
> responsible for making it so.

Agreed.

> It seems clear, at least to me, from
> RFC4861 that node implementations are not, nodes MUST assume subnets,
> and therefore IIDs, could be any length. It is, in fact, the network
> and/or system administrators that are responsible to configure routers,
> or possibly the hosts directly, with global unicast subnets of /64 and
> therefore 64-bit IIDs. The link-local subnet and IID length are defined
> by the appropriate IPv6-over-FOO document. I think it would be useful to
> make this clear in the IPv6 Addressing Architecture. 
> 
> Also, if the 64-bit boundary is as fundamental as many are claiming, why
> is it not an error condition to have subnet and IID length of other than
> 64?  I believe only SLAAC would think a prefix other than /64 with an A
> flag is an error, and it just doesn't generate an address..  Further,
> even if it doesn't generate an address it still supposed to treat the
> prefix as on-link if that flag is set regardless of its length. 

At the time of MAC-based IIDs, the reason for which SLAAC would give up
is that SLAAC only new how to create Modified EUI-64 IIDs. As such, give
any other prefix length, it wouldn't know how to create an IID. With
RFC7217, this is would be trivial.

> most node implementations allow the static configuration of prefixes,
> and therefore IIDs, of any length. To me, all of this makes it
> abundantly clear that, with the exception of SLAAC, the 64 bit IID is an
> operational dictum, not a protocol requirement.    

Agreed.

> boundary, I point them out as things that need better explanations.

Agreed.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jun 2018 18:18:47 +0300

> software implementation to continue to hardcode 64 as the IID length for

Unless such applications behave like that after checking the upper three
bits of the prefix, then that's very bad behavior, since they are
enforcing this 64-bit-IID restriction on *all* of the address space.

Tell you what is going to happen if .e.g. we were to allow for
variable-length addresses (or even some non-64-bit fixed IID) in such
other parts of the address space: it wouldn't work, because hardcoding
the value "64" in paces where they shouldn't.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jun 2018 11:15:31 +1200

> software implementation to continue to hardcode 64 as the IID length for

I think implementations will change when the market demands a change,
and that's largely out of the IETF's hands. I also think we're in a
stronger position if our documents are self-consistent and match
reality, which is why I'm looking forward to David Farmer's draft.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Jun 2018 13:00:38 +0200

> I again really disagree. Experience will dictate what has to be
> done. As others have explained recently, situations such as car
> networks have already shown that subnetting with longer prefixes
> is desirable. Pretending that everyone is getting /48s allocated
> is not reality, and it seems unlikely to become more true in the
> future.

You give the arguments why the hard boudary is required.

The total space of /64s is big enough that every subnet can have its own
/64. That's not a technical problem. Yet someow people manage to create
situations where you want to subdivide a /64. 

At the same time all RIRs have policies that allow customers to get a /48.
We have enough /48s that every customer can get one.

There is no technical problem to solve. We have enough /48s. A /48 is in
general big enough to give every subnet a /64. 

By removing the 64 bit boundary and making it work across all platform just
causes a race to the bottom. 

There is no technical reason why operators would provide customers with 
long prefixes. So there is no reason to assume that they will stop before
reaching the bottow.

Personally I don't like SLAAC with pseudo-random IIDs. So in that sense
letting the race to the bottow happen to kill of SLAAC would be a good
thing. But I don't think the resulting chaos would be good for the (IPv6)
internet.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Jun 2018 16:51:22 +0200

>What do you do if all you got is a /64, and you want/need to subnet?

What do you do if all you got is a /128 and you want/need to subnet?

What you do you with a /120 prefix? Just generate a pseudo-random 8-bit IID
and hope for the best?

---

From: S Moonesamy <[email-masked]>
Date: Sat, 23 Jun 2018 05:38:30 -0700

Hi Philip,
>causes a race to the bottom.

For the sake of disclosure, I'll mention that I am affiliated with Afrinic.

There was a discussion about recommendations of the IETF about IPv6 
address assignments and it ended with a RFC 6177.  I suggest reading 
the summary of that discussion (in Section 5).

Regards,
S. Moonesamy

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Jun 2018 19:51:02 +0200

>the summary of that discussion (in Section 5).

Unfortunately, RFC 6177 contains exactly the worrying arguements that
should encourage drawing a line in the sand and keeping the 64 bit
boundary.

The IETF had clear technical ideas why customers should get a /48.

It is possible that the IETF mis-understood operational concerns. However,
RFC 6177 does not discuss clear operational problems with /48. Instead
we get the following text:

"While the /48 recommendation does simplify address space management
"for end sites, it has also been widely criticized as being wasteful.
"For example, a large business (which may have thousands of employees)
"would, by default, receive the same amount of address space as a home
"user, who today typically has a single (or small number of) LAN and a
"small number of devices (dozens or less).

It is clear that operators consider bits to precious without any operational
reason behind that. What are the benefits of providing customers with
longer prefixes? We don't know.

So reality is that operators cannot know what a customer really needs. They
have some model of what a customer should need according to them, and the
possibility to upsell.

So instead of having clear guide lines that customers need to get a /48,
we now have a discussion on subdividing /64s.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sat, 23 Jun 2018 20:12:45 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Saturday, June 23, 2018 10:51

> What you do you with a /120 prefix? Just generate a pseudo-random
> 8-bit IID and hope for the best?

There are many examples when sequential 8-bit IIDs would work just fine. No need to assume that the IID must always be random. All it needs to be is unique, in that subnet.

It seems to me that we are attempting to base the entire addressing model of IPv6 on one use case. Almost like if IPv6 is only for smartphones in public venues. Subnetting flexibility can be very important, yet we have no instruction stating that all allocations must have prefix lengths less than or equal to 48, or even 56. And we know that this is not happening in the real world.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Jun 2018 08:49:43 +1200

Philip, your message is mighty like a straw man.

> By removing the 64 bit boundary

Nobody is proposing that.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Jun 2018 08:56:06 +1200

> What do you do if all you got is a /128 and you want/need to subnet?

Nobody is advocating that.

> What you do you with a /120 prefix? Just generate a pseudo-random 8-bit IID

You're clearly in a context where you don't care about either IID guessability or scanning attacks, so you could use any method whatever for assigning IIDs.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Jun 2018 09:16:02 +1200

On 24/06/2018 05:51, Philip Homburg wrote:
> It is clear that operators consider bits to precious... 

That's true. These are operators who were more or less literally
traumatised by the IPv4 addressing crunch, and who see that variable
length addressing would have avoided this problem for ever. I remember
some very violent arguments in the mid-1990s with operators who felt
that using fixed length addresses in IPv6 was a major blunder. This is
the same argument, except that now it's about variable length prefixes,
which prolonged IPv4's life by at least twenty years.

> ... without any operational
> reason behind that.

That's false; the reason is their IPv4 experience.

> What are the benefits of providing customers with

That's distorting the argument, which is about the risks of
making assignments too rigid and the possible long-term downsides.

> we now have a discussion on subdividing /64s.

No. Again, nobody is proposing changing the current /64 boundary, for
the current provider/subscriber type of network. It works, there are
practical benefits to a standard IID length for SLAAC, and there's no
realistic prospect of prefix shortage in 2000::/3.

But we have no idea what the future will bring or what the IoT will
really turn out to be. A few moments' thought shows that the edge networks
for moving vehicles and fixed roadside infrastructure will be nothing
like existing provider/subscriber networks, for example. For those
networks we need total flexibility in the design space; a magic
boundary at /64 looks like premature ossification to me.

I have no idea what the SAIL and LAP values for a generic IoT network
might be, but I see no reason to believe they will be 64.

     Brian

---

From: joel jaeggli <[email-masked]>
Date: Sat, 23 Jun 2018 17:25:32 -0700

> What do you do if all you got is a /128 and you want/need to subnet?
I ask  myself that every time I encounter stateful dhcpv6...

When you're attached to a /64 you also have that problem without PD of
how to subnet.

bridging is of somewhat dubious utility, especially if 802.1x is involved.
> What you do you with a /120 prefix? Just generate a pseudo-random 8-bit IID
I would presume that someone assigning prefixes that long has some goal
other than address conservation.

On such example might be neighbor exhaustion protection.

I'm dubious that such an approach  indeed an long prefix length is
generally appropriate for devices trying to use privacy address-like
mechanisms, as a datacenter/application operator, however I certainly
have hosts which do not.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jun 2018 10:22:36 -0400

Brian E Carpenter <[email-masked]> wrote:
    > really turn out to be. A few moments' thought shows that the edge
    > networks for moving vehicles and fixed roadside infrastructure will be
    > nothing like existing provider/subscriber networks, for example. For
    > those networks we need total flexibility in the design space; a magic

    > might be, but I see no reason to believe they will be 64.

Real (non-wifi-connected camera stuff) IoT networks are not based upon
emulating the 25yr obsolete 10base2 Coax cable the way that 100G ethernet
still is.

Current technology, (RFC6550-ROLL, but also if you use OLSRv2,
BABEL, and even LOADNG), assigns a /128 to each IoT node from within
a /64, and routes the /128.  The network size is not limited by routing table
size of the smaller nodes, but by the routing table size of the largest
nodes.

The /64 boundary is useful within 2000::/3 and ULA-space, because it becomes
the natural aggregation point beyond which routing information is always
summarized.

The real problem is that people are clinging to ethernet and wifi as
broadcast media, when they haven't been that for decades: it's all layer-2
tricks caused by a shortage of IPv4 for subnetting.

If you can give that up, then the things go straight down to the bottom
*immediately*, with /128 per-host with /128 routing, and layer-2 and layer-3
becoming blurred, and IPv4 being mapped into IPv6-only networks.
IID generation still works, and you still need to allocate at least a /64 per
home, but the L bit is always 0.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 24 Jun 2018 19:00:51 +0200

Le 24/06/2018 à 16:22, Michael Richardson a écrit :
[...]

> ----------------MESSAGE ORGINAL ci-dessous------------------
> 
> 

Other IoT networks do use Ethernet, SLAAC and do need growth beyond 64.

For example, an IoT Router that connects a car to the Internet.  The car 
network is made of more than 2 segments of Ethernet subnets.  The main 
access to Internet is cellular.  The device that does it is called "IoT" 
device by manufacturer, because it is small and has sensors too.  There 
is a tiny Ethernet RJ45 involved too.

Other smartphones, glasses and watches are also called 'IoT' by their 
manufacturers and use SLAAC.

NB-IoT devices equipped with Ethernet RJ45 are also hindered by 64.

Refs available upon request.

> a /64, and routes the /128.

That assignment is a kind that is not SLAAC.

Maybe that is a difference that makes it not be bothered by 64.

Alex

>  The network size is not limited by routing table

---

From: Philip Homburg <[email-masked]>
Date: Sun, 24 Jun 2018 20:24:55 +0200

>Nobody is proposing that.

If you think there is consensus on keeping the 64 bit boundary then I wonder
why we are still not done with this discussion.

How hard is it to write something to the effect that for the purposes of
SLAAC an IID is always length 64?

What I see is a group that wants to start a race to the bottom today and
another group that want to have the option of starting a race to the bottom
tomorrow.

Both groups would disagree with hardcoding 64-bit IIDs in the IPv6 address
architecture. Or even in SLAAC.

> length addressing would have avoided this problem for ever. I
> remember some very violent arguments in the mid-1990s with operators
> who felt that using fixed length addresses in IPv6 was a major
> blunder. This is the same argument, except that now it's about
> variable length prefixes, which prolonged IPv4's life by at least
> twenty years.

So basically you are saying we put traumatised operators in charge of making
sure that end users get enough addresses? What could possibly go wrong.

> That's false; the reason is their IPv4 experience.

IPv4 was already predicted to run out before most operators were even offering
IPv4 access. If anything, IPv4 is lasting longer than anyone expected.

> That's distorting the argument, which is about the risks of making
> assignments too rigid and the possible long-term downsides.

As far as I know, there are no serious computations of those risks. Just
a bit of handwaving: lots of device, therefor risk. 

> networks for moving vehicles and fixed roadside infrastructure will
> be nothing like existing provider/subscriber networks, for example.
> For those networks we need total flexibility in the design space;
> a magic boundary at /64 looks like premature ossification to me.
> 
> I have no idea what the SAIL and LAP values for a generic IoT
> network might be, but I see no reason to believe they will be 64.

Just a small back of the envelope calculation.

Let's assume we assign one /64 per subnet. Howmany IoT devices would that
support when we run out.

To keep it simple I assume an average of one IoT device per subnet. In reality
we can expect many IoT devices per subnet. At the same time, there will be
some inefficiency in allocating subnets. I assume those effects will cancel
each other out and we can support 2**64 IoT devices. That's 1.8e19 devices.

Let's assume in the near future a workld population of 10 billion, or 1e10.

So we have 1.8e9 devices per person. If assume an average lifetime of 10 years,
then we have a replacement rate of 1.8e8 per year, or 5.1e5 per person per day.

In other words, we run out of /64s when everybody in the world is installing 
half a million IoT devices per day.

(Bringing back the good old 'H ratio' (RFC 1715), then with an H ration of
.25, which I have to admit is called optimistic, we would still allow 200
new IoT devices to be installed per person per day with an average lifetime
of 10 year).

Maybe the people who want to conserve bits can come up with a plausible
prediction of when we are expected to run out of 2000::/3

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 10:06:22 +0900

The whole arguments depend on the definition of subnet. What if, over time, you want to divide a subnet thus formed into multiple sub-subnets?

There might be many cases wherein you might want this sub-subnetting:

  o Your home was given a /64, but you’re now about to install a number of IoT islands of each member devices are of different types and for different application purposes; you want to separate each IoT islands into separate sub-subnets.

  o That need might be dynamic so that you want to try those IoT island trials at one time and kill them at another time, i.e., trial and error.

  o You don’t want to bother to ask your upstream whomever to assign you more /64’s, for that job might sometimes be troublesome and just irritating; some upstream provider of yours might be technically ignorant, not competent, stubborn for no reason, and you don’t bother arguing with those losers. Depending on where you live in on this globe, your upstream guy might not be as civilized as those living in blessed part of the globe.

  o If the 64 bits have to be used only for IIDs, that sub-subletting I might like to try is out of the question. Why not let me move the boundary so that I can form multiple sub-subnets in my trial field.

  o You might say that I should configure each IoT’s manually, not using SLAAC or something like that line, but that’s also out of the question, for the total number of my devices could be huge and I do want to benefit from open-source codes so that I concentrate on the IoT applications rather than Internet management.

This might be just one example, but ossifying the boundary might be hindering yet-to-come wild innovative applications we can hardly imagine at this point of time.

---
DY

> On 25 Jun 2018, at 03:24, Philip Homburg <[email-masked]> wrote:
>

---

From: James R Cutler <[email-masked]>
Date: Sun, 24 Jun 2018 21:14:25 -0400

> On Jun 24, 2018, at 9:06 PM, DY Kim <[email-masked]> wrote:
> 
> 

This assumes that your ISP is not following the recommendation to delegate a /56 prefix for local use. Many do so.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2018 13:29:17 +1200

> This assumes that your ISP is not following the recommendation to delegate a /56 prefix for local use. Many do so.

Also, I don't believe anybody is proposing to change the recommendation to
delagate *at least* a /56. My ISP, like many others, delegates a /48.

   Brian

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 10:31:33 +0900

Do you mean /56 for each household user?

---
DY

> On 25 Jun 2018, at 10:14, James R Cutler <[email-masked]> wrote:
> 
> This assumes that your ISP is not following the recommendation to delegate a /56 prefix for local use.

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 10:32:57 +0900

Has your home got a /48?

---
DY

> On 25 Jun 2018, at 10:29, Brian E Carpenter <[email-masked]> wrote:
> 
> My ISP, like many others, delegates a /48.

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 10:59:27 +0900

A novice question already answered in this ML:

  o What prefix does your cellphone get from your mobile operator? /56? /48? Or just a /64?

---
DY

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2018 14:08:12 +1200

> Has your home got a /48?

Yes. It's temporary, i.e. I get a new one if the modem has to
reconnect; a static address would presumably cost extra.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 25 Jun 2018 02:19:12 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> Also, I don't believe anybody is proposing to change the recommendation
> to delagate *at least* a /56. My ISP, like many others, delegates a /48.

Perhaps, but all of these arguments are quite unconvincing. We are using the simplest examples today, to deliberately limit what we can do in the future. The most telling is the idea that IP addresses should be thought of as something assigned to individuals, who will then assign them to things in their house.

We could assign a /64 to every bridge, and then subdivide that into separate networks for each component part of the bridge, right down to strain gauges on each bolt and rivet. V2I communications for autonomous vehicles, the "I" aspect, would similarly consume huge address space, not related to individuals. In the vehicles themselves, the address space is organized into separate subsystems, with routers/firewalls to protect each subsystem. There's no telling how deep this architecture will go, in the future.

Besides, we've been here before! We had exactly the same myopia with IPv4, thinking that IP addresses were to be related to mainframe computers. The 32 bits seemed so ample. Well, that didn’t last long. Today, we are thinking in terms of "people." Why? I'd rather think in terms of rivets.

Bert

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 11:23:28 +0900

Good.

To be frank, I live in an uncivilized country; no ISP providers in Corea are in full operation of IPv6 addresses. My home has a Gigabit connection to KT, but no IPv6 addresses. I’m not sure whether KR ISP’s are operating IPv6 in their backbones, but yet no IPv6 provision to customers. KR is yet an IPv4 island, I’m afraid.

KR has acquired some over 5K /32 blocks, but perhaps as a reserve for future use.

  https://한국인터넷정보센터.한국/jsp/eng/ipas/statistics/ipV6.jsp

Perhaps, I’m personally not qualified for IPv6 discussions…

---
DY

> On 25 Jun 2018, at 11:08, Brian E Carpenter <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Mon, 25 Jun 2018 11:52:52 +0900

Not even for my iPhone 7.

Even if they will, a KT tech engineer says all they provide would be a /128 for a cell phone.

Simply disastrous of KR?

---
DY

> On 25 Jun 2018, at 11:23, DY Kim <[email-masked]> wrote:
> 
> Good.
>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Jun 2018 21:59:12 -0600

>   o What prefix does your cellphone get from your mobile operator? /56? /48? Or just a /64?
LTE 3gpp release  8 style networks don't do prefix delegation, the /64
on your interface is the one you get.

Arguing by example isn't maybe so useful if you'de  like them in the
future  to do something different then what they did in 2009.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Jun 2018 08:36:28 +0200

I will suggest reading RIPE690

https://www.ripe.net/publications/docs/ripe-690

A cellular phone usually will get a /64 for each PDP context.

Regards,

Jordi

-----Mensaje original-----

De: ipv6 <[email-masked]> en nombre de DY Kim <[email-masked]>

Fecha: lunes, 25 de junio de 2018, 4:00

Para: 6man WG <[email-masked]>

Asunto: Re: SAILing LAPs

    ---

    DY

    [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Jun 2018 11:27:33 +0200

I had private email with Michael.

He explained it better to me.

I agree with most points he makes: Ethernet and WiFi on IoT devices are
so used to /64 and SLAAC, which make for a 64 problem. Yet these same
IoT devices could work with host-based routes too. If they did, there
would be no /64 problem.

He rightfully points to a particular protocol that would work and that
has no /64 problem and that does not use SLAAC. It's RPL.

On my particular IoT context, I can not consider RPL.

But I do agree with Michael's technical points.

Alex

Le 24/06/2018 à 19:00, Alexandre Petrescu a écrit :
>>      > But we have no idea what the future will bring or what the IoT 
>> will
>>      > really turn out to be. A few moments' thought shows that the edge
>>      > networks for moving vehicles and fixed roadside infrastructure 
>> will be
>>      > nothing like existing provider/subscriber networks, for 
>> example. For
>>      > those networks we need total flexibility in the design space; a 
>> magic
>>      > boundary at /64 looks like premature ossification to me.
>>
>>      > I have no idea what the SAIL and LAP values for a generic IoT 
>> network
>>      > might be, but I see no reason to believe they will be 64.
>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 25 Jun 2018 08:00:28 -0700

On Sun, Jun 24, 2018 at 11:36 PM, JORDI PALET MARTINEZ <
jordi.palet=[email-masked]> wrote:

> Which means that cell phones are typically getting a persistent prefix.
That is very easy to track on the Internet and scenario randomizing IIDs
for privacy has little effect to mitigate that.

I think this underscores what might be missing from this thread. Addresses
are no longer simple identifiers for end points of communication and
prefixes don't necessarily define actual subnets (like in the celluar phone
case). There are a host privacy and security expectations on them. For
instance, there are arguments that sparse allocation is necessary to deter
address scanning. Periodically changing addresses is recommended for
improved privacy. Or, there have been proposals that each flow get its own
IP address to help privacy. Taking these into consideration, I doubt 64
bits addresses would be sufficient. Maybe 128 bits is if used wisely.

Tom

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

---

From: DY Kim <[email-masked]>
Date: Tue, 26 Jun 2018 01:15:41 +0900

This means… if I’d turn my cell phone into a router to manage local children IoT devices, I can form only one subnet. The sub-subletting I mentioned in an earlier example would be out of the question. Nested subnetting wouldn’t be possible unless the requirement for IIDs to be 64 bits be relaxed.

---
DY

> On 25 Jun 2018, at 15:36, JORDI PALET MARTINEZ <[email-masked]> wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Jun 2018 18:38:56 +0200

Specs support DHCPv6-PD in cellular networks for that. When really needed, operators/vendors will do, in fact is being done when you have instead of a cellular smartphone a cellular broadband router.

Regards,

Jordi

-----Mensaje original-----

De: DY Kim <[email-masked]>

Fecha: lunes, 25 de junio de 2018, 18:15

Para: JORDI PALET MARTINEZ <[email-masked]>

CC: 6man WG <[email-masked]>

Asunto: Re: SAILing LAPs

    ---

    DY

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 25 Jun 2018 18:05:02 +0000

> This means… if I’d turn my cell phone into a router to manage local children IoT devices, I can form only one subnet. The sub-subletting I mentioned in an earlier example would be out of the questi…

Yes. And this is also true for customers of fixed wireless. Suggestions of what ISPs “should” do are thoroughly unhelpful when faced with reality. 
Barbara 

> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=6OSmqa2TnPHqG5iYZFJ9cZFbwNm58-IMiMt7Z-EgfZI&s=hfWG-OHWgfuvO_j5H1kWxspm2OcTpikGlAwS1XEQLaQ&e=

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 25 Jun 2018 18:10:52 +0000

> On Jun 25, 2018, at 12:40 PM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

I’ll believe that when I see it actually deployed. I haven’t seen any wireless deployments with dhcpv6 ia_pd. So I don’t believe. 
Barbara 

> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.consulintel.es&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Qnwf-4oo2Cp2gzs8DtRUlnZ_q8RF5aKQyBKHrL7OVpU&s=4TrAPzInsHVdqtBgHoBmZSDwL8PlnNYEGDll62AfPPs&e=
> The IPv6 Company
> 
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Qnwf-4oo2Cp2gzs8DtRUlnZ_q8RF5aKQyBKHrL7OVpU&s=BvXbdl9KMKUNoHc5XfCKSfIedpp8VY8cZc6RK6gBZDE&e=

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jun 2018 09:02:28 +1200

> Yes. And this is also true for customers of fixed wireless. Suggestions of what ISPs “should” do are thoroughly unhelpful when faced with reality. 

Perhaps this could be described as "the Great Rediscovery of variable length
subnet masks and classless addressing of 2018"?

The great advantage of IPv6 over IPv4 is that we have the luxury of
adding the concept of a shortest acceptable identifier length to
the old concepts of VLSM and CIDR.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Mon, 25 Jun 2018 15:28:02 -0600

> It seems to me that we are attempting to base the entire addressing model of IPv6 on one use case. Almost like if IPv6 is only for smartphones in public venues. Subnetting flexibility can be very i…

When I see proposals such as 
https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03
(disclaimer I'm listed as a contributor on that one). I don't see the
motivation as address conservation. nor do I see very long prefix
assignments (down to 128 for example) as being unaligned with addressing
privacy or sparseness goals,  they may well be associated with better
scaling particularly around L2 signaling or better yet eliminating it.

We for example allocate /127s for peering circuits as /64  assignments 
(there's a /44 set aside for those in our IPAM system).

One particular problem that  I believe that this working group is
committed to addressing is protecting router control planes from
resource exhaustion, neighbor discovery being a place where threat of
resouce consuption can be particularly accute.

In order to discuss the intersection of this problem and how I
understand operators and standards work have tried to address them I
have quickly thrown together a document.

https://datatracker.ietf.org/doc/draft-jaeggli-v6ops-indefensible-nd/

Which is one case where I believe longer subnet masks are a legitimate
expression of how one might address the behavior of neighbor discovery.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 25 Jun 2018 16:11:19 -0600

> the old concepts of VLSM and CIDR.
When you're dealing with a loopback or more generally with a route it's
not clear to me why there would be any consideration that there might be
a situation where acceptable prefix length differed from the ability to
route on it. and I would apply that assumption to IIDs.

in our case we bind

          inet6 addr: 2a04:4e42::/32 Scope:Global

to a loopback interface so a host can answer for any of those IPs.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jun 2018 13:24:11 +1200

> route on it. and I would apply that assumption to IIDs.

There might be good reasons unconnected with routing why a site might
choose a shortest *acceptable* prefix other than the default value.
Privacy and scanning attack concerns might lead to as long as possible;
compressibility and the ND attack issue might lead to as short as
possible.

Anyway it feels more and more like an operational parameter whenever
I think about it, architecturally constrained by LAP+SAIL <= 128.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 Jun 2018 12:07:38 +0200

>https://datatracker.ietf.org/doc/draft-jaeggli-v6ops-indefensible-nd/

Can you explain how you expect SLAAC to work with a /120 prefix? 

Note that draft-bourbaki-6man-classless-ipv6-03 suggests that in the context
of SLAAC, the IID length could be reduced to 48 bits. But that doesn't help
with attacks on neighbor discovery.

In the context of DHCPv6, then are no particular problems which allocating
addresses from a /120 prefix. 

Just like it was a good idea to have a fixed /48 prefix length that allows
you to swap one /48 for another without affecting local subnet numbering,
it is also a good idea to assign a /64 to each subnet. Even if you would
number hosts out of a /120, having a /64 makes it possible to switch to a
different technology at a later stage without having to renumber subnets.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Jun 2018 10:30:31 -0600

On 6/26/18 4:07 AM, Philip Homburg wrote:
> r
In the datacenter operations context, which is where I work mostly I
don't see SLAAC as a particularly appropriate technology. Beyond the
bootstrap configuration of manangement interfaces most address
configuration is mananged by configuration an provisioning systems, and
in some cases things that we might call SDN controllers.
> with attacks on neighbor discovery.
Yeah it does not.
> different technology at a later stage without having to renumber subnets.
Renumbering doesn't have to be a huge issue. it's clear that in some
cases it is just like in v4.  Cloud networking has made a lot of people
a lot more comfortable with relatively ephemeral addresses. That said
that I completely agree that defensible network address assignment is
not to my mind a misguided attempt at address conservation.

If one takes prefix per host work to it's logical conclusion, routing to
a host and attaching a   prefix, perhaps a 64 possibly longer or shorter
depedning on the application on a loopback, those addresses do not have
to be defended by DAD, don't have to be discovered on the upstream
router using ND, and can be employed ephemerally without incurring
signaling costs beyond the single routing table entry.

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Jun 2018 19:39:06 +0200

> On 26 Jun 2018, at 18:30, joel jaeggli <[email-masked]> wrote:
> 

We had a student test this on wireless a few years ago and write a paper. We dubbed this p2p Ethernet. Solved the problems with ND, energy consumption etc. Requires routing to the edge or a somewhat tight integration with l2 devices. 

Cheers 
Ole

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Jun 2018 11:51:08 -0600

> We had a student test this on wireless a few years ago and write a paper. We dubbed this p2p Ethernet. Solved the problems with ND, energy consumption etc. Requires routing to the edge or a somewha…
We deploy bgp advertised, loopback installed, host prefixs within
datacenters, so yes we also have some exposure to this methodology.
> Ole
yep

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 26 Jun 2018 23:58:47 +0100

> Can you explain how you expect SLAAC to work with a /120 prefix?

I don't think anyone would expect this to work properly?

There are plenty of ways of shooting yourself in the foot.  For example, 
you can specify a DHCP lease time of 1 second, which is an enormously 
silly thing to do in most cases, but does that mean that variable length 
dhcp leases are intrinsically dumb?  Of course not.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Jun 2018 00:11:53 +0100

> different technology at a later stage without having to renumber subnets.

It's very frustrating when people imply that ipv6 renumbering is 
straightforward on the basis that the IID doesn't change.  This claim 
has no basis in production reality.

If your network is based on SLAAC, then it's easy to renumber because 
the network uses an autoconfiguration mechanism which supplies the 
prefix and the prefix length and changing this is a simple one-line 
affair on a single device.  The choice between static or variable length 
subnet masks has little or nothing to do with the difficult of 
renumbering in this situation because Prefix Length is a parameter which 
is supplied in the ND protocol, and which could be changed.

The difficulty with renumbering relates to how to reconfigure all of the 
devices where the address / netmask tuple has been pinned down manually. 
  E.g. in an isp provisioning system, or on HR's printer configuration 
on their laptops, or on the corporate firewalls or whatever.

We need to consign the "ipv6 makes renumbering easy" canard to the bin. 
It's not easy and never will be except in cases where there is strict 
host-initiated autoconfiguration, and in that situation the presence or 
absence of a netmask is of nearly zero concern because it makes no 
difference whatever to renumbering.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Jun 2018 00:18:02 +0100

Ole Troan wrote on 26/06/2018 18:39:
> We had a student test this on wireless a few years ago and write a
> paper. We dubbed this p2p Ethernet. Solved the problems with ND,
> energy consumption etc. Requires routing to the edge or a somewhat
> tight integration with l2 devices.
this would have been a very nice architecture, multicast problems 
notwithstanding.  Sadly, if we had wanted this in ipv6, it would have 
been necessary to have had it in ipv4 too, because moving from a shared 
broadcast domain-style network with a layer2-layer3 interface mechanism 
would have been too much of a conceptual jump when moving from ipv4 to 
ipv6.  Alas!

Nick

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jun 2018 10:18:10 +1000

> On 27 Jun 2018, at 9:11 am, Nick Hilliard <[email-masked]> wrote:
> 
> It's very frustrating when people imply that ipv6 renumbering is straightforward on the basis that the IID doesn't change.  This claim has no basis in production reality.
> 
> If your network is based on SLAAC, then it's easy to renumber because the network uses an autoconfiguration mechanism which supplies the prefix and the prefix length and changing this is a simple one-line affair on a single device.  The choice between static or variable length subnet masks has little or nothing to do with the difficult of renumbering in this situation because Prefix Length is a parameter which is supplied in the ND protocol, and which could be changed.
> 
> The difficulty with renumbering relates to how to reconfigure all of the devices where the address / netmask tuple has been pinned down manually.  E.g. in an isp provisioning system, or on HR's printer configuration on their laptops, or on the corporate firewalls or whatever.
> 
> We need to consign the "ipv6 makes renumbering easy" canard to the bin. It's not easy and never will be except in cases where there is strict host-initiated autoconfiguration, and in that situation the presence or absence of a netmask is of nearly zero concern because it makes no difference whatever to renumbering.

It can be done easier than it currently is being done.

Hosts can securely update their own addresses in the DNS.  This is
done in AD and can just as easily be done in none AD scenarios.  Just
add a KEY (RFC 2535) record to the DNS with a public key for the node
at the nodes name and use SIG(0) (RFC 2931) to sign the UPDATE (RFC 2136)
request to update the address records.

There is a DNS implementations that take UPDATE access control down to the
individual name and type level using the mechanisms listed above and have
supported doing this for more than a decade now.

It is also possible use SIG(0) to authenticate update requests at or below
the SIG(0) name to allow for adding underscore prefix entries.  You can
securely add node TLSA records that way.

Unfortunately NAT made doing most of this moot with IPv4 but the capability
was there.  IPv6 changes the picture as GUA can be assigned to all nodes.

SIG(0) can also potentially be used to perform automated delegations in the
IP6.ARPA tree along with PD.  draft-andrews-dnsop-pd-reverse describes such
a mechanism.

Mark

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 27 Jun 2018 09:42:27 +0200

> I don't think anyone would expect this to work properly?

On linux it does not work.

I continue to look for somebody to help make it work on linux kernel.

A 3-day effort by a beginner kernel programmer was not successful.  He 
did find the SLAAC places in the kernel where '64' is a constant. 
However, making it '65' is not straightforward.  He did not succeed.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Jun 2018 10:57:03 +0100

Do you mind if I quote this in future as an example of how renumbering 
is easier with IPv6?

Nick

Mark Andrews wrote on 27/06/2018 01:18:
> done in AD and can just as easily be done in none AD scenarios.
> Just add a KEY (RFC 2535) record to the DNS with a public key for the
> node at the nodes name and use SIG(0) (RFC 2931) to sign the UPDATE
> (RFC 2136) request to update the address records.
> 
> There is a DNS implementations that take UPDATE access control down
> to the individual name and type level using the mechanisms listed
> above and have supported doing this for more than a decade now.
> 
> It is also possible use SIG(0) to authenticate update requests at or
> below the SIG(0) name to allow for adding underscore prefix entries.
> You can securely add node TLSA records that way.
> 
> Unfortunately NAT made doing most of this moot with IPv4 but the
> capability was there.  IPv6 changes the picture as GUA can be
> assigned to all nodes.
> 
> SIG(0) can also potentially be used to perform automated delegations
> in the IP6.ARPA tree along with PD.  draft-andrews-dnsop-pd-reverse
> describes such a mechanism.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jun 2018 00:39:20 +1000

I’m saying it could be easier if OS vendors integrated code to do this
and with IPv6 there is a reason to do so.  People have been doing this
with home grown DHCP client hooks for years now.  It just needs to
become a standard part of the OS.

Simple policies to allow a machine to update its own addresses
from BIND (named).

SIG(0) or TSIG
zone example.org {
	...
	update-policy { grant * self . A AAAA; };
};

AD
zone example.org {
	...
	update-policy { grant * ms-self . A AAAA; };
};

Samba
zone example.org {
	...
	update-policy { grant * krb5-self . A AAAA; };
};

If you want to allow for prefix updates replace “self” with “selfsub”.
The type list can be empty (most types) or ANY.

A more complicated policy which allows the machine to update its A and AAAA
records and any TLSA records in prefix names.  It also allows the “admin”
TSIG key to update any record in the zone which is used to install KEY
records for machines.

key “admin" {
        algorithm hmac-sha256;
        secret “XXXXXXXXXXXXXXXXXX";
};

zone example.org {
	...
	update-policy {
		grant admin subdomain * ANY;
		grant * self . A AAAA;
		grant * selfsub . TLSA;
	};
};

> On 27 Jun 2018, at 7:57 pm, Nick Hilliard <[email-masked]> wrote:
> 
> Do you mind if I quote this in future as an example of how renumbering is easier with IPv6?
> 
> Nick
> 
>> Hosts can securely update their own addresses in the DNS.  This is done in AD and can just as easily be done in none AD scenarios.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jun 2018 13:50:46 -0500

> On Jun 26, 2018, at 6:11 PM, Nick Hilliard <[email-masked]> wrote:
> 

Thanks for pointing this out. When we were writing what is now RFC 4192, I think you and I spoke at some length on this exact topic. The introduction of that note starts out:

   The Prussian military theorist Carl von Clausewitz [Clausewitz]
   wrote, "Everything is very simple in war, but the simplest thing is
   difficult.  These difficulties accumulate and produce a friction,
   which no man can imagine exactly who has not seen war....  So in war,
   through the influence of an 'infinity of petty circumstances' which
   cannot properly be described on paper, things disappoint us and we
   fall short of the mark".  Operating a network is aptly compared to
   conducting a war.  The difference is that the opponent has the futile
   expectation that homo ignoramus will behave intelligently.
...
   This document addresses the key procedural issues in renumbering an
   IPv6 [RFC2460] network without a "flag day".  The procedure is
   straightforward to describe, but operationally can be difficult to
   automate or execute due to issues of statically configured network
   state, which one might aptly describe as "an infinity of petty
   circumstances".  As a result, in certain areas, this procedure is
   necessarily incomplete, as network environments vary widely and no
   one solution fits all.

Yes, static configuration. It's everywhere, and it means that one cannot automatically do very much with addresses or prefixes without taking the static configuration into account.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2018 09:30:32 +1200

We did discuss all this in 6renum. There's still unfinished business
from https://tools.ietf.org/html/rfc7010 and of course prefix-per-host
would add to that list.

Regards
   Brian

On 28/06/2018 06:50, Fred Baker wrote:
> ....

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jun 2018 09:36:44 -0700

Hi Philip,
>RFC 6177 does not discuss clear operational problems with /48. Instead

The assignment policies are developed within each RIR.  The (policy) 
changes could be motivated by economic considerations.

Regards,
S. Moonesamy

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 19:57:55 +0200

I don't really agree with "economic considerations".

I've been (and I'm) active for many years with policy proposals in all the 5 RIRs, and of course following the discussions, and in general, any economic consideration is out of scope. It is mainly about "justification" of the need of the resources.

Regards,

Jordi

-----Mensaje original-----

De: ipv6 <[email-masked]> en nombre de S Moonesamy <[email-masked]>

Fecha: jueves, 28 de junio de 2018, 18:44

Para: Philip Homburg <[email-masked]>, <[email-masked]>

Asunto: Re: SAILing LAPs 

    Hi Philip,

    Regards,

    S. Moonesamy 

    [email-masked]