On Feb 23, 2017, at 7:49 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
Maybe Linux is different.
YEs in a sesne.
I fired up a Linux box and tried ip -6 address add 2001:db8:dead::beef dev
wlp2s0
It works - the /nn is not required - but the prefix length shown
by ip -6 address show is /128, so that seems to be the Linux default.
I recall having a related discussion several years ago on an IETF mailing list.
There should be, in my opinion, *no* prefix length associated with a simple
address assigned to an interface - neither when the address is assigned nor
when the address is shown in response to a config query. It's just an address.
The client's list prefixes is, in the abstract, separate from the list of
addresses assigned to interfaces and populated through other means like RA or
manual config, *not* by inference from address assignment.
This way of thinking about addresses and prefixes explains why DHCPv6 does not
include a prefix length with assigned addresses. DHCPv6 simply assigns 128-bit
addresses. Any prefix tables are populated through separate mechanisms.
IPv4 has no equivalent to RAs, so the workaround is to infer prefix assignment
from address assignment.
- Ralph
(Sorry, can't cut and paste from that screen to this one. Also I can't
mess with the RAs since it is a shared gateway.)
Regards
Brian
On 24/02/2017 00:57, Alexandre Petrescu wrote:
Le 22/02/2017 à 21:04, Brian E Carpenter a écrit :
On 22/02/2017 22:41, Alexandre Petrescu wrote:
<snip>
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'.
Wrong. Sorry to get all technical, but on Windows:
Ok, I didnt know Windows acts that way.
C:\windows\system32>netsh interface ipv6 add address ?
Usage: add address [interface=]<string> [address=]<IPv6 address>[/<integer>]
[[type=]unicast|anycast]
[[validlifetime=]<integer>|infinite]
[[preferredlifetime=]<integer>|infinite]
[[store=]active|persistent]
[[skipassource=]true|false]
The [/<integer>] looks pretty optional to me.
I agree.
I just tried
netsh interface ipv6 add address 12 2001:db8:dead::beef
and now I have three addresses:
C:\windows\system32>netsh interface ipv6 show addresses
Interface 12: Wireless Network Connection
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Manual Preferred infinite infinite 2001:db8:dead::beef
Public Preferred 1h54m9s 54m9s
fd63:45eb:dc14:0:28cc:dc4c:9703:6781
Other Preferred infinite infinite fe80::28cc:dc4c:9703:6781%12
When I try to ping 2001:db8:dead::cafe, I see what I expected in Wireshark:
neighbour solicitations from 2001:db8:dead::beef to ff02::1:ff00:cafe.
In other words, the new address is treated as on-link. I can't find any
trace
of an associated prefix entry.
This looks strange. The NS for 2001:db8:dead::beef are normal - they
are DAD. But to consider it on-link, without having been told the plen
is /64 and the prefix, is not normal.
I suppose Windows configures an address and a prefix/plen by receiving
an RA. And then, when adding manually an address it considers that
address to be part of that link too. That is not normal, because the
prefix 2001:db8 is certainly not the same as the one in the RA.
I suppose Windows programmers made it so because they needed that
[/integer] to be optional but they also needed the addresses that are
manually configured to be part of some subnet... which one?
To check this behaviour, one would silence the RAs, netsh restart, and
then manually configure an address without plen, and add a default gw.
Can that ping the gw? Can it ping the Internet? If yes, then it means
there is a /64 hidden somewhere that must be removed. If it does not
work, then it's good - it misses the plen.
Maybe Linux is different.
YEs in a sesne.
Alex
Brian