Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

Ralph Droms <rdroms.ietf@gmail.com> Fri, 05 September 2014 16:42 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CEF1A0AF0 for <dhcwg@ietfa.amsl.com>; Fri, 5 Sep 2014 09:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 OenKxZyf_bw2 for <dhcwg@ietfa.amsl.com>; Fri, 5 Sep 2014 09:42:06 -0700 (PDT)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBD51A0AE6 for <dhcwg@ietf.org>; Fri, 5 Sep 2014 09:42:06 -0700 (PDT)
Received: by mail-pd0-f170.google.com with SMTP id r10so16022271pdi.15 for <dhcwg@ietf.org>; Fri, 05 Sep 2014 09:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yi8iRxnecReuJYA7YQMXEoD4Te3ynxR4FXyLV2b68W8=; b=nkNC7GhBcTa108ugb1RUvKiDSqSvH+nqCSCOH4Ueur782GcmSoI88FA3CC1njMrJwU A7YaT/mf9Vu+8hIM1Bm4K4OOLAi/+LlYXdzEQepXkN0PyUFW/AcQCkw/Y+2/NbpJeVPC j3nIhT9bKzoK3jg6+m1xfeX9s01irqAHmZG3uE02qr4LKSBo8yd+cBOZwnEQ3rqttU/V uy3FIu28qfNTcX06RB64lY2M+MJr3T18QVVV/vpWMheITwXnTrU7rKsHpSfLK9/f4TgT Sm4r5cfx4XzrOICPj1OKrvch/CSdUFz+Z/ZcAZXDFmsGotRUZGzNXwBJaK6D2rDTlAg3 Fgzg==
X-Received: by 10.66.66.6 with SMTP id b6mr14997684pat.51.1409935326073; Fri, 05 Sep 2014 09:42:06 -0700 (PDT)
Received: from [128.97.151.129] ([128.97.151.129]) by mx.google.com with ESMTPSA id iu10sm2144690pbd.57.2014.09.05.09.42.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 09:42:04 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: iPad Mail (11D257)
In-Reply-To: <5409D1A0.4040407@gmail.com>
Date: Fri, 05 Sep 2014 09:42:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F23B845B-5409-4D05-92A3-EF57505D9C64@gmail.com>
References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <AD6668B4-834A-4777-B667-006BA06A2C4F@gmail.com> <53E39157.8060708@gmail.com> <CAJE_bqcr5ytrgrUWwPLvZ=vHNPe=C4OZcah0529suOLOgM6odA@mail.gmail.com> <53E39635.60608@gmail.com> <CAJE_bqcv6PavTP_-EM-FMwD1hVrsqnfmWaCceZQshsxXNVr=4w@mail.gmail.com> <5409C1B8.3000101@gmail.com> <EC3A32FA-CE3F-41DC-A7CF-109F87980DE9@gmail.com> <5409D1A0.4040407@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/rshRyJ859AVuWppCP_gPUS9pNE0
Cc: dhcwg <dhcwg@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Sep 2014 16:42:08 -0000


> On Sep 5, 2014, at 8:07 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> 
> Le 05/09/2014 16:24, Ralph Droms a écrit :
>> 
>> On Sep 5, 2014, at 6:59 AM 9/5/14, Alexandru Petrescu
>> <alexandru.petrescu@gmail.com> wrote:
>> 
>>> Le 07/08/2014 18:24, 神明達哉 a écrit :
>>>> At Thu, 07 Aug 2014 17:07:33 +0200, Alexandru Petrescu
>>>> <alexandru.petrescu@gmail.com> wrote:
>>>> 
>>>>> That aside, I wonder why programmers have set that 64 in the
>>>>> kernel data absent a prefix length field in DHCP/RA, if not
>>>>> because of the fact that specifications are lacking.  Were it
>>>>> for DHCPv6 to have a prefix length field for assigned address
>>>>> A, then programmer would be clearer of what to put on that
>>>>> field, I think.
>>>> 
>>>> I guess you're basically re-raising a long standing discussion
>>>> of whether to provide an on-link prefix via DHCPv6.
>>>> 
>>>> My understanding is that we have never reached a consensus on
>>>> this at IETF (consider, for example, how
>>>> http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00
>>>> 
>>>> 
> was discussed and we still don't have any published outcome), so a
>>>> simple rehash of it won't bring us anywhere.  At the very least
>>>> it's safer to discuss it outside the scope of rfc3315bis (because
>>>> otherwise we'll never be able to publish the bis).
>>> 
>>> Jinmei, thanks for the pointer.
>>> 
>>> But I wonder whether there is any draft that talks about how DHCPv6
>>> sends a prefix-length of the assigned IPv6 address, to the Client?
>>> (not Prefix Delegation, but the equivalent of the Prefix Length
>>> field of a PIO of a Router Advertisement)?
>> 
>> According to current published IPv6 standards, there is no prefix
>> length associated with an IPv6 address.  An IPv6 address assigned to
>> an interface in a host is a 128-bit value.   There is no implication
>> that any leftmost bits of an IPv6 address assigned to an interface
>> correspond to any prefixes assigned to a link.
> 
> But in practice if I say "ifconfig add eth0 1::1" it will result in "1::1/128".  That '128' is put in 'prefix length' fields.
> 
> There is a difference between the address being a 128bit value and a prefix length of that value.

I seem to recall having a similar discussion several years ago, in which I argued that the ifconfig syntax and semantics are wrong and that ifconfig should omit the prefix length entirely.  The consensus was that it was too late to fix ifconfig.

I'm hoping someone else might also recall that conversation and confirm or correct my memory...

> 
>> An IPv6 host is made aware of prefix(es) on a link, which it then
>> uses for forwarding decisions, through ND PIOs.
> 
> Also for on-link determination.

Right (I sort of included on-link determination under forwarding)...

> 
>> DHCPv4 includes a subnet mask with the assigned address as a way for
>> a host to infer a prefix assigned to the associated link.
>> 
>> Can you describe how the prefix length associated with an assigned
>> address is used in the kernel code from which you extracted the
>> snippet below?
> 
> The snippet is from DHCPv6 client code, not from kernel code.  It is that line which makes subsequently that the address assigned on the interface has a prefix-length 64.

Ok, but there is still the question of why the API in the code snippet includes a prefix length and...
> 
> For the kernel part, I would go as far as to say that this highly-used kernel code is not in line with the standards:
> linux/.../if_inet6.h:
>> struct inet6_ifaddr {
>> 43    struct in6_addr    addr;
>> 44    __u32    prefix_len;
> 
> This is the structure which defines addresses on interfaces.  The very fact that the prefix-len is an integer (and not a pointer, which could be nil) means that every address assigned on an interface must have a prefix length.

... how is the prefix_len component of the struct used in the kernel?

> 
> This concept is very different than saying that an address may have no prefix length.
> 
> Alex
> 
>> 
>>> 
>>> Alex
>>> 
>>>> } else { /* Current practice is that all subnets are /64's, but *
>>>> some suspect this may not be permanent. */ client_envadd(client,
>>>> prefix, "ip6_prefixlen", "%d", 64);
>>> ^ make this variable.
>>> 
>>>> 
>>>> -- JINMEI, Tatuya
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>