Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Alexandre Petrescu <[e-mail]>]

Sorry for interfering Lorenzo, but I think there is an error here.

Le 22/02/2017 à 16:56, Lorenzo Colitti a écrit :
[...]
> Also, bear in mind that the interface ID length is *not* the same as
> the prefix you route to the link.

I guess you mean the plen1 of a prefix routed to a link is not the same
as a plen2 (128-IIDlen) advertised by RA on that link.

If plen1 is /63 and the IIDlen is 64 then RFC4862 (SLAAC) text says the
prefix in the RA must be discarded.  For this reason people make a /64
out of that /63 by putting a 0 in there.  Should it be 0 or 1?  Silence
in specs about this.

If plen1 is /120 and the plen in the RA is /64 then there is a big
problem, below.

If on another hand you mean that that /64 is not in an RA but manually
configured in the interface: then why put 64 when all the subnet has is
a 120?  Who asks for this?  The 4291bis spec?  That's an error too.

> Given that you're talking about static configuration, you can
> perfectly well configure all the hosts with /64 prefixes, but give
> them addresses that are all in a given /120

I guess you mean to manually assign 2001:db8::1/120 on a machine, and
2001:db8::2/120 on another.  I dont see why setting a /64 there at all.

> and then route only the /120 to that link.

YEs.  One could route the /120 to that link, and have each Host on that
link statically configure an IP address with that /120 prefix length.
That works.

ND and NUD also work ok with /120.

But,

If one puts a /64 in a RA in a subnet where only a /120 is routed to
then things may break.  Some Hosts may self-configure SLAAC/Ethernet
some addresses with an IID of length 64 which are routed elsewhere, not
to them.  Outgoing packets may go, but incoming packets go to some other
place.

> That will also avoid all the attacks.

YEs, some ND attacks will be avoided if using a /120.  One does not need
to put /64 anywhere in order to avoid ND attacks.

> It also makes configuration much simpler, because you don't have to
> touch any of the hosts when you run out of the /120: just increase
> the /120 to a /119 on the router and move up from ::ff to ::100. That
> is 100% supported by the current text of RFC4291bis, which requires
> that the router forward packets to the /120.

YEs, I agree.  It can be extended that way.  But in this case, again,
why the need to put /64 there?

> This trick doesn't work in IPv4,

I agree: in IPv4 it amounts to forwarding a /24 to a subnet and set /16
as subnet mask on the addresses of Hosts in that subnet.  That can
create problems.  They are more visible in IPv4.

Same in IPv6: if one forwards a /120 to a subnet then set /120 as that
prefix length (aka subnet mask).  Otherwise problems.

One can do such trick equally well in IPv4 and in IPv6 and one is
equally conscious of the problems created.

Alex

>
> ...
>
> There is public data that suggests that the backbone you are
> familiar with might be connected to a public internet exchange which
> uses a /112 as peering lan prefix.
>
>
> For the record, I don't dispute either of those.
>
>> Also, backbone networks are a tiny percentage of the links on the
>> planet.
>
> I certainly will not deny that fact. Are you familiar with the
> concept of the McNamara fallacy?
>
>
> I wasn't. But that fallacy would apply to your arguments just as well
> as to mine. You're the one that brought numbers to the thread first.