ietf
[Top] [All Lists]

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

2017-02-23 05:38:42
On Thu, Feb 23, 2017 at 12:56:45AM +0900, Lorenzo Colitti wrote:
On Thu, Feb 23, 2017 at 12:31 AM, Job Snijders <job(_at_)ntt(_dot_)net> 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

<Prev in Thread] Current Thread [Next in Thread>