Subject: fe80::/16 on specific link layers

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 14:30:01 +0000

Hi, I am seriously considering the use of fe80::/16 on a specific link layer
so that the network part is 16 bits and the "host" part is 112 bits.

Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the
corresponding LL address is fe80:2001:db8:1:2::/16.

The question is what would break if we did this? The link layer would
know how to deal with it, but would the IPv6 layer be able to handle it?
And, what about apps that deal with IPv6 LL's?

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jul 2017 01:08:52 +1000

Hi Fred,

> And, what about apps that deal with IPv6 LL's?

I'll think a bit more about fe80::/16.

To start with, here a draft which includes what I summarised about
LLs. I think that fe80::/16 would conflict with both the current IANA
fe80::/10, RFC4291 LL assignments and the fe80::/64 IPv6-over-foo link
conventions we have. (I'd think it might be useful to keep the /10
through /64 for a random subnet ID like we have for ULAs i.e. globally
unique link-local addresses, to avoid the scope/interface index
requirement when using LL addresses within API sockets)

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 16:09:21 +0000

Hi Mark,

Thanks for the draft pointer. I think there is value in documentation that
discusses LLs.

About fe80::/16, that was my modification of Tom Herbert's proposal and
was motivated by a desire to have embedded prefixes in a readable form.
Tom's proposal was to use fe80::/10 but in that case the embedded prefix
is unreadable to humans and more difficult to parse for implementations.

So, as long as fe80::/16 is correctly recognized by the specific link layer,
I think the question becomes one of whether the IPv6 layer and apps
can handle it. BTW, two apps that come to mind that deal with LLs are
ping6 and dhcpv6 but I am sure there are many others.

Thanks - Fred

> -----Original Message-----
> From: Mark Smith [mailto:[email-masked]]
> Sent: Friday, July 28, 2017 8:09 AM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Re: fe80::/16 on specific link layers
> 
> Hi Fred,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 16:43:54 +0000

Hi again Mark,

> I'll think a bit more about fe80::/16.

Actually, I think we don't have to worry about fe80::/16. I just realized
that we can use fe80::/10 and then when we embed the IPv6 prefix we
can simply prepend 6 '0' bits so that the actual prefix begins at bit 16 so
that it prints and parses nicely. So, we would have:

fe80::2001:db8:1:1::/10

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jul 2017 03:00:16 +1000

> that it prints and parses nicely. So, we would have:

The trouble is that per RFC4291, the bits between FE80::/10 and
FE80::/64 are to currently be all zeros.

https://tools.ietf.org/html/rfc4291#section-2.5.6

Admittedly I'm not sure where're you're putting 2001:db8:1:1, because
there are multiple "::'s. If it is after /64, then it's fine.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 17:04:43 +0000

Hi Mark,

> Sent: Friday, July 28, 2017 10:00 AM

But, can that be overridden by an IPv6-over-foo document?
 
> there are multiple "::'s. If it is after /64, then it's fine.

My mistake - it should have said fe80:2001:db8:1:1::/10 (i.e., only one "::").

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jul 2017 03:31:04 +1000

> But, can that be overridden by an IPv6-over-foo document?

I don't think it can be, the text says nothing about exceptions being
allowed via IPv6-over-foo documents. I don't think there is any
ambiguity or room for link specific formats in "Link-Local addresses
have the following format".

I'd think a link-type-specific RFC would have trouble reaching
consensus on updating that text. A more general RFC that is not link
type specific would probably have a better chance.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 17:44:38 +0000

Hi Mark,

> Sent: Friday, July 28, 2017 10:31 AM

OK.

> type specific would probably have a better chance.

OK - then maybe we can do that with my draft on "The AERO Address":

https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/

Or, if you wanted join efforts in some way on a more general doc
on LL's maybe we could discuss that.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Jul 2017 11:27:55 -0700

At Fri, 28 Jul 2017 14:30:01 +0000,

> And, what about apps that deal with IPv6 LL's?

It would break BSD-variant implementations, which internally use the
2nd 16-bit field of link-local addresses to identify the corresponding
link, e.g., fe80:1::abcd means fe80::abcd in link "#1".  (It's an
internal form and doesn't appear on wire).

Yes, that's an ugly implementation-specific hack and you could blame
the designer of the idea.  But I'm afraid we can't simply ignore the
deployment base as a matter of practice.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jul 2017 18:48:24 +0000

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Friday, July 28, 2017 11:28 AM

I can see how it might be attractive to make use of unused bits, but...

> the designer of the idea. 

...the implementation will have to be updated as the specs are
updated.

> But I'm afraid we can't simply ignore the

I think you have this backwards - it is the implementation that
is ignoring the specs, and not the other way around.

That there may be implementations that ignore the specs does
not mean that the specs cannot be updated.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Jul 2017 13:22:46 -0700

At Fri, 28 Jul 2017 18:48:24 +0000,

> not mean that the specs cannot be updated.

I don't disagree in principle.  I just provided a data point that you
can't just ignore or dismiss in practice, i.e., just saying
implementations should be updated doesn't automagically make it
happen.  If we make the decision with full understanding of the
expected interoperability problem with the existing large deployment
base and the corresponding delay of the deployment of the updated
protocol spec due to the necessary upgrade (if it ever happens
satisfactorily), that's the wg's call.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Mon, 31 Jul 2017 12:37:35 +1000

> deployment base as a matter of practice.

I'm curious what the consequences would be of making BSD-variants
compliant? Are any user space applications relying on it? Does BSD
support the Sockets API and therefore applications should be using the
scope_id field for zone (ifindex) information rather than using this
link ID in the reserved LL address field?

I appreciate it would be a change in behaviour, however I wonder
whether it would really just be a cosmetic one, only visible in the
output of utilities such as 'ifconfig'?

Regards,
Mark.

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

---

From: "Andrey V. Elsukov" <[email-masked]>
Date: Mon, 31 Jul 2017 12:53:07 +0300

> output of utilities such as 'ifconfig'?

It is not visible for application, but when you will use the second u16
word of the address like in the 'fe80:2001:db8:1:2::/16', the kernel can
not save it internally, because the scope zone id is stored here. I.e.
2001 will be overwritten by interface index.

However, I did already the most of work to drop this hack from FreeBSD
kernel. But I can't say this for others.

-- 
WBR, Andrey V. Elsukov

---

From: 神明達哉 <[email-masked]>
Date: Mon, 31 Jul 2017 10:09:08 -0700

At Mon, 31 Jul 2017 12:37:35 +1000,

> link ID in the reserved LL address field?

The hack is largely hidden from applications.  Most ordinary
applications using the standard socket API won't see the embedded
link-zone ID in the address.  Also, they are supposed to use the
standard sin6_scope_id field when specifying a link-local address
rather than manually embedding the link-zone ID in the address.
Actually, most of the apps should even be agnostic about the address
scope - they use text-to-address conversion library functions, such as
getaddrinfo(), which understands the extended textual format as
defined in RFC4007 and sets the sin6_scope_id field appropriately;
same for the address-to-text conversion.

So, even if the kernel is updated to get rid of the hack that won't
affect most user-level applications.

Some special purpose applications still deal with the hack themselves,
though.  They include network statistics apps (that read the kernel
memory directly) and routing protocol apps (these tend to use
non-standard APIs to get access to the kernel's routing table, where
the raw in-memory representation is exchanged between the kernel and
apps).

--
JINMEI, Tatuya