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

Job Snijders <> Thu, 23 February 2017 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC5E12A04E; Thu, 23 Feb 2017 03:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id myZ2BIyrN23u; Thu, 23 Feb 2017 03:37:48 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30830129FD4; Thu, 23 Feb 2017 03:37:48 -0800 (PST)
Received: by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1cgriC-0008wi-SF (; Thu, 23 Feb 2017 11:37:47 +0000
Date: Thu, 23 Feb 2017 12:37:05 +0100
From: Job Snijders <>
To: Lorenzo Colitti <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <>
References: <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <>
Cc: 6man WG <>,, IETF-Discussion Discussion <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 11:37:49 -0000

On Thu, Feb 23, 2017 at 12:56:45AM +0900, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 12:31 AM, Job Snijders <> 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,