Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 18:42:46 +0900

On Wed, Mar 1, 2017 at 4:56 AM, Brian E Carpenter <
[email-masked]> wrote:

> > I really don't understand this statement. How can you say that it's a
> > parameter, given that every RFC that has been published on this topic
> > starting from 1998 states that (most) IIDs are 64 bits long?
>
> Yes, I think we have a long tradition of expressing this badly, and now
> is a chance to get it right. It's clear at the point where it's
> introduced in RFC4291 that it's a floating boundary:
>
>   "A slightly sophisticated host (but still rather simple) may
>    additionally be aware of subnet prefix(es) for the link(s) it is
>    attached to, where different addresses may have different values for
>    n:
>
>    |          n bits               |           128-n bits            |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+"
>
> but later in the same document we state that (128-n) == 64. That is
> inconsistent; what we're trying to do now is fix that inconsistency
> in a way that is *also* consistent with running code, SLAAC, and the
> newly important privacy issues that require long, unpredictable IIDs.
>

Ah, I see the disconnect here: you're talking about the addressing
architecture, and I'm talking about unicast addresses assigned to actual
networks. Those addresses are called "all global unicast addresses except
the ones that start with binary 000" in 3513 and 4291, and "aggregatable
global unicast addresses" (specifically, 2000::/3) in 2373.

What I'm saying is that for that latter type of address, the IID length has
always been fixed to 64, and should continue to be.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 18:51:32 +0900

On Wed, Mar 1, 2017 at 5:33 AM, David Farmer <[email-masked]> wrote:

> However many OSes also allow configurations other than just /64, is this
>>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it
>>> that way,
>>>
>>
>> IMO the important question is not "should an OS refuse to configure a /65
>> when manually configuring an address". I think the much more important
>> questions are, "can the OS assume that it can use the full 64 bits to form
>> an IID", and "will this link ever run out of IPv6 addresses". The answers
>> to those should be yes and no.
>>
>
> I don't disagree with your answers, and you may not think the manual
> config question is important, but others seem too.
>

FWIW I wouldn't oppose an exception for manually-configured addresses on
routers.

And you don't have too.  But, your saying no one else can ever have a
> reason to do that, and I'm not so sure about that.  And something on the
> other side of the Internet can't make any assumption about what I'm doing
> anyway.  You are saying it can't be done because the 64 bit boundary is
> even more important than CIDR and addresses on the other side of the
> Internet are supposed to be opaque.  Where as I disagree, CIDR and the
> opaqueness of addresses across the Internet are more fundamental properties
> than 64 bit boundary.  Which is why I say the 64 bit boundary is really a
> RECOMMENDATION.  And CIDR and the opaqueness of addresses across the
> Internet are REQUIREMENTS.
>

Let's see if there is common ground here. I agree that routers should
forward on arbitrary prefix lengths. It's probably reasonable that hosts
should not make assumptions about other host's IP addresses (except if they
are on the same subnet). But I think a host should be allowed to assume
that its own subnet and its own IID are 64 bits long.

>
>
>> Another thing I think we should avoid is to remove the fixed 64 barrier
>> and open the door to having this debate again and again, once for every new
>> IPv6-over-foo document and once for every new address configuration
>> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the
>> future).
>>
>
> Which is why it time to get this right and saying it is now and forever 64
> isn't right.
>

Do you agree that a fixed boundary is useful or not? For 20 years the
standards have guaranteed that 64 bits of IIDs were available to hosts that
wanted to use them. If we make that barrier mobile, there will be no
guarantee in the standards any more. Who should be allowed to set the
boundary? An IPv6-over-foo document? An address configuration technology
such as SLAAC? An ISP that wants to charge you $1 for every /128 you use?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 18:59:26 +0900

On Wed, Mar 1, 2017 at 4:27 PM, Greg Hankins <[email-masked]>
wrote:
>
> We can never change our
> implementation to be compliant with the proposed text because of the
> operational havoc it would create for our customers.  It's simply
> infeasible
> to impose these kind of addressing restrictions.

The word "change" is incorrect here, because the standard that was current
when Nokia wrote its implementation had pretty much exactly the same
requirement. (The reason for that is that *all* past standards have
contained this language except for RFC 1884, which specified /80, which
won't work in the real world.)

Could you reword your position to take into account that fact?

---

From: [email-masked]
Date: Wed, 01 Mar 2017 11:04:43 +0100 (CET)

> always been fixed to 64, and should continue to be.

Which, as pointed out repeatedly in this discussion, means ignoring
the real world cases of non 64 bit IIDs. Thus I completely disagree
with the "should continue to be".

Steinar Haug, AS2116

---

From: [email-masked]
Date: Wed, 01 Mar 2017 11:09:27 +0100 (CET)

> FWIW I wouldn't oppose an exception for manually-configured addresses on

But you would oppose it for hosts? Then I don't think we're any
further.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 19:09:52 +0900

> with the "should continue to be".

Ok, I'll bite. In all seriousness, what are the concrete use cases of
limiting subnet sizes? So far I've heard:

   - "I only need 3 addresses" (but not "I only need 3 addresses and here's
   why I can't accept 2^64 instead of 3")
   - ND exhaustion attacks

What else? You don't have to list them here, a pointer to a previous
message will do.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 19:13:17 +0900

> But you would oppose it for hosts? Then I don't think we're any

Not sure about that. I suppose it also depends on what manual means. If
it's literally just operators configuring them manually by editing
configuration files that's probably fine, but that's not what you want to
do, is it?

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 01 Mar 2017 10:19:26 +0000

Lorenzo Colitti wrote:
>   * "I only need 3 addresses" (but not "I only need 3 addresses and
>     here's why I can't accept 2^64 instead of 3")
>   * ND exhaustion attacks
> 

* established practice since the 1990s, suggesting that any attempt to
un-ring this particular bell is likely not to succeed.

Nick

---

From: Greg Hankins <[email-masked]>
Date: Wed, 1 Mar 2017 05:44:57 -0500

On Wed, Mar 01, 2017 at 06:59:26PM +0900, Lorenzo Colitti wrote:
>Could you reword your position to take into account that fact?

Call it whatever you want, the point again is that we have customers who have
deployed whatever addressing architecture meets their requirements, and we
can't force them to change it.  It's their network and their address space.

You are correct that other standards had the same requirement, which my
current and all of my former employer's* implementations also ignored for
the same reasons that have been mentioned.  This is a good opportunity
for the -bis revision to reflect the state of operational deployments that
have proven the assumptions in the original standard to be impractical.

Is anyone aware of any implementations that comply with this requirement?

Greg

* Riverstone, Force10, Brocade

--
Greg Hankins <[email-masked]>

---

From: [email-masked]
Date: Wed, 01 Mar 2017 11:58:19 +0100 (CET)

> configuration files that's probably fine, but that's not what you want to

Yes, that is exactly what I want to do. I want to be able to use the
ifconfig command to set an IPv6 address with a netmask different from
64, and to have the corresponding config file entry take effect when
the box is booted or the service restarted.

Steinar Haug, AS2116

---

From: [email-masked]
Date: Wed, 1 Mar 2017 11:58:51 +0100

Greg,

> Is anyone aware of any implementations that comply with this requirement?

There might be some misunderstanding here.
This last call is about a document requested to be elevated from draft standard (deprecated) to Internet standard.

This document cannot be elevated to Internet standard if we added a change that would affect interoperability or require changes in implementations.

What we are arguing over is finding text that balances between ensuring that implementations do the right thing (support all prefix lengths) and allowing existing (SLAAC, NPT66, ILNP) and new mechanisms that assume the 64 bit boundary to exist / be invented. Combine that with trying to enforce the policy boundary of giving half the bits to the network and the other half of bits to the users.

Best regards,
Ole

---

From: [email-masked]
Date: Wed, 1 Mar 2017 12:04:02 +0100

> On 1 Mar 2017, at 11:58, [email-masked] wrote:
> 

And that clearly always have been permitted. E.g. how would you otherwise configure a /128 loopback.
I agree that current text have always been at best ambiguous on this point.

Best regards,
Ole

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 1 Mar 2017 12:23:27 +0100

> On 28 Feb 2017, at 13:04, Alexandre Petrescu <[email-masked]> wrote:
> 
> Finally, there is no advice of what bits to put between fe80:: and a
> 64bit the Interface ID - zeros or ones?  linux says it's a fe80::/64 and
> IIRC BSD says it's a fe80::/10.  The routing entries based on that can
> make for interop problems.

I think there is advice. As I understand, /10 is reserved but only /64 is specified.

RFC 4291 IP Version 6 Addressing Architecture
  2.5.6.  Link-Local IPv6 Unicast Addresses

     Link-Local addresses are for use on a single link.  Link-Local
     addresses have the following format:

     |   10     |
     |  bits    |         54 bits         |          64 bits           |
     +----------+-------------------------+----------------------------+
     |1111111010|           0             |       interface ID         |
     +----------+-------------------------+----------------------------+

Cheers,

Dan

---

From: [email-masked]
Date: Wed, 01 Mar 2017 14:45:03 +0100 (CET)

> the same reasons that have been mentioned.

And will presumably continue to do so, because customers will demand
this functionality in the form of RFPs etc. We are certainly planning
demand this in RFPs.

Steinar Haug, AS2116

---

From: David Farmer <[email-masked]>
Date: Wed, 1 Mar 2017 08:36:34 -0600

On Wed, Mar 1, 2017 at 3:51 AM, Lorenzo Colitti <[email-masked]> wrote:

>>> IMO the important question is not "should an OS refuse to configure a
>>> /65 when manually configuring an address". I think the much more important

I think manually configuration should be OPTION for all hosts , and I'd
RECOMMEND it for routers, but i wouldn't REQUIRE or even necessary
RECOMMEND it for general host. It would be my personal preference that all
host have a way to be manually configured, but OPTIONAL is good enough for
the standard I think.

> that its own subnet and its own IID are 64 bits long.

A host has to actually look at the RA to determine it, and can't just
assume. I'd concede that an RA set to and other than /64 with the "a" flag
set SHOULD be considered a misconfiguration, but it is possible to set RAs
with other than /64, especially if you don't set the "A" flag.  And if you
manually set set the 128 address and it's within the range defined by the
RA then the host SHOULD use it as excepted.  Furthermore, I think a host
configured with an 128 address via DHCPv6 SHOULD work much the same way,
but I'm willing to be convinced otherwise on that.

Now to me that says RAs with /64 are REQUIRED iff (if and only if) the "A"
flag is set.  Otherwise RAs with /64 are RECOMMENDED, but other lengths are
allowed.  Also you MAY manually configure a host with a subnet length in
addition to manually configuring a 128 address, and only in the case were a
host is manually configured with a 128 bit address and there is not
associated manually configured subnet length or there is no associated RA
is it ever ok to assume /64.

Another thing I think we should avoid is to remove the fixed 64 barrier and
>>> open the door to having this debate again and again, once for every new
>> Which is why it time to get this right and saying it is now and forever
>> 64 isn't right.
>>
>

I'll agree there is a 64 bit boundary, I don't conceded it's fixed, it's
only been considered fixed but cause we errantly allow the word required in
RFC4291 and its predecessors, CIDR and the opaqueness of addresses across
the Internet are more fundamental principles than the 64 bit boundary.  The
64 bit boundary is a convenience, a very important convenience, a very
highly RECOMMENDED convenience, but only a convenience.  It doesn't
override CIDR and the opaqueness of addresses across the Internet.

Thanks.
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Wed, 1 Mar 2017 09:08:03 -0600

> override CIDR and the opaqueness of addresses across the Internet.

I'll add;  It is so highly RECOMMENDED and so convenient we deluded
ourselves into thinking it was actually a REQUIREMENT, that actually
overdid the more important concepts of CIDR and the opaqueness of addresses
across the Internet.  The idea that the 64 bit boundary is fixed is a
delusion, an appealing delusion, none the less a delusion.

> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 00:53:49 +0900

> un-ring this particular bell is likely not to succeed.

Can you explain the difference between your reply and "we've been doing it
for 20 years therefore it must be the right thing to do"?

The latter is a a) not a technical argument, and b) not a useful argument
if most of that operational knowledge was formed using IPv4. Given that for
most of the 1990s IPv6 had not been designed, much less operationally
deployed, I assume that you do indeed mean IPv4.

The reason why IPv4 addressing practiced don't necessarily apply in IPv6 is
the protocols are completely different in terms of address availability.
Example: in IPv4, CIDR is an absolute necessity in order not to run out of
space. In IPv6, it's not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 00:56:34 +0900

Yes, there are implementations that rely on the fact that IIDs are
specified to be 64 bits to provide useful functionality. And they are
widely deployed.

I have no objection to a router accepting a /117 prefix length when
configuring an IPv6 address. I do object to making host code that relies on
/64 noncompliant.

---

From: Iván Arce <[email-masked]>
Date: Wed, 1 Mar 2017 13:11:09 -0300

> specified to be 64 bits to provide useful functionality. And they are

I keep reading this on the list and wonder. What are these implementations?

Can we actually enumerate implementations that rely and dont' rely on a
fixed plen of 64 bits? Does a survey about that specific claim already
exist?

FTR: I believe RFC 4291bis SHOULD NOT mandate a fixed 64 bit plen in
general. I think any specific exceptions should be enumerated explicitly
and justified, and that existing behavior of some host OS that does not
adhere to spec should be described in an Informational I-D.

-ivan

-- 
Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
http://www.fundacionsadosky.org.ar
TE: (+54-11) 4328-5164
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E

---

From: Iván Arce <[email-masked]>
Date: Wed, 1 Mar 2017 14:03:08 -0300

El 1/3/17 a las 6:51, Lorenzo Colitti escribió:

> 
>         Another thing I think we should avoid is to remove the fixed 64
>         barrier and open the door to having this debate again and again,
>         once for every new IPv6-over-foo document and once for every new
>         address configuration protocol (today we have SLAAC and DHCPv6,
>         who knows what we'll have in the future).
> 
> 
>     Which is why it time to get this right and saying it is now and
>     forever 64 isn't right.
> 
> 
> standards have guaranteed that 64 bits of IIDs were available to hosts
> that wanted to use them. If we make that barrier mobile, there will be
> no guarantee in the standards any more. Who should be allowed to set the
> such as SLAAC? 

The last paragraph of section "2.5.1 Interface identifiers" in 4291 said:

   The details of forming interface identifiers are defined in the
   appropriate "IPv6 over <link>" specification, such as "IPv6 over
   Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].

The corresponding paragraph in rfc4291bis is:

   The details of forming interface identifiers are defined in other
   specifications, such as "Privacy Extensions for Stateless Address
   Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating
   Semantically Opaque Interface Identifiers with IPv6 Stateless Address
   Autoconfiguration (SLAAC)"[RFC7217].  Specific cases are described in
   appropriate "IPv6 over <link>" specifications, such as "IPv6 over
   Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T
   G.9959 Networks" [RFC7428].  The security and privacy considerations
   for IPv6 address generation is described in [RFC7721].

Don't you agree with that?

-ivan

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Mar 2017 20:30:24 +0100

Let me add one more point here I just tried:

Le 28/02/2017 à 13:04, Alexandre Petrescu a écrit :
[...]
> 64bit the Interface ID - zeros or ones?  linux says it's a fe80::/64
> and IIRC BSD says it's a fe80::/10.  The routing entries based on
> that can make for interop problems.

For information, today on linux a /65 RA is called "illegal" and a /63
RA makes a Host to _not_ configure an address.  What linux wants is a 64
and nothing else.  This is not normal, and it's not programmer's fault.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Mar 2017 20:42:02 +0100

Le 01/03/2017 à 12:04, [email-masked] a écrit :
>>>>> FWIW I wouldn't oppose an exception for manually-configured
>>>>> addresses on routers.
>>>>
>>>> But you would oppose it for hosts? Then I don't think we're
>>>> any further.
>>>>
>>>
>>> Not sure about that. I suppose it also depends on what manual
>>> means. If it's literally just operators configuring them manually
>>> by editing configuration files that's probably fine, but that's
>>> not what you want to do, is it?
>>
>> Yes, that is exactly what I want to do. I want to be able to use
>> the ifconfig command to set an IPv6 address with a netmask
>> different from 64, and to have the corresponding config file entry
>> take effect when the box is booted or the service restarted.
>
> And that clearly always have been permitted.

In a sense yes, but in the sense of the longest-match algorithm this
permission is not that clearcut, because it is over-ridden.

Let me explain an example.

I am permitted to freely add a fe80::1/63 on my linux but the
longest-match algorithm will over-ride my fe80::/63 intention because
the kernel over-rides it with a _by_default_ fe80::/64 prefix it added
there without me asking it.  That _by_default_ is also resisting reboots.

So - yes, it is permitted, but only to be over-ridden by the 64.  In
other words: I am permitted to add a fe80::1/63 and I will be succsefull
in my intention _if_ I also delete the kernel's intention which is there
by default, and that after each reboot.

(in Windows there is a similar thing).

In that sense, I agree with you.

> E.g. how would you otherwise configure a /128 loopback.

In linux /128 is a particular case.  It pops up after an ifconfig if
that ifconfig did not specify a plen parameter.

There are /128s on other interfaces than loopbacks.

There may be a confusion in considering that /128 is a prefix length, or
it just means an address.  DHCPv6 people think a /128 means just one
address, whereas RA people think /128 is something that could be put in
an RA.

> I agree that current text have always been at best ambiguous on this

I agree.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Mar 2017 20:47:51 +0100

> I think there is advice. As I understand, /10 is reserved but only /64 is specified.

Sorry, I dont understand that?

What is the difference?  Why reserving X if only specifying Y?  What 
other concept is similar: is there some other number which is reserved 
and only number+1 is specified?

Why couldnt we just reserve without specifying?  Or specifying without 
reserving?

If we continue with reserving _and_ specifying we continue wasting these 
54bits there.

What are these 54bits for?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Mar 2017 08:48:39 +1300

> Don't you agree with that?

Iván,

That is the basis for Alexandre's suggestion to simply drop the mention
of 64 from the architecture: because it's an implementation parameter.
With my Computer Scientist hat on, I think that's the right thing to do.
With my Pragmatist hat on, I think stating that /64 is recommended is
a more practical approach. Stating that it's required is plain wrong.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Mar 2017 20:53:46 +0100 (CET)

> and nothing else.  This is not normal, and it's not programmer's fault.

Could you please elaborate on the last sentence. What do you mean by "not 
normal"?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Mar 2017 07:10:05 +1100

On 2 March 2017 at 06:48, Brian E Carpenter <[email-masked]> wrote:
> a more practical approach.

"Anything that can be configured can be misconfigured."

https://www.ietf.org/rfc/rfc5505.txt

> Stating that it's required is plain wrong.
>
>     Brian
>
> 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, 2 Mar 2017 10:20:28 +1300

> What are these 54bits for?

Nothing. They are reserved and must be zero. That's quite common in 
protocol design.

Link-local is a special case, because it must be possible to create
an address with absolutely no prior information.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 01 Mar 2017 22:37:22 +0000

Lorenzo Colitti wrote:
> Can you explain the difference between your reply and "we've been doing
> it for 20 years therefore it must be the right thing to do"?
> 
> The latter is a a) not a technical argument, and b) not a useful
> argument if most of that operational knowledge was formed using IPv4.
> Given that for most of the 1990s IPv6 had not been designed, much less
> operationally deployed, I assume that you do indeed mean IPv4.

Kindly stop throwing straw men into this discussion.  This is extremely
unhelpful and is not going to result in anything useful.

Nick

---

From: Iván Arce <[email-masked]>
Date: Wed, 1 Mar 2017 20:07:50 -0300

I agree.

Either not mentioning /64 at all or just saying it is recommended but
leaving the specifics to a "IPv6 over X" specification is better than
bolting a fixed prefix len in the standard.

Incidentally, I think this should have been deprecated in RFC 7136 when
EUI-64 was (sortof) killed.

-ivan

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 02:08:56 -0300

> Don't you agree with that?

To add to what Ivan said, the only text in the "IPv6 over <foo>"
documents that has anything to do with the 64-bit IIDs is the
description of how to come up with Modified-EUI64 identifiers. RFC7217,
the recommended algorithm for forming IIDs, does not employ Modified
EUI64 format identifiers, and formally updates all such RFCs.

For instance, RFC7217 explicitly says:

   2.  The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.

          We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits).

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 09:11:30 +0100

Le 01/03/2017 à 20:53, Mikael Abrahamsson a écrit :
>> For information, today on linux a /65 RA is called "illegal" and a
>> /63 RA makes a Host to _not_ configure an address.  What linux
>> wants is a 64 and nothing else.  This is not normal, and it's not
>> programmer's fault.
>
> Could you please elaborate on the last sentence. What do you mean by
> "not normal"?

It is not normal for linux kernel to complain about a plen==65 in the RA
- it should not complain.  Do you think it is normal?

It is not normal for a linux kernel to _not_ form an IPv6 address when
it receives a plen==63.  It would have been normal to append the IID to
it.  Do you think it is abnormal for a linux kernel to form an IPv6
address when it receives a plen==63?

Alex

---

From: Erik Kline <[email-masked]>
Date: Thu, 2 Mar 2017 17:14:54 +0900

> address when it receives a plen==63?

These statements have zero basis in fact.  The Linux kernel is behaving
according to all currently available (proposed) standards.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 09:24:14 +0100

Le 01/03/2017 à 22:20, Brian E Carpenter a écrit :
>>>> Finally, there is no advice of what bits to put between fe80::
>>>> and a 64bit the Interface ID - zeros or ones?  linux says it's
>>>> a fe80::/64 and IIRC BSD says it's a fe80::/10.  The routing
>>>> entries based on that can make for interop problems.
>>>
>> What is the difference?  Why reserving X if only specifying Y?
>> What other concept is similar: is there some other number which is
>> reserved and only number+1 is specified?
>>
>> Why couldnt we just reserve without specifying?  Or specifying
>> without reserving?
>>
>> If we continue with reserving _and_ specifying we continue wasting
>> these 54bits there.
>>

If so, then it's not a fe80::/10, but an fe80::/64, and we should
refrain from writing fe80::/10 anywhere.

Which brings back the question of why 64?

> an address with absolutely no prior information.

I agree, an LL should be created w/o prior info coming out of the computer.

But, among other requirements, that address should have less privacy
issues too.  In an LL a longer IID (e.g. a 108bit IID) would have better
privacy characteristics than a 64bit IID - resist longer to brute force
attacks.

By the fe80::/10 definition it is allowed to set a 108bit IID in LL, but
by fe80::/64 definition it is not.

In other settings with less computers on a subnet (less privacy
concerns), or less interfaces on a computer (IoT), an IID of length 1
for a LL address would be sufficient, which would make an fe80::/127
relevant as well.  Why must they support fe80::/64 when they dont need
that much?

These questions are all the more important when knowing that many IP
stacks make these numerous fe80::/64 entries in the rt table, by default.

In IPv4 computers their rt table is a clean slate after boot... no need 
to clean.

Alex

>
> Brian
>
>>
>> Alex
>>
>>>
>>>
>>> RFC 4291 IP Version 6 Addressing Architecture 2.5.6.  Link-Local
>>> IPv6 Unicast Addresses
>>>
>>> |   10     | |  bits    |         54 bits         |          64
>>> bits           |
Cheers,
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 09:30:02 +0100

Le 02/03/2017 à 09:14, Erik Kline a écrit :
>
>
> On 2 March 2017 at 17:11, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>

Well... do you have a standard for IPv6 over cellular links?   Or IPv6 
over USB?  I dont.  And I consider linux to act wrongly when being sent 
an RA plen==65 on these links and refusing them as "illegal".

I think it should not refuse it on Ethernet either, but there you have a 
standard RFC2464.  And for that I agree with you.  Even though it should 
be perfectly fine to use that plen==65 to have an entry in the rt table, 
and use a manually configured address in that plen.

I dont have a standard that tells that the computer is forbidden from 
introducing a 0 between 63 and 64 such that the plen==63 plus IID==64 
make for 128.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 02:10:44 -0300

> a more practical approach. Stating that it's required is plain wrong.

+1

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 02:15:55 -0300

On 03/01/2017 08:07 PM, Iván Arce wrote:
[....]
> EUI-64 was (sortof) killed.

Modified EUI-64 should have been killed a long time ago. But Lorenzo has
been very loud in keeping that flawed approach alive.

For instance, RFC8064 recommends against its use for stable addresses,
but leaves the door open for employing Modified EUI-64 if the underlying
link-layer address has been randomized -- a scheme that is still flawed
because, among other things, it unnecessarily wastes 18 bits of entropy
and follows a well-known bad practice of re-using numeric IDs across
different layers and contexts.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 17:46:23 +0900

> Don't you agree with that?

Sure, but that text only specifies the details of how the IIDs are formed,
not how long they are. Right now they are all 64 bits long because other
text in RFC 4291 says that they are.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 17:54:00 +0900

> unhelpful and is not going to result in anything useful.

Let me rephrase the question. I asked for use cases for longer-than-/64
prefixes and listed the ones I have seen so far:

Do you have additional use cases? "This is the way we've done it for 20
years" is not a use case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 17:57:00 +0900

On Thu, Mar 2, 2017 at 2:15 PM, Fernando Gont <[email-masked]> wrote:

> among other things, it unnecessarily wastes 18 bits of entropy
>

If you ever want that argument to be convincing you'll need to explain by
how much the additional 18 bits of entropy benefit real users in realistic
situations.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 10:31:07 +0100 (CET)

On Thu, 2 Mar 2017, Alexandre Petrescu wrote:

> perfectly fine to use that plen==65 to have an entry in the rt table, and use 
> a manually configured address in that plen.

Linux does the right thing in not autoconfiguring itself address(es) when 
plen isn't 64. However, what does it do when it receives an PIO with plen 
of 65 and M=1 and then it gets an IA_NA and configures that on the 
interface? Doesn't it install the /65 in the routing table?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 06:39:59 -0300

On 03/02/2017 05:57 AM, Lorenzo Colitti wrote:
> On Thu, Mar 2, 2017 at 2:15 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> , and> 
> If you ever want that argument to be convincing you'll need to explain
> by how much the additional 18 bits of entropy benefit real users in
> realistic situations.

It's the other way around: if you are randomizing IDs for the sake of
privacy, you should make an argument for wasting 18 bits (other than "I
do it because I can").

You should also make an argument for reusing IDs in different layers and
contexts, something that is known to be a bad practice, and is the
reason for which we have had to work on: RFC7721, RFC7707, RFC7217,
RFC8064, besides patching/updating more than 14 standards.

Besides, since we (IETF) do not specify how link-layer addresses are
generated, it would be very bad to make the security/privacy properties
of the addresses we do specify (IPv6) on the properties of those
(link-layer) that we don't.

That said, if you're keen to waste 18 bits of the address, you should
probably write a draft to propose that the default subnet size/prefix be
82. Otherwise you're literally wasting 18 bits that could be used for
something else.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 06:49:57 -0300

On 03/02/2017 05:54 AM, Lorenzo Colitti wrote:
> On Thu, Mar 2, 2017 at 7:37 AM, Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

I could para-phrase you: because other prefixes longer than 64 are more
than enough in all realistic situations.

Thanks,

---

From: Tore Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 10:52:06 +0100

* Lorenzo Colitti <[email-masked]>

> forward on arbitrary prefix lengths. It's probably reasonable that
> hosts should not make assumptions about other host's IP addresses
> (except if they are on the same subnet). But I think a host should be
> allowed to assume that its own subnet and its own IID are 64 bits
> long.

Such an assumption would fundamentally break SIIT [RFC7915]. Consider
the following examples of IPv4-translatable IPv6 addresses [RFC6052]
that might be assigned to hosts on different links in a vanilla SIIT
(a.k.a. IVI) deployment:

1) 2001:db8::192.0.2.1/120
2) 2001:db8::198.51.100.1/120
3) 2001:db8::203.0.113.0/120

These are all in the same /64 but if these tree hosts assume the /120
prefix length is incorrect and "helpfully correct" it to /64, then they
can no longer communicate with each other.

Thus, if you want to give the host permission to make such an assumption
of /64, you'd need to make exceptions for IPv4-translatable IPv6
addresses (or deprecate RFC7915 and possibly RFC6052).

However, creating such an exception probably means in practise that
implementations much apply it to the entire IPv6 address space, because
there is no way for a host to determine whether or not, e.g.,
2001:db8::c000:201 (host #1 above) is an IPv4-translatable IPv6 address
or not (that I'm aware of, anyway).

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 19:19:34 +0900

> can no longer communicate with each other.

I think you and I have already covered this case. I don't see how we can
define the IID in any meaningful way for RFC 6052 addresses. In the limited
case of /96 it might work, but in the general case it won't.

Consider a translation prefix of 2001:db8::/56. In this case 192.0.2.1/24
becomes (I think) 2001:db8:0:c0:2:100::/80. But if you configure
2001:db8:0:c0:2:100::/80 on an interface, that really won't work the way
you'd like it to. For example, suppose the node gets a packet whose
destination address is 2001:db8:0:c0:2:100::1. It won't match any of the IP
addresses configured it on the system. So it will either drop it, forward
it on-link (if L=1) or forward it back to the router it came from,
potentially causing a routing loop.

So really, you can't express this type of configuration using only an IPv6
address and a prefix length, because they don't provide enough information
to do that. "2001:db8:0:c0:2:100::/80" by itself is not enough: you need
one more piece of information, which is the length of the NAT64 prefix.

As I said before, I think we should have an exception for IPv6 addresses
where the only non-zero bits in the IID are an IPv4 address. Those aren't
really IPv6 addresses anyway, they're just convenient representations for
IPv4 addresses.

---

From: Iván Arce <[email-masked]>
Date: Thu, 2 Mar 2017 07:51:35 -0300

> by how much the additional 18 bits of entropy benefit real users in

No, its the other way around, really.

But that is a discussion for a different thread.

-ivan

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 12:06:41 +0100

Le 02/03/2017 à 10:31, Mikael Abrahamsson a écrit :
>> perfectly fine to use that plen==65 to have an entry in the rt
>> table, and use a manually configured address in that plen.
>
> Linux does the right thing in not autoconfiguring itself address(es)
> when plen isn't 64.

Whereas it is the right thing if on Ethernet (RFC2464) it is wrong on 
cellular links for which we have no RFC IPv6-over-foo.  Same with USB 
and to a certain extent on WiFi.

> However, what does it do when it receives an PIO with plen of 65 and
> M=1 and then it gets an IA_NA and configures that on the interface?

I dont know.  But I guess it still calls that 65 plen "illegal".

> Doesn't it install the /65 in the routing table?

Dont know, but there is a need to check.

How about the /63 case?  Do you think it is normal that linux kernel 
does not configure an IP address on Ethernet when receiving a plen==63?

Alex

---

From: Tore Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 12:11:04 +0100

> define the IID in any meaningful way for RFC 6052 addresses.

Precisely. So if you build an host implementation that, quote,
«assume[s] that its own subnet and its own IID are 64 bits long», as
you suggested in your previous message, that would as I understand it
break RFC7915/RFC6052 (the «vanilla SIIT» use case).

> In the limited case of /96 it might work, but in the general case it
> won't.
> 
> Consider a translation prefix of 2001:db8::/56. In this case
> 192.0.2.1/24 becomes (I think) 2001:db8:0:c0:2:100::/80. But if you
> configure 2001:db8:0:c0:2:100::/80 on an interface, that really won't
> work the way you'd like it to. For example, suppose the node gets a
> packet whose destination address is 2001:db8:0:c0:2:100::1. It won't
> match any of the IP addresses configured it on the system. So it will
> either drop it, forward it on-link (if L=1) or forward it back to the
> router it came from, potentially causing a routing loop.

This is somewhat besides my original point. However, it is no
different from a non-SIIT situation you'd get with a subnet prefix of
2001:db8::/64, a host configured with 2001:db8::1, and a packet
destined for 2001:db8::2.

I'd imagine that in most deployments the packet destined for
2001:db8::2 / 2001:db8:0:c0:2:100::1 will never reach the node at
2001:db8::1 / 2001:db8:0:c0:2:100:: becuase the router or node
attempting to deliver a packet to the latter address will first need to
resolve it, but there's nobody on the link to answer the transmitting
router/node's neighbour solicitations for those addresses and thus it
will just be dropped (and possibly cause some ICMPv6 unreachables to be
generated).

Or if it is a ND-less PtP interface and the host is also behaving as a
router you'd indeed get a loop. But again, that's no different than
what would happen with any regular non-RFC6052 /64, as documented in
RFC6164 section 5.1.

> So really, you can't express this type of configuration using only an
> IPv6 address and a prefix length, because they don't provide enough
> information to do that. "2001:db8:0:c0:2:100::/80" by itself is not
> enough: you need one more piece of information, which is the length
> of the NAT64 prefix.

I'm not exactly sure what you're saying here? RFC7915 does currently
work, and hosts participating in a network using RFC7915 do not need to
know the length of the translation prefix.

Side note: NAT64 [RFC6146] does not have this issue because it does not
use IPv4-translatable IPv6 addresses (the same goes for SIIT-DC). That
is, saying that all IPv6 prefixes must be /64 and enforcing that in the
host stacks would not prevent use of NAT64 (or SIIT-DC). The issue only
arises for networks/technologies that are using IPv4-translatable IPv6
addresses such as (traditional) SIIT.

> As I said before, I think we should have an exception for IPv6
> addresses where the only non-zero bits in the IID are an IPv4
> address. Those aren't really IPv6 addresses anyway, they're just
> convenient representations for IPv4 addresses.

Well, the point is that in order to ensure compatibility with SIIT such
an «exception» would need to _always_ apply, and then it's not really
much of an exception anymore.

At least I don't see how an IPv6 implementation could possibly
distinguish between any arbitrary (non-IPv4-translatable) IPv6 address
and IPv4-translatable IPv6 address?

As an example, take "2001:db8:1:2:3:4:c000:201".

This could be an IPv4-embedded IPv6 address where "c000:201" represents
the IPv4 address 192.0.2.1, but it could also just be an arbitrary
regular IPv6 address that someone configured. You can't know which it
is just by looking at the address, right?

And even if you did know, it wouldn't really match the «only non-zero
bits in the IID are an IPv4 address», because if you either:

1) consider the IID to always be 64 bits, then there's some nonzero
bits in there ("3:4") that are not part of the embedded IPv4 address, or

2) if you consider the IID to be the bits remaining after the subnet
prefix has been stripped off, e.g., 2001:db8:1:2:3:4:c000:200/120
(representing 192.0.2.0/24), then the IID simply does not contain a
complete IPv4 address as it's just 8 bits long.

Tore

---

From: Wilco Baan Hofman <[email-masked]>
Date: Thu, 2 Mar 2017 12:37:55 +0100

> and to a certain extent on WiFi.
It is undefined on non-IEEE802 networks and /64 is the one thing that
works for SLAAC, operationally.
> I dont know.  But I guess it still calls that 65 plen "illegal".
Which would be correct in the IEEE802 case, undefined in other cases,
still not incorrect behaviour from Linux in this case.
> does not configure an IP address on Ethernet when receiving a plen==63?
I would actually consider that normal, because the standard basically
mandates /64 and configuring on /63 is undefined at this time. As
implementer I would also reject such prefixes, because the code for
generating the EUI-64 and the privacy extension address all (correctly)
assume 64-bits of space, not 63, not 65.

==
Summarizing:

I think we can get consensus on:
- Making a recommendation of /64 for end-user networks
- Keep it required for things that depend on /64 (SLAAC, DHCPv6, ILNP,
NPT66, etc)
- Allow things like v4mapped address to use different subnet sizes, they
don't configure via SLAAC or similar methods. This makes sure SIIT keeps
working.
- Make prefixes of /65-/126 allowed on fully statically configured
interfaces, such as on routers

==

I don't think we're going to get consensus on dropping /64 boundary
entirely or on requiring the /64 boundary for everything.

We can't drop it entirely, because it would break deployments at end
user devices. And it is still a good recommendation to use /64 subnets
on those networks.

Conversely, we can't completely keep it, because it does not match the
operational reality in point-to-point links between routers. Configuring
/127 does not always work yet and does not cover the PTMP case (VRRP,
multiple BGP sessions). Configuring /64 on those links would make the
routers vulnerable to ND exhaustion.

Kind regards,

Wilco Baan Hofman

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 13:20:26 +0100 (CET)

> does not configure an IP address on Ethernet when receiving a plen==63?

As far as I am aware, the only documents we have regarding 
autoconfigration of adresses on ethernet says to only do this on plen == 
64. Thus it shouldn't be done on any other plen.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 13:36:44 +0100

Le 02/03/2017 à 12:37, Wilco Baan Hofman a écrit :
>>> Linux does the right thing in not autoconfiguring itself
>>> address(es) when plen isn't 64.
>>
>> Whereas it is the right thing if on Ethernet (RFC2464) it is wrong
>> on cellular links for which we have no RFC IPv6-over-foo.  Same
>> with USB and to a certain extent on WiFi.
>>

I agree with you.  And this is a place where everything can be right or
wrong: there is no consistency.  Interop problems loom there.

The fact that we have IPv6 running ok over 4G ptp links, and over USBnet 
is a very encouraging sign that makes many happy: look, IPv6 even there! 
  But it does not mean it does not have problems.

>>> However, what does it do when it receives an PIO with plen of 65
>>> and M=1 and then it gets an IA_NA and configures that on the
>>> interface?
>>

Yes.  For more precision - correct _only_ for the 802.3 case (IPv6 over 
Ethernet).  Because we dont have an IPv6-over-WiFi either (802.11).

> still not incorrect behaviour from Linux in this case.

I think someone can call it correct or incorrect equally well.  Because
there is no consistent spec or set of specs.  I call it incorrect.

>> How about the /63 case?  Do you think it is normal that linux
>> kernel does not configure an IP address on Ethernet when receiving
>> a plen==63?
>>
> mandates /64 and configuring on /63 is undefined at this time.

I would like to doubt your saying 'basically'.

Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used for
stateless autoconfiguration [ACONF] of an Ethernet interface must have a
length of 64 bits".

It does not say which prefix of [ACONF/RFC2462] must be /64?  Is it a
global prefix in RA?  Or is it the link-local prefix?  Both these
prefixes are relevant for the above phrase, both are mentioned in ACONF,
yet only one is present in RA (the one linux complains about when at
65).  Is the mandate cited above applying to the prefix in RA?  Or to
the link-local prefix?  If the mandate applies to the prefix in RA then
linux is right to complain, on Ethernet.  If the mandate applies only to
the LL prefix, then linux is wrong to complain about 65 in RA.  If the
mandate applies to both then RFC4291 is wrong when it says fe80::/10.

RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64".

It does not forbid that that 64bit prefix be formed by self-appending a
0 to a /63 from the RA, or other mechanism.

Besides, RFC4862 (successor to 2462) says "If the sum of the prefix
length and interface identifier length does not equal 128 bits, the
Prefix Information option MUST be ignored." And linux does _not_ ignore
a /63 in the RA: it adds a rt entry for that /63 prefix.  That's not
normal either.

You see what I mean?

> As implementer I would also reject such prefixes, because the code
> for generating the EUI-64 and the privacy extension address all
> (correctly) assume 64-bits of space, not 63, not 65.

Makes sense.

But linux does not simply reject a /63.

A linux kernel receiving a '/63' in RA will add a rt entry even though 
it does not configure an address.  So that's not really 'rejection' of 
the prefix (unless of course you define 'reject' to mean 'silently add a 
route and then drop the packet'.)

Do you agree with that?

Alex

[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 13:44:19 +0100

Le 02/03/2017 à 13:20, Mikael Abrahamsson a écrit :
> autoconfigration of adresses on ethernet says to only do this on plen
> == 64. Thus it shouldn't be done on any other plen.

Mikael,

I explained separately something I think makes sense, but here it is
briefly anyways.

IPv6-over-Ethernet RFC2464 says a certain plen must be 64, but it's not
clear whether that plen is the plen of the prefix in RA, or the plen of
the LL address.

If the plen that RFC refers to is that of the LL address (not that of
the plen of the prefix in the RA) then linux shouldnt reject prefixes in
RA with plen==65.

Besides, no spec stops somebody from forming a /64 out of a /63 received
in RA plus a 0.  Or somehow else.

Anyways, you seem to be two thinking and reading specs otherwise than I
do, so I may not insist...

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 13:46:12 +0100 (CET)

> Ethernet).  Because we dont have an IPv6-over-WiFi either (802.11).

We have IPv6 for 802.1 framed networks (that was my understanding). Both 
802.3 and 802.11 uses ethernet frames, so why wouldn't they be considered 
the same from L3 IPv6 point of view?

That's the way it's been done historically anyway, as far as I can see.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 14:29:55 +0100

Le 02/03/2017 à 13:46, Mikael Abrahamsson a écrit :
>> Yes.  For more precision - correct _only_ for the 802.3 case (IPv6
>>  over Ethernet).  Because we dont have an IPv6-over-WiFi either
>> (802.11).
>
> We have IPv6 for 802.1 framed networks (that was my understanding).
> Both 802.3 and 802.11 uses ethernet frames,

Well, yes in principle.  But I would doubt your saying 'both'.

Because if one looks at an IPv6 packet captured in monitor mode on WiFi
one does not see any Ethernet header.  Or maybe you mean something else
by an Ethernet frame(?).  Or maybe you meant that local processing
converts between these Ethernet headers and 802.11 headers(?).

On the air the IPv6 packets have 802.11 headers (not EthernetII headers)
_and_ 802.11 trailers.  One can see them with wireshark in monitor mode.
  These headers and trailers have many fields relevant for some IPv6
fields in IPv6 headers (e.g. traffic class, and others).  Yet we have no
spec about how would one map some these from 802.11 to IP.

We do have a spec about how to map an IP mcast address to a MAC mcast
address, what ethertype to use in EthernetII header (which is _not_ the
802.11 Headers), and that's about it.

We also have software everywhere that converts between 802.11 headers
and 802.3 EthernetII headers.  That software is not documented either.

> so why wouldn't they be considered the same from L3 IPv6 point of
> view?

Because that is the easy choice.  And because if we do so, then we lose
many of features these miriad of link layers have to offer.

This is one reason why many IPv6-over-foo IoT-specific links get
written: to take advantage of the link layer features at IP layer.

I would agree that all these links _could_ be the same from the IPv6
stack standpoint, but there are many IoT adaptation layers out there
which make it that the Ethernet view you mention above is not used at
least in some places.

> That's the way it's been done historically anyway, as far as I can

I agree with you.

But, there are some IETF documents that consider some aspects which
could be qualified as the domain of IPv6-over-802.11, and without
considering a IPv6-over-Ethernet.  E.g. draft-ietf-tsvwg-ieee-802-11-01
"Guidelines for DiffServ to IEEE 802.11 Mapping".

_If_ we had an IPv6-over-WiFi document (not just IPv6-over-Ethernet)
then we could have proposed these DiffServ mapping proposals to go along
with unicast mapping, and mcast mapping proposals of the typical
IPv6-over-Ethernet.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 23:02:34 +0900

> know the length of the translation prefix.

Oh, I see. It works if you ensure that all the hosts and translators agree
on how to calculate the suffix, and no two hosts have IPv6 addresses that
differ only in the suffix. IPv6 addresses that don't have this property
experience unidirectional connectivity to IPv4, and can cause packets to be
sent by third parties to the host that has the correct suffix. Fair enough.

> much of an exception anymore.

How about an exception for IPv6-translatable addresses, then? I don't think
it's essential that the host know that the addresses are IPv6-translatable.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 15:36:11 +0100

* Lorenzo Colitti

> > > So really, you can't express this type of configuration using
> > > only an IPv6 address and a prefix length, because they don't
> > > provide enough information to do that. "2001:db8:0:c0:2:100::/80"
> > > by itself is not enough: you need one more piece of information,
> > > which is the length of the NAT64 prefix.
> >
> > work, and hosts participating in a network using RFC7915 do not
> > need to know the length of the translation prefix.
> 
> Oh, I see. It works if you ensure that all the hosts and translators
> agree on how to calculate the suffix,

Yes, apart from the fact that the hosts usually don't need to
«calculate» anything or even have any awareness of the translation
taking place:

For outbound flows from a host with an IPv4-translatable IPv6 address
to the IPv4 internet, a DNS64 recursor would typically take care of
that calcuation. This works exactly the same as if you're using
Stateful NAT64 instead.

For inbound flows to such a host it only has to respond normally to the
source address in the incoming IPv6 request packet - which may or may
not be an IPv4-embedded IPv6 address. Again, this works same as with
Stateful NAT64 (assuming the NAT64 device allows inbound flows from the
IPv4 network in the first place, e.g., using static BIB entries).

> and no two hosts have IPv6 addresses that differ only in the suffix.
> IPv6 addresses that don't have this property experience
> unidirectional connectivity to IPv4, and can cause packets to be sent
> by third parties to the host that has the correct suffix. Fair enough.

Indeed, if you arbitrarily start setting the bits RFC6052 says should be
all 0 you will have successfully shot yourself in the foot. (Not that I
believe this is relevant to the discussion at hand.)

> > Well, the point is that in order to ensure compatibility with SIIT
> > such an «exception» would need to _always_ apply, and then it's not
> > really much of an exception anymore.
> 
> How about an exception for IPv6-translatable addresses, then? I don't
> think it's essential that the host know that the addresses are
> IPv6-translatable.

Exactly, you'd need an exception for IPv4-translatable IPv6 addresses.

But if you're coding up an host OS IPv6 stack you can't differentiate
between IPv4-translatable IPv6 addresses and «normal» IPv6 addresses.
After all there's no flag or property that tells the host stack that a
given IPv6 address is IPv4-translatable or not.

An OS/IPv6 stack implementer therefore has no choice but to make this
«exception» apply to *all* IPv6 addresses, allowing addresses to be
configured with arbitrary-length IIDs, thus making the exception the
rule.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Mar 2017 00:35:40 +0900

> given IPv6 address is IPv4-translatable or not.

Agreed. But note: I'm not suggesting that hosts should refuse to manually
configure arbitrary-length prefix lengths. Hosts allow this today and I
have no problem with that.

What I'm saying is that the IID length for unicast addresses, with a few
exceptions, should continue to be fixed at 64 bits. Those exceptions should
be unicast addresses that start with binary 000 (RFC 4291) point-to-point
links that use /127 (RFC 6164), IPv6-translatable addresses (RFC 6052), and
probably not much else.

The reason the fixed 64-bit length is important is that it ensures that
subnets never run out of addresses, and that's an extremely desirable
property.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 17:23:26 +0100

Le 02/03/2017 à 16:35, Lorenzo Colitti a écrit :
> [...]
> The reason the fixed 64-bit length is important is that it ensures 
> that subnets never run out of addresses, and that's an extremely 
> desirable property.

Ok, but maybe it's the operators running out of /64s, no?

I speculate, but I couldn't imagine a cellular operator dedicating a 
/40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its 
end users.    (the cellular operator I work with dedicates a /47 to 
cover its end users).

Alex

---

From: Sander Steffann <[email-masked]>
Date: Thu, 2 Mar 2017 18:49:41 +0100

Hi,

> Ok, but maybe it's the operators running out of /64s, no?

No

> I speculate, but I couldn't imagine a cellular operator dedicating a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its end users.    (the cellular operator I work with dedicates a /47 to cover its end users).

A /40 is nothing. An operator get's a *minimum* of a /32, and in RIPE land can get a /29 by just asking for it. A /40 is less than 1/2048th of a small operator's address space.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 19:05:25 +0100 (CET)

On Thu, 2 Mar 2017, Alexandre Petrescu wrote:

> end users.  (the cellular operator I work with dedicates a /47 to cover 
> its end users).

Then that cellular operator is extremely small and only has less than 128k 
users.

3GPP mandates /64 per PDP context. That's what mobile operators use.

I know operator who allocate new pools to their GGSNs in chunks of /44s, 
ie covering a million users at a time.

/40 is not much, is one 1/256th of the default allocation you get by just 
showing up and saying "hello, I am LIR and I want to use IPv6".

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 19:24:26 +0100

>> Ok, but maybe it's the operators running out of /64s, no?

So why dont they give more than one such /64 to one end user?

>> I speculate, but I couldn't imagine a cellular operator dedicating
>> a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to
>> cover its end users.    (the cellular operator I work with
>> dedicates a /47 to cover its end users).
>
> A /40 is nothing.

??

> An operator get's a *minimum* of a /32,

I can agree to that.  But I am also familiar with the common practice to
use chunks of GUAs on the interconnection links (instead of LLs or
ULAs).  There too people say "we have enough of these IPv6 prefixes, no
worry".

But it's again speculation.

> and in RIPE land can get a /29 by just asking for it.

That looks simple.

> A /40 is less than 1/2048th of a small operator's address space.

Look, let us talk only about the cellular parts of a certain country of
what such an operator may get.  I can agree with you that an operator
may get much from RIPE, but I ask how much of it will she assign to its
end users on cellular links?

Do you know of a cellular operator assigning a shorter-than-/47 prefix
to cover its cellular end users?  I am not asking to name it, but
whether such thing exists is sufficient for me.

Alex

> Cheers, Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 19:27:33 +0100

Le 02/03/2017 à 19:05, Mikael Abrahamsson a écrit :
>> cover its end users.  (the cellular operator I work with dedicates
>> a /47 to cover its end users).
>
> Then that cellular operator is extremely small and only has less
> than 128k users.

Yes, it looks so.

> I know operator who allocate new pools to their GGSNs in chunks of
> /44s, ie covering a million users at a time.

YEs yes, but how much of that /44 is covering the end-users and how much
is reserved for interconnnections?

> /40 is not much, is one 1/256th of the default allocation you get by
> just showing up and saying "hello, I am LIR and I want to use IPv6".

Ah great, but I guess few cellular operators (if any?) are LIRs.  Or
maybe that's true and I didnt know.

If all this were that simple and clearcut - there are enough /64s out
there - then why operators only assign one per one end user?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 19:33:03 +0100 (CET)

> is reserved for interconnnections?

Nothing. It's /44 to the GGSN/SPGW.

> maybe that's true and I didnt know.

You don't know.

> there - then why operators only assign one per one end user?

Because DHCPv6-PD hasn't been implemented in mobile networks yet (that I 
know of). So that's all they can do per 3GPP standards.

Residential rollouts, most use /56 per customer.

>From the RIRs, you can without further justification get /48 per "site", 
so if you show up to RIR and you're LIR and you say "hello, I have 40 
million customers and I want to give each customer a /48" then they'll 
give you a /22 most likely. You're perfectly within your right as an 
operator to deploy /48 per customer per current RIR rules that I am aware 
of.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 02 Mar 2017 19:54:49 +0100

Actually, is not correct that most use /56 for residential.

>From my last review of the survey, worldwide, 22% use /48, 35% use /56, but there is a lot of ISPs (33%) doing it wrong and using /64, which of course, we are explaining them that is wrong. 10% use “other” sizes.

Full details at:

https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey

Saludos,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Responder a: <[email-masked]>
Fecha: jueves, 2 de marzo de 2017, 19:33
Para: Alexandre Petrescu <[email-masked]>
CC: <[email-masked]>
Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

    

    You don't know.

    

    

**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 20:00:15 +0100

Le 02/03/2017 à 19:33, Mikael Abrahamsson a écrit :
[...]
>> If all this were that simple and clearcut - there are enough /64s
>> out there - then why operators only assign one per one end user?
>
> Because DHCPv6-PD hasn't been implemented in mobile networks yet
> (that I know of).

This situation lasts since more than 5 years now.  It is very
suspicious.  I wonder what is wrong and what can be done to get it fixed.

Alex

> So that's all they can do per 3GPP standards.
>
> so if you show up to RIR and you're LIR and you say "hello, I have
> 40 million customers and I want to give each customer a /48" then
> they'll give you a /22 most likely. You're perfectly within your
> right as an operator to deploy /48 per customer per current RIR rules
> that I am aware of.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 20:02:33 +0100

Le 02/03/2017 à 19:54, JORDI PALET MARTINEZ a écrit :
>> From my last review of the survey, worldwide, 22% use /48, 35% use
>> /56, but there is a lot of ISPs (33%) doing it wrong and using /64,
>> which of course, we are explaining them that is wrong. 10% use
>> “other” sizes.

So how comes that households can get /56s but smartphones no?

Really there must be something there hidden.

Alex

>  Saludos, Jordi
> -----Mensaje original----- De: ipv6 <[email-masked]> en nombre
> de Mikael Abrahamsson <[email-masked]> Organización: People's Front
> Against WWW Responder a: <[email-masked]> Fecha: jueves, 2 de marzo
> de 2017, 19:33 Para: Alexandre Petrescu
> <[email-masked]> CC: <[email-masked]> Asunto: Re:
> Objection to draft-ietf-6man-rfc4291bis-07.txt
>
>> YEs yes, but how much of that /44 is covering the end-users and how
>> much is reserved for interconnnections?
>
>> Ah great, but I guess few cellular operators (if any?) are LIRs.
>> Or maybe that's true and I didnt know.
>
> You don't know.
>
> (that I know of). So that's all they can do per 3GPP standards.
>
>  million customers and I want to give each customer a /48" then
> -- Mikael Abrahamsson    email: [email-masked]
>
> ********************************************** 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 use of the
> individual(s) named above. If you are not the intended recipient be
> aware that any disclosure, copying, distribution or use of the
> contents of this information, including attached files, is
> prohibited.
>
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 02 Mar 2017 20:06:15 +0100

I guess because the lack of DHCPv6-PD support, as you already indicated?

I think majority of the households and business customers get configured the CPE by means for DHCPv6-PD …

Saludos,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 2 de marzo de 2017, 20:02
Para: <[email-masked]>
Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

    

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 20:15:27 +0100

> I guess because the lack of DHCPv6-PD support, as you already

But for deity's sake - DHCPv6-PD is available as open source... it's
common software.  Just download and install.  The IETF Specs suggest it,
and the 3GPP specs require it too.

There must be something else making these router equipment manufacturers
refraining from downloading and installing DHCPv6-PD.

> I think majority of the households and business customers get
> configured the CPE by means for DHCPv6-PD …

AFAIK my CPE at home does not use DHCPv6-PD, but something based on
IPv4, like 6rd.  I think it's something developped in-house at that
particular operator.

Alex

>
> Saludos, Jordi
>
>
> -----Mensaje original----- De: ipv6 <[email-masked]> en
> nombre de Alexandre Petrescu <[email-masked]> Responder
> a: <[email-masked]> Fecha: jueves, 2 de marzo de 2017,
> 20:02 Para: <[email-masked]> Asunto: Re: Objection to
> draft-ietf-6man-rfc4291bis-07.txt
>
>
>
>>> From my last review of the survey, worldwide, 22% use /48, 35%
>>> use /56, but there is a lot of ISPs (33%) doing it wrong and
>>> using /64, which of course, we are explaining them that is
>>> wrong. 10% use “other” sizes.
>
>> -----Mensaje original----- De: ipv6 <[email-masked]> en
>> nombre de Mikael Abrahamsson <[email-masked]> Organización:
>> People's Front Against WWW Responder a: <[email-masked]> Fecha:
>> jueves, 2 de marzo de 2017, 19:33 Para: Alexandre Petrescu
>>> YEs yes, but how much of that /44 is covering the end-users and
>>> how much is reserved for interconnnections?
>>
>> right as an operator to deploy /48 per customer per current RIR
>> rules that I am aware of.
>>
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be for
>> the use of the individual(s) named above. If you are not the
>> intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information, including
>> attached files, is prohibited.
>>
>>
>>
> or confidential. The information is intended to be for the use of
> the individual(s) named above. If you are not the intended recipient
> be aware that any disclosure, copying, distribution or use of the

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 02 Mar 2017 20:25:29 +0100

I understood from one of your previous emails that 3GPP doesn’t require DHCPv6-PD. RFC6653, suggest its use, so probably we got confused ourselves and 3GPP is actually using it.

6rd is a different thing, because is actually IPv4 link and IPv6 is a tunnel, so you typically use DHCP (v4).

In IPv6-only world (including cellular), the WAN link will be IPv6-only instead of dual-stack. This is already happening.

If they don’t use it, I guess is the same reason why big vendors didn’t implemented yet RDDNS …

Cellular world is using 464XLAT, and they use DHCPv6-PD. Check RFC6877.

Saludos,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 2 de marzo de 2017, 20:15
Para: <[email-masked]>
Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

    

    
    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Mar 2017 21:23:56 +0100

Le 02/03/2017 à 20:25, JORDI PALET MARTINEZ a écrit :
> I understood from one of your previous emails that 3GPP doesn’t
> require DHCPv6-PD.

Right - if I understand correctly, it does not require DHCPv6-PD on the
UE.  Maybe in the core, but not in the UE.

> RFC6653, suggest its use, so probably we got confused ourselves and
> 3GPP is actually using it.
>

I agree.

> In IPv6-only world (including cellular), the WAN link will be
> IPv6-only instead of dual-stack. This is already happening.
>

I wonder if Windows refusing RDNSS doesn't have somehting to do with its
Teredo; and extending this logic to smartphones: the lack of answers to
DHCPv6-PD issued from the UE may have something to do with 464xlat presence.

Could it be that 464xlat presence on UE makes it that DHCPv6-PD is
impossible on same UE?

> Cellular world is using 464XLAT, and they use DHCPv6-PD. Check

I guess you mean cellular stations (like BS, not the User Equipment)
uses DHCPv6-PD within the fixed network.

Because cellular operator I am aware of replies to DHCPv6-PD requests
issued from an User Equipment.

Alex

> de Alexandre Petrescu <[email-masked]> Responder a:
> <[email-masked]> Fecha: jueves, 2 de marzo de 2017,
> 20:15 Para: <[email-masked]> Asunto: Re: Objection to
> common software.  Just download and install.  The IETF Specs suggest
> it, and the 3GPP specs require it too.
>
> There must be something else making these router equipment
> manufacturers refraining from downloading and installing DHCPv6-PD.
>
>> nombre de Alexandre Petrescu <[email-masked]>
>> Responder a: <[email-masked]> Fecha: jueves, 2 de
>> marzo de 2017, 20:02 Para: <[email-masked]> Asunto: Re: Objection
>> to draft-ietf-6man-rfc4291bis-07.txt
>>
>>
>>
>>> People's Front Against WWW Responder a: <[email-masked]>
>>> Fecha: jueves, 2 de marzo de 2017, 19:33 Para: Alexandre
>>> Petrescu <[email-masked]> CC: <[email-masked]>
>>>> YEs yes, but how much of that /44 is covering the end-users
>>>> and how much is reserved for interconnnections?
>>>
>>>> Ah great, but I guess few cellular operators (if any?) are
>>>> LIRs. Or maybe that's true and I didnt know.
>>>
>>> You don't know.
>>>
>>>> If all this were that simple and clearcut - there are enough
>>>> /64s out there - then why operators only assign one per one end
>>>> user?
>>>
>>> so if you show up to RIR and you're LIR and you say "hello, I
>>> have 40 million customers and I want to give each customer a /48"
>>> then they'll give you a /22 most likely. You're perfectly within
>>> your right as an operator to deploy /48 per customer per current
>>> RIR rules that I am aware of.
>>>
>>> ********************************************** IPv4 is over Are
>>> you ready for the new Internet ? http://www.consulintel.es The
>>> IPv6 Company
>>>
>>> privileged or confidential. The information is intended to be
>>> for the use of the individual(s) named above. If you are not the
>>> distribution or use of the contents of this information,
>>> including attached files, is prohibited.
>>>
>>>
>>>
>> ********************************************** IPv4 is over Are
>> you ready for the new Internet ? http://www.consulintel.es The
>> IPv6 Company
>>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 02 Mar 2017 22:21:07 +0000

> years" is not a use case.

Thank you for rephrasing the question in a neutral way.  Here is my answer:

https://www.ietf.org/mail-archive/web/ietf/current/msg101724.html

We will probably need to agree to disagree on it.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Mar 2017 09:48:56 +1100

In message <[email-masked]>, Alexandre Petrescu
 writes:
> Le 02/03/2017  20:25, JORDI PALET MARTINEZ a crit :
> > I understood from one of your previous emails that 3GPP doesnt
> > require DHCPv6-PD.
>
> > If they dont use it, I guess is the same reason why big vendors
> > didnt implemented yet RDDNS
>

No.  They are or should be orthogonal.  One is about providing IPv4
as as service.  The other is about providing IPv6 address space.

> uses DHCPv6-PD within the fixed network.

No, the UE should be using DHCPv6-PD.  This is how tethered equipement
should be getting IPv6 address space.

> > Le 02/03/2017  20:06, JORDI PALET MARTINEZ a crit :
> >> configured the CPE by means for DHCPv6-PD
> >
> >> Le 02/03/2017  19:54, JORDI PALET MARTINEZ a crit :
> >>>> wrong. 10% use other sizes.
> >>
> >>> nombre de Mikael Abrahamsson <[email-masked]> Organizacin:

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

---

From: 神明達哉 <[email-masked]>
Date: Thu, 2 Mar 2017 18:24:25 -0800

> make for interop problems.

I don't know exactly what you mean by "BSD says it's a fe80::/10", but
BSD variants use a 64-bit IID to configure (e.g) an ethernet interface
with a link-local address, as specified in RFC4862 and RFC2464.  They
also only recognize addresses that match fe80::/64 as on-link:

Destination                       Gateway                       Flags      Netif
fe80::%em0/64                     link#1                        U           em0

On the other hand, BSDs' implementation of the IN6_IS_ADDR_LINKLOCAL()
macro only checks the first 10 bits:

#define IN6_IS_ADDR_LINKLOCAL(a)        \
        (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))

If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for
link-local.  But it has nothing to do with the length of IIDs.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Mar 2017 13:49:48 +0900

> We will probably need to agree to disagree on it.

Actually, I agree with the comment itself. What I would like you to do is
implement your comment. I think what I above call "use cases" is what your
linked email calls "field deployment issues". If so, then my question
becomes: can you provide concrete examples of said field deployment issues?
What can't you do if all your subnets are fixed to /64?

If we don't have concrete examples, all we have is "some operators say
fixed /64 is bad". But we don't know why they say it's bad, and how bad it
is, or even how many of those operators say it's bad. If nobody disagreed
with the staetments being made by the operators on this thread, that would
be fine. But because there *is* disagreement, then reaching consensus
requires finding a balance between what those operators say is best and
what others in this thread (mostly host developers) say is best. That
requires concrete examples, so that we can all look at the engineering
tradeoffs together.

I'm going to ask again: what's the harm if all your IID lengths are /64 or
/127? What can't you do? (Other than use IPv6-translatable addresses, which
we should have an exception for.) You're free not to answer that question
at all, or to answer it with more general statements around operator
feedback being important to standards development, as you have so far, but
if you don't answer it with specific examples, I don't expect that you'll
be able to convince the other side of the debate any more than you have so
far.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 3 Mar 2017 07:09:57 +0100 (CET)

On Thu, 2 Mar 2017, JORDI PALET MARTINEZ wrote:

> I understood from one of your previous emails that 3GPP doesn’t require 
> DHCPv6-PD. RFC6653, suggest its use, so probably we got confused 
> ourselves and 3GPP is actually using it.

3GPP is like IETF, it produces documents. DHCPv6-PD has been in 3GPP 
documents since 2012.

Market requirements then makes these documents get implemented. Sometimes 
almost immediately, sometimes 5 years down the line, sometimes never.

DHCPv6-PD seems to be one of these functions that takes a long time. 
Possibly because 64SHARE is already available and solves a majority of the 
problem space. Current 3GPP deployments can be seen as being close to a 
/64 PD deployment in end-user functionality. Works for a lot of use-cases, 
but not what we want long term. However, very widely available in both 
networks and devices.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 10:29:13 +0100

Le 02/03/2017 à 23:48, Mark Andrews a écrit :
>
> In message <[email-masked]>,
> Alexandre Petrescu writes:
>> Right - if I understand correctly, it does not require DHCPv6-PD on
>> the UE.  Maybe in the core, but not in the UE.
>>
>>> RFC6653, suggest its use, so probably we got confused ourselves
>>> and 3GPP is actually using it.
>>>
>>> 6rd is a different thing, because is actually IPv4 link and IPv6
>>>  is a tunnel, so you typically use DHCP (v4).
>>
>> I agree.
>>
>> I wonder if Windows refusing RDNSS doesn't have somehting to do
>> with its Teredo; and extending this logic to smartphones: the lack
>>  of answers to DHCPv6-PD issued from the UE may have something to
>> do with 464xlat presence.
>>

I can agree.

With my operator I asked her once 'why not giving DHCPc6-PD to
smartphone' and she replied 'because now we do 464xlat on the
smartphone, and that is sufficient'.  As such it sounds illogical
statement, although I guess s/he has some reasons to say so.

But let me ask differently: maybe it's because 464xlat requires some
kernel version that DHCPv6-PD doestn support, or vice-versa?  Maybe it's
because once you run 464xlat on smartphone it takes control of the
unique default route and DHCPv6-PD couldnt?  Some reason like that?

Has one tried DHCPv6-PD software simultaneosuly with 464xlat? (even
knowing the cellular operator would not reply to DHCPv6 Slicitations).

>> I guess you mean cellular stations (like BS, not the User
>> Equipment) uses DHCPv6-PD within the fixed network.
>
> No, the UE should be using DHCPv6-PD.  This is how tethered
> equipement should be getting IPv6 address space.

I agree with yuo.

This is why I dont understand the cellular operators dont do DHCPv6-PD.
  And I guess it is so because they are told it's sufficient to run the
64share INFORMATIONAL RFC.

Are the people advising 64share to tethering-willing telecom operators
conscious it's non-interoperable?

Is the 64share advice coming together with the claim there are enough
/64s out there?

Alex

>> Because cellular operator I am aware of replies to DHCPv6-PD
>> requests issued from an User Equipment.
>>
>> Alex
>>
>>>
>>> Saludos, Jordi
>>>
>>>
>>> marzo de 2017, 20:15 Para: <[email-masked]> Asunto: Re: Objection
>>> But for deity's sake - DHCPv6-PD is available as open source...
>>> it's common software.  Just download and install.  The IETF Specs
>>> suggest it, and the 3GPP specs require it too.
>>>
>>> AFAIK my CPE at home does not use DHCPv6-PD, but something based
>>>  on IPv4, like 6rd.  I think it's something developped in-house
>>> at that particular operator.
>>>
>>> Alex
>>>
>>>>
>>>> Saludos, Jordi
>>>>
>>>>
>>>> Responder a: <[email-masked]> Fecha: jueves, 2
>>>> de marzo de 2017, 20:02 Para: <[email-masked]> Asunto: Re:
>>>>>> From my last review of the survey, worldwide, 22% use /48,
>>>>>>  35% use /56, but there is a lot of ISPs (33%) doing it
>>>>>> wrong and using /64, which of course, we are explaining
>>>>>> them that is wrong. 10% use other sizes.
>>>>
>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-s
>>
>>
>>
>>
urvey
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>>>
>>>>>
>>>>
>>>>> Saludos, Jordi
>>>>>
>>>>>
>>>>> -----Mensaje original----- De: ipv6 <[email-masked]>
>>>>> en nombre de Mikael Abrahamsson <[email-masked]>
>>>>> Organizacin: People's Front Against WWW Responder a:
>>>>> <[email-masked]> Fecha: jueves, 2 de marzo de 2017, 19:33
>>>>> Para: Alexandre Petrescu <[email-masked]> CC:
>>>>> <[email-masked]> Asunto: Re: Objection to
>>>>>> YEs yes, but how much of that /44 is covering the
>>>>>> end-users and how much is reserved for interconnnections?
>>>>>
>>>>>> If all this were that simple and clearcut - there are
>>>>>> enough /64s out there - then why operators only assign one
>>>>>>  per one end user?
>>>>>
>>>>> Because DHCPv6-PD hasn't been implemented in mobile networks
>>>>>  yet (that I know of). So that's all they can do per 3GPP
>>>>> standards.
>>>>>
>>>>> so if you show up to RIR and you're LIR and you say "hello,
>>>>> I have 40 million customers and I want to give each customer
>>>>> a /48" then they'll give you a /22 most likely. You're
>>>>> perfectly within your right as an operator to deploy /48 per
>>>>>  customer per current RIR rules that I am aware of.
>>>>>
>>>>> you ready for the new Internet ? http://www.consulintel.es
>>>>> The IPv6 Company
>>>>>
>>>>> privileged or confidential. The information is intended to
>>>>> be for the use of the individual(s) named above. If you are
>>>>> not the intended recipient be aware that any disclosure,
>>>>> copying, distribution or use of the contents of this
>>>>> information, including attached files, is prohibited.
>>>>>
>>>>>
>>>>>
>>>> for the use of the individual(s) named above. If you are not
>>>> the intended recipient be aware that any disclosure, copying,
>>> IETF IPv6 working group mailing list [email-masked]
>>> Administrative Requests:

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 10:58:59 +0100

Le 03/03/2017 à 03:24, 神明達哉 a écrit :
>> Finally, there is no advice of what bits to put between fe80:: and
>>  a 64bit the Interface ID - zeros or ones?  linux says it's a
>> fe80::/64 and IIRC BSD says it's a fe80::/10.  The routing entries
>>  based on that can make for interop problems.
>
> I don't know exactly what you mean by "BSD says it's a fe80::/10",

Tatuya, sorry, that may have been a mistake on my part.  That was
based on a vague recollection.

> but BSD variants use a 64-bit IID to configure (e.g) an ethernet
> interface with a link-local address, as specified in RFC4862 and
> RFC2464.
>
> They also only recognize addresses that match fe80::/64 as on-link:

When you say 'recognize' you mean by using the below macro?  If so, it 
may be quite approximate and vague to recognize on 10bit something that 
is generated on 64bit.  A precise recognition would be on 64bit.

> Destination                       Gateway Flags Netif fe80::%em0/64
> link#1 U           em0
>
> On the other hand, BSDs' implementation of the
> IN6_IS_ADDR_LINKLOCAL() macro only checks the first 10 bits:
>
> #define IN6_IS_ADDR_LINKLOCAL(a)        \ (((a)->s6_addr[0] == 0xfe)
>  && (((a)->s6_addr[1] & 0xc0) == 0x80))
>
> link-local.

Yes that 10 comes out of 8 plus the 2 of the 0xc0 mask.

If so, it means BSD uses a 10bit mask to recognise a LL, but uses a
64bit mask to generate an LL.  Maybe it is prudent enough.

BUt it may not be correct.  The right way would be to use precisely same
generation and recognition masks.

Otherwise there can be risks of incompatibility, address space waste, 
and probably others.

I guess the programmer assumes the bits between 10 and 64 are simply 0
(others may say it's 1).

But we should not say the generation is using a 10bit mask and
recognition is using a 64bit mask, nor vice-versa.  It reads incorrectly.

> But it has nothing to do with the length of IIDs.

Well, if the length of the IID is 64, and the fe80::/10 recognition is 
hardcoded at 10, then what does BSD put between position 10 and 64 when 
trying to recognise an LL address it has just generated?

Alex

> -- JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 11:06:41 +0100

Le 03/03/2017 à 05:49, Lorenzo Colitti a écrit :
[...]
> If we don't have concrete examples,

Lorenzo - I for myself provided such concrete examples publicly, 
multiple times in the past, replying specifically to your request of 
concrete examples.  Do you remember?

Alex

---

From: Job Snijders <[email-masked]>
Date: Fri, 3 Mar 2017 17:27:34 +0700

> be able to convince the other side of the debate any more than you have so

I am surprised you say stuff like "If we don't have concrete examples" -
i shared actual data with the group. Is there a communication breakdown?

/127 doesnt work with all equipment, /64 might leave one or both parties
open to nd cache attacks, /126 works most of the time (hence 52% of NTTs
interfaces are configured with /126), /124 or /120 is useful when you
have more than two bgp speakers in a single layer-2 segment, etc.

You've argued that you can mitigate nd cache issues, by applying
non-trivial mechanisms, some of which are more theoretical then
practical. Operators have chosen to entirely eliminate any risk of cache
exhaustion issues by making linknets smaller.

If I have a hammer, a nail, and a piece of wood; why would I use QoS or
routing tricks?

What I would've expected from IETF crowd is appreciation for continuing
to deploy IPv6 in face of all the troubles we've seen over the years,
instead we're being told "U R NUMBERING WRONG!!" and see absolute
dismissal for current operational practices and recognition why the
state of affairs is what it is.

It is upsetting that this information needs to be repeated over and over
again. Why are you not listening? The last decennia has already proven
that flexibility is a necessity to operate the networks.

The dogs bark, but the caravan goes on.

Regards,

Job

---

From: <[email-masked]>
Date: Fri, 3 Mar 2017 10:30:36 +0000

Hi Alex,

> 64share INFORMATIONAL RFC.

This is a chicken-and-egg problem: you need both the cellular device and the network side to support prefix delegation + prefix exclude option, but while waiting for that to happen /64 share is your solution. Below what you can read in RFC7849:

=====
   L_REC#1:  For deployments that require that the same /64 prefix be
             shared, the cellular device should support [RFC7278] to
             enable sharing a /64 prefix between the LAN and the WAN
             interfaces.  The WAN interface is the one towards the
             Gateway GPRS Support Node (GGSN) / Packet Data Network
             Gateway (PGW).

                Prefix Delegation (refer to L_REC#2) is the target
                solution for distributing prefixes in the LAN side but,
                because the device may attach to earlier 3GPP release
                networks, a means to share a /64 prefix is also
                recommended [RFC7278].

                [RFC7278] must be invoked only if Prefix Delegation is
                not in use.

   L_REC#2:  The cellular device must support Prefix Delegation
             capabilities [RFC3633] and must support the Prefix Exclude
             Option for DHCPv6-based Prefix Delegation as defined in
             [RFC6603].  Particularly, it must behave as a Requesting
             Router.

                Cellular networks are more and more perceived as an
                alternative to fixed broadband networks for home IP-
                based services delivery; especially with the advent of
                smartphones and 3GPP data dongles.  There is a need for
                an efficient mechanism to assign larger prefixes (other
                than /64s) to cellular hosts so that each LAN segment
                can get its own /64 prefix and multi-link subnet issues
                to be avoided.

                In case a prefix is delegated to a cellular host using
                DHCPv6, the cellular device will be configured with two
                prefixes:

                (1)  one for the 3GPP link allocated using the Stateless
                     Address Autoconfiguration (SLAAC) mechanism and

                (2)  another one delegated for LANs acquired during the
                     Prefix Delegation operation.

                Note that the 3GPP network architecture requires both
                the WAN and the delegated prefix to be aggregatable so
                the subscriber can be identified using a single prefix.

                Without the Prefix Exclude Option, the delegating router
                (GGSN/PGW) will have to ensure compliance with [RFC3633]
                (e.g., halving the delegated prefix and assigning the
                WAN prefix out of the first half and the prefix to be
                delegated to the terminal from the second half).

                Because Prefix Delegation capabilities may not be
                available in some attached networks, L_REC#1 is strongly
                recommended to accommodate early deployments.
=====

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Alexandre Petrescu
> Envoyé : vendredi 3 mars 2017 10:29
> À : Mark Andrews
> Cc : [email-masked]
> Objet : Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
> 
> 
> 
> >>> Administrative

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 11:52:03 +0100

Le 03/03/2017 à 11:30, [email-masked] a écrit :
> Hi Alex,
>
>
>> This is why I dont understand the cellular operators dont do
>> DHCPv6-PD. And I guess it is so because they are told it's
>> sufficient to run the 64share INFORMATIONAL RFC.
>
> This is a chicken-and-egg problem: you need both the cellular device
>  and the network side to support prefix delegation + prefix exclude
> option,

How can that vicious circle be broken?

I have some smartphone and other M2M modules here on which we could try
a few things.  What would operator expect to hear from this smartphone?

Is the ISC DHCPv6-PD Client messages enough?

Does operator also need 'prefix exclude'?  Mandatory?

Is the ISC DHCPv6-PD implementing 'prefix exclude'?

> but while waiting for that to happen /64 share is your solution.

Operator should understand that /64 share is impossible to use in
concrete settings like vehicular networks, road-side units, and similar.

> Below what you can read in RFC7849:

If I read it I will certainly suggest improvements to it.  It should
reflect reality.

> ===== L_REC#1:  For deployments that require that the same /64 prefix
> be shared, the cellular device should support [RFC7278] to enable
> sharing a /64 prefix between the LAN and the WAN interfaces. The WAN
> interface is the one towards the Gateway GPRS Support Node (GGSN) /
> Packet Data Network Gateway (PGW).
>
> Prefix Delegation (refer to L_REC#2) is the target solution for

It's not a 'target', it is a 'now'.

> distributing prefixes in the LAN side but, because the device may
> attach to earlier 3GPP release networks, a means to share a /64
> prefix is also recommended [RFC7278].

No!  That recommendation is wrong.  That RFC is INFORMATIONAL and we
should stop recommending it.  I has huge problems, at least with respect
to scalability.

> [RFC7278] must be invoked only if Prefix Delegation is not in use.

... _and_ if it works for the network being deployed.  If it does not
work, it MUST NOT be invoked.

> capabilities [RFC3633] and must support the Prefix Exclude Option for
> DHCPv6-based Prefix Delegation as defined in [RFC6603].

Why is the 'prefix exclude' option a MUST?  I may need to understand
that, by further reading...

> Particularly, it must behave as a Requesting Router.

Yes, and it is a MUST not a must.
>
> Cellular networks are more and more perceived as an alternative to
> fixed broadband networks for home IP- based services delivery;

I agree.

> especially with the advent of smartphones and 3GPP data dongles.

_and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are
only the USB dongles, there are no other kinds of dongles).

> There is a need for an efficient mechanism to assign larger prefixes
>  (other than /64s) to cellular hosts

I fully agree.

> so that each LAN segment can get its own /64 prefix

_if_ that LAN is an Ethernet, yes it needs a /64.  Often it is the case.

> and multi-link subnet issues to be avoided.

I agree, RFC must be cited.

> In case a prefix is delegated to a cellular host using DHCPv6, the
> cellular device will be configured with two prefixes:
>
> (1)  one for the 3GPP link allocated using the Stateless Address
> Autoconfiguration (SLAAC) mechanism and
>
> (2)  another one delegated for LANs acquired during the Prefix
> Delegation operation.

I dont know what you mean by 'configured', but this second prefix may 
just be in the rt table of the device (not necessarily on its interfaces).

How about the default route?

> Note that the 3GPP network architecture requires both the WAN and the
> delegated prefix to be aggregatable so the subscriber can be
> identified using a single prefix.

IT's good to avoid waste.

> Without the Prefix Exclude Option, the delegating router (GGSN/PGW)
> will have to ensure compliance with [RFC3633] (e.g., halving the
> delegated prefix and assigning the WAN prefix out of the first half
> and the prefix to be delegated to the terminal from the second
> half).

So 'prefix exclude' is not mandatory in order to have DHCPv6-PD working.

>
> Because Prefix Delegation capabilities may not be available in some
> attached networks, L_REC#1 is strongly recommended to accommodate
> early deployments. =====

It's wrong.  We should _never_ recommend somehting we know it does not 
scale.  Because if we do it may get in widespread use and later we'll 
have a hard time getting rid of.

Alex

>
> Cheers, Med
>
>
>> -----Message d'origine----- De : ipv6
>> [mailto:[email-masked]] De la part de Alexandre Petrescu
>> Envoyé : vendredi 3 mars 2017 10:29 À : Mark Andrews Cc :
>> [email-masked] Objet : Re: Objection to
>>>>> I understood from one of your previous emails that 3GPP
>>>>> doesnt require DHCPv6-PD.
>>>>
>>>> Right - if I understand correctly, it does not require
>>>> DHCPv6-PD on the UE.  Maybe in the core, but not in the UE.
>>>>
>>>>> RFC6653, suggest its use, so probably we got confused
>>>>> 6rd is a different thing, because is actually IPv4 link and
>>>>> IPv6 is a tunnel, so you typically use DHCP (v4).
>>>>
>>>> I agree.
>>>>
>>>>> In IPv6-only world (including cellular), the WAN link will
>>>>> be IPv6-only instead of dual-stack. This is already
>>>>> happening.
>>>>>
>>>>> If they dont use it, I guess is the same reason why big
>>>>> vendors didnt implemented yet RDDNS
>>>>
>>>> I wonder if Windows refusing RDNSS doesn't have somehting to
>>>> do with its Teredo; and extending this logic to smartphones:
>>>> the lack of answers to DHCPv6-PD issued from the UE may have
>>>> something to do with 464xlat presence.
>>>>
>>>> Could it be that 464xlat presence on UE makes it that DHCPv6-PD
>>>> is impossible on same UE?
>>>
>>> No.  They are or should be orthogonal.  One is about providing
>>> IPv4 as as service.  The other is about providing IPv6 address
>>> space.
>>
>> I can agree.
>>
>> But let me ask differently: maybe it's because 464xlat requires
>> some kernel version that DHCPv6-PD doestn support, or vice-versa?
>> Maybe it's because once you run 464xlat on smartphone it takes
>> control of the unique default route and DHCPv6-PD couldnt?  Some
>> reason like that?
>>
>> Has one tried DHCPv6-PD software simultaneosuly with 464xlat?
>> (even knowing the cellular operator would not reply to DHCPv6
>> Slicitations).
>>
>> This is why I dont understand the cellular operators dont do
>> DHCPv6-PD. And I guess it is so because they are told it's
>> sufficient to run the 64share INFORMATIONAL RFC.
>>
>> Are the people advising 64share to tethering-willing telecom
>> operators conscious it's non-interoperable?
>>
>> Is the 64share advice coming together with the claim there are
>> enough /64s out there?
>>
>> Alex
>>
>>>>> en nombre de Alexandre Petrescu
>>>>> <[email-masked]> Responder a:
>>>>> <[email-masked]> Fecha: jueves, 2 de marzo de
>>>>> 2017, 20:15 Para: <[email-masked]> Asunto: Re: Objection to
>>>>> But for deity's sake - DHCPv6-PD is available as open
>>>>> source... it's common software.  Just download and install.
>>>>> The IETF Specs suggest it, and the 3GPP specs require it
>>>>> too.
>>>>>
>>>>>> I think majority of the households and business customers
>>>>>> get configured the CPE by means for DHCPv6-PD
>>>>>
>>>>> AFAIK my CPE at home does not use DHCPv6-PD, but something
>>>>> based on IPv4, like 6rd.  I think it's something developped
>>>>> in-house at that particular operator.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> Saludos, Jordi
>>>>>>
>>>>>>
>>>>>> en nombre de Alexandre Petrescu
>>>>>> <[email-masked]> Responder a:
>>>>>> <[email-masked]> Fecha: jueves, 2 de marzo de
>>>>>> 2017, 20:02 Para: <[email-masked]> Asunto: Re: Objection to
>>>>>>>> From my last review of the survey, worldwide, 22% use
>>>>>>>> /48, 35% use /56, but there is a lot of ISPs (33%)
>>>>>>>> doing it wrong and using /64, which of course, we are
>>>>>>>> explaining them that is wrong. 10% use other sizes.
>>>>>>
>>>>>>> -----Mensaje original----- De: ipv6
>>>>>>> <[email-masked]> en nombre de Mikael Abrahamsson
>>>>>>> <[email-masked]> Organizacin: People's Front Against
>>>>>>> WWW Responder a: <[email-masked]> Fecha: jueves, 2 de
>>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu
>>>>>>> <[email-masked]> CC: <[email-masked]>
>>>>>>> Asunto: Re: Objection to
>>>>>>>> Ah great, but I guess few cellular operators (if any?)
>>>>>>>>  are LIRs. Or maybe that's true and I didnt know.
>>>>>>>
>>>>>>> You don't know.
>>>>>>>
>>>>>>>> enough /64s out there - then why operators only assign
>>>>>>>>  one per one end user?
>>>>>>>
>>>>>>> Because DHCPv6-PD hasn't been implemented in mobile
>>>>>>> networks yet (that I know of). So that's all they can do
>>>>>>>  per 3GPP standards.
>>>>>>>
>>>>>>> so if you show up to RIR and you're LIR and you say
>>>>>>> "hello, I have 40 million customers and I want to give
>>>>>>> each customer a /48" then they'll give you a /22 most
>>>>>>> likely. You're perfectly within your right as an operator
>>>>>>> to deploy /48 per customer per current RIR rules that I
>>>>>>> am aware of.
>>>>>>>
>>>>>>> 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 use of the individual(s) named
>>>>>>> above. If you are not the intended recipient be aware
>>>>>>> that any disclosure, copying, distribution or use of the
>>>>>>> contents of this information, including attached files,
>>>>>>> is prohibited.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>  be for the use of the individual(s) named above. If you
>>>>>> are not the intended recipient be aware that any
>>>>>> disclosure, copying, distribution or use of the contents
>>>>>> of this information, including attached files, is
>>>>>> prohibited.
>>>>>>
>>>>>>
>>>>>>
>>>>> ready for the new Internet ? http://www.consulintel.es The
>>>>> IPv6 Company
>>>>>

---

From: [email-masked]
Date: Fri, 3 Mar 2017 12:18:47 +0100

Job,

[...]

> that flexibility is a necessity to operate the networks.

of course. at the same time please remember that there is significant distrust towards the operators.
if we as the users gave in now, will you turn around and charge me by the address tomorrow?

as have been mentioned before the hard part is to find text that is clear on the policy, allows for new innovations and use of ILNP, /64 to the host, NPT66, but also recognises that I can configure /128s, or that I on my laptop split a /64 into /80s for each of my VMs...

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 14:14:39 +0100

Le 03/03/2017 à 12:18, [email-masked] a écrit :
> Job,
>
> [...]
>
>> It is upsetting that this information needs to be repeated over and
>> over again. Why are you not listening? The last decennia has
>> already proven that flexibility is a necessity to operate the
>> networks.
>

I agree.

One view at a certain operator is that the deployed 3GPP Release number
does not support DHCPv6-PD for end users.  As such that view can only be
interpreted as an invitation to wait for the next release of 3GPP
Release before hoping to see DHCPv6-PD on the smartphone.  With no
guarantee whatsoever.

Until then what can one do to support multiple scalable IPv6 subnets at
the edges of 3GPP networks?  Use NAT66? Make a 65 SLAAC?  Mandate /65
DHCPv6 addresses on end devices tainted by fe80::/64?

None sounds RECOMMENDED.

Alex

> as have been mentioned before the hard part is to find text that is
> clear on the policy, allows for new innovations and use of ILNP, /64
>  to the host, NPT66, but also recognises that I can configure /128s,
>  or that I on my laptop split a /64 into /80s for each of my VMs...
>
> Cheers, Ole
>
>
>

---

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

> How can that vicious circle be broken?

Money.  This is not a 3GPP release issue, this is a money backing the
deployment cost.  And, despite the cost of free software being $0, my ipv6
project was charged nearly a million dollars in QA cost from adjacent
business units... just as an example that nothing is free.

That said, if the v2v customer requiring PD put in an order for 10,000+
(guessing) lines , they would likely get dhcpv6-pd.

Asking for it at ietf, not likely helpful. The standards and guidance all
say do PD, now you just need $

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 18:43:33 +0100

Le 03/03/2017 à 17:37, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 2:52 AM Alexandre Petrescu
> Le 03/03/2017 à 11:30, [email-masked]
> <mailto:[email-masked]> a écrit :
>> Hi Alex,
>>
>>
>> This is a chicken-and-egg problem: you need both the cellular
>> device and the network side to support prefix delegation + prefix
>> exclude option,
>
> Money.

Prior to giving money, investors want to see a proof-of-concept.

We cant make a proof-of-concept with a real cellular operator because
no-one delivers PD.

> This is not a 3GPP release issue, this is a money backing the
> deployment cost. And, despite the cost of free software being $0, my
> ipv6 project was charged nearly a million dollars in QA cost from
> adjacent business units... just as an example that nothing is free.

If cellular operators are going to ask 10.000EUR each time a protocol
needs deployment then we wont go far.

I think they should plan differently.

I think DHCPv6-PD deployment is a too key issue to just put a price tag 
on it.

Just pouring money on something can also worsen the problem worse: you 
just say a figure and then everybody calls you with offers, some with 
less technical merit than others.

> That said, if the v2v customer requiring PD put in an order for
> 10,000+ (guessing) lines , they would likely get dhcpv6-pd.

What is '10.000+' lines?  Do you mean one may need 10.000EUR in order to
get DHCPv6-PD deployed on a cellular operator network?

> Asking for it at ietf, not likely helpful.

I am talking about this at IETF because it is at IETF that many
operators are present and make decisions.  I saw it already.

Obviously I am not asking the IETF to deploy some protocol.

What I am asking at IETF is that people retire 64share from the
recommendation to 3GPP.  That is just a small step.

> The standards and guidance all say do PD,

Well no.  The guidance reads 'until PD arrives do 64share'.  They say
'PD is the target', they dont say 'PD is a MUST'.  A 'target' is
something that may take some time to reach... how long time?  It's now
several years...

Now I want them to say 'dont do 64share'.

> now you just need $

But the community of deployers of vehicular network devices _already_
pays money under the form of subscriptions.  And that's huge money
during years, strongly backed alliances, much more than just 10.000EUR.

Isn't it that these cellular operators may be greedy when asking for
more and more money in order to deploy a particular protocol?

I would rather ask these operators:

What's the technical difficulty of deploying DHCPv6-PD?

Is it difficulty to re-visit IPv6 addressing plans? (presumably planned
for one /64 per Host would now have to do more).

Is it billing issue?

Is it fear of too much traffic?

Security?

Is it the 3GPP recommendation of using 64share instead of DHCPv6-PD?

Alex

> I have some smartphone and other M2M modules here on which we could
> try a few things.  What would operator expect to hear from this
> smartphone?
>
>> ===== L_REC#1:  For deployments that require that the same /64
>> prefix be shared, the cellular device should support [RFC7278] to
>> interfaces. The WAN interface is the one towards the Gateway GPRS
>> Support Node (GGSN) / Packet Data Network Gateway (PGW).
>>
>  should stop recommending it.  I has huge problems, at least with
> respect to scalability.
>
>> capabilities [RFC3633] and must support the Prefix Exclude Option
>> for DHCPv6-based Prefix Delegation as defined in [RFC6603].
>
>> There is a need for an efficient mechanism to assign larger
>> prefixes (other than /64s) to cellular hosts
>
> I fully agree.
>
>> Note that the 3GPP network architecture requires both the WAN and
>> the delegated prefix to be aggregatable so the subscriber can be
> It's wrong.  We should _never_ recommend somehting we know it does
> not scale.  Because if we do it may get in widespread use and later
> we'll have a hard time getting rid of.
>
> Alex
>
>>
>> Cheers, Med
>>
>>
>>> [mailto:[email-masked] <mailto:[email-masked]>] De
> la part de Alexandre Petrescu
>>> [email-masked] <mailto:[email-masked]> Objet : Re: Objection to
>>>> In message <[email-masked]
> <mailto:[email-masked]>>,
>>>>> Could it be that 464xlat presence on UE makes it that
>>>>> DHCPv6-PD is impossible on same UE?
>>>>
>>>>>> -----Mensaje original----- De: ipv6 <[email-masked]
> <mailto:[email-masked]>>
>>>>>> <[email-masked]
> <mailto:[email-masked]>> Responder a:
>>>>>> <[email-masked]
> <mailto:[email-masked]>> Fecha: jueves, 2 de marzo de
>>>>>> 2017, 20:15 Para: <[email-masked] <mailto:[email-masked]>>
> Asunto: Re: Objection to
>>>>>>  based on IPv4, like 6rd.  I think it's something
>>>>>> developped in-house at that particular operator.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Saludos, Jordi
>>>>>>>
>>>>>>>
>>>>>>> <[email-masked]
> <mailto:[email-masked]>>
>>>>>>> <[email-masked]
> <mailto:[email-masked]>> Responder a:
>>>>>>> <[email-masked]
> <mailto:[email-masked]>> Fecha: jueves, 2 de marzo de
>>>>>>> 2017, 20:02 Para: <[email-masked] <mailto:[email-masked]>>
> Asunto: Re: Objection to
>>>>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-
>
>>>>>
>>>>>
>>>>>
>>>>>
>> deployment-s
>>>>>
>>>>>
>>>>>
>>>>>
>>> urvey
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Saludos, Jordi
>>>>>>>>
>>>>>>>>
>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>> en
> nombre de Mikael Abrahamsson
>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>> Organizacin:
> People's Front Against
>>>>>>>> WWW Responder a: <[email-masked]
> <mailto:[email-masked]>> Fecha: jueves, 2 de
>>>>>>>> <[email-masked]
> <mailto:[email-masked]>> CC: <[email-masked]
> <mailto:[email-masked]>>
>>>>>>>> Asunto: Re: Objection to
>>>>>>>>> Ah great, but I guess few cellular operators (if
>>>>>>>>> any?) are LIRs. Or maybe that's true and I didnt
>>>>>>>>> know.
>>>>>>>>
>>>>>>>> You don't know.
>>>>>>>>
>>>>>>>>> enough /64s out there - then why operators only
>>>>>>>>> assign one per one end user?
>>>>>>>>
>>>>>>>> networks yet (that I know of). So that's all they can
>>>>>>>> do per 3GPP standards.
>>>>>>>>
>>>>>>>>  likely. You're perfectly within your right as an
>>>>>>>> operator to deploy /48 per customer per current RIR
> <mailto:[email-masked]>
>>>>>>>>
>>>>>>>>
> <mailto:[email-masked]> Administrative
>>>>>>>> that any disclosure, copying, distribution or use of
>>>>>>>> the contents of this information, including attached
>>>>>>>> files, is prohibited.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> <mailto:[email-masked]> Administrative
> <mailto:[email-masked]>
>>>>>>> privileged or confidential. The information is intended
>>>>>>> to be for the use of the individual(s) named above. If
>>>>>>> you are not the intended recipient be aware that any
> <mailto:[email-masked]> Administrative
> <mailto:[email-masked]>
> <mailto:[email-masked]> Administrative
> <mailto:[email-masked]>
> <mailto:[email-masked]> Administrative
> <mailto:[email-masked]> Administrative Requests:

---

From: 神明達哉 <[email-masked]>
Date: Fri, 3 Mar 2017 11:03:17 -0800

At Thu, 2 Mar 2017 13:36:44 +0100,

> the link-local prefix?  If the mandate applies to the prefix in RA then

Both, and I believe at least most implementers have had no difficulty
in interpreting the spec that way.

> mandate applies to both then RFC4291 is wrong when it says fe80::/10.

Like in my previous message, I don't know what "it says fe80::/10" in
this context.  I also don't know implementation details of the Linux
kernel either, but the BSD implementation uses:

- uses the 64-bit IID (as specified in RFC2464)
- uses the fe80::/64 prefix (as defined in RFC4291 Section 2.5.6)
- combine these to configure a link-local address fe80::<64-bit IID>
  as specified in Section 5.3 of RFC4862

To me there's nothing confusing or unclear here, and I suspect the
Linux implementation essentially does the same thing.

> RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64".

That's fine.  The only thing this RFC is expected to say is the length
of IIDs.  RFC4862 defines how we use the IID to (auto)configure
addresses.  And RFC4862 applies it to both link-local and global.

> 0 to a /63 from the RA, or other mechanism.

It's not the job of RFC2464.  RFC4862 imposes the restriction through
its Section 5.5.3 bullet d):

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

> a /63 in the RA: it adds a rt entry for that /63 prefix.  That's not

I suspect you're probably conflating SLAAC with on-link prefix
determination.  I guess that "rt entry for that /63 prefix" is to
treat the /63 prefix as on-link (assuming the corresponding PIO has L
bit on).  If so, that's the correct behavior per RFC4861 (not 4862).
It's also correct to ignore that prefix for SLAAC per RFC4862 (not
4861).  Nothing wrong here.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 3 Mar 2017 11:14:00 -0800

At Fri, 3 Mar 2017 10:58:59 +0100,
Alexandre Petrescu <[email-masked]> wrote:

> When you say 'recognize' you mean by using the below macro?

No.  I meant it wouldn't consider a destination address that matches
fe80::/10 but not fe80::/64 to be on-link for any of its local links.

> Otherwise there can be risks of incompatibility, address space waste,

The BSD implementation doesn't (auto)generate a link-local address
that does not match fe80::/64.  It also doesn't send a packet to a
destination that matches fe80::/10 but not fe80::/64 to outside of the
node.  So I don't see any possibility of incompatibility, at least in
practice.

You may not *like* that implementation, but to me, it's merely a
matter of taste, not about correctness.

> trying to recognise an LL address it has just generated?

zero, as specified in RFC4291 and RFC4862 (btw I don't understand what
you mean by "when trying to recognise an LL address it has just
generated" in this context).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 22:09:47 +0100

Le 03/03/2017 à 20:03, 神明達哉 a écrit :
> At Thu, 2 Mar 2017 13:36:44 +0100, Alexandre Petrescu
>> Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used
>>  for stateless autoconfiguration [ACONF] of an Ethernet interface
>> must have a length of 64 bits".
>>
>> It does not say which prefix of [ACONF/RFC2462] must be /64?  Is it
>> a global prefix in RA?  Or is it the link-local prefix?  Both these
>> prefixes are relevant for the above phrase, both are mentioned in
>> ACONF, yet only one is present in RA (the one linux complains about
>> when at 65).  Is the mandate cited above applying to the prefix in
>> RA?  Or to the link-local prefix?  If the mandate applies to the
>> prefix in RA then
>
> Both, and I believe at least most implementers have had no
> difficulty in interpreting the spec that way.

If it is both, then it requires that the prefix used for address
autoconfiguration of LL addresses to be 64bit length.

But the LL prefix is fe80::/10.

"fe80::/10" means it is a prefix.  It does not mean it is "a mask for 
implementation in BSD and other OSs C macros to recognise the LL address".

So, what goes between /10 and /64?  Why?

>> linux is right to complain, on Ethernet.  If the mandate applies
>> only to the LL prefix, then linux is wrong to complain about 65 in
>>  RA.  If the mandate applies to both then RFC4291 is wrong when it
>>  says fe80::/10.
>
> Like in my previous message, I don't know what "it says fe80::/10"
> in this context.  I also don't know implementation details of the
> Linux kernel either, but the BSD implementation uses:
>
> - uses the 64-bit IID (as specified in RFC2464) - uses the fe80::/64
>  prefix (as defined in RFC4291 Section 2.5.6)

And ignores the same document's fe80::/10.  And some implementer does
not appreciate that.

> as specified in Section 5.3 of RFC4862

And who tells the implementer what to put between /10 and /64?

Should that be 0s?  1s?  An arbitrary random mix of 0s and 1s?

> Linux implementation essentially does the same thing.

I think you dont want to see the potential confusion because you do not
ask yourself what to put between /10 and /64.  I think you silently
assume that should be 0s.

> That's fine.  The only thing this RFC is expected to say is the
> length of IIDs.

Well, let's clarify: the RFC2464 does say too that the prefix length
should be.  It does say it must be 64.

> RFC4862 defines how we use the IID to (auto)configure addresses. And
>  RFC4862 applies it to both link-local and global.

Yes.

>> It does not forbid that that 64bit prefix be formed by
>> self-appending a 0 to a /63 from the RA, or other mechanism.
>
> It's not the job of RFC2464.  RFC4862 imposes the restriction
> through its Section 5.5.3 bullet d):

Well then, it should.

BEcause currently RFC2464 says "An IPv6 address prefix used
for stateless autoconfiguration [ACONF] of an Ethernet interface
must have a length of 64 bits".

If we go by your recommendation above, then it means RFC2464 must not
say that.

> If the sum of the prefix length and interface identifier length does
>  not equal 128 bits, the Prefix Information option MUST be ignored.

YEs, that's what RFC4862 says, and I agree.

>> Besides, RFC4862 (successor to 2462) says "If the sum of the
>> prefix length and interface identifier length does not equal 128
>> bits, the Prefix Information option MUST be ignored." And linux
>> does _not_ ignore a /63 in the RA: it adds a rt entry for that /63
>> prefix. That's not normal either.
>
> determination.

I dont conflate.

> I guess that "rt entry for that /63 prefix" is to treat the /63
> prefix as on-link (assuming the corresponding PIO has L bit on).

YEs.

> If so, that's the correct behavior per RFC4861 (not 4862).

So RFC4862 should not require the Host to ignore a received non 128
plen+IID, because RFC4861 accepts it.

As such, either rfc4862 or rfc4861 should be modified to make it work
together.  Maybe rfc4862 should not require the Host to refuse a
received plen+IID not making for 128.

> 4861).

If some RFC requires the Host to ignore the PIO and some other RFC
requires the Host to interpret it, and both RFCs are mandatory to
implement, under the same conditions, isn't there a conflict?

> Nothing wrong here.

That is your view, and I respect it.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 3 Mar 2017 14:02:10 -0800

At Fri, 3 Mar 2017 22:09:47 +0100,

> So, what goes between /10 and /64?  Why?

For (auto)configuring a link-local address?  If so, it's all-0 bits,
as defined in Section 2.5.6 of RFC4291:

   |   10     |

> And ignores the same document's fe80::/10.  And some implementer does

I'm not sure what you mean by this here, but out of curiosity, who is
that implementer and what does it actually do by not appreciating
that?  Auto-configuring a link-local address that does not match fe80::/64?

> Should that be 0s?  1s?  An arbitrary random mix of 0s and 1s?

0s, as described in RFC4291 Section 2.5.6.

> assume that should be 0s.

If "what to put between /10 and /64" is for (auto)configuring
link-local addresses, yes, I assume it's 0s.  But not "silently" -
it's based on Section 2.5.6 of RFC4291.

BTW, I do not necessarily disagree that there may be "some confusion"
if one sees this:

      Link-Local unicast   1111111010           FE80::/10       2.5.6
(Section 2.4 of RFC4291)

and this:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+
(Section 2.5.6 of RFC4291)

like, wondering "what if the intermediate 54 bits are non-0?  should
it be called a link-local address?".

But, at least in terms of auto-generating link-local addresses, the
specs are clear enough to me that these bits should be set to 0.
That's why I always try to clarify the context is to auto-generate a
link-local address in this conversation.

If you want to further clear any possible confusion between the
intermediate 54 bits, I wouldn't discourage you to write a "mystery of
the intermediate 54 bits for fe80::/10" draft:-)

> If we go by your recommendation above, then it means RFC2464 must not

I guess we're just not on the same page...trying to rephrase my point,
it doesn't matter that RFC2464 "does not forbid that that 64bit prefix
be formed by self-appending a 0 to a /63 from the RA", since RFC4862
forbids it anyway (by the "sum must be 128" requirement).

> plen+IID, because RFC4861 accepts it.

Here I actually see conflating.  RFC4862 only says the host MUST
ignore such prefix *for SLAAC*.  It doesn't say, for example, it
should ignore the entire RA or even for that particular PIO for other
purposes than SLAAC.  But I admit this point may be subtle and can
easily be misunderstood.  RFC4862 tried to clarify that subtlety a bit
in the following paragraph of that section (that was actually written
by me):

      It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type.  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.  Thus, it
      should be safe to validate the advertised prefix length here, in
      order to detect and avoid a configuration error specifying an
      invalid prefix length in the context of address autoconfiguration.

but this conversation seems to suggest it's still not clear enough.

> together.

4861 and 4862 already work together.  But, we could make it even
clearer that prefix length validation for on-link determination
(actually there's no restriction for this) and prefix length
validation for SLAAC are independent, if and when we want to update
these RFCs.

> Maybe rfc4862 should not require the Host to refuse a

No, it should still require that, as there's currently no defect in
the spec even if it may still not be crystal clear for some.  However,
you have the right to propose loosening the requirement, so if you
think that change is necessary, please feel free to write a draft.

> implement, under the same conditions, isn't there a conflict?

No, there's no conflict, once one understands the two types
validations are independent:

- RFC4861 does not impose any restriction on the prefix length in PIO
  for on-link determination purpose (and therefore the host is
  expected to accept any length of prefix for on-link determination)
- RFC4862 requires the host to ignore the PIO of some particular
  length for the purpose of SLAAC (and therefore the host is expected
  to not use a prefix of "invalid length" to configure an address)

Both can coexist.  BSDs literally implement it.  From your previous
message, I guess so does Linux.  I also suspect so do other major OS
implementations such as Windows or Solaris, as this separation has
been in fact one of common test cases in IPv6 protocol conformance
test suites.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 23:40:08 +0100

Le 03/03/2017 à 23:02, 神明達哉 a écrit :
> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu
>> "fe80::/10" means it is a prefix.  It does not mean it is "a mask
>> for implementation in BSD and other OSs C macros to recognise the
>> LL address".
>>
> |   10     | |  bits    |         54 bits         |          64 bits
> | +----------+-------------------------+----------------------------+

Is that figure picturing a fe80::/10 or a fe80::/64?

Is the prefix extended from fe80::/10 to fe80::/64 with 0s?  Or is the
IID len extended from 64 to to become an IID len==108?

If we stopped saying fe80::/10 then it would be clearer.

But one seems to be forced to continue talking about fe80::/10.

Otherwise we would never write text reading "fe80::/10".

>>> - uses the 64-bit IID (as specified in RFC2464) - uses the
>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6)
>>
>> And ignores the same document's fe80::/10.  And some implementer
>> does not appreciate that.
>
> that?

Let us say that I talked to many IPv6 stack implementers and I continue
to.  So to answer this question there is not one person in particular
that I could name, but rather the name of a few persons, and a sort of
average I make from my discussions.

Moreover, whenever I invoke such 3rd person, it is the very optimistic
view.  I avoid saying all the bad things that I heard, and I keep the
good things.

> Auto-configuring a link-local address that does not match fe80::/64?

I mean this: is one implementer mandated to bzero() the bits from /10 to
/64?  Or not?  Nobody is telling her so.

If one writes code that generate an LL address by using a /64 mask, and
then tries to make sure by recognising it by using a /10 macro, there is
obviously place for false negatives or false positives.

If the 4291 spec wrote everywhere that the prefix is "fe80::/64"  (and
never write "fe80::/10"), then the implementer would be helped a lot.
She would generate and reognise by always using a 64bit mask.

But that would be wrong to put in an IPv6 Addressing Archi, because 64
is too much of a limit, anyways.

Additionally, when we talk  about the first 3 bits 000, we dont write
"::/3" because "::/3" is a prefix and there is a risk of confusion.

You may remember the discussion about how to denote a default route.

>>> - combine these to configure a link-local address fe80::<64-bit
>>> IID> as specified in Section 5.3 of RFC4862
>>

Are these 0s part of the plen or part of the IID?

>>> To me there's nothing confusing or unclear here, and I suspect
>>> the Linux implementation essentially does the same thing.
>>
>> I think you dont want to see the potential confusion because you
>> do not ask yourself what to put between /10 and /64.  I think you
>> silently assume that should be 0s.
>

That section 2.5.6 does not say whether the 0s are part of the plen or
part of the IID.

It is your reading, with an inclined view to make everything work, that
makes it read so.

But read it with an inquiring view: is the 0 part of the IID or of the
plen?  The section does not answer.

> |   10     | |  bits    |         54 bits         |          64 bits
> | +----------+-------------------------+----------------------------+

I agree with the doubt.

>  link-local address in this conversation.

Yes, it's clear it should be 0.  But it's not clear whether the 0s are
part of the plen or part of the IID.

> intermediate 54 bits, I wouldn't discourage you to write a "mystery
> of the intermediate 54 bits for fe80::/10" draft:-)

I agree :-)  When I hear this I think I need to stop talking because I
cant write so many drafts as I write emails :-)

But some of these things are indeed doubts there for a long time.
>> BEcause currently RFC2464 says "An IPv6 address prefix used for
>> stateless autoconfiguration [ACONF] of an Ethernet interface must
>> have a length of 64 bits".
>>
>> If we go by your recommendation above, then it means RFC2464 must
>> not say that.
>
> I guess we're just not on the same page...trying to rephrase my
> point, it doesn't matter that RFC2464 "does not forbid that that
> 64bit prefix be formed by self-appending a 0 to a /63 from the RA",
> since RFC4862 forbids it anyway (by the "sum must be 128"
> requirement).

I dont understand you.

I want to say this: RFC2464 does require the prefix len to be 64.

> ignore such prefix *for SLAAC*.

That emphasis is yours, it's not in the document.  The document says it
must ignore it.

> It doesn't say, for example, it should ignore the entire RA or even
> for that particular PIO for other purposes than SLAAC.

It says it must ignore the PIO.  IT does not say for what to ignore it.

> But I admit this point may be subtle and can easily be misunderstood.
> RFC4862 tried to clarify that subtlety a bit in the following
> paragraph of that section (that was actually written by me):
>
> It is the responsibility of the system administrator to ensure that
> the lengths of prefixes contained in Router Advertisements are
> consistent with the length of interface identifiers for that link
> type.  It should be noted, however, that this does not mean the
> advertised prefix length is meaningless.  In fact, the advertised
> length has non-trivial meaning for on-link determination in
> [RFC4861] where the sum of the prefix length and the interface
> identifier length may not be equal to 128.  Thus, it should be safe
> to validate the advertised prefix length here, in order to detect and
> avoid a configuration error specifying an invalid prefix length in
> the context of address autoconfiguration.

It reads reasonable.  But the other paragraph requiring to ignore the 
PIO which is non 64 is still there.  These two paragraphs are contradictory.

One requires consistency, the other requires 64.

We are going to write the same for IPv6 Addressing Architecture?  A 
paragraph requiring 64 and another requiring variable length?

> but this conversation seems to suggest it's still not clear enough.

BEcause when writing RFCs it is not by adding paragraphs that things get 
clearer.  Clarification paragraphs may be good, but often removing some 
paragraphs can also improve clarity.

There are readers out there, most often the programmers.  They dont care 
about the earlier discussion involving pride and other feelings.  They 
want consistency - things that can be easily implemented.

>> As such, either rfc4862 or rfc4861 should be modified to make it
>> work together.
>
>> Maybe rfc4862 should not require the Host to refuse a received
>> plen+IID not making for 128.
>

Ah this invitation.  The title reads great!  "Mistery of...".  Thanks, 
but no, not at this time :-)

>>> It's also correct to ignore that prefix for SLAAC per RFC4862
>>> (not 4861).
>>
> for on-link determination purpose (and therefore the host is expected
> to accept any length of prefix for on-link determination) - RFC4862
> requires the host to ignore the PIO of some particular length for the
> purpose of SLAAC (and therefore the host is expected to not use a
> prefix of "invalid length" to configure an address)
>

Ok.

Alex

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Mar 2017 14:51:17 -0800

Read the fine RFC, Alexandre. We used to have something called a site-local address, which was fe80::/10 with 54 bits that were not all zero and a 64 bit IID, and the link-local address was fe80::/10 with 54 bits of zero. We deprecated the site-local address, but link-local is still fe80::/10 followed by 54 bits that are all zero.

> On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> It reads reasonable.  But the other paragraph requiring to ignore the PIO which is non 64 is still there.  These two paragraphs are contradictory.
> 
> We are going to write the same for IPv6 Addressing Architecture?  A paragraph requiring 64 and another requiring variable length?
> 
> BEcause when writing RFCs it is not by adding paragraphs that things get clearer. Clarification paragraphs may be good, but often removing some paragraphs can also improve clarity.
> 
> There are readers out there, most often the programmers.  They dont care about the earlier discussion involving pride and other feelings.  They want consistency - things that can be easily implemented.
> 
> Ah this invitation.  The title reads great!  "Mistery of...".  Thanks, but no, not at this time :-)
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Mar 2017 23:54:54 +0100

> That section 2.5.6 does not say whether the 0s are part of the plen
> or part of the IID.
> 
> It is your reading, with an inclined view to make everything work,
> that makes it read so.
> 
> But read it with an inquiring view: is the 0 part of the IID or of
> the plen?  The section does not answer.

Section 5.3 of RFC 4862 spells it out in great detail:
   A link-local address is formed by combining the well-known link-local
   prefix FE80::0 [RFC4291] (of appropriate length) with an interface
   identifier as follows:

   1.  The left-most 'prefix length' bits of the address are those of
       the link-local prefix.

   2.  The bits in the address to the right of the link-local prefix are
       set to all zeroes.

   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

   If the sum of the link-local prefix length and N is larger than 128,
   autoconfiguration fails and manual configuration is required.  The
   length of the interface identifier is defined in a separate link-
   type-specific document, which should also be consistent with the
   address architecture [RFC4291] (see Section 2).  These documents will
   carefully define the length so that link-local addresses can be
   autoconfigured on the link.

   A link-local address has an infinite preferred and valid lifetime; it
   is never timed out.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 4 Mar 2017 13:09:35 +0100

Fred,

I think the problem I have - agreed, on my side - is that "fe80::/10" is
sometimes read as a link-local address, other times as a prefix
configured on a computer, other times as just the first 10bits of an LL
address.

The difficulty is in that people say "prefix" meaning the first bits
from left to right, and other times "prefix" meaning what is configured
on a computer.  They are different.

This "fe80::/10" seems to be the first ten bits of a link-local address;
"fe80::/10" is not an address and not a prefix to be configured on a
computer, even though whenever we write "P::/X" we understand it as a
prefix configured on a computer.

The prefix configured on a computer is "fe80::/64" and the LL address is
"fe80::1".

I had the same problem with textual representation of site-local "fec0",
with the default route "2001::/3", with the two ULAs "fc00::/7"
"fd00::/7" and recently with the 16 prefixes denoted by
2001:db8:ffff:cafe::/60 despite the mandatory presence of a single
character (the 'e' in cafe could have been 0, 1, 2... f).

I propose to introduce new ASCII characters in the textual
representation of IPv6 addresses:

fe80:://10 means the first 10 bits of an address, it does not mean it is
the configured prefix of an address in the rt table, nor is it a prefix
used for on-link determination.

fg00:://7 means the first 7 bits of a ULA, also represented as
"fc00::/7" or as "fd00::/7".

2001:db8:ffff:caf*::/60 means one or more configured prefixes from 0 to
f at the place of *.

I will try to use these characters in conversation to see what it gives.

Alex

Le 03/03/2017 à 23:51, Fred Baker a écrit :
> Read the fine RFC, Alexandre. We used to have something called a
> site-local address, which was fe80::/10 with 54 bits that were not
> all zero and a 64 bit IID, and the link-local address was fe80::/10
> with 54 bits of zero. We deprecated the site-local address, but
> link-local is still fe80::/10 followed by 54 bits that are all zero.
>
>>>> If it is both, then it requires that the prefix used for
>>>> address autoconfiguration of LL addresses to be 64bit length.
>>>>
>>>> "fe80::/10" means it is a prefix.  It does not mean it is "a
>>>> mask for implementation in BSD and other OSs C macros to
>>>> recognise the LL address".
>>>>
>>> For (auto)configuring a link-local address?  If so, it's all-0
>>> bits, as defined in Section 2.5.6 of RFC4291:
>>>
>>
>> Is the prefix extended from fe80::/10 to fe80::/64 with 0s?  Or is
>> the IID len extended from 64 to to become an IID len==108?
>>
>>>> And ignores the same document's fe80::/10.  And some
>>>> implementer does not appreciate that.
>>>
>>> I'm not sure what you mean by this here, but out of curiosity,
>>> who is that implementer and what does it actually do by not
>>> appreciating that?
>>
>> Let us say that I talked to many IPv6 stack implementers and I
>> continue to.  So to answer this question there is not one person
>> in particular that I could name, but rather the name of a few
>> persons, and a sort of average I make from my discussions.
>>
>> Moreover, whenever I invoke such 3rd person, it is the very
>> optimistic view.  I avoid saying all the bad things that I heard,
>> and I keep the good things.
>>
>> I mean this: is one implementer mandated to bzero() the bits from
>> /10 to /64?  Or not?  Nobody is telling her so.
>>
>> If one writes code that generate an LL address by using a /64
>> mask, and then tries to make sure by recognising it by using a /10
>> macro, there is obviously place for false negatives or false
>> positives.
>>
>> If the 4291 spec wrote everywhere that the prefix is "fe80::/64"
>> (and never write "fe80::/10"), then the implementer would be
>> helped a lot. She would generate and reognise by always using a
>> 64bit mask.
>>
>> But that would be wrong to put in an IPv6 Addressing Archi,
>> because 64 is too much of a limit, anyways.
>>
>> Additionally, when we talk  about the first 3 bits 000, we dont
>> write "::/3" because "::/3" is a prefix and there is a risk of
>> confusion.
>>
>>>>> - combine these to configure a link-local address
>>>>> fe80::<64-bit IID> as specified in Section 5.3 of RFC4862
>>>>
>>>>> To me there's nothing confusing or unclear here, and I
>>>>> suspect the Linux implementation essentially does the same
>>>>> thing.
>>>>
>>>> I think you dont want to see the potential confusion because
>>>> you do not ask yourself what to put between /10 and /64.  I
>>>> think you silently assume that should be 0s.
>>>
>>> link-local addresses, yes, I assume it's 0s.  But not "silently"
>>> - it's based on Section 2.5.6 of RFC4291.
>>
>> That section 2.5.6 does not say whether the 0s are part of the
>> plen or part of the IID.
>>
>>> BTW, I do not necessarily disagree that there may be "some
>>> confusion" if one sees this:
>>>
>>>
>>> like, wondering "what if the intermediate 54 bits are non-0?
>>> should it be called a link-local address?".
>>
>> I agree with the doubt.
>>
>>> But, at least in terms of auto-generating link-local addresses,
>>> the specs are clear enough to me that these bits should be set
>>> to 0. That's why I always try to clarify the context is to
>>> auto-generate a link-local address in this conversation.
>>
>> Yes, it's clear it should be 0.  But it's not clear whether the 0s
>> are part of the plen or part of the IID.
>>
>>> intermediate 54 bits, I wouldn't discourage you to write a
>>> "mystery of the intermediate 54 bits for fe80::/10" draft:-)
>>
>> I agree :-)  When I hear this I think I need to stop talking
>> because I cant write so many drafts as I write emails :-)
>>
>>>> stateless autoconfiguration [ACONF] of an Ethernet interface
>>>> If we go by your recommendation above, then it means RFC2464
>>>> must not say that.
>>>
>>>  64bit prefix be formed by self-appending a 0 to a /63 from the
>>> RA", since RFC4862 forbids it anyway (by the "sum must be 128"
>>> requirement).
>>
>> I dont understand you.
>>
>>>>> I guess that "rt entry for that /63 prefix" is to treat the
>>>>> /63 prefix as on-link (assuming the corresponding PIO has L
>>>>> bit on).
>>>>
>>>> YEs.
>>>>
>>>> So RFC4862 should not require the Host to ignore a received
>>>> non 128 plen+IID, because RFC4861 accepts it.
>>>
>> That emphasis is yours, it's not in the document.  The document
>> says it must ignore it.
>>
>>> It doesn't say, for example, it should ignore the entire RA or
>>> even for that particular PIO for other purposes than SLAAC.
>>
>>> But I admit this point may be subtle and can easily be
>>> misunderstood. RFC4862 tried to clarify that subtlety a bit in
>>> the following paragraph of that section (that was actually
>>> written by me):
>>>
>>> determination in [RFC4861] where the sum of the prefix length
>>> and the interface identifier length may not be equal to 128.
>>> Thus, it should be safe to validate the advertised prefix length
>>> here, in order to detect and avoid a configuration error
>>> specifying an invalid prefix length in the context of address
>>> autoconfiguration.
>>
>> It reads reasonable.  But the other paragraph requiring to ignore
>> the PIO which is non 64 is still there.  These two paragraphs are
>> contradictory.
>>
>> We are going to write the same for IPv6 Addressing Architecture?
>> A paragraph requiring 64 and another requiring variable length?
>>
>> BEcause when writing RFCs it is not by adding paragraphs that
>> things get clearer. Clarification paragraphs may be good, but
>> often removing some paragraphs can also improve clarity.
>>
>> There are readers out there, most often the programmers.  They
>> dont care about the earlier discussion involving pride and other
>> feelings.  They want consistency - things that can be easily
>> implemented.
>>
>>>> As such, either rfc4862 or rfc4861 should be modified to make
>>>> it work together.
>>>
>>> validation for SLAAC are independent, if and when we want to
>>> update these RFCs.
>>>
>>> No, it should still require that, as there's currently no defect
>>> in the spec even if it may still not be crystal clear for some.
>>> However, you have the right to propose loosening the
>>> requirement, so if you think that change is necessary, please
>>> feel free to write a draft.
>>
>>>> If some RFC requires the Host to ignore the PIO and some other
>>>> RFC requires the Host to interpret it, and both RFCs are
>>>> mandatory to implement, under the same conditions, isn't there
>>>> a conflict?
>>>
>>> - RFC4861 does not impose any restriction on the prefix length
>>> in PIO for on-link determination purpose (and therefore the host
>>> is expected to accept any length of prefix for on-link
>>> determination) - RFC4862 requires the host to ignore the PIO of
>>> some particular length for the purpose of SLAAC (and therefore
>>> the host is expected to not use a prefix of "invalid length" to
>>> configure an address)
>>>
>>> Both can coexist.  BSDs literally implement it.  From your
>>> previous message, I guess so does Linux.  I also suspect so do
>>> other major OS implementations such as Windows or Solaris, as
>>> this separation has been in fact one of common test cases in
>>> IPv6 protocol conformance test suites.
>>
>> Ok.
>>
>> Alex
>>
>>>
>>> -- JINMEI, Tatuya
>>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 4 Mar 2017 13:33:05 +0100

This proposal has now a DOI: 10.13140/RG.2.2.30828.36484

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Mar 2017 08:29:44 +1300

> configured on a computer, other times as just the first 10bits of an LL

It's a prefix. ("Point, à la ligne.", comme on dit en francais.)

The problem isn't there. It's that in a router, a prefix is the thing
you perform longest match against. In a host, it's what you use in
source address selection, next-hop router selection, and on-link
determination, and during address auto-configuration. So it has
many roles.

And fe80::/x is just a special case. No way round that. Also, it's
meaningless without an interface, but we don't write fe80::/10%eth0.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 5 Mar 2017 13:39:47 +0100

Le 04/03/2017 à 20:29, Brian E Carpenter a écrit :
>> I think the problem I have - agreed, on my side - is that
>> "fe80::/10" is sometimes read as a link-local address, other times
>> as a prefix configured on a computer, other times as just the first
>> 10bits of an LL address.
>
> The problem isn't there. It's that in a router, a prefix is the
> thing you perform longest match against. In a host, it's what you use
> in source address selection, next-hop router selection, and on-link
> determination, and during address auto-configuration. So it has many
> roles.

YEs, it has many roles.  An additional role is that of recognising an
address based on its X leading bits.  Even though the prefix of that
address is not only its X leading bits.

This is in itself confusing.

> And fe80::/x is just a special case. No way round that.

...there are so many special cases: fc00 an fd00 meaning the same, the 
::/0, the 1::1/128 meaning an address _and_ a prefix, and so on.

> Also, it's meaningless without an interface, but we don't write
> fe80::/10%eth0.

I think that %iface should be mandatory in notation of LLs.  Otherwise 
there can be collision.

Alex

---

From: Christian Huitema <[email-masked]>
Date: Sun, 5 Mar 2017 16:14:38 -0800

> I think that %iface should be mandatory in notation of LLs.  Otherwise

Mandatory in what context? The interface ID is only defined in the
context of a machine. %Eth0 on one machine may designate the same link
as %10 on another.

-- Christian Huitema

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 16:00:58 -0500

>         (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))

Tatuya, masking it that way it means that fe81::/10 is also recognized 
as an LL address prefix, right?  I think it is good, but just checking.

> If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for

That '10' hardcoded is not a problem, because RFC4291 requires it to be 10.

I agree.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Mon, 27 Mar 2017 14:24:24 -0700

At Mon, 27 Mar 2017 16:00:58 -0500,

> as an LL address prefix, right?  I think it is good, but just checking.

fe81::/10 is just an "abnormal" form of fe80::/10, but I guess you
actually meant fe81::/16.  Assuming so, your understanding is correct:
an address that matches fe81::/16 is recognized as unicast link-local
wherever the IN6_IS_ADDR_LINKLOCAL macro is used for the test.  For
example, BSD kernels consider this kind of address to be unicast
link-local in the validation of received RA:

    if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) {
        nd6log((LOG_ERR,
            "nd6_ra_input: src %s is not link-local\n",
            ip6_sprintf(ip6bufs, &saddr6)));
        goto bad;
    }
(this code only checks the first 10 bits).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 17:25:02 -0500

Le 27/03/2017 à 16:24, 神明達哉 a écrit :
> At Mon, 27 Mar 2017 16:00:58 -0500, Alexandre Petrescu
>>> #define IN6_IS_ADDR_LINKLOCAL(a)        \ (((a)->s6_addr[0] ==
>>> 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
>>
>> Tatuya, masking it that way it means that fe81::/10 is also
>> recognized as an LL address prefix, right?  I think it is good,
>> but just checking.
>
> fe81::/10 is just an "abnormal" form of fe80::/10,

Err, I dont think fe81::/10 is an abnormal LL.  I think fe81::/10, 
fe82::/10, ... febf::/10 are all normal forms of LL.

> but I guess you actually meant fe81::/16.

I did not mean fe81::/16, I meant fe81::/10.

fe80      is: 1111 1110 1000 0000
fe80::/10 is: 1111 1110 10
fe81::/10 is: 1111 1110 10

Alex

> Assuming so, your understanding is correct: an address that matches
> fe81::/16 is recognized as unicast link-local wherever the
> IN6_IS_ADDR_LINKLOCAL macro is used for the test.  For example, BSD
> kernels consider this kind of address to be unicast link-local in the
> validation of received RA:
>
> if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) { nd6log((LOG_ERR,
> "nd6_ra_input: src %s is not link-local\n", ip6_sprintf(ip6bufs,
> &saddr6))); goto bad; } (this code only checks the first 10 bits).
>
> -- JINMEI, Tatuya
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 27 Mar 2017 17:50:59 -0700

At Mon, 27 Mar 2017 17:25:02 -0500,

> fe82::/10, ... febf::/10 are all normal forms of LL.

By abnormal I meant setting the tenth bit is meaningless just as

> fe81::/10 is: 1111 1110 10

But in any case, I believe my previous message answered your main
question.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 27 Mar 2017 17:53:17 -0700

On Mon, Mar 27, 2017 at 5:50 PM <[email-masked]> wrote:

> By abnormal I meant setting the tenth bit is meaningless

Oops, it should be "the 16th bit".  Sorry for the noise.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 20:11:24 -0500

> (this code only checks the first 10 bits).

If this code runs on an Ethernet interface, then I think it is wrong. 
BEcause the link-local prefix on an Ethernet interface is fe80::/64, and 
not fe80::/10.

IN6_IS_ADDR_LINK_LOCAL run on Ethernet should use a mask of 64bits, not 
10bits, as it currently does.

In general, a generic IN6_IS_ADDR_LINKLOCAL is good to use a /10 mask. 
But some different IN6_IS_ADDR_LINK_LOCAL_ETHERNET is good with mask /64.

fe81::1 on Ethernet is not a Link Local address.

fe81::1 in general _is_ a Link Local address.

(and, yes, ideally, it would be good to make that 64 a parameter even of 
Ethernet, but that is a separate discussion).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 20:16:09 -0500

> Oops, it should be "the 16th bit".  Sorry for the noise.

Well, I agree setting the 16th bit can be meaningless, because it is 
beyond the first hextet.

fe80:1::/10 is too long, because that "1" is way beyond the 10th bit.

But fe81::/10 is not meaningless.

fe80::/10 is not more meaningful than fe81::/10.

Actually one can wonder why RFC writers decided to write fe80::/10 when 
they could have written fe81::/10 equaly well.  Or even fe90::/10 or 
febf::/10.  All these designate the same 10bits - the mask 1111 1110 10.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Tue, 28 Mar 2017 08:02:23 +0100

Alexandre Petrescu <[email-masked]> wrote:

> Actually one can wonder why RFC writers decided to write fe80::/10 when they could have written fe81::/10 equaly well.  Or even fe90::/10 or febf::/10.  All these designate the same 10bits - the mask 1111 1110 10.

I thought this was answered a good few messages ago. It is customary to always write the "lowest value that fits" - ie the one where all the non-prefix bits are zero.
So fe80::/10 fits - all the bits after the first 10 are zero
fe81::/10 does not fit - when you mask off the non-prefix bits you get a different value

So while in terms of maths, after doing the masking you get the same result, by not applying the "all host bits are zero" rule - you have introduced confusion for humans.

As pointed out, 172.17.0.0/12 might make as much sense as 172.16.0.0/12 IFF you ignore this feature. Applying the mask to 172.17.0.0/12 gives you non-zero host bits - hence why we don't use that.
It's all to do with consistency and avoidance of confusion. And we need as much of that as we can - I know plenty of supposedly network capable people who cannot understand the concept of 172.16.1.0/23 being a valid IP address !

But to be frank, I still can't see what the proposal is about - just what use case does it solve ?

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Mar 2017 07:46:59 -0500

Le 28/03/2017 à 02:02, Simon Hobson a écrit :
>> Actually one can wonder why RFC writers decided to write fe80::/10
>> when they could have written fe81::/10 equaly well.  Or even
>> fe90::/10 or febf::/10.  All these designate the same 10bits - the
>> mask 1111 1110 10.
>
> I thought this was answered a good few messages ago.

I did not see?

> It is customary to always write the "lowest value that fits"

I did not know it was customary?  Maybe it should be documented.

As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult to
compare visually two IPv6 addresses, and tell which is lower value.

> - ie the one where all the non-prefix bits are zero. So fe80::/10
> fits - all the bits after the first 10 are zero fe81::/10 does not
> fit - when you mask off the non-prefix bits you get a different
> value

Well, makes sense.

But from this to say that LL addresses are _only_ those that start with
fe80 there is a long way.

> So while in terms of maths, after doing the masking you get the same
> result, by not applying the "all host bits are zero" rule - you have
> introduced confusion for humans.

Ok.

But humans introduce further confusion when mandating these host bits to
be 0.

These bits are not necessarily 0 - they can be whatever.

That is a need to say 'whatever' - not necessarily '0'.

> As pointed out, 172.17.0.0/12 might make as much sense as
> 172.16.0.0/12 IFF you ignore this feature. Applying the mask to
> 172.17.0.0/12 gives you non-zero host bits -

A-ha!  I did not know that.

> hence why we don't use that. It's all to do with consistency and
> avoidance of confusion. And we need as much of that as we can - I
> know plenty of supposedly network capable people who cannot
> understand the concept of 172.16.1.0/23 being a valid IP address !

But there should be a way to say that 172.16.0.0/12 is just one valid 
example, not the only one.

That 172.17.0.0/12 is also a private address.

Just like when one types 'ls abc*' vs typing 'ls abcd'.

That is the need.

> what use case does it solve ?

Well, the discussion is issued from the following observations:
- rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
   calls it fe80::/64 - which is right?
- BSD code recognizes an LL address by its 10 first bits only (not by
   64): it drops an ND message if not convinced.  That is reason enough
   to visit the problem closely.
- much f2f conversation calls ULA an "fd00" and an LL an "fe80".  This
   goes very far when assigning addresses on interfaces.  Few if any
   assign an "fe81" or an "fc00", although both are correct LL and ULA
   respectively.

And I think it is so because of the textual representation of IPv6
addresses.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Tue, 28 Mar 2017 14:19:59 +0100

> I did not know it was customary?  Maybe it should be documented.

It probably is somewhere - but I'm not a walking encyclopaedia of RFCs 1

> These bits are not necessarily 0 - they can be whatever.

It depends on the context. If you are talking about a HOST address, then clearly the host identifier part of the address will be non-zero. If you are talking about a subnet (or prefix on IPv6 terminology) then it's non-sensical to have the host identifier non-zero.

Taking a simple example. If you talk about 192.168.0.123/24 then I'd take that as meaning the host with host identifier "123" in the subnet 192.168.0.0/24. If you used it in the context of anything other than talking about a host address then I;d take you task for not using the *network* address of 192.168.0.0/24.

> But there should be a way to say that 172.16.0.0/12 is just one valid example, not the only one.
> 

172.17.0.0/12 is a HOST address, it is not a NETWORK address. As explained above, if you apply the right operations, it comes down to being HOST 1.0.0 in NETWORK 172.16.0.0/12. There is absolutely no confusion here, that's really basic IPv4 operations. Sadly a lot of people can't cope with these basics !

> Just like when one types 'ls abc*' vs typing 'ls abcd'.

Those two commands are not the same. The first is about all files starting abc (analogous to all IPs or hosts in a subnet), the second is about the one file abcd (analogous to a single IP/host in a network).

>  calls it fe80::/64 - which is right?

Right, so this is really nothing about using masks, prefix notation, etc - it's purely that somewhere along the line there's been an inconsistency in definition. One definition says one thing, another says something else.
By one definition, fe81::<some 64 bit ID> is a link local address, while by another definition it isn't.
I would suggest that the way to deal with that is to discuss which is correct and have one or both RFCs updated so they say the same thing. Unless there's something in the context that makes them both right.
Given that there are implementations "in the wild" relying on fe80::<something>/64, it might be hard to settle on the wider ranging definition and accept that the rest of fe80::/10 is effectively lost to other uses - having been lost in the gap between the definitions.

---

From: [email-masked]
Date: Tue, 28 Mar 2017 08:53:18 -0500

Alexandre,

I think we have spent enough time on this subject now.
If you want to discuss this further I suggest you do that off-line.

Best regards,
Ole

> On 28 Mar 2017, at 07:46, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Mar 2017 10:16:51 -0500

Ole,

With all due respect.

Who do you think I should contact off-line?

I do not agree with rfc2464bis saying:
> 5.  Link-Local Addresses
>
>    The IPv6 link-local address [I-D.ietf-6man-rfc4291bis] for an
>    Ethernet interface is formed by appending the Interface Identifier,
>    as defined above, to the prefix FE80::/64.

I have not seen a resolution to it.

You may qualify my messages as being too many, but all I am trying to 
say is to clarify it.

Yours,

Alex

---

From: [email-masked]
Date: Tue, 28 Mar 2017 10:30:40 -0500

Alexandre,

> Who do you think I should contact off-line?

From the chairs perspective it seems like you are in the rough seeing a problem here.
Since we are both at the IETF, why don't we and whomever else is interested sit down and talk this over?

> You may qualify my messages as being too many, but all I am trying to say is to clarify it.

Then write a draft to that effect. I am unclear on what you are trying to achieve, and from the thread it doesn't appear many others get that either.

Best regards,
ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 29 Mar 2017 20:39:27 -0500

[...]
>> Well, the discussion is issued from the following observations: -
>> rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
> Right, so this is really nothing about using masks, prefix notation,
> etc - it's purely that somewhere along the line there's been an
> inconsistency in definition. One definition says one thing, another
> says something else. By one definition, fe81::<some 64 bit ID> is a
> link local address, while by another definition it isn't.

I tend to agree, but I think others think otherwise.

I think some people think that fe80::/64 is right whereas others think 
that fe80::/10 is right.

> I would suggest that the way to deal with that is to discuss which is
> correct and have one or both RFCs updated so they say the same thing.

I agree.

> Unless there's something in the context that makes them both right.

What is that?

> Given that there are implementations "in the wild" relying on
> fe80::<something>/64, it might be hard to settle on the wider
> ranging definition and accept that the rest of fe80::/10 is
> effectively lost to other uses - having been lost in the gap between
> the definitions.

The BSD code that was shown earlier checks the src of a received ND 
packet against fe80::/10 (not against fe80::/64).

And other code in same OS BSD adds fe80::/64 (not fe80::/10) in the rt 
table.

Because of this there can be problems.

Alex