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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 23 February 2017 11:57 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FAF12A187 for <ietf@ietfa.amsl.com>; Thu, 23 Feb 2017 03:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham 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 654PZIXC9Y8r for <ietf@ietfa.amsl.com>; Thu, 23 Feb 2017 03:57:38 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2B112A17D for <ietf@ietf.org>; Thu, 23 Feb 2017 03:57:37 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1NBvY50010498; Thu, 23 Feb 2017 12:57:34 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D76272074BE; Thu, 23 Feb 2017 12:57:34 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C8C09200B4E; Thu, 23 Feb 2017 12:57:34 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1NBvYDg005927; Thu, 23 Feb 2017 12:57:34 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, ietf@ietf.org
References: <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <047994c3-9cce-12ce-55bb-bf3ae3369b57@gmail.com> <20170221225857.GE32367@Vurt.local> <f84828c0-7d37-6c56-b1a6-6260227b4f44@gmail.com> <efd19030-6a81-3e14-d294-94e4605f15a1@gmail.com> <252c3c52-a158-f65a-bc6f-7c4686db7544@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <619d77db-8b4d-704a-4f68-6ca6cf3433e7@gmail.com>
Date: Thu, 23 Feb 2017 12:57:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <252c3c52-a158-f65a-bc6f-7c4686db7544@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mkGb4ZpkF8mgFRUOWkPEfWqbmzY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 11:57:39 -0000


Le 22/02/2017 à 21:04, Brian E Carpenter a écrit :
> On 22/02/2017 22:41, Alexandre Petrescu wrote:
> <snip>
>
>>> Well that does two things: configures a 128 bit address (as Chris
>>> points out, *all* addresses are 128 bits, duh) and associates a
>>> prefix length with it, which afaik is optional.
>>
>> The prefix length is not optional.  There is no system out there on
>> which one could configure a 128bit address without explicitely telling
>> '/128' or '/64' or '/something-else'.
>
> Wrong. Sorry to get all technical, but on Windows:

Ok, I didnt know Windows acts that way.

>
> C:\windows\system32>netsh interface ipv6 add address ?
>
> Usage: add address [interface=]<string> [address=]<IPv6 address>[/<integer>]
>              [[type=]unicast|anycast]
>              [[validlifetime=]<integer>|infinite]
>              [[preferredlifetime=]<integer>|infinite]
>              [[store=]active|persistent]
>              [[skipassource=]true|false]
>
> The [/<integer>] looks pretty optional to me.

I agree.

> I just tried
>    netsh interface ipv6 add address 12 2001:db8:dead::beef
> and now I have three addresses:
>
> C:\windows\system32>netsh interface ipv6 show addresses
>
> Interface 12: Wireless Network Connection
>
> Addr Type  DAD State   Valid Life Pref. Life Address
> ---------  ----------- ---------- ---------- ------------------------
> Manual     Preferred     infinite   infinite 2001:db8:dead::beef
> Public     Preferred      1h54m9s      54m9s fd63:45eb:dc14:0:28cc:dc4c:9703:6781
> Other      Preferred     infinite   infinite fe80::28cc:dc4c:9703:6781%12
>
> When I try to ping 2001:db8:dead::cafe, I see what I expected in Wireshark:
> neighbour solicitations from 2001:db8:dead::beef to ff02::1:ff00:cafe.
> In other words, the new address is treated as on-link. I can't find any trace
> of an associated prefix entry.

This looks strange.  The NS for 2001:db8:dead::beef are normal - they 
are DAD.  But to consider it on-link, without having been told the plen 
is /64 and the prefix, is not normal.

I suppose Windows configures an address and a prefix/plen by receiving 
an RA.  And then, when adding manually an address it considers that 
address to be part of that link too.  That is not normal, because the 
prefix 2001:db8 is certainly not the same as the one in the RA.

I suppose Windows programmers made it so because they needed that 
[/integer] to be optional but they also needed the addresses that are 
manually configured to be part of some subnet... which one?

To check this behaviour, one would silence the RAs, netsh restart, and 
then manually configure an address without plen, and add a default gw. 
Can that ping the gw?  Can it ping the Internet?  If yes, then it means 
there is a /64 hidden somewhere that must be removed.  If it does not 
work, then it's good - it misses the plen.

> Maybe Linux is different.

YEs in a sesne.

Alex

>
>      Brian
>