Subject: There are claims of ambiguity over what is a link-local address

From: Mark Andrews <[email-masked]>
Date: Mon, 07 May 2012 09:59:19 +1000

See the nanog thread starting here:
	http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 May 2012 07:56:54 +0100

> 	http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html

I'm sure the intention was to reserve the entire /10 prefix
but it's correct that the RFC is not clear about this.
Seems like an erratum is needed.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 May 2012 09:50:31 +0200

That ambiguity around the prefix length /10 vs /64 of a link-local
address should be clarified.

If clarified, among other advantages, it would  allow to write C code
which, when typing "ifconfig eth0 add fe80::1" it would know to fill in
the prefix length by itself, and not wonder about which length should it be.

Alex

Le 07/05/2012 08:56, Brian E Carpenter a écrit :
> I'm sure the intention was to reserve the entire /10 prefix but it's
> correct that the RFC is not clear about this. Seems like an erratum
> is needed.
>
> Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dave Thaler <[email-masked]>
Date: Mon, 7 May 2012 15:38:55 +0000

>From the thread cited:
> Or did the authors really intend that most of fe80::/10
> remain unused, and *only* a single /64 at the very
> start of fe80::/10 would be valid?

Right.

The intent was a bit clearer in RFC 3513, which RFC 4291
obsoletes.  Section 4 has:

> The initial assignment of IPv6 address space is as follows:
>
> Allocation                            Prefix         Fraction of
>                                       (binary)       Address Space
> -----------------------------------   --------       -------------
...
> Link-Local Unicast Addresses          1111 1110 10   1/1024
> Site-Local Unicast Addresses          1111 1110 11   1/1024

And yet a bit clearer in RFC 2373 (and RFC 1884 the original).
It has the same as above plus:

> The only address prefixes which should be predefined in an
> implementation are the:
>
>   o Unspecified Address
>   o Loopback Address
>   o Multicast Prefix (FF)
>   o Local-Use Prefixes (Link-Local and Site-Local)
>   o Pre-Defined Multicast Addresses
>   o IPv4-Compatible Prefixes

So they define the /10 as the link local *prefix*,
within which any *addresses* have to fall into the /64.
The rest of the /10 is unused but is still defined as link-local
scope.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Monday, May 07, 2012 12:51 AM
> To: [email-masked]
> Subject: Re: There are claims of ambiguity over what is a link-local address
> 
> That ambiguity around the prefix length /10 vs /64 of a link-local address
> should be clarified.
> 
> If clarified, among other advantages, it would  allow to write C code which,
> when typing "ifconfig eth0 add fe80::1" it would know to fill in the prefix
> length by itself, and not wonder about which length should it be.
> 
> Alex
> 
> > correct that the RFC is not clear about this. Seems like an erratum is
> > needed.
> >
> > Brian
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 May 2012 16:54:48 +0000

> So they define the /10 as the link local *prefix*, within which any *addresses* have to fall into the /64.
> The rest of the /10 is unused but is still defined as link-local scope.

The specs may be reasonable, but they did cause confusion for addresses in FE80::/10 but out of FE80::/64. Some implementations appear to treat these addresses as global, others as local, and yet others as "unexpected." There may be a way to use these addresses as an attack vectors against poor implementations. Given that, I would suggest to be very specific:

* FE80::/64 is used for configuring link local addresses;
* FE80::/10 is reserved by the IETF. 
* By default, implementations SHOULD discard packets received from addresses in FE80::/10 outside of FE80::/64

-- Christian Huitema

---

From: David Conrad <[email-masked]>
Date: Mon, 7 May 2012 10:07:49 -0700

Hi,

On May 7, 2012, at 9:54 AM, Christian Huitema wrote:
> Given that, I would suggest to be very specific:

+1

> * By default, implementations SHOULD discard packets received from addresses in FE80::/10 outside of FE80::/64

I personally believe the lesson we've learned from the Class E space is that this sort of reservation/direction is less useful than we might like.  

Regards,
-drc

---

From: Tina TSOU <[email-masked]>
Date: Mon, 7 May 2012 17:16:52 +0000

Sent from my iPhone

> * By default, implementations SHOULD discard packets received from addresses in FE80::/10 outside of FE80::/64
These statements are much clearer.

---

From: Dan Luedtke <[email-masked]>
Date: Mon, 7 May 2012 19:20:57 +0200

Hi,

> I personally believe the lesson we've learned from the Class E space is that this sort of reservation/direction is less useful than we might like.

It might be common sense, but could you give me a hint why a
implementation SHOULD not discard those packets? I really tried to
craft a scenario, but none come to my mind so far.

regards,
  Dan

-- 
Dan Luedtke
http://www.danrl.de

---

From: Dave Thaler <[email-masked]>
Date: Mon, 7 May 2012 17:32:23 +0000

> Sent: Monday, May 07, 2012 10:21 AM
> To: David Conrad
> Cc: Christian Huitema; 6man
> >> * By default, implementations SHOULD discard packets received from
> >> addresses in FE80::/10 outside of FE80::/64
> > I personally believe the lesson we've learned from the Class E space is that
> this sort of reservation/direction is less useful than we might like.
> 
> implementation SHOULD not discard those packets? I really tried to craft a
> scenario, but none come to my mind so far.

MUST NOT would seem to match the intent of the original
RFCs which say:
"   Routers must not forward any packets with link-local source or
   destination addresses to other links."

-Dave

---

From: Dan Luedtke <[email-masked]>
Date: Mon, 7 May 2012 19:40:27 +0200

Hello,

>   destination addresses to other links."
Got it now, thanks :) Yes, weakening the requirements seems to be not
useful in this case.
I prefer MUST NOT, too.

Regards,
  Dan

-- 
Dan Luedtke
http://www.danrl.de

---

From: David Farmer <[email-masked]>
Date: Mon, 07 May 2012 15:48:24 -0500

On 5/7/12 12:40 CDT, Dan Luedtke wrote:
> Hello,
>
> On Mon, May 7, 2012 at 7:32 PM, Dave Thaler<[email-masked]>  wrote:

"MUST NOT be forwarded" is not the same thing as "MUST be dropped".

Everything in the Link-Local scope "MUST NOT be forwarded" to another 
interface.  Everything in FF80::/10 is in the Link-Local Scope. 
FF80::/64 is currently used for Link-Local addressing, the reset of 
FF80::/10 is reserved.  I believe the comment was that saying that the 
reserved space should be dropped is incorrect and will frustrate future 
use of the reserved portion of FF80::/10 if there is any.

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