Le 22/02/2017 à 00:23, Brian E Carpenter a écrit :
On 22/02/2017 11:58, Job Snijders wrote:
On Wed, Feb 22, 2017 at 11:44:42AM +1300, Brian E Carpenter wrote:
On 21/02/2017 23:13, Job Snijders wrote:
On Tue, Feb 21, 2017 at 02:11:15PM +1300, Brian E Carpenter
wrote:
On 21/02/2017 13:19, Job Snijders wrote:
On Thu, Feb 16, 2017 at 09:40:01AM +0100,
otroan(_at_)employees(_dot_)org wrote:
There are many reasons for the 64 bit boundary. -
Allowing identifier locator split: 8+8 / GSE that led to
ILNP and NPT66
Irrelevant.
Not really. They are both running code. You may not want them
in *your* network but that isn't the point. Some people want
them.
And there is a lot of other running code too, not just SLAAC
which is mandatory to implement in every IPv6 host. So this
actually trumps all the other arguments: it's 64 bits because
it's 64 bits.
When someone utters the phrase "it is X because it is X", the
rhetorical imperative seems to be to dismiss further
conversation (perhaps any internal dialogue as well, which may
be the primary purpose). "It is what it is" therefore, there’s
nothing more to be said about it...
Except when it's not 64 bits?
That wasn't quite my intention. I just wanted to underline that
(like it or not) it was set at 64 bits many years ago and a lot
has been built on that.
...
I've looked at all configured IPv6 addresses on AS 2914
equipment. Interestingly enough, the below table is a
reflection of not only NTT's own addressing, and (since
AS2914's core function is to connect networks to each other)
also of its peers and customers. In the end, whatever makes the
thing work is the thing that will be configured.
/127 - 22% /126 - 52% /125 - 0,9% /124 - 0,5% /120 - 0,04% /112
- 0,02% /64 - 23%
Thanks, that's interesting. So 23% of the devices might have
RFC4291-compliant IIDs. The others are configured with 128 bit
IPv6 addresses. Is that correct?
The percentage is not the percentage of devices, but the percentage
of interconnections. In all instances the addresses are staticly
configured.
OK, but from the outside I can't know that for the /64 subnets.
Back to my example from earlier, to make sure we are on the same
page, this is output from a standard Linux machine:
job@tardis:~$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1
job@tardis:~$ sudo ip -6 addr show dev eth1 3: eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6
2001:728:1808:1::21/126 scope global valid_lft forever
preferred_lft forever inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
valid_lft forever preferred_lft forever job@tardis:~$
Most network engineers would call the above example "configuring a
/126 on an interface" - but am I understanding correctly that in
your taxonomy you would call this "configuring a 128 bit IPv6
address"?
Well that does two things: configures a 128 bit address (as Chris
points out, *all* addresses are 128 bits, duh) and associates a
prefix length with it, which afaik is optional.
The prefix length is not optional. There is no system out there on
which one could configure a 128bit address without explicitely telling
'/128' or '/64' or '/something-else'.
By specifications, I think only DHCPv6 specs say that the address
assigned to a Client has no prefix length. In practice though, the
address assigned by DHCPv6 w/o prefix length gets a 'by default' prefix
length often hardcoded as '/64'.
But the interface has already auto-configured a link-local address,
with a 64 bit IID. So yes, that's exactly what I mean.
Which brings back: the LL address should have a prefix length or no? If
yes should it be /64 (2464bis) or /10 (4291bis)?
Linux sets it at /64 by default... and I disagree with it, 4291bis
disagrees too.
Alex
That being so, perhaps the words that are missing are "The IID
length requirement does not apply to interfaces that are
explicitly configured with 128 bit addresses." Because the
requirement is meaningless for such interfaces.
The terminology might confuse some people, as in common language
when one configures "a /128", or 'a 128 bit address', it usually
means you are configuring something like a loopback address.
Perhaps:
"The IID length requirement does not apply to interfaces that are
explicitly configured without autoconfiguration."
(perhaps even remove the word 'explicitly')
"The IID length requirement does not apply to interfaces that are
configured without autoconfiguration."
Personally I think that's right. (However, if you manually configure
an address that matches a pre-existing prefix announced by an RA, it
will be assumed to belong to that prefix. I've done that by hand on
Windows, not sure I've done it in Linux.)
Brian