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

Job Snijders <job@ntt.net> Thu, 23 February 2017 11:37 UTC

Return-Path: <job@ntt.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5E12A04E; Thu, 23 Feb 2017 03:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myZ2BIyrN23u; Thu, 23 Feb 2017 03:37:48 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30830129FD4; Thu, 23 Feb 2017 03:37:48 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cgriC-0008wi-SF (job@us.ntt.net); Thu, 23 Feb 2017 11:37:47 +0000
Date: Thu, 23 Feb 2017 12:37:05 +0100
From: Job Snijders <job@ntt.net>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170223113705.GJ89584@hanna.meerval.net>
References: <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <CAKD1Yr2n=ogFo7LJYgjcraoFxioQQzmo8HYxzNRJ10VA8xMVOg@mail.gmail.com> <20170222153129.GE89584@hanna.meerval.net> <CAKD1Yr2-yS-tX9Pe0Rk_74hnXa9Rc-yTHV0m=Kbi2q0wvYGgPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKD1Yr2-yS-tX9Pe0Rk_74hnXa9Rc-yTHV0m=Kbi2q0wvYGgPg@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tcWUBfUaCSPyIrpdwLFz1SxGiJQ>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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 <job@ntt.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