Subject: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00)

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jun 2017 15:47:44 +0000

Hi, one example where /64 is very useful is for the construction of AERO
addresses as documented in:

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

The draft is very short, but here are the main thrusts:

   "An AERO address is an IPv6 link-local address with an interface
   identifier based on a prefix that has been delegated to a node for
   its own exclusive use.  AERO addresses begin with the prefix
   fe80::/64 and include in the interface identifier (i.e., the lower
   bits) a 64-bit prefix taken from one of the node's delegated
   prefixes.  For example, if the node receives the IPv6 prefix:

      2001:db8:1000:2000::/64

   it constructs its corresponding AERO addresses as:

      fe80::2001:db8:1000:2000"

   "The AERO address is intended for use by mobile networks that comprise
   a mobile router and a tethered network of "Internet of Things"
   devices that travel together with the router as a single unit.  The
   mobile router assigns the AERO address to its upstream interface over
   which it receives a prefix delegation from a delegating router.  The
   manner for receiving the delegated prefix could be through static
   configuration or some automated prefix delegation service."

I further believe this link-local address format may prove to be useful for
any scenarios where a prefix delegation is received.

Thanks in advance for comments.

Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Monday, June 05, 2017 8:34 AM
> To: Brian E Carpenter <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: Re: draft-bourbaki-6man-classless-ipv6-00
> 
> Hi,
> 
> > On 3 Jun 2017, at 22:12, Brian E Carpenter <[email-masked]> wrote:
> >
> > On 04/06/2017 05:32, Roger Jørgensen wrote:
> >> On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders <[email-masked]> wrote:
> >> <snip>
> >>> Abstract:
> >>>   Over the history of IPv6, various classful address models have been
> >>>   proposed, none of which has withstood the test of time.  The last
> >>>   remnant of IPv6 classful addressing is a rigid network interface
> >>>   identifier boundary at /64.  This document removes the fixed position
> >>>   of that boundary for interface addressing.
> >>
> >> what I find odd is that we over and over again are morphing IPv6 into IPv4
> >> with just more IP adresses...
> >
> > That simply isn't true. The draft doesn't abolish the concept of 'interface
> > identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. It
> > doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack the choice
> > of /64 for all IPv6-over-foos to date.
> >
> > It does say two things.
> >
> > 1. BCP198
> > 2. n in the addressing architecture is a parameter.
> 
> And it that sense, it’s fine, i.e. /64 is RECOMMENDED, and used for the various IPv6-over-foos that Brian mentioned, but also it sends
> a message to not hardcode /64.
> 
> The draft could cite RFC7421 and (for the point about address availability) RFC7934.
> 
> Like David, at the university where we deployed IPv6, we didn’t try to lock down addresses to hosts; rather we used SNMP-based
> polling of network devices for accountability. We also had 802.1X (through eduroam) on WiFi, and I know of some universities
> deploying 802.1X for wired networks as well. There’s also the Cisco ND syslogging capability if you use their platform.
> 
> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Jun 2017 10:04:08 -0700

> any scenarios where a prefix delegation is received.

Couldn't you do this same trick with any delegated prefix up to 118 bits length?

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jun 2017 18:13:37 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, June 05, 2017 10:04 AM
> To: Templin, Fred L <[email-masked]>
> Cc: Tim Chown <[email-masked]>; Brian E Carpenter <[email-masked]>; 6man <[email-masked]>
> Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00)
> 

Very good question, since link-local prefix is technically fe80::/10. But,
what would implementations do with a link-local that doesn't begin with
fe80::/64?

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Jun 2017 17:03:28 -0700

> what would implementations do with a link-local that doesn't begin with
RFC3513 defines link address with zero in the 54 bits following the 10
bit prefix. I doubt any implementation would care if those bits
weren't zeroes, hopefully it's just treated as a /10 IP address that
can be configured and used.

Tom

---

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

Le 05/06/2017 à 17:47, Templin, Fred L a écrit :
>    fe80::/64

I am not sure whether fe80::/64 or the fe80::/10 is the right prefix for 
link-local addresses.  So I am not sure whether the below method is ok.

> and include in the interface identifier (i.e., the lower

Why is it more useful to form address fe80::2001:db8:1000:2000 instead
of fe80::random? Is it such that the route in the Access Router easily
knows the address of the mobile router? (there could be some
alternatives to learn that address).

Is the method dependent on that 64 be 64?  Or could it work with 65?

Alex

---

From: Morizot Timothy S <[email-masked]>
Date: Tue, 6 Jun 2017 10:19:01 +0000

>link-local addresses.  So I am not sure whether the below method is ok.

The RFC seems pretty clear to me. fe80::/10 is reserved. At present only fe80::/64 is defined for link local. Which makes sense since a device connecting needs to know what the link local /64 is before it has any other information.

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

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         |
   +----------+-------------------------+----------------------------+

Since I had someone configure "custom" link local addresses on a network using other subnets in fe80::/10 once upon a time, I also know that some devices will not work at all without manually and statically configuring them in the neighbor table, which is what we did until I figured out what was misconfigured and had them fix it. So in most instances, it would be unwise to configure anything else on routers.

Scott

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 14:05:49 +0200

Le 06/06/2017 à 12:19, Morizot Timothy S a écrit :
> The RFC seems pretty clear to me. fe80::/10 is reserved. At present only fe80::/64 is defined for link local.

fe80::/10 is 'reserved' at IANA page
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

Where is fe80::/64 'defined'?

Alex

> Which makes sense since a device connecting needs to know what the link local /64 is before it has any other information.
>

---

From: Morizot Timothy S <[email-masked]>
Date: Tue, 6 Jun 2017 12:17:28 +0000

>Where is fe80::/64 'defined'?

Um, I included the link from the RFC that specifies unicast link local and even copied and pasted the actual specification into my response.

So I'm a bit confused by your question. 

Was something in the binary representation of the specification (instead of hex) confusing? Anyway, there are certainly plenty of non-routers who implement link local as specified in the standard RFC.

Scott

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 14:40:49 +0200

>    |  bits    |         54 bits         |          64 bits           |

Does this figure 'define' fe80::/64?

All it says is that there is an fe80::/10 followed by 54 0 bits, and 
then a 64bit IID.

At the risk of being called pedantic - are you sure it is not one's 
reading that interprets that text to mean that
RFC4291 'defines' fe80::/64?

And why are the 54 bits reset?  Are they a waste?

Alex

---

From: Morizot Timothy S <[email-masked]>
Date: Tue, 6 Jun 2017 13:00:06 +0000

Not sure what to say. fe8 (in hex) followed by 52 binary zeros *is* fe80::/64. There's nothing ambiguous about it. Translated to hex, that would be: fe80 0000 0000 0000. It's not any random network prefix. It's specifically and explicitly all zeros. In a proposed standard RFC, not an informational one. Something that specific in a standards document *is* a specification.

And as I noted, there are certainly non-router devices that implement link local as specified and will not work if the router specifies anything other than fe80::/64 for link local. Presumably the whole /10 is reserved to allow for future expansion of the standard. Or perhaps to avoid confusion. Frankly, I have no idea why the whole thing is reserved. But in the current standard, unicast link local is fe80::/64.

Scott

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2017 7:41 AM
To: Morizot Timothy S; [email-masked]
Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 15:40:47 +0200

Le 06/06/2017 à 15:00, Morizot Timothy S a écrit :
> Not sure what to say. fe8 (in hex) followed by 52 binary zeros *is*
> fe80::/64.

Sounds logic but.

Nothing in the figure says that the 52 zeros are part of the LL prefix 
fe80::/10, or part of some other subnet prefix within.

Were some RFC to say literally: "fe80::/64 is the link-local prefix", 
then I would agree with you.  But it would contradict itself saying 
earlier section 2.4 "Link-Local unicast FE80::/10".

> There's nothing ambiguous about it. Translated to hex, that would
> be: fe80 0000 0000 0000. It's not any random network prefix. It's
> specifically and explicitly all zeros.

fe80 0000 0000 0000 is not fe80::/10.

> In a proposed standard RFC, not an informational one. Something that
>  specific in a standards document *is* a specification.

Yes, it is an RFC on a Stds Track, and not INFORMATIONAL.  It has more
agreement behind it, and other things.

This document defines IPv6 Architecture for the entire Internet, not
just some link types.

It _could_ be more appropriate to define fe80::/64 in an IPv6-over-foo
RFC, and in a more non-ambiguous manner, with solid reasons on that
particular link.

> And as I noted, there are certainly non-router devices that implement
> link local as specified

YEs.

> and will not work if the router specifies anything other than
> fe80::/64 for link local.

What in particular may not work?

I think I can safely 'ifconfig add eth0 fe80::1/11'.

> Presumably the whole /10 is reserved to allow for future expansion
> of the standard.

Which expansion can one imagine here?

If fe80::/10 is reserved by IANA as 'link-local' and fe80::/64 is
thought by many to be 'link-local' too - where is the place for
expansion?  fe80::/65 maybe?

> Or perhaps to avoid confusion.

The confusion is there: fe80::/10 is reserved yet fe80::/64 is thought
by many to be defined.

> Frankly, I have no idea why the whole thing is reserved. But in the
> current standard, unicast link local is fe80::/64.

I can understand your opinion.

Alex

>
> Scott
>
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: Tuesday, June 06, 2017
> 7:41 AM To: Morizot Timothy S; [email-masked] Subject: Re: /64 and
> AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00)
>
>
>
>>> I am not sure whether fe80::/64 or the fe80::/10 is the right
>>> prefix for link-local addresses.  So I am not sure whether the
>>> below method is ok.
>>
>> The RFC seems pretty clear to me. fe80::/10 is reserved. At present
>> only fe80::/64 is defined for link local. Which makes sense since a
>> device connecting needs to know what the link local /64 is before
>> it has any other information.
>>
>> |   10     | |  bits    |         54 bits         |          64
>> bits           |
> reading that interprets that text to mean that RFC4291 'defines'
> fe80::/64?
>
>> Since I had someone configure "custom" link local addresses on a
>> network using other subnets in fe80::/10 once upon a time, I also
>> know that some devices will not work at all without manually and
>> statically configuring them in the neighbor table, which is what we
>> did until I figured out what was misconfigured and had them fix it.
>> So in most instances, it would be unwise to configure anything else
>> on routers.
>>
>> Scott
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Jun 2017 14:52:51 +0000

Hi Tom,

> Sent: Monday, June 05, 2017 5:03 PM
> bit prefix.

That seems to be still the case for RFC4291 and RFC4291(bis).

> I doubt any implementation would care if those bits

A strict implementation of RFC4291/RFC4291(bis) would care.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Jun 2017 15:01:25 +0000

> > current standard, unicast link local is fe80::/64.

Is RFC4291(bis) still open for edits?

Thanks - Fred