Subject: who should update: the implementation or the RFC

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 21:11:09 +0200

In private this discussion happened:

who should update: the implementation or the RFC?

In particular, BSD may be updated to accept fe80:1::1 or linux may be 
updated to refuse it; or RFC may be updated to accept fe80:1::1.

My point of view is that RFC should be updated to reflect what linux 
does;  BSD can continue the way it does, whether it wants to update, or not.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Apr 2019 10:04:02 +0930

> who should update: the implementation or the RFC?

Implementation.

Protocol specifications are the ultimate source of truth for
implementations. That doesn't mean they're error free, but it does mean
that if two implemenations disagree on protocol behaviour, the protocol
specification should  tell you which one is right.

The easiest bug report you can send to a vendor is a citation to an RFC.

Spec updates, beyond error corrections, need to be explained and justified,
with a justification meaning explaining a number of things such as what
problem problem it solves, why the problem can't be solved within the
existing specifications, what benefits the proposal has etc.

Out of spec behaviour in a popular implementation, by itself and without
justification, is not enough.

This is the fundamental problem I have with your Link Local draft. There is
not enough of a problem statement. It's not clear what the problem is and
how widespread it is to justify updating RFC4291.

If Link-Local addresses are left at 64 bit IIDs, what problem is going to
occur in the future that hasn't happened in the last 20 years of IPv6
implementations autoconfiguring and using 64 bit IID Link- Local addresses?
Right now it seems like you're trying to fix something that isn't broken.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 11:11:36 +0200

Mark,

I would like to ask you whether you support my draft, or not?

I give some explanation below, just in case.

Le 19/04/2019 à 02:34, Mark Smith a écrit :
> 
> 
> On Fri., 19 Apr. 2019, 04:41 Alexandre Petrescu, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Spec updates, beyond error corrections, need to be explained and 
> justified, with a justification meaning explaining a number of things 
> such as what problem problem it solves, why the problem can't be solved 
> within the existing specifications, what benefits the proposal has etc.
> 
> This is the fundamental problem I have with your Link Local draft. There 
> is not enough of a problem statement.

The problem is explained, but it depends to whom.  Many people require 
many different explanations.

In short the problem is: linux allows ifconfig eth0 fe80:1::1, whereas 
BSD doesnt.  To me that is enough a problem.

There are also many incoherencies in the specs, including an Errata that 
requests a draft but there is no draft.

> It's not clear what the problem is 
> and how widespread it is to justify updating RFC4291.
> 
> If Link-Local addresses are left at 64 bit IIDs, what problem is going 
> to occur in the future that hasn't happened in the last 20 years of IPv6 

If the IID len is left at 64  where it is now, it leads to a situation 
that people say that anything else is a violation of standards.

I do not agree that I work with something (fe80:1::1) that is a 
violation of standards.

> Right now it seems like you're trying to fix something that 

So it may seem to you.  But let me ask you: do you know on what kind of 
networks I work?

Alex

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

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Apr 2019 12:12:47 +0200

> In short the problem is: linux allows ifconfig eth0 fe80:1::1,
> whereas BSD doesnt.  To me that is enough a problem.

I find myself going in the oposite direction: I consider fe80::/10 a
historical mistake. For all practical purposes the link local prefix is
fe80::/64. 

Historically, IIDs were tied to MAC addresses. So it made sense to reserve a
short link local prefix to accomodate networks with longer IIDs.

However, based on current address allocation plans for global addresses,
there cannot be IIDs longer than 64 bits. In addition to that, we replaced
MAC addresses as the basis of IIDs with pseudo-random numbers.

I won't go into the discussion of IIDs shorter than 64 bits.

So we can say, that based on operational experience, there is no need for
longer IIDs. Therefor to keep the IPv6 address architecture simple and
easy to understand, it is best to set the length of IIDs for link local and
SLAAC to 64 bit (until such time as there is consensus on shorter IIDs
for SLAAC).

(there could be existing IPv6-over-foo specifications where the length of the
IID for link local is not 64. In that case, those specifications should be
marked as an exception).

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Apr 2019 22:40:44 +0930

> So it may seem to you.  But let me ask you: do you know on what kind of

Well, that's the problem. I don't, so I don't understand your problem.

Explain it to me, and I might then understand you problem and agree with
your solution (or not, but that means I think I have a better solution, and
you should challenge me to provide it to you so you can make your judgement
on it ;-) )

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Apr 2019 22:54:33 +0930

> historical mistake. For all practical purposes the link local prefix is

I see it as an aggregate vs. implementation issue.

IANA allocateted FE80::/10 for Link-Local addresses.

RFC 4291 says that implemenations use FE80::/64 to form their interface
Link-Local addresses.

There's an undefined gap there, however if the question is specific to an
interface, then RFC 4291 takes precedence.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 15:33:07 +0200

Le 19/04/2019 à 15:10, Mark Smith a écrit :
> 
> 
> On Fri., 19 Apr. 2019, 18:41 Alexandre Petrescu, 
>      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
> your solution (or not, but that means I think I have a better solution, 
> and you should challenge me to provide it to you so you can make your 
> judgement on it ;-) )

I work on vehicular networks.  I have several partners, although only 
few (if any) see or care about IETF.

In one such vehicular network there are 3 cars in a convoy.  Each car 
has several computers and routers.  Each car has an IPv6 OCB (OCB - 
Outside the Context of a BSSID, an 802.11 mode at 5.9GHz, specific for 
vehicles) interface on front bumper and another interface on the rear 
bumper.  There is a distinct IPv6 subnet between a pair of cars (at a 
distinct 5.9GHz channel), and several IPv6 subnets in each car, with 
hubs, etc.

When setting this up automatically, and troubleshooting IPv6 routing, I 
need:
- simple way to ping.  It must be simple, because in-car programmer
   position is uncomfortable (not like at a desk); copy paste is
   difficult of long IPv6 addresses.  Shorter commands to type are
   easier.
- no globally routable prefixes on interfaces between cars, because it's
   hard to determine which car should allocate a prefix to which other
   car.
- distinct link-local addresses for all between-cars interfaces, because
   when ping replies I need to understand quickly from which car it
   comes.
- a same Interface ID on all front bumbers (e.g. '1') and same Interface
   ID on all rear bumpers (e.g. '2'); so that it easy to remember and
   picture in mind.

That leads me to manually assign (script) fe80:1::1/32 and fe80:1::2/32 
on the subnet between first and second cars, fe80:2::1/32 and 
fe80:2::2/32 between 2nd and 3rd car, and why not more cars later.

It is an address architecture.

It works on linux.  It pings ok.  It helps troubleshooting.

The fe80::IID/64 addresses are also present on all interfaces, and they 
are used by the ND protocol.

fe80::IID/64 and fe80:1::1/32 work ok on interfaces.

I dont know how else than using 32 plen on fe80:: addresses could this 
be done.

Alex

>      >     does;  BSD can continue the way it does, whether it wants to
>     update,
>      >     or not.
>      >
>      >     Alex
>      >
>      >   
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>      >

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 15:34:57 +0200

Le 19/04/2019 à 15:24, Mark Smith a écrit :
> 
> 
> On Fri., 19 Apr. 2019, 19:43 Philip Homburg, 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> There's an undefined gap there, however if the question is specific to 
> an interface, then RFC 4291 takes precedence.

But now we write IP-over-OCB interface, so the question is specific to 
that interface.

I dont understand why RFC4291 should take preference, when the specific 
IP-over-OCB document presumably knows better what is that interface.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Apr 2019 15:52:12 +0200

Hi Mark,

> RFC 4291 says that implemenations use FE80::/64 to form their interface Link-Local addresses.
> 
> There's an undefined gap there, however if the question is specific to an interface, then RFC 4291 takes precedence.

For people in the RIR world it's a common thing: you get a prefix from the RIR and then make assignments from it for specific purposes. You can route the aggregate allocation, but you're not allowed to use the unassigned parts (until you make an assignment). In this case fe80::/10 is the allocation and fe80::/64 is the assignment.

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 15:54:15 +0200

> For people in the RIR world it's a common thing: you get a prefix from the RIR and then make assignments from it for specific purposes. You can route the aggregate allocation, but you're not allowe…

I request the assignment of fe80:1::/32, fe80:2::/32 and fe80:3::/32 for me.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Apr 2019 16:00:19 +0200

> It works on linux.  It pings ok.  It helps troubleshooting.

It seems that you are abusing fe80::/10 just because you need something easy to
type.

You could just as well use fe80::1:1/64

Or a ULA fd00:1::1/32 

or many other possibilities.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Apr 2019 16:00:46 +0200

Hi

> I request the assignment of fe80:1::/32, fe80:2::/32 and fe80:3::/32 for me.

Well, in that case you'll have to contact the allocation holder :)

fe80::/10 is marked as "Reserved by protocol", which is described as:

Reserved-by-Protocol - A boolean value indicating whether the
      special-purpose address block is reserved by IP, itself.  This
      value is "TRUE" if the RFC that created the special-purpose
      address block requires all compliant IP implementations to behave
      in a special way when processing packets either to or from
      addresses contained by the address block.

The RFC is RFC4291, which defines how to use it.

If you want anything from fe80::/10 you'll have to update RFC4291.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 15:01:53 +0100

> I request the assignment of fe80:1::/32, fe80:2::/32 and fe80:3::/32 for 

Then write an internet draft to request them.

If it reaches consensus, the IANA will delegate those assignments.  If 
it does not, then request another address block assignment either via a 
RIR or via IETF / IANA.

If you squat on fe80:X::/32 in the interim, and one day in the future it 
turns out that cars can no longer interoperate correctly because of this 
decision, then bear it in mind that there will be a permanent record of 
the fact that you were advised that this address space is reserved by IANA.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:02:20 +0200

> If you want anything from fe80::/10 you'll have to update RFC4291.

YEs, I want that.

Do you agree that I update RFC4291?

Alex

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Apr 2019 10:09:04 -0400

To be clear, what you can do is write an internet draft that you propose 
as an update to RC 4291.  It is up toe the 6man working group whether 
they accept that draft, progress that draft, and eventually request 
publication of the draft as an RFC.
You can not, as your woridng suggests, unilaterally update RFC 4291.

Yours,
Joel

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:12:13 +0200

> Then write an internet draft to request them.

?  No, not one other I-D that nobody agrees with.

> it does not, then request another address block assignment either via a 

I would like to request 3 fe80/32s via IETF / IANA without writing 
another I-D.

What is the process?

Alex

---------------------------------------------------------------------
> the fact that you were advised that this address space is reserved by IANA.

Yes, I bear in mind.

This little fe80 risk is much less than other risks of same 192.168 in 
all cars.

This little fe80 risk is much less compared to lack of security of 
cleartext messages advertised by numerous Road-Side Units, leading to 
many risks to safety.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:14:39 +0200

Joel,

Thank you for the suggestion.

Please do not suggest me to write another Internet Draft that nobody 
agrees with.

My question to you is the following: do you agree to update RFC4291?

Please reply if you agree, otherwise dont bother, thank you.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 15:15:36 +0100

> I would like to request 3 fe80/32s via IETF / IANA without writing 

You write another I-D.

It will need to be standards track, to update RFC4291.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:19:44 +0200

> It will need to be standards track, to update RFC4291.

If I write it, do you support it?

Alex

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Apr 2019 07:21:01 -0700

> On Apr 19, 2019, at 6:33 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> In one such vehicular network there are 3 cars in a convoy.  Each car has several computers and routers.  Each car has an IPv6 OCB (OCB - Outside the Context of a BSSID, an 802.11 mode at 5.9GHz, specific for vehicles) interface on front bumper and another interface on the rear bumper.  There is a distinct IPv6 subnet between a pair of cars (at a distinct 5.9GHz channel), and several IPv6 subnets in each car, with hubs, etc.
> 
> When setting this up automatically, and troubleshooting IPv6 routing, I need:
> That leads me to manually assign (script) fe80:1::1/32 and fe80:1::2/32 on the subnet between first and second cars, fe80:2::1/32 and fe80:2::2/32 between 2nd and 3rd car, and why not more cars later.
> 

It feels like you are using the link local addresses sideways, because you want to embed logical structure in what is essentially designed at a flat space. 

It also feels like you are feeding temporary choices such as two radios per car into what should be a long term design. If today's car designers feel a need for two radios, I am pretty sure that tomorrow's cars will have dozens of them.

I really believe that you should reconsider that design. I am sure that if you open up to that, we can find several experts ready to help you.

> It works on linux.  It pings ok.  It helps troubleshooting.

That feels like a bug in Linux...

-- Christian Huitema

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 15:25:43 +0100

> If I write it, do you support it?

I don't see any reason to.  There's nothing magical about the address 
range that you're requesting.  You could just as easily request another 
address range without updating RFC4291.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 15:29:23 +0100

> historical mistake. For all practical purposes the link local prefix is

It's been defined this way since 1998.

The interface ID specified in RFC1884 for link-local addresses was 118 
bits (section  2.4.8), but by the time rfc2373 came around in 1998, the 
IID was changed to 64 bits (section 2.5.8).

> 2.5.8 Local-Use IPv6 Unicast Addresses
> 
>    There are two types of local-use unicast addresses defined.  These
>    are Link-Local and Site-Local.  The Link-Local is for use on a single
>    link and the Site-Local is for use in a single site.  Link-Local
>    addresses have the following format:
> 
>    |   10     |
>    |  bits    |        54 bits          |          64 bits           |
>    +----------+-------------------------+----------------------------+
>    |1111111010|           0             |       interface ID         |
>    +----------+-------------------------+----------------------------+

Itojun committed this code in 1999:

> https://github.com/kame/kame/blob/51ca2998733f77d51c565d599e787522256722ac/kame/sys/netinet6/in6.h#L262-L263

... which effectively gave fe80:: a /16 netmask in the initial Kame 
stack.  So it looks like at the time that this was committed to the Kame 
project, /64 was the correct netmask, and that the Kame implementation 
was incorrect.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:38:47 +0200

Le 19/04/2019 à 16:25, Nick Hilliard a écrit :
> I don't see any reason to.

I find it not polite from your part to make me write another Internet 
Draft, just to have something to not agree with.

I suggest you take another topic to not agree with.

> There's nothing magical about the address 

fe80:1::/32 breaks the 54 0 bits depicted by lls in Figure of RFC4291.

I am not insisting on updating RFC4291 either, but several people said 
that I cant use fe80:1::/32 without modifying RFC4291.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Apr 2019 16:41:12 +0200

Hi Alex,

> If I write it, do you support it?

That depends on the content. I don't care who writes a draft, I care about what's in it...

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:02:21 +0200

Sander,

> That depends on the content. I don't care who writes a draft, I care about what's in it...

I posted a new draft-petrescu-6man-ll-32-ietf-iana-request-00
It's titled "A request to IETF / IANA to Allocate a 32bit Link-Local Prefix"

Do you support it?

I am asking you that, because without explicit support, the AD is under 
the impression there is no support for this.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Apr 2019 17:19:56 +0200

Hi Alex,

> It's titled "A request to IETF / IANA to Allocate a 32bit Link-Local Prefix"

No, there is no content in that draft that explains what the purpose is. Without any proper reasoning behind why fe80:1::/32 should be used and what it should be used for I object to this draft.

> I am asking you that, because without explicit support, the AD is under the impression there is no support for this.

You'll have to do better than this.
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:35:31 +0200

Christian,

Le 19/04/2019 à 16:21, Christian Huitema a écrit :
>> In one such vehicular network there are 3 cars in a convoy.  Each
>> car has several computers and routers.  Each car has an IPv6 OCB
>> (OCB - Outside the Context of a BSSID, an 802.11 mode at 5.9GHz,
>> specific for vehicles) interface on front bumper and another
>> interface on the rear bumper.  There is a distinct IPv6 subnet
>> between a pair of cars (at a distinct 5.9GHz channel), and several
>> IPv6 subnets in each car, with hubs, etc.
>> 
>> When setting this up automatically, and troubleshooting IPv6
>> routing, I need: - simple way to ping.  It must be simple, because
>> in-car programmer position is uncomfortable (not like at a desk);
>> copy paste is difficult of long IPv6 addresses.  Shorter commands
>> to type are easier. - no globally routable prefixes on interfaces
>> between cars, because it's hard to determine which car should
>> allocate a prefix to which other car. - distinct link-local
>> addresses for all between-cars interfaces, because when ping
>> replies I need to understand quickly from which car it comes. - a
>> same Interface ID on all front bumbers (e.g. '1') and same
>> Interface ID on all rear bumpers (e.g. '2'); so that it easy to
>> remember and picture in mind.
>> 
>> That leads me to manually assign (script) fe80:1::1/32 and
>> fe80:1::2/32 on the subnet between first and second cars,
>> fe80:2::1/32 and fe80:2::2/32 between 2nd and 3rd car, and why not
>> more cars later.
>> 
> It feels like you are using the link local addresses sideways,

Sideways?  They are on the front and rear of the car, not on the sides. 
(not yet).

> because you want to embed logical structure in what is essentially
> designed at a flat space.

I cant put globally unique prefixes on these subnets, yet each subnet 
should be identified uniquely by a number.  The fe80 addresses are not 
unique, unless I make them so with fe80:1::, fe80:2::, etc.

I dont understand what you mean by flat space, and logical structure.

I dont undersand what you think is wrong with the design.

> It also feels like you are feeding temporary choices such as two
> radios per car into what should be a long term design. If today's car
> designers feel a need for two radios, I am pretty sure that
> tomorrow's cars will have dozens of them.

I agree, your intuition seems right to me.

I am asked by car robotizer to actually do more of these radios, for 
application specific purposes.  Basically they want the car to be the 
maximum aware of what's around, at places where others cant see.  Also 
they may want more bandwidth (but didnt ask until now).

I think my method of using fe80:1::/32 will scale to many radios per car 
because there is much subnet id space in that 32; e.g. wihtin that 32 
there is fe80:1:1::/48, fe80:1:2::/48, etc.

You seem to be saying that fe80:1::/32 is not enough when there are more 
radios per car?

> I really believe that you should reconsider that design. I am sure
> that if you open up to that, we can find several experts ready to
> help you.

Well, I can reconsider it in the future.

But I need that that fe80:1::/32 now to not be called a violation of 
something, now.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:39:49 +0200

Le 19/04/2019 à 17:19, Sander Steffann a écrit :
> Hi Alex,
> 
>> I posted a new draft-petrescu-6man-ll-32-ietf-iana-request-00 It's
>> titled "A request to IETF / IANA to Allocate a 32bit Link-Local
>> Prefix"
>> 
>> Do you support it?
> 
> No, there is no content in that draft that explains what the purpose
> is. Without any proper reasoning behind why fe80:1::/32 should be
> used and what it should be used for I object to this draft.

I propose the addition of the following explanation.

Do you still object?

NEW:> In one such vehicular network there are 3 cars in a convoy.  Each car
> Outside the Context of a BSSID, an 802.11 mode at 5.9GHz, specific
> for vehicles) interface on front bumper and another interface on the
> rear bumper.  There is a distinct IPv6 subnet between a pair of cars
> (at a distinct 5.9GHz channel), and several IPv6 subnets in each car,
> with hubs, etc.
> 

Alex

> 
>> I am asking you that, because without explicit support, the AD is
>> under the impression there is no support for this.
> 
> You'll have to do better than this. Sander
>

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Apr 2019 18:38:45 +0200

iH Alex,

> I propose the addition of the following explanation.

Yes, that's handwaving, not a specification for an RFC.
Sander

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Apr 2019 10:38:25 -0700

At Fri, 19 Apr 2019 16:38:47 +0200,

> fe80:1::/32 breaks the 54 0 bits depicted by lls in Figure of RFC4291.

I suspect you two talk about different things.  I believe Nick meant a
different address space than fe80::/10, similar to 2001:db8::/32
reserved for documentation purposes.  If that serves your purpose,
you'll only need to publish something similar to RFC3849.  It didn't
have to update the addressing architecture RFC, neither would such
"IPv6 Address Prefix Reserved for IPv6-over-COB" document.  Publishing
it would not be trivial either, but I can see it much more promising
than trying to get new assignments within the special space of fe80::/10.

btw, I don't see it impolite at all:

At Fri, 19 Apr 2019 15:25:43 +0100,
Nick Hilliard <[email-masked]> wrote:

> I don't see any reason to.  [...]

You asked what is the process; he gave an answer to it, that's it.  He
didn't even try to make you write it.  With all due respect, if you
didn't alienate people who don't support your argument using such a
strong word like politeness, you'd actually be more successful in
getting support.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 23:58:53 +0200

> Yes, that's handwaving, not a specification for an RFC.

Thank you for the clarification.  I had no time to write more than what 
appears to you to be handwaving.

But it's solved now.

I no longer request support.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 00:11:04 +0200

Le 19/04/2019 à 19:38, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Note: I retired from the IPv6-over-OCB draft.  The IPWAVE WG has 
consensus on 64.  I am not part of that.

For the suggestion of different address space than fe80::/10 - I need a 
space with link-local semantics, not ULA nor Global.

Once it is ULA or Global it means that routers may forward them.  I dont 
want them forwarded.

> btw, I don't see it impolite at all:

MAybe impolite was not the right word.  I excuse.

Alex

> Nick Hilliard <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Apr 2019 11:07:06 +1200

On 20-Apr-19 01:24, Mark Smith wrote:
> 
> 
> On Fri., 19 Apr. 2019, 19:43 Philip Homburg, <[email-masked] <mailto:[email-masked]>> wrote:
> 

Agreed. But note that there's something a bit special about link local
in contrast to SLAAC-assigned global unicast addresses. In theory,
an IPv6-over-foo could be specified with a variable IID length
for global unique addresses. But that is impossible for link local
addresses, since they can be configured in the absence of any RAs.
("In the absence of routers, a host can only generate link-local
addresses." [Section 1 of RFC4862])
So IPv6-over-foo must specify an IID length for link local addresses.
("Link-local addresses have a well-known prefix that identifies the (single)
shared link to which a set of nodes attach.  A host forms a link-
local address by appending an interface identifier to the link-
local prefix." [Section 3 of RFC4862])
Today that prefix length is 64, because RFC4291 says so.

Therefore, even if an IPv6-over-foo states that the prefix length
for global unicast address construction is dynamic and is supplied
by the RAs (which is clearly allowed by RFC4862), the prefix length
for link-local is static, and is constrained to /64 by RFC4291.

As we know, there's no consensus in this WG to change that. But we
should be clear, I think, that the /64 applied to link-local and
the /64 applied to SLAAC global unicast are independent choices.
There's no reason in physics or computer science why they need to
be the same. Simply, we've collectively chosen them to be the same
for the last 20 years.

   Brian

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 15:30:14 +0200

Brian,

Le 20/04/2019 à 01:07, Brian E Carpenter a écrit :
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>> I find myself going in the oposite direction: I consider fe80::/10
>> a historical mistake. For all practical purposes the link local
>> prefix is fe80::/64.
>> 
>> 
>> There's an undefined gap there, however if the question is specific
>> to an interface, then RFC 4291 takes precedence.
> 
> Agreed. But note that there's something a bit special about link
> local in contrast to SLAAC-assigned global unicast addresses. In
> theory, an IPv6-over-foo could be specified with a variable IID
> length for global unique addresses. But that is impossible for link
> local addresses, since they can be configured in the absence of any
> RAs. ("In the absence of routers, a host can only generate
> link-local addresses." [Section 1 of RFC4862]) So IPv6-over-foo must
> specify an IID length for link local addresses. ("Link-local
> addresses have a well-known prefix that identifies the (single) 
> local address by appending an interface identifier to the link- local
> prefix." [Section 3 of RFC4862]) Today that prefix length is 64,
> because RFC4291 says so.
> 
> Therefore, even if an IPv6-over-foo states that the prefix length for
> global unicast address construction is dynamic and is supplied by the
> RAs (which is clearly allowed by RFC4862), the prefix length for
> link-local is static, and is constrained to /64 by RFC4291.
> 
> should be clear, I think, that the /64 applied to link-local and the
> /64 applied to SLAAC global unicast are independent choices.

I agree with the text above in its entirety.

This is how I agree with it.

In SLAAC, both GUAs and LLs get self-configured.

I agree that the '/64' applied to global addresses and the '/64' applied 
to link-local addresses are two choices.

These choices are based on two completely distinct sources.

These are the sources:

Whereas the GUA gets its prefix length from the RA (not from an RFC), 
the LL gets it from RFC4291 (not from RA).

I will add something about this in the draft about the prefix length of 
LL addresses.

Alex

  There's
> no reason in physics or computer science why they need to be the
> same. Simply, we've collectively chosen them to be the same for the
> last 20 years.
> 
> Brian
> 
>> Historically, IIDs were tied to MAC addresses. So it made sense to
>> reserve a short link local prefix to accomodate networks with
>> longer IIDs.
>> 
>> However, based on current address allocation plans for global
>> addresses, there cannot be IIDs longer than 64 bits. In addition to
>> that, we replaced MAC addresses as the basis of IIDs with
>> pseudo-random numbers.
>> 
>> So we can say, that based on operational experience, there is no
>> need for longer IIDs. Therefor to keep the IPv6 address
>> architecture simple and easy to understand, it is best to set the
>> length of IIDs for link local and SLAAC to 64 bit (until such time
>> as there is consensus on shorter IIDs for SLAAC).
>> 
>> (there could be existing IPv6-over-foo specifications where the
>> length of the IID for link local is not 64. In that case, those
>> specifications should be marked as an exception).
>> 
>> 
>> [email-masked] <mailto:[email-masked]> Administrative Requests:
>> https://www..ietf.org/mailman/listinfo/ipv6
>> <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:17:41 +0200

Le 19/04/2019 à 15:52, Sander Steffann a écrit :
> For people in the RIR world it's a common thing: you get a prefix
> from the RIR and then make assignments from it for specific purposes.
> You can route the aggregate allocation, but you're not allowed to use
> the unassigned parts (until you make an assignment). In this case
> fe80::/10 is the allocation and fe80::/64 is the assignment.

Noted.  I will add that allocation-assignment distinction in the draft.

AS a side note:

I ponder over why I[A]NA is not doing this Assignment, since it's an 
Assignment authority.

I suppose RIR does not do this assignment of fe80::/64 neither the 
allocation of fe80::/10.

I suppose I can not ask RIR to give me, temporarily, fe80:1::/32.

Alex