Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Alexandre Petrescu <> Wed, 01 March 2017 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8455129676 for <>; Wed, 1 Mar 2017 11:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.332
X-Spam-Status: No, score=-5.332 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, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bsjuVQt8lbAT for <>; Wed, 1 Mar 2017 11:41:58 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3365D1298B5 for <>; Wed, 1 Mar 2017 11:41:58 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v21Jft0C002806 for <>; Wed, 1 Mar 2017 20:41:55 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id DE9DE20CE1E for <>; Wed, 1 Mar 2017 20:41:55 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id CA14B20BC80 for <>; Wed, 1 Mar 2017 20:41:55 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v21JftRo003444 for <>; Wed, 1 Mar 2017 20:41:55 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
References: <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 1 Mar 2017 20:42:02 +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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Wed, 01 Mar 2017 19:42:03 -0000

Le 01/03/2017 à 12:04, a écrit :
>> On 1 Mar 2017, at 11:58, wrote:
>>>>> FWIW I wouldn't oppose an exception for manually-configured
>>>>> addresses on routers.
>>>> But you would oppose it for hosts? Then I don't think we're
>>>> any further.
>>> Not sure about that. I suppose it also depends on what manual
>>> means. If it's literally just operators configuring them manually
>>> by editing configuration files that's probably fine, but that's
>>> not what you want to do, is it?
>> Yes, that is exactly what I want to do. I want to be able to use
>> the ifconfig command to set an IPv6 address with a netmask
>> different from 64, and to have the corresponding config file entry
>> take effect when the box is booted or the service restarted.
> And that clearly always have been permitted.

In a sense yes, but in the sense of the longest-match algorithm this
permission is not that clearcut, because it is over-ridden.

Let me explain an example.

I am permitted to freely add a fe80::1/63 on my linux but the
longest-match algorithm will over-ride my fe80::/63 intention because
the kernel over-rides it with a _by_default_ fe80::/64 prefix it added
there without me asking it.  That _by_default_ is also resisting reboots.

So - yes, it is permitted, but only to be over-ridden by the 64.  In
other words: I am permitted to add a fe80::1/63 and I will be succsefull
in my intention _if_ I also delete the kernel's intention which is there
by default, and that after each reboot.

(in Windows there is a similar thing).

In that sense, I agree with you.

> E.g. how would you otherwise configure a /128 loopback.

In linux /128 is a particular case.  It pops up after an ifconfig if
that ifconfig did not specify a plen parameter.

There are /128s on other interfaces than loopbacks.

There may be a confusion in considering that /128 is a prefix length, or
it just means an address.  DHCPv6 people think a /128 means just one
address, whereas RA people think /128 is something that could be put in
an RA.

> I agree that current text have always been at best ambiguous on this
> point.

I agree.


> Best regards, Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list Administrative
> Requests:
> --------------------------------------------------------------------