Subject: Re: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-01.txt

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:03:22 +0200

Hi,

This draft defines the term 'prefix length' but it never uses it.  Not
'prefix-length' either.

page 10:
> prefix length             The number of bits in a prefix.

This should be corrected: either one doesn't define it, or one uses it.

One example reason is the following.

I am trying to find a field containing the prefix length of an assigned
address, in a DHCP exchange (IPv4's 'subnet mask') - is it present or
not?  Should it or not?   The wireshark dump does not expose any field
as "prefix length". (dump available upon request).  Searching the term
'prefix length' in the draft issues precisely one hit - the definition.

That DHCP exchange results in the Host assigning a prefix length 64 on
the address on the interface: I am not sure whether it does so because
DHCP tells it so, or otherwise the programmer thought - as often was the
case in other contexts - that the 64 prefix length is something that
should always be there.

There is no advertised prefix on the link (there is an RA but w/o RIO).

Alex

Le 19/05/2014 17:16, Bernie Volz (volz) a écrit :
> The dhcpv6bis team is pleased to have published a revision of
> RFC3315bis work.
>
> This version of the draft: 1. Incorporates the RFC3315 Errata. 2.
> Incorporates the changes made to RFC3315 by other RFCs. 3. Addresses
> other issues raised via email to the original authors or the
> dhcpv6bis team or in other documents (such as ​
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01).
>
> This mostly covers the Milestone A (apply before merge) tickets -
> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most of the
> tickets resolved are at the bottom in the "A easy, apply before
> merge" category).
>
> This version of the draft does NOT yet cover the merge from RFC 3633
> (and RFC 3736), though you find a few instances where that work was
> started. Adding this material is the next major goal.
>
> We would appreciate any reviews people can do on this draft - please
> provide comments on what needs to be fixed or you feel is not an
> appropriate change! (Send mail to [email-masked]).

>
> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01
> Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01
>
> - Bernie (for the dhcpv6bis team)
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Monday, May 19, 2014 11:03 AM
> To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); Tomek
> Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael C.
> Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko (ayourtch);
> Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; Michael Richardson;
> Ted Lemon Subject: New Version Notification for
> draft-dhcwg-dhc-rfc3315bis-01.txt
>
>
> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has been
> successfully submitted by Bernie Volz and posted to the IETF
> repository.
>
> Name:		draft-dhcwg-dhc-rfc3315bis Revision:	01 Title:		Dynamic Host
> Configuration Protocol for IPv6 (DHCPv6) bis Document date:
> 2014-05-19 Group:		Individual Submission Pages:		108 URL:
> http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt
>
>
>
Status:         https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/
> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01
> Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01
>
> Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP)
> enables DHCP servers to pass configuration parameters such as IPv6
> network addresses to IPv6 nodes.  It offers the capability of
> automatic allocation of reusable network addresses and additional
> configuration flexibility.  This protocol is a stateful counterpart
> to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be
> used separately or concurrently with the latter to obtain
> configuration parameters.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:12:36 +0200

Ok, so sorry, yes, the 'prefix-length' term is present in draft-3315 -02.

Still, I am still wondering: does DHCPv6 assign a prefix length which 
tags an address? (not prefix delegation).

Or is the presence of /64 on computers running DHCP a pure invention of 
the programmer?

Alex

Le 07/08/2014 16:03, Alexandru Petrescu a écrit :
> Status:
> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Aug 2014 10:35:31 -0400

On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu <[email-masked]> wrote:

> Still, I am still wondering: does DHCPv6 assign a prefix length which tags an address? (not prefix delegation).

Assuming you mean "128-bit IPv6 address", the answer is "no".

> 
> Or is the presence of /64 on computers running DHCP a pure invention of the programmer?

I don't understand your question.  There is no "prefix length" associated with an address.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:46:47 +0200

Le 07/08/2014 16:35, Ralph Droms a écrit :
>> Still, I am still wondering: does DHCPv6 assign a prefix length
>> which tags an address? (not prefix delegation).
>

I am facing this computer which receives an RA without prefix length (no 
Prefix Information OPtion, just helps set the default route), and then 
runs DHCPv6 to obtain an IPv6 address A, and the resolver's address.

After these messages, the computer configures the IPv6 address as A/64.

I wonder where from comes that /64?  Is DHCPv6 telling it it should be a 
/64?

Alex

>>> This draft defines the term 'prefix length' but it never uses it.
>>> Not 'prefix-length' either.
>>>
>>> page 10:
>>> I am trying to find a field containing the prefix length of an
>>> assigned address, in a DHCP exchange (IPv4's 'subnet mask') - is
>>> it present or not?  Should it or not?   The wireshark dump does
>>> not expose any field as "prefix length". (dump available upon
>>> request).  Searching the term 'prefix length' in the draft issues
>>> precisely one hit - the definition.
>>>
>>> That DHCP exchange results in the Host assigning a prefix length
>>> 64 on the address on the interface: I am not sure whether it does
>>> so because DHCP tells it so, or otherwise the programmer thought
>>> - as often was the case in other contexts - that the 64 prefix
>>> length is something that should always be there.
>>>
>>>> This version of the draft: 1. Incorporates the RFC3315 Errata.
>>>> 2. Incorporates the changes made to RFC3315 by other RFCs. 3.
>>>> Addresses other issues raised via email to the original authors
>>>> or the dhcpv6bis team or in other documents (such as ​
>>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most
>>>> of the tickets resolved are at the bottom in the "A easy, apply
>>>> before merge" category).
>>>>
>>>> This version of the draft does NOT yet cover the merge from RFC
>>>> 3633 (and RFC 3736), though you find a few instances where that
>>>> work was started. Adding this material is the next major goal.
>>>>
>>>> We would appreciate any reviews people can do on this draft -
>>>> please provide comments on what needs to be fixed or you feel
>>>> is not an appropriate change! (Send mail to
>>>> [email-masked]).
>>>
>>>
>>>>
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff:
>>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01
>>>>
>>>> [mailto:[email-masked]] Sent: Monday, May 19, 2014
>>>> 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz);
>>>> Tomek Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael
>>>> C. Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko
>>>> (ayourtch); Tomek Mrugalski; Sheng Jiang; Marcin Siodelski;
>>>> Michael Richardson; Ted Lemon Subject: New Version Notification
>>>> for draft-dhcwg-dhc-rfc3315bis-01.txt
>>>>
>>>>
>>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has
>>>> been successfully submitted by Bernie Volz and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-dhcwg-dhc-rfc3315bis Revision:    01 Title:
>>>> Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis
>>>> Document date: 2014-05-19 Group:        Individual Submission
>>>> Pages:        108 URL:
Status:
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff:
>>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01
>>>>
>>>> Abstract: The Dynamic Host Configuration Protocol for IPv6
>>>> (DHCP) enables DHCP servers to pass configuration parameters
>>>> such as IPv6 network addresses to IPv6 nodes.  It offers the
>>>> capability of automatic allocation of reusable network
>>>> addresses and additional configuration flexibility.  This
>>>> protocol is a stateful counterpart to "IPv6 Stateless Address
>>>> Autoconfiguration" (RFC 4862), and can be used separately or
>>>> concurrently with the latter to obtain configuration
>>>> parameters.
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time
>>>> of submission until the htmlized version and diff are available
>>>> at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>> _______________________________________________ dhcwg mailing
>>>> list [email-masked]
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Aug 2014 16:54:08 +0200

Alex,

> 
> I am facing this computer which receives an RA without prefix length (no Prefix Information OPtion, just helps set the default route), and then runs DHCPv6 to obtain an IPv6 address A, and the resolver's address.
> 
> I wonder where from comes that /64?  Is DHCPv6 telling it it should be a /64?

then computer is buggy. RFC5942.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Aug 2014 10:57:23 -0400

> I wonder where from comes that /64?  Is DHCPv6 telling it it should be a /64?

In my opinion, it is a bug in the network stack.  The DHCPv6 server has no knowledge of prefix(es) that might or might not be assigned on the link to which that interface is attached.  The IPv6 address from DHCPv6 has no associated prefix length.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:59:30 +0200

> then computer is buggy. RFC5942.

I have never seen a computer which says 'nil' next to an address when 
you type ifconfig.  There's always a '/' some-figure there, like /64, 
/128, /0, etc.

It's as if you said there is no subnet mask in IPv4.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Aug 2014 08:01:17 -0700

At Thu, 07 Aug 2014 16:46:47 +0200,

> I wonder where from comes that /64?  Is DHCPv6 telling it it should be a

Perhaps the behavior described in Section 3 of
http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 ?

--
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 17:02:08 +0200

Le 07/08/2014 16:57, Ralph Droms a écrit :
>>>> Still, I am still wondering: does DHCPv6 assign a prefix
>>>> length which tags an address? (not prefix delegation).
>>>
>> I am facing this computer which receives an RA without prefix
>> length (no Prefix Information OPtion, just helps set the default
>> route), and then runs DHCPv6 to obtain an IPv6 address A, and the
>> resolver's address.
>>
> In my opinion, it is a bug in the network stack.  The DHCPv6 server
> has no knowledge of prefix(es) that might or might not be assigned on
> the link to which that interface is attached.  The IPv6 address from
> DHCPv6 has no associated prefix length.

I tend to agree, but I guess we have room for interpretation whenever 
'nothing' is discussed.

I guess it would be better if ifconfig said A/128 after a non-PIO-RA 
DHCP exchange, rather than saying 'nothing', or 'nil'.

It shouldn't be saying '64' in any case, I think we agree with that.

Alex

>>>>> This draft defines the term 'prefix length' but it never uses
>>>>> it. Not 'prefix-length' either.
>>>>>
>>>>> page 10:
>>>>> I am trying to find a field containing the prefix length of
>>>>> an assigned address, in a DHCP exchange (IPv4's 'subnet
>>>>> mask') - is it present or not?  Should it or not?   The
>>>>> wireshark dump does not expose any field as "prefix length".
>>>>> (dump available upon request).  Searching the term 'prefix
>>>>> length' in the draft issues precisely one hit - the
>>>>> definition.
>>>>>
>>>>> That DHCP exchange results in the Host assigning a prefix
>>>>> length 64 on the address on the interface: I am not sure
>>>>> whether it does so because DHCP tells it so, or otherwise the
>>>>> programmer thought - as often was the case in other contexts
>>>>> - that the 64 prefix length is something that should always
>>>>> be there.
>>>>>
>>>>>> The dhcpv6bis team is pleased to have published a revision
>>>>>> of RFC3315bis work.
>>>>>>
>>>>>> This version of the draft: 1. Incorporates the RFC3315
>>>>>> Errata. 2. Incorporates the changes made to RFC3315 by
>>>>>> other RFCs. 3. Addresses other issues raised via email to
>>>>>> the original authors or the dhcpv6bis team or in other
>>>>>> documents (such as ​
>>>>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6
>>>>>> (most of the tickets resolved are at the bottom in the "A
>>>>>> easy, apply before merge" category).
>>>>>>
>>>>>> This version of the draft does NOT yet cover the merge from
>>>>>> RFC 3633 (and RFC 3736), though you find a few instances
>>>>>> where that work was started. Adding this material is the
>>>>>> next major goal.
>>>>>>
>>>>>> We would appreciate any reviews people can do on this draft
>>>>>> - please provide comments on what needs to be fixed or you
>>>>>> feel is not an appropriate change! (Send mail to
>>>>>> [email-masked]).
>>>>>
>>>>>
>>>>>>
>>>>>> Htmlized:
>>>>>> [mailto:[email-masked]] Sent: Monday, May 19,
>>>>>> 2014 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie
>>>>>> Volz (volz); Tomek Mrugalski; Bernie Volz (volz); Marcin
>>>>>> Siodelski; Michael C. Richardson; Sheng Jiang; Ted Lemon;
>>>>>> Andrew Yourtchenko (ayourtch); Tomek Mrugalski; Sheng
>>>>>> Jiang; Marcin Siodelski; Michael Richardson; Ted Lemon
>>>>>> Subject: New Version Notification for
>>>>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt
>>>>>> has been successfully submitted by Bernie Volz and posted
>>>>>> to the IETF repository.
>>>>>>
>>>>>> Name:        draft-dhcwg-dhc-rfc3315bis Revision:    01
>>>>>> Title: Dynamic Host Configuration Protocol for IPv6
>>>>>> (DHCPv6) bis Document date: 2014-05-19 Group:
>>>>>> Individual Submission Pages:        108 URL:
>>>>>> (DHCP) enables DHCP servers to pass configuration
>>>>>> parameters such as IPv6 network addresses to IPv6 nodes.
>>>>>> It offers the capability of automatic allocation of
>>>>>> reusable network addresses and additional configuration
>>>>>> flexibility.  This protocol is a stateful counterpart to
>>>>>> "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and
>>>>>> can be used separately or concurrently with the latter to
>>>>>> obtain configuration parameters.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the
>>>>>> time of submission until the htmlized version and diff are
>>>>>> available at tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>> _______________________________________________ dhcwg
>>>>>> mailing list [email-masked]
>>>>> _______________________________________________ dhcwg
>>>>> mailing list [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Aug 2014 11:05:28 -0400

On Aug 7, 2014, at 10:59 AM 8/7/14, Alexandru Petrescu <[email-masked]> wrote:

> I have never seen a computer which says 'nil' next to an address when you type ifconfig.  There's always a '/' some-figure there, like /64, /128, /0, etc.

Were it up to me, I would report the addresses without a prefix length, and report all known assigned prefixes separately.

> It's as if you said there is no subnet mask in IPv4.

The subnet mask in IPv4 is used to infer prefixes assigned to a link.  IPv6 explicitly assigns links to prefixes and announces those prefixes through RAs.  Because of the explicit announcements, there is no need to imply prefixes through subnet masks.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 17:07:33 +0200

> http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 ?

Thanks for pointing out that section.  I am surprised to discover it, 
although I am a co-author of this draft.  As I read it I think it is 
very true.

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.

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Aug 2014 17:10:11 +0200

> 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.

address assignment and onlink determination are two quite separate things.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Aug 2014 11:10:10 -0400

On Aug 7, 2014, at 11:02 AM 8/7/14, Alexandru Petrescu <[email-masked]> wrote:

> I tend to agree, but I guess we have room for interpretation whenever 'nothing' is discussed.
> 
> I guess it would be better if ifconfig said A/128 after a non-PIO-RA DHCP exchange, rather than saying 'nothing', or 'nil'.
> 

See my previous e-mail.  In my opinion, a list of addresses with no prefix length and a list of prefixes with prefix lengths would be most correct.

In the case you described, with no prefixes announced in RAs, the host has no knowledge of on-link prefixes and would simply list the assigned addresses.  That host will forward all traffic (other than link-local) to the default router.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Aug 2014 11:11:45 -0400

On Aug 7, 2014, at 11:07 AM 8/7/14, Alexandru Petrescu <[email-masked]> wrote:

> Thanks for pointing out that section.  I am surprised to discover it, although I am a co-author of this draft.  As I read it I think it is very true.
> 

Does anyone know what the field is used for?  The prefix length on the prefix should be used for forwarding rules, not any length on the address, right?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 17:15:03 +0200

Le 07/08/2014 17:05, Ralph Droms a écrit :
>>>> length (no Prefix Information OPtion, just helps set the
>>>> default route), and then runs DHCPv6 to obtain an IPv6 address
>>>> A, and the resolver's address.
>>>>
>> I have never seen a computer which says 'nil' next to an address
>> when you type ifconfig.  There's always a '/' some-figure there,
>> like /64, /128, /0, etc.
>
> Were it up to me, I would report the addresses without a prefix
> length, and report all known assigned prefixes separately.

Sounds reasonable.  And thus the relationship between the assigned 
address and the prefix valid on that link would still be variable (i.e. 
the address is part of that prefix, or not).

> The subnet mask in IPv4 is used to infer prefixes assigned to a link.
> IPv6 explicitly assigns links to prefixes and announces those
> prefixes through RAs.

Yes, and no: prefixes are not always announced on links.  The PIO 
(prefix information option) is not mandatory in RAs, I guess, because of 
the name 'option'.  I just received many RAs without any PIO.  This is 
on a cellular link.  The RA just gives its src address (to use as 
default route) and the MTU (such as to not trigger fragmentation).

Alex

> Because of the explicit announcements, there
> is no need to imply prefixes through subnet masks.
>
>>
>> Alex
>>
>>>
>>> cheers, Ole
>>>
>>>
>>>
>>
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 17:20:25 +0200

Le 07/08/2014 17:11, Ralph Droms a écrit :
>>> At Thu, 07 Aug 2014 16:46:47 +0200, Alexandru Petrescu
>>> <[email-masked]> wrote:
>>>
>> Thanks for pointing out that section.  I am surprised to discover
>> it, although I am a co-author of this draft.  As I read it I think
>> it is very true.
>>
>> 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.
>
> Does anyone know what the field is used for?

It helps extract from the address the prefix and its length, and then 
insert a routing table entry.  This becomes a 'Connected' route in some 
manufacturer's parlance.  It is a '*' route in linux (no next-hop).  On 
all address of it one has to run ND to find its MAC address, otherwise 
use the default route.

> The prefix length on the prefix should be used for forwarding rules,
> not any length on the address, right?

YEs, but forwarding is preceded by ND: ND needs the MAC address of the 
default route next-hop, otherwise ND needs the MAC address of the dst in 
the packet.

This has to do with the order in which NCache is searched and the 
routing table is searched.  The NC is using an exact match search, the 
other is longest match...

Sigh about too much detail ...

Alex

>>> -- JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Aug 2014 09:24:32 -0700

At Thu, 07 Aug 2014 17:07:33 +0200,

> 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, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 21:52:44 +0200

> we'll never be able to publish the bis).

Yesm this is outside the rfc3315-bis discussion.

The only minor nit is that it should define "prefix length" and use it, 
not use "prefix-length".

Alex