Subject: draft-ietf-6man-rfc4291bis

From: <[email-masked]>
Date: Fri, 22 Jan 2016 06:59:09 +0000

draft-ietf-6man-rfc4291bis
2.4.6<https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01#section-2.4.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         |

   +----------+-------------------------+----------------------------+

The definition is wrong.The middle 54 bits can be any value.Please fix it.

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Jan 2016 00:03:24 +1100

On 22 Jan 2016 5:29 PM, <[email-masked]> wrote:
> 2.4.6.  Link-Local IPv6 Unicast Addresses
>
>
>
>
>

How did you come to that conclusion?

Some implementations might be tolerant of non-zero values in those 54 bits,
but that doesn't make the definition wrong.

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

---

From: Sander Steffann <[email-masked]>
Date: Fri, 22 Jan 2016 14:17:52 +0100

Hi,

> Some implementations might be tolerant of non-zero values in those 54 bits, but that doesn't make the definition wrong.

It has always been interesting that a /10 is reserved for link-local while only a /64 is commonly used. The 54 bits in the middle could be anything, but they are always 0. FreeBSD even uses that assumption to store the scope-id in those bits:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index

I *did* go WTF when Gert Döring pointed that out to me...

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jan 2016 08:11:01 +1300

On 23/01/2016 02:17, Sander Steffann wrote:
> It has always been interesting that a /10 is reserved for link-local while only a /64 is commonly used. The 54 bits in the middle could be anything, 

No, the standard has always said that they *are* zero. We attempted to clarify this
in RFC 7421 - please see the bottom of this page:
http://tools.ietf.org/html/rfc7421#page-11

> but they are always 0. FreeBSD even uses that assumption

It's not an assumption; it's the standard.

> to store the scope-id in those bits:
> 

But it has nothing to do with bits on the wire; it's just a bit of magic
inside the stack. As that manual entry says "When you specify scoped addres
to the command line, NEVER write the embedded form..."

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Fri, 22 Jan 2016 20:56:01 +0100

Hi Brian,

> http://tools.ietf.org/html/rfc7421#page-11

True, I still had RFC 1884 in mind. RFC 2373 already updated that. I feel old now :)

> to the command line, NEVER write the embedded form..."

It will be a hell of a mess when some future RFC decides to use other parts of fe80::/10 though :)  It's still reserved space, even if it isn't being used today. Maybe we should be pragmatic and explicitly document fe80::/64 as the only bit of fe80::/10 that can ever be used, to make sure some future RFC doesn't define that space and cause problems for existing implementations. It's not likely we'll ever do that anyway and there is plenty of other address space future RFCs can use.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jan 2016 15:38:10 -0300

> I *did* go WTF when Gert Döring pointed that out to me...

I don't recall what I was doing, but I do recall meaning to use such
link-locals and find it was not possible.

Another "WTF" was that on some platforms 2001:db8::/64 seem to be
blocked by the kernel, and not usable at all.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jan 2016 11:04:16 +1300

> blocked by the kernel, and not usable at all.

That seems quite reasonable, though. (Don't you mean 2001:db8::/32?)

Which platforms, BTW? And was it connect or send that complained?

(I have a reason for asking that takes a while to explain...)

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jan 2016 19:00:41 -0300

> It's not an assumption; it's the standard.

Without looking back at the specs right now I seem to recall finding the
definition of ll addresses as fe80::/10 confusing in that respect.
The current behavior implies fe80::/64 rather than fe80::/10.

(This was a gotcha for me when I found that fe80::/10 doesn't actually
work. For instance, when you play with ll addresses in BSD, you have to
manually force the corresponding words to be zero, since the kernel will
always return the scope and interface index in such words).

FWIW, I'd say that, for the most part, RFC7421 implicitly talks about
longer prefixes rather than shorter ones...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jan 2016 19:10:10 -0300

Hi, Brian,

> That seems quite reasonable, though. (Don't you mean 2001:db8::/32?)

I meant 2001:db8::/32, sorry.

FWIW, I don't think it's a reasonable out-of-the-box behavior.

Sample scenario:

I was meaning to use this addresses in a virtual network for a training
course. Since they didn't work as expected, I ended up using ULAs. --
it'd been great to be able to use 2001:db8::/16 so that documentation
could use the same addresses as in the actual vrtual network we were
employing.

> (I have a reason for asking that takes a while to explain...)

I'll double-check and come back to you, since I had written notes about
this. -- iirc, it was bsd platforms that wouldn't even forward packets
containing these addresses -- and there was no way to override this.

Thanks,

---

From: [email-masked]
Date: Sat, 23 Jan 2016 09:41:12 +0100 (CET)

> Which platforms, BTW? And was it connect or send that complained?

That seems quite *un*reasonable to me. I would certainly vote with
my wallet and refuse to buy such equipment.

Steinar Haug, AS2116

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 23 Jan 2016 09:38:55 -0500

On Sat, Jan 23, 2016 at 3:41 AM, <[email-masked]> wrote:

> To quote from RFC 3849:
"This is *not* a local-use address prefix, and the filters may be used
   in both local and public contexts."  (Emphasis mine.)

I think it's a reasonable choice to filter bogus packets at the source.

Kerry Lynn

---

From: David Farmer <[email-masked]>
Date: Sat, 23 Jan 2016 08:30:45 -0800

> On Jan 23, 2016, at 06:38, Kerry Lynn <[email-masked]> wrote:
> 

I agree that is reasonable default behavior, and clearly the intent of RFC 3849.  However, I think it is equally reasonable to expect some way to override such default behavior.  As stated I read it says, ok to filter or not to filter.  Otherwise, I would have expected more than just a permissive to be used, and a recommendation or stronger yet a requirement to filter.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jan 2016 11:34:44 -0500

> That seems quite reasonable, though. (Don't you mean 2001:db8::/32?)

It's not reasonable to me.  It should be possible to setup a lab of equipment
according to the documentation that was provided, exactly as documented.

If someone wants to put a warning into a GUI... that's fine.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Smith <[email-masked]>
Date: Sun, 24 Jan 2016 10:02:35 +1100

> according to the documentation that was provided, exactly as documented.

While I sympathise with the viewpoint, that is using that documentation
prefix for more documentation.

I think ULAs for training labs are better, and would show that
documentation prefixes should not be used on live networks of any type.

---

From: "Raymond Burkholder" <[email-masked]>
Date: Sat, 23 Jan 2016 19:21:12 -0400

>While I sympathise with the viewpoint, that is using that documentation prefix for more documentation.
>I think ULAs for training labs are better, and would show that documentation prefixes should not be used on live networks of any type.

I believe it goes both ways.  When writing documentation, you want to test what you documented.  So, you build something with the documentation addresses, prove that it works, then put into documentation verbatim.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 24 Jan 2016 01:40:16 +0000

> If someone wants to put a warning into a GUI... that's fine.

Counterpoint:

If you don't automatically filter, this stuff leaks into tables, etc.
The Internet is no longer a place where you can assume that everyone
playing has clue....

--------------------------
route-views>show bgp ipv6 unicast 2001:db8::/32 longer-prefixes
BGP table version is 553396, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f
RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2001:DB8:0:FF::ABCF/128
                       2001:B08:2:280::4:100
                                                              0 3277 3267
41313 ?
-------------------
Wombat:~ wkumari$ whois -h whois.cymru.com AS41313
AS Name
NOVATEL-AS _Novatel_ Eood,BG
-------------------
route-views>traceroute ipv6 2001:DB8:0:FF::ABCF
Type escape sequence to abort.
Tracing the route to 2001:DB8:0:FF::ABCF

  1 vl-51-gw.uoregon.edu (2001:468:D01:33::1) [AS 3582] 1 msec 0 msec 0 msec
  2 2001:468:D01:2::9 [AS 3582] 0 msec 1 msec *
  3  *  *  !H
route-views>
---------------

Looking at V4:
wkumari@vimes:~$ whois 192.0.2.0 | grep -v '#' | head
NetRange:       192.0.2.0 - 192.0.2.255
CIDR:           192.0.2.0/24
NetName:        TEST-NET-1
NetHandle:      NET-192-0-2-0-1
Parent:         NET192 (NET-192-0-0-0-0)
NetType:        IANA Special Use

route-views>sho ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 810163
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  20771 47872 12615 8866 8717 5421
    80.241.176.31 from 80.241.176.31 (80.241.176.30)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

wkumari@vimes:~$ whois as5421 | tail -20

role:           Sofia University St. Kliment Ohridski NCC
address:        5, James Bourchier Blvd.
address:        1164 Sofia
address:        Bulgaria
phone:          +35928161579
org:            ORG-UoS32-RIPE
admin-c:        HUBY-RIPE
tech-c:         HUBY-RIPE
tech-c:         MP24687-RIPE
nic-hdl:        NCC123-RIPE
abuse-mailbox:  [email-masked]
mnt-by:         AS5421-MNT
created:        2013-11-12T14:18:16Z
last-modified:  2013-11-12T14:18:16Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.84.1
(DB-1)

Wombat:~ wkumari$ traceroute 192.0.2.1
traceroute to 192.0.2.1 (192.0.2.1), 64 hops max, 52 byte packets
 1  10.10.10.254 (10.10.10.254)  10.884 ms  2.628 ms  0.902 ms
 2  172.20.0.1 (172.20.0.1)  3.901 ms  12.389 ms  1.824 ms
 3  12.197.88.1 (12.197.88.1)  2.102 ms  2.084 ms  2.246 ms
 4  * * *
 5  * * *

192.0.2.0/24 is one of the IPv4 documentation prefixes. It is being leaked
into the table by AS5421 (Sofia University St. Kliment Ohridski).
If you don't automatically filter bogons these data, they *will* leak into
the global tables.

Traceroute leaves my access-point, the hotel (Hyatt) NAT and then packets
get dropped once they enter ATT.

Belt *and* suspenders *and* duct tape *and* baling wire...

W

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2016 08:37:05 -0300

On 01/23/2016 11:38 AM, Kerry Lynn wrote:
> On Sat, Jan 23, 2016 at 3:41 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

I find it unreasonable that this is the only crap that the boxes in
question filter, and, even more, than there's no way to override this.

Id also expect that something that is used in documentation is usable in
a local context -- otherwise, how could I possibly e.g. deliver a
virtual network to students, and at the same time document such network
using a prefix that is IETF-friendly for that purpose?

 -- the only option I've seen has been to use ULAs, but then one is not
really supposed to use ULAs for that.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2016 11:01:42 -0300

On 01/23/2016 08:02 PM, Mark Smith wrote:
> 
> On 24 Jan 2016 3:04 AM, "Michael Richardson" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>>
>> Brian E Carpenter <[email-masked]
> <mailto:[email-masked]>> wrote:

Then, how do you document such lab while still complying with our rules
for documentation?

A prefix that can only be used to write on paper is not of much use...
and to some extent a waste of address space...

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2016 11:04:05 -0300

> I believe it goes both ways.  When writing documentation, you want to test what you documented.  So, you build something with the documentation addresses, prove that it works, then put into documen…

Exactly. And not just that: at times you also want to show the output of
actual commands, tests, etc. And if the documentation prefixes are not
usable, you have to resort to use a different prefix, then "patch" the
output. -- this wastes manpower, and also potentially introduces errors
(and, at times, it may not even be possible (think about screen captures
of a GUI)).

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2016 11:08:27 -0300

On 01/23/2016 10:40 PM, Warren Kumari wrote:
[....]
> The Internet is no longer a place where you can assume that everyone
[....]
> If you don't automatically filter bogons these data, they *will* leak
> into the global tables.
> 
> Traceroute leaves my access-point, the hotel (Hyatt) NAT and then
> packets get dropped once they enter ATT.
> 

I guess I would complain less if:
1) Said platform were to drop other crap
2) There was an option to override this behavior

The above said, I'm left with the question: "If you want to, say,
provide a virtual network for training (along with documentation),
and/or show the output of tools run on said network, which prefix would
you use, while still complying with IETF documentation 'rules'?".

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jan 2016 09:49:32 -0500

Raymond Burkholder <[email-masked]> wrote:
    > I believe it goes both ways.  When writing documentation, you want to
    > test what you documented.  So, you build something with the
    > documentation addresses, prove that it works, then put into
    > documentation verbatim.

Exactly.

(Using a ULA would convince some people that they can only use a ULA in
certain situations where in fact, a ULA would be wrong)

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jan 2016 09:52:37 -0500

> The Internet is no longer a place where you can assume that everyone playing
    > has clue....

Nobody said that it shouldn't be filtered by default, but the default needs
to be an explicit list, not compiled in code, which it appears has occured.

There are probably a dozen prefixes that should never go into the DFZ, and I
have no problem if a router manufacturer provides a prefix-list that is
pre-initialized with those values.  But, using that should be at the
operator's discretion.

    > If you don't automatically filter bogons these data, they *will* leak into

Nobody is arguing otherwise.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jan 2016 09:53:59 -0500

> really supposed to use ULAs for that.

And, ULAs don't fit into the 2000::/3 filter that you'd want to write to
include or exclude things.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Raymond Burkholder" <[email-masked]>
Date: Sun, 24 Jan 2016 12:06:20 -0400

> pre-initialized with those values.  But, using that should be at the

Otherwise we'll end up with what happened with 240.0.0.0/4, where it was
hard-coded and can't be re-used without herculean effort.  But too late for
that particular case, but is a reminder not to do the same wrong thing over
again.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Jan 2016 11:38:30 -0500

Documenting a Lab is quite different from documenting a protocol.

We found, far too often, that IP addresses used in RFCs and similar 
documents were being copied verbatim into networks that then leaked into 
the operational world.  This was not a guess.  This was an observed 
property.

So the IETF took a decision to reserve a block of addresses for use in 
documentation that would never appear on the wire, anywhere.  It was the 
only way we could find to resolve this problem.  And it seems to have 
significantly improved the situation.

Yes, it is a rule we made.  Yes, we could change it.  But before asking 
that it be changed, please look at the potential risk, and include those 
observed risks in any discussion of changing the rules.

Yours,
Joel

---

From: [email-masked]
Date: Sun, 24 Jan 2016 21:33:16 +0100 (CET)

> significantly improved the situation.

This decision *may* have improved the situation - however, "would never
appear on the wire, anywhere" is simply not the case.

The following boxes will happy route prefixes under 2001:db8::/32, as
verified in the lab just now (pingable, appears in routing protocols):

Juniper MX104	 JunOS 14.1R6.4
Cisco ASR1001	 IOS XE 15.4(3)S4
Huawei NE5000	 VRP 8.90
Huawei NE40E-M2F VRP 8.100

> observed risks in any discussion of changing the rules.

I would be happy with a router which kept 2001:db8::/32 off the wire
by default, but which also let me explicitly *turn off* the default
behavior.

A router which completely prevented me from using 2001:db8::/32 would
make me rather unhappy, and I would probably vote with my wallet.

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Jan 2016 11:53:53 +1100

> Then, how do you document such lab while still complying with our rules

If you're recording the lab configuration for later reference, then you'd
record the ULA addresses used.

If you're writing documentation to demonstrate an addressing concept or to
present in a presentation, then 2001:db8::/32 should be used.

It's a second hand story that I heard a long time ago, however there was an
instance where a company used their own IPv4 address space in early IPv4
training course notes, which students then took back to their own network
and used. I think it was also leaked into the DFZ more than once (if I
recall it might have been Sun and address space that started with 131.)

So I see the documentation prefix to be purely used in documentation, not
on any live equipment, to help prevent reuse in other networks. Using ULAs
in labs, including in training course labs, also creates an opportunity to
discuss how to use and generate ULAs, and why they have the random
component, and use the problems of reusing a prefix like the documentation
prefix or site-locals.

Regards,
Mark.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Jan 2016 04:24:46 +0000

So, I may have missed it, but was it said *which* platform it was that
didn't allow this?

W

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Jan 2016 01:41:38 -0300

> So, I may have missed it, but was it said *which* platform it was that

I seem to recall it was FreeBSD. I could re-check if there's interest...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Jan 2016 05:27:33 -0300

On 01/24/2016 01:38 PM, Joel M. Halpern wrote:
> Yes, it is a rule we made.  Yes, we could change it.  

My understanding is that, in many platforms, 2001:db8::/16 is no
different from ULAs in this respect: just another bogon to filter.

However, the particular platform I was referring to had a hardcoded
filter for this one. -- i.e., such filtering is not widespread.

> But before asking

I'm not asking for it to be changed (not so far, at least). I'm rather
asking what's the prefix I'm supposed to use for e.g. delivering and
documenting a lab. If that's something other than 2001:1db8::/16, I'm
not sure why in this case this would not produce the "copy&paste"
problem you're referring to -- whether folks c&p from RFCs or from some
PDF someone is providing seems rather irrelevant.

Thanks,

---

From: [email-masked]
Date: Mon, 25 Jan 2016 09:36:22 +0100 (CET)

> I seem to recall it was FreeBSD. I could re-check if there's interest...

Just tested FreeBSD 9.3 and 10.2: 2001:db8::/32 prefixes just work,
with no apparent problems.

Steinar Haug, AS2116

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Jan 2016 05:46:46 -0300

> with no apparent problems.

Having a FreeBSD box acting as a router? -- I seem to recall that was
the scenario in which I found issues (freebsd 8 or the like.. but should
check).

---

From: [email-masked]
Date: Mon, 25 Jan 2016 10:14:20 +0100 (CET)

> the scenario in which I found issues (freebsd 8 or the like.. but should

Yes I have that too :-)  Works fine with FreeBSD 9.3 and 10.2, not
checked FreeBSD 8.

Steinar Haug, AS2116

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jan 2016 10:39:09 -0500

> documenting a lab. If that's something other than 2001:1db8::/16, I'm

I would not be opposed to have a few additional prefixes allocated for lab
use.
In particular, I'd prefer it if the prefixes differed in the first digit or
two, so I'd love to have, for instance:

2201:1db8::/16
2601:1db8::/16
2C01:1db8::/16
2F01:1db8::/16
3601:1db8::/16
3C01:1db8::/16

or something like that reserved for lab use... (Yes, and AS112'ed)

---

From: Brian Haberman <[email-masked]>
Date: Mon, 25 Jan 2016 12:51:43 -0500

> The current behavior implies fe80::/64 rather than fe80::/10.

FE80::/10 is defined as link-scoped unicast.
FE80::/64 is defined as link-local address space.

There is nothing in the specs that would preclude a new format in the
link-scoped unicast address space.  It just needs to be defined.

Regards,
Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Jan 2016 10:03:00 +0200

> and to some extent a waste of address space...

There is documentation and documentation.  Documentation that gets very 
widely advertised (e.g. a Stevens book) should certainly use 2001:db8. 
But documentation with limited audience should use ULAs or real 
addresses.  One should use specific means to protect that documentation 
from public viewing, like strong access control.

I got used to handwriting 2001:db8 on paper, on drawing boards, and not 
on computers.

Paper: made of cellulose extracted from wood.

Virtual paper: powerpoint, electronic documents, machine writing.

Virtual network: virtual box, virtual machines.

An address typed on a virtual box should not be 2001:db8 because the 
stack is real although the machine is virtual.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Jan 2016 10:04:37 +0200

> (and, at times, it may not even be possible (think about screen captures

If the audience is limited, a teacher can use real addresses, not the 
2001:db8.  Just tell them to keep these addresses safe from public view.

The 2001:db8 is a documentation prefix, yes, but not the only prefix 
usable for such purpose.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Jan 2016 10:06:39 +0200

> certain situations where in fact, a ULA would be wrong)

I agree.  At that point give a LL, a multicast, or a global address. 
Just tell the readers of that paper to not re-distribute because it's 
just an example, or because it can clash with others, or because it's 
the real address on our secure network and we dont want others to know it.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 08:29:16 +1300

On 26/01/2016 21:06, Alexandre Petrescu wrote:
...
> Just tell the readers of that paper to not re-distribute
> because it's just an example, or because it can clash with others, or because it's the real address on our secure network and we
> dont want others to know it.

Honestly this is naive.

If you give an example, somebody somewhere *will* try it out on the live Internet.
Because that's what humans do.

About the first thing we had to do when we started taking TCP/IP seriously at
CERN (around 1986) was renumber everything to get away from 1.0.0.0/8. Because
some early documentation used that as an example. Humans haven't changed much
since 1986.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Jan 2016 20:34:00 -0300

> Because that's what humans do.

+1

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Jan 2016 23:42:38 -0800

> link-scoped unicast address space.  It just needs to be defined.

I think it's quite reasonable that we shouldn't infill sparse address
space  with assumptions. If we reserved something but didn't allocate
it, it's unallocated, not a free-for-all; seems like the basic
conservative assumption.

It is reasonable to allow for the configuration of unallocated
resources. After all it's not always the case that software has to
change to account for new usage, but it's also reasonable to accept that
such usage may be allowable under common defaults.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 27 Jan 2016 09:51:49 +0200

>> dont want others to know it.

When people give examples of credit card numbers, license plates or new 
bank notes, they often bar it with a "fake" diagonal.  That seems naïve 
too yet it's common practice against counterfeit.

> Because that's what humans do.

Yes.

> some early documentation used that as an example. Humans haven't changed much

The first thing I type on a computer to see whether it supports IPv6 is 
ifconfig eth0 add 1::1/128 because that's the fastest way to check.

Alex

>     Brian
n

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Jan 2016 11:50:41 -0800

At Fri, 22 Jan 2016 14:17:52 +0100,
Sander Steffann <[email-masked]> wrote:

> It has always been interesting that a /10 is reserved for link-local
> while only a /64 is commonly used. The 54 bits in the middle could
> be anything, but they are always 0. FreeBSD even uses that
> assumption to store the scope-id in those bits:

> I *did* go WTF when Gert Döring pointed that out to me...

We all knew it was an ugly hack, and we wouldn't implement it that way
if we wrote the stack today.  But any long-lived thing like BSDs and
IPv6 has historical context.  I'd say it's a bit unfair to just go WTF
without at least learning that.  In case you're willing to learn it,
I'm pasting relevant text below from a book I co-authored.

--
JINMEI, Tatuya

Since the 16-bit field embedding the zone ID should be 0 in the wire
according to the address format, using this field for implementation
specific purpose may be justified as long as it is restricted inside
the kernel.  Still, you may wonder why we need to be bothered with the
strange form while the sockaddr_in6{} structure should be able to
contain complete information in a cleaner way.

This is primarily for historical and compatibility reasons.  At the
time the KAME project started, the sockaddr_in6{} structure did not
have the sin6_scope_id field (see RFC2133), and link-local addresses
had to be disambiguated in an implementation-dependent manner.  The
embedded form was a KAME-specific workaround to this problem.  It was
used anywhere in the kernel for representing IPv6 addresses, including
some protocol independent parts of the kernel like the routing table
or the routing socket API.

Since then, several applications have been developed, and some of
those had to care about the embedded form directly.  Among those were
routing tools such as route6d, a RIPng daemon (which will be described
in Chapter 1 of Book-II).  Such programs had to deal with the embedded
form of IPv6 link-local addresses through the routing socket.  Another
example is system administration tools that directly refer to the
kernel memory, such as the netstat program.  These applications needed
to clear the embedded zone ID and set the sin6_scope_id correctly
before showing the address to the user.

In 1999, RFC2553 solved the ambiguity issue by adding the
sin6_scope_id field to the sockaddr_in6{} structure.  The KAME and BSD
implementations supported the new API, and updated most IPv6-related
interfaces accordingly, including input and output system calls on an
AF_INET6 socket.  Unfortunately, however, it seemed too late to update
the routing table structure and the routing socket interface: routing
tools were so tightly associated with the embedded form; on the other
hand, the routing interface is generally protocol-independent and the
KAME developers did not think it acceptable for the BSD community to
introduce IPv6-specific changes to such a general interface.

Therefore, the current kernel implementation adopts a "hybrid"
approach as shown in Figure XX (omitted here).  The IPv6 protocol
stack in the kernel generally maintains IPv6 addresses in the
sockaddr_in6{} structure with the zone ID being both embedded in the
sin6_addr field and specified in the sin6_scope_id field.  In the
protocol independent routing table, the zone ID is only embedded
within the sin6_addr field.  The IPv6 protocol stack is responsible
for clearing or restoring the sin6_scope_id field when it deals with
the routing table.  The same relationship applies to the protocol
independent interface address structures, since these are tightly
related to the routing table and can often be exchanged with the
routing table transparently.

Ordinary applications, when they ever need to care about address
scopes, can and should only be aware of the sin6_scope_id field.  They
must not directly refer to or set the second 16-bit of an IPv6 address
assuming the embedded form.  When an application passes an IPv6
address through a standard AF_INET6 socket (e.g., as the packet's
destination address), the IPv6 protocol stack will convert the
structure into its internal "hybrid" form.  Similarly, when the kernel
passes an IPv6 address to an application, the protocol stack will make
sure that the embedded part is cleared and the sin6_scope_id field is
set appropriately.

Finally, applications that need to interact with the kernel part
maintaining the embedded form are required special handling by
themselves.  They should directly interpret the embedded form assuming
the kernel implementation, and, when necessary, convert the address in
the non-embedded form using the standard sin6_scope_id field before
passing the address to the kernel through the AF_INET6 socket
interface.  Some management tools that directly access the kernel
memory image via the kvm interface or IPv6 routing daemons using the
routing socket belong to this category.

Another effect of the embedded form is that network masks can be
contiguous.  For example, we can apply the natural 64-bit contiguous
mask for FE80:1:: to represent "FE80::%1/64".  On the other hand, if
the link identifier were in fact stored in the sin6_scope_id field, we
would need a non-contiguous mask for the separate field.  This is not
a big deal, though, since BSD's routing routines can naturally handle
non-contiguous masks.

In any event, applications should generally avoid relying on the
kernel specific details whenever possible.  Indeed, the applications
should not even be aware of such details.  There are plenty of reasons
for this:

- The first obvious reason is portability.  Since the embedded form is
  specific to the KAME and BSD kernel implementations, applications that
  take an action relying on that particular form will not work on other
  operating systems.
- Secondly, address ambiguity is not specific to link-local or
  interface-local addresses; any non-global multicast addresses are
  inherently ambiguous.  Thus, an ad-hoc check specific to
  interface-local or link-local scopes assuming the embedded form can be
  the source of a bug in the future.  It should also be noted that we
  cannot embed the zone ID for unicast prefix based multicast addresses,
  which does not have enough space in the address format.
- Third, this is vulnerable to future changes of the embedded form in
  the kernel.  For example, the embedded position may change or the
  zone ID may not actually be the interface index, even though such a
  drastic change will unlikely be made due to compatibility issues.
- Fourth, we may not always be able to
  assume the embedded field is zero for a packet received from the
  wire.
  In fact, there is a new standard format of link-local multicast
  addresses that requires the second 16-bit of the address be a non-0 value
  [RFC4489].
  Additionally, while it is moot whether other link-local addresses
  with the second 16-bit field being non-0 is valid or not in terms of
  the address architecture specification, it would at least make the
  validation procedure more complex with the embedded internal form.
- Finally, the embedded field is a 16-bit integer, while the
  standard sin6_scope_id field is 32-bit.  This mismatch may
  cause annoying corner case or error handling.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Jan 2016 14:05:53 -0800

> Yes I have that too :-)  Works fine with FreeBSD 9.3 and 10.2, not

So, while all the implementation-independent discussions of this
thread are interesting and possibly useful, we don't yet know if such
a box exists in the real world, right?  It's also surprising to me if
an out-of-box FreeBSD node (whether configured with enabling/disabling
IPv6 forwarding) really rejects 200a:db8::/32 by default, and without
any interface to override it.

--
JINMEI, Tatuya

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Jan 2016 15:56:42 -0800

> If you don't automatically filter, this stuff leaks into tables, etc.

Internal vs. border is a very real and important distinction here. On 
the border I would have no objection to documentation prefixes being in 
a default block rule, but it should have a way to be turned off.

As someone who writes a non-zero amount of documentation/teaching 
material, the ability to use examples verbatim is priceless.

I have also found it useful in the past to use a documentation prefix to 
provision a point to point link on secondary interfaces between hosts, 
precisely because that prefix should never show up on the larger 
network; and using it did not interfere with any other "proper" prefixes 
that were actually (or might be in the future) in use.

Being draconian about not routing documentation prefixes in 
hardware/software is overstepping.

Doug