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

[Job Snijders <[e-mail]>]

On Thu, Feb 23, 2017 at 12:56:45AM +0900, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 12:31 AM, Job Snijders <[e-mail]> wrote:
> 
> > rfc6164 and rfc6583 are great examples that document considerations
> > regarding not using a /64, it simply is not always the best fit.
> 
> RFC6583-style attacks (of which the class addressed by RFC6164 is a
> subset) are low payoff and pretty easy to mitigate using very small
> changes to ND implementations. You can solve most or all of the
> problem by using per-interface ND queues and prioritizing existing and
> gleaned ND entries over incomplete ones. You can do even better by
> pushing the filtering away from the host so that you don't have to
> carry the packets.

The perfect solution is always just one upgrade away! :-)

> Also, bear in mind that the interface ID length is *not* the same as
> the prefix you route to the link. 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 and then route only the /120 to that link. That will also avoid
> all the 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.

Thanks for sharing this Lorenzo, it something I did not think of. I
appreciate the cleverness of this trick, just as much as the next person
appreciates this funny photo [2]. :-)

However, while the trick can be made to work on Linux, it does not
appear to work on Cisco IOS XR, JunOS and OpenBSD. As such, its no more
then a party trick, and cannot be considered as a supportive argument
for an Internet Standard.

For the benefit of the working group, what Lorenzo describes is the
following in linux-lingo:

    $ sudo ip -6 address add    2001:67c:208c:4291::1/64 dev eth1
    $ sudo ip -6 route   delete 2001:67c:208c:4291::/64 dev eth1
    $ sudo ip -6 route   add    2001:67c:208c:4291::/126 dev eth1

    $ sudo ip -6 route show dev eth1
    2001:67c:208c:4291::/126  metric 1024

    $ sudo ip -6 addr show dev eth1
    3: eth1: <BROADCAST,MULTICAST> mtu 1500 qlen 1000
        inet6 2001:67c:208c:4291::1/64 scope global tentative
        valid_lft forever preferred_lft forever

I also fear that the moment "disunited addressing & routing" become
commonplace, you'll find your devices on the dirty end of a
'/120 routed + /64 addressed'-link and have a dysfunctional experience.
As far as I know there is no way to signal host "only a /120 out of this
/64 is routed".

Kind regards,

Job

[2]: http://instituut.net/~job/ietf-6man.jpg