Subject: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message (was: draft-dhcwg-dhc-rfc3315bis-02.txt)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Sep 2014 15:59:20 +0200

Le 07/08/2014 18:24, 神明達哉 a écrit :
> At Thu, 07 Aug 2014 17:07:33 +0200,
> Alexandru Petrescu <[email-masked]> 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)?

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 5 Sep 2014 07:24:18 -0700

On Sep 5, 2014, at 6:59 AM 9/5/14, Alexandru Petrescu <[email-masked]> wrote:

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

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

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?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Sep 2014 17:07:12 +0200

Le 05/09/2014 16:24, Ralph Droms a écrit :
>>> At Thu, 07 Aug 2014 17:07:33 +0200, Alexandru Petrescu
>>> <[email-masked]> 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
>>> 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).
>>
>> 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.

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

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

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.

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 5 Sep 2014 09:42:04 -0700

> On Sep 5, 2014, at 8:07 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> 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...

> Also for on-link determination.

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Sep 2014 19:05:27 +0200

Le 05/09/2014 18:42, Ralph Droms a écrit :
>>>>>> 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
>>>>> 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).
>>>>
>>>> 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.
>>
> 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.
>

WEll, your discussion was maybe at a time when ifconfig required a 
prefix-len parameter.  It no longer does.  But ifconfig introduces a 
'128' when the user does not specify that parameter.  BEcause that 
prefix-length is mandatory in the structure.

>>> An IPv6 host is made aware of prefix(es) on a link, which it
>>> then uses for forwarding decisions, through ND PIOs.
>>
>>> 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.
>
>> 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.
>

Good question, let's see.

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 5 Sep 2014 11:28:22 -0700

At Fri, 5 Sep 2014 09:42:04 -0700,

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

I don't remember the discussion, but in the case of an admin utility
like ifconfig, I personally think it makes sense to allow the user to
specify the address and on-link prefix at the same time.  In practice,
if you manually configure an address it would be quite common that a
prefix (normally /64) derived from the address is to be considered
on-link.  Configuring a PC-based router is probably one common use
case like this.  And, if this makes sense, I think it makes sense to
keep the UI consistent for both IPv4 and IPv6, if only for POLA.

I can imagine a counter argument: we might say this is rather bad in
that it helps proliferation of the naive assumption of specific
on-link prefixes (again, often /64).  And I see a point in that
argument, too.  But it doesn't seem to be something on which we can
declare one side is definitely right/wrong.

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

I don't know much about the Linux kernel, but the situation is quite
similar in BSDs.  This is an example from the FreeBSD kernel code that
is also used as a system call argument:

struct  in6_aliasreq {
        char    ifra_name[IFNAMSIZ];
        struct  sockaddr_in6 ifra_addr;
        struct  sockaddr_in6 ifra_dstaddr;
        struct  sockaddr_in6 ifra_prefixmask;
        int     ifra_flags;
        struct in6_addrlifetime ifra_lifetime;
        int     ifra_vhid;
};

Both address and prefix "mask" are to be specified to configure an
address.  (Although I don't remember) this may be a part of the
possible "too late" discussion.  Architecturally and in hindsight, the
argument structure should have been separated into address
configuration and prefix configuration (and for that matter, prefix
should have been specified as a bit length, not a bit mask, for IPv6).
But the API had probably been exposed too long that we couldn't make
it "cleaner" without heavily breaking compatibility.

Anyway, within the BSD kernel, addresses are prefixes are managed
separately, so it should be more architecturally correct than you
might think from the API spec.  The experiments shown in
draft-ietf-6man-why64 prove that, and I guess that's generally the
same for other host implementations according to the experimental
results.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 08 Sep 2014 21:01:44 -0300

Hi, Jinmei,

On 09/05/2014 03:28 PM, 神明達哉 wrote:
>> that ifconfig should omit the prefix length entirely.  The
>> consensus was that it was too late to fix ifconfig.
>> 
> like ifconfig, I personally think it makes sense to allow the user
> to specify the address and on-link prefix at the same time.

+1

> on-link prefixes (again, often /64).

Well, is that really naive? -- i.e.,
http://tools.ietf.org/html/draft-ietf-6man-why64

(Whether ths being "casted into stone" s a good thing (or not) is, of
course, a different question)

> similar in BSDs.  This is an example from the FreeBSD kernel code
> that is also used as a system call argument:
> 
> struct  in6_aliasreq { char    ifra_name[IFNAMSIZ]; struct
> sockaddr_in6 ifra_addr; struct  sockaddr_in6 ifra_dstaddr; struct
> sockaddr_in6 ifra_prefixmask; int     ifra_flags; struct
> in6_addrlifetime ifra_lifetime; int     ifra_vhid; };
> 
> possible "too late" discussion.  Architecturally and in hindsight,
> the argument structure should have been separated into address 

mmm... why?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Sep 2014 11:13:59 -0400

>> to specify the address and on-link prefix at the same time.

Working again from unreliable memory, I recall this point was raised (likely by Jinmei-San) during the previous discussion of this topic.

I can see the rationale behind specifying an on-link prefix with the address ... my personal preference would be to keep them separate to avoid confusion (but nobody asked me).

> course, a different question)

Jinmei-san has made exactly my argument - better to keep the concepts separate and avoid the /64 assumption.  I'd add that I think it's important to keep in mind that IPv6 is "different" from IPv6 in that an address taken by itself never really has an associated prefix length.
>> should have been specified as a bit length, not a bit mask, for

...and where is that "mask" used elsewhere in the kernel.

I agree that it's "too late" to fix it (at least, I personally don't have the energy to take on the challenge), but perhaps some comments might be added to the code regarding the purpose of the "mask"?

- Ralph

---

From: Simon Hobson <[email-masked]>
Date: Tue, 9 Sep 2014 17:14:37 +0100

Perhaps it's just me struggling to break out from "IPv4 thinking", but I struggle to see what use an IPv6 address is without explicitly or implicitly a prefix length to go with it. Unless you restrict yourself to "on link" communications, at some point you need to work out whether, when using that address, the other address you wish to communicate with is local (on link) or remote.

I know there's the arguments that in many large organisations, the routers and DHCP servers are managed by different groups - but the groups still need to agree on what the prefixes and prefix lengths are for any network !

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Sep 2014 09:56:24 -0700

At Mon, 08 Sep 2014 21:01:44 -0300,

> course, a different question)

Interestingly, I had that particular draft in my mind when I made this
comment:-)  My understanding of the draft is that while it generally
lists cases for sticking to the commonly-used prefix length (= 64
bits), it also carefully notes that architecturally the magic number
of 64 is not a fixed constant.  So, one would be "naive", for example,
if they develop a router that can never handle prefixes whose length
is longer than 64 bits, even in some kind of "slow path".

But I guess that's just a matter of subtle meaning of the word
"naive", and (I hope) we are generally on the same page.

> > should have been specified as a bit length, not a bit mask, for

At least as for the prefix length, because a "network mask" must be
contiguous in IPv6.  If the API accepts a bit mask as the
representation of a prefix, it'll need to perform additional
validation.

As for the separation of address configuration and prefix
configuration, it may rather be a matter of preference/opinion, but I
thought it's architecturally better since we'd need to have an
API to just specify an on-link prefix (just as the UI equivalent of
receiving an RA prefix information option with A bit being off and L
bit on).  In the case of BSD variants there's actually such an
interface via the routing socket, but IMO that's not really
intuitive.  And, once we have a prefix configuration API, it'll be
just redundant to also have it as part of the address configuration
API.  In general, this level of API is quite low level and often
protocol specific.  So, IMO, it's a good thing to enforce
"architecturally-correct" thinking through the API design.

But I don't insist that's the only correct way of seeing this.  And,
in any case, I'm not intending to propose revising the API (or adding
a new one) that way.  Hence "hindsight".

--
JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Sep 2014 16:35:18 -0400

Simon ...

> Perhaps it's just me struggling to break out from "IPv4 thinking", but I struggle to see what use an IPv6 address is without explicitly or implicitly a prefix length to go with it. Unless you restr…

The way I think about IPv6 addresses, prefixes and prefix length is that the prefix length is associated with the prefix, not the address.  In typical usage, the prefix is matched against the leftmost bits of the address corresponding to the prefix length and a match indicates the address is in the subnet defined by the prefix.

In my opinion, the "IPv4 thinking" is the association of a prefix length with an address, implicitly defining a prefix; for example, an on-link prefix derived from an assigned address.  In IPv6, prefixes and addresses are more clearly delineated and the prefix lengths are associated explicitly with the prefixes.

> I know there's the arguments that in many large organisations, the routers and DHCP servers are managed by different groups - but the groups still need to agree on what the prefixes and prefix leng…

Yes, there need to be agreement - and the agreed upon conventions are typically expressed in ND PIOs, which give the lengths for the advertised prefixes.

- Ralph

> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 10 Sep 2014 03:27:52 +0000

Perhaps it has been raised already in this thread, but there is again a draft on using DHCPv6 for some ND aspects:

http://datatracker.ietf.org/doc/draft-sarikaya-dhc-dhcpv6-raoptions-sadr

I am not advocating this work, just pointing out it is yet another attempt to distribute prefix information via DHCPv6.

There already has been an email discussion with the author that this work is probably best done in another WG (if at all).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Tuesday, September 09, 2014 4:35 PM
To: Simon Hobson
Cc: dhcwg
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

Simon ...

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 12:02:31 +0200

Hi Ralph,

I have a comment.

Le 09/09/2014 17:13, Ralph Droms a écrit :
>>>> 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 don't remember the discussion, but in the case of an admin
>>> utility like ifconfig, I personally think it makes sense to allow
>>> the user to specify the address and on-link prefix at the same
>>> time.
>>
>> +1
>
> Working again from unreliable memory, I recall this point was raised
> (likely by Jinmei-San) during the previous discussion of this topic.
>
> I can see the rationale behind specifying an on-link prefix with the
> address ... my personal preference would be to keep them separate to
> avoid confusion (but nobody asked me).
>
>>
>>
>>
>>> I can imagine a counter argument: we might say this is rather bad
>>> in that it helps proliferation of the naive assumption of
>>> specific on-link prefixes (again, often /64).
>>
>> (Whether ths being "casted into stone" s a good thing (or not) is,
>> of course, a different question)
>
> Jinmei-san has made exactly my argument - better to keep the concepts
> separate and avoid the /64 assumption.  I'd add that I think it's
> important to keep in mind that IPv6 is "different" from IPv6 in that
> an address taken by itself never really has an associated prefix
> length.

I do agree than in IPv6 an address is a 128bit value and that's it.

But in implementation there's always a prefix length associated to it.

We discussed how new ifconfig accepts the absence of a prefix-len value 
but silently puts a 64 in there.

Windows 7 has this way of configuring manually an IPv6 address and the 
prefix length is mandatory.  Not sure about Windows 8 though.

Alex

>>
>>
>>
>>> I don't know much about the Linux kernel, but the situation is
>>> quite similar in BSDs.  This is an example from the FreeBSD
>>> kernel code that is also used as a system call argument:
>>>
>>> sockaddr_in6 ifra_addr; struct  sockaddr_in6 ifra_dstaddr;
>>> struct sockaddr_in6 ifra_prefixmask; int     ifra_flags; struct
>>> Both address and prefix "mask" are to be specified to configure
>>> an address.  (Although I don't remember) this may be a part of
>>> the possible "too late" discussion.  Architecturally and in
>>> hindsight, the argument structure should have been separated into
>>> address configuration and prefix configuration (and for that
>>> matter, prefix should have been specified as a bit length, not a
>>> bit mask, for IPv6).
>>
>> mmm... why?
>
> I agree that it's "too late" to fix it (at least, I personally don't
> have the energy to take on the challenge), but perhaps some comments
> might be added to the code regarding the purpose of the "mask"?
>
> - Ralph
>
>>
>> Thanks!
>>
>> Best regards, -- Fernando Gont e-mail: [email-masked] ||
>> [email-masked] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
>> 3945 96EE A9EF D076 FFF1
>>
>>
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 12:07:13 +0200

Le 09/09/2014 18:56, 神明達哉 a écrit :
> contiguous in IPv6.

I agree.  In IPv4 it is contiguous as well.

The means of a mask is rather holes in strings, rather than a contiguous 
string.

That said, and I sound pompous, routing algorithms could be designed 
over prefixes as holed strings.  They could save bits in the addresses, 
for example mask-out the inner fffe of Ethernet IIDs.

Alex

>  If the API accepts a bit mask as the

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 11:31:52 +0100

> But in implementation there's always a prefix length associated to it.

AFAICS, what seems to be being debated is :
Should we have a separate table of prefixes and prefix lengths kept separate from the table of addresses ?
Consensus appears to be saying "yes, that's how it should be".

So any system using an address needs to lookup the prefix associated with that address in order to get the prefix length - rather than have it stored alongside the address itself.
I can see that it's (in data terms) "cleaner" as it removes duplication. But is it "cleaner" overall to add an extra redirection to get the information ? Not to mention the "management overhead" of having to check every time an address is removed to see if the prefix is still in use by another address (in which case keep it), or not (in which case remove it ?)

Just seems to be "purist for the sake of being pure" when (IMO) it doesn't appear to make sense overall.

Or have I got it all wrong again ?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Sep 2014 10:57:02 +0000

Few years back, in the 6man mailer, we have discussed this issue.  If the router has different prefix length than what the DHCPv6 server assigned to the client, who wins?

Hemant

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, September 09, 2014 11:28 PM
To: Ralph Droms; Simon Hobson
Cc: dhcwg
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Tuesday, September 09, 2014 4:35 PM
To: Simon Hobson
Cc: dhcwg
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

Simon ...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 07:00:03 -0400

> Or have I got it all wrong again ?

I've worked on the code for an IPv6 stack, but I'm not familiar with the internals of any of the popular commercial stacks, so I'll ask: when does an implementation need to have the prefix length information?  My understanding is that "prefix length" only makes sense in the context of a prefix, so I'm curious about when it would be used in an implementation.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 07:03:02 -0400

> But in implementation there's always a prefix length associated to it.

OK, so it seems to me that the prefix length associated with an address is an implementation artifact and not an inherent property of IPv6.

> 
> We discussed how new ifconfig accepts the absence of a prefix-len value but silently puts a 64 in there.
> 
> Windows 7 has this way of configuring manually an IPv6 address and the prefix length is mandatory.  Not sure about Windows 8 though.

How is the prefix length associated with an address actually used in the implementation?  I'm curious about whether there is some aspect of the prefix length that I don't understand or if the inclusion of the prefix length with an address is strictly a hold-over from IPv4 implementations...

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Sep 2014 11:14:33 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Wednesday, September 10, 2014 7:03 AM
To: Alexandru Petrescu
Cc: dhcwg; Fernando Gont; 神明達哉
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

>OK, so it seems to me that the prefix length associated with an address is an implementation artifact and not an inherent property of IPv6.

Right,  See RFC 5942, where we made an explicit mention of the fact because some incorrect host implementations assumed the prefix length to be 64.

[Any assigned address on an interface should initially be considered as having no internal structure as shown in [RFC4291].]

Hemant

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 12:40:03 +0100

> Few years back, in the 6man mailer, we have discussed this issue.  If the router has different prefix length than what the DHCPv6 server assigned to the client, who wins?

No-one - your network is broken, just the same as if the DHCP server used the right prefix length but got the prefix (or equivalent part of the address depending on how you want to talk about it) wrong.
Which is why I mentioned earlier - not giving out the prefix from a DHCP6 server doesn't mean you don't still need to get the server and router guys to agree on what the network looks like.

> I've worked on the code for an IPv6 stack, but I'm not familiar with the internals of any of the popular commercial stacks, so I'll ask: when does an implementation need to have the prefix length i…

Surely, when "a device" needs to send a packet - it needs to know if it is to a local neighbour which it'll need to find out about via neighbour discovery), or if it's remote in which case it needs to decide which of the available router(s) to send it via. Given an IP address, it needs to know how many bits of that are prefix, and how many are device address - hence it needs to know the prefix length.

So the prefix length is either stored with the address assigned to an interface, or it's stored in a separate table and the code needs to do a table search to get the prefix length it needs in order to send packets from whatever address the sending service is trying to use.

Or am I missing some "magic" where the device (or specifically the packet sending code) doesn't need to know where the split between prefix and host part of an address is in order to make the on-link vs router decision ?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Sep 2014 12:03:08 +0000

The analysis below is an ipv4 perspective looking at ipv6.  Please read RFC 5942 and see rules for on-link determination.  Only a PIO in the RA or a Redirect message are means to signal a prefix as on-link.   If the RA does not include a PIO, all destinations are off-link.  

Hemant

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 14:19:10 +0200

Le 10/09/2014 12:31, Simon Hobson a écrit :
> AFAICS, what seems to be being debated is : Should we have a
> separate table of prefixes and prefix lengths kept separate from the
> table of addresses ? Consensus appears to be saying "yes, that's how
> it should be".
>
> So any system using an address needs to lookup the prefix associated
> with that address in order to get the prefix length

That may prove not easy to do.  It is unspecified (how to match
an address to a prefix may be assumed to be longest-prefix match but
what if the found prefix differs from the temp-prefix which just
matched, and how about the default).

> - rather than have it stored alongside the address itself. I can see
> that it's (in data terms) "cleaner" as it removes duplication. But is
> it "cleaner" overall to add an extra redirection to get the
> information ? Not to mention the "management overhead" of having to
> check every time an address is removed to see if the prefix is still
> in use by another address (in which case keep it), or not (in which
> case remove it ?)

I tend to agree.

> doesn't appear to make sense overall.

In a sense yes, it's a quest of purity, maybe too pedantic(?)

But I found a practical case of an IPv6/4G cellular connection where the 
RA does not contain the prefix neither its length, and DHCPv6 gives the 
address.  What should the DHCPv6 implementation put in that prefix 
length field of its kernel IPv6 stack?  128?  64?  Because it must put 
something.

Until now, putting 64 in that local prefix-length field, just out of the 
blue, seems a safe bet - nothing breaks, the communication works.

Alex

> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 13:38:12 +0100

> The analysis below is an ipv4 perspective looking at ipv6.  Please read RFC 5942 and see rules for on-link determination.  Only a PIO in the RA or a Redirect message are means to signal a prefix as…

Thanks, it makes more sense now !
Trouble is, it's the first time I've come across that information - and I at least have an interest in working with IPv6. I can't help thinking that an awful lot of trouble is brewing away - heck, I keep coming across IT professionals with no grasp of IPv4 basics :(

Having had the "fun" of how stateful firewalls screw up networks that rely on redirects, I just hope some of the vendors have read that RFC. Why do I have a sense of foreboding ...

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 14:41:59 +0200

Le 10/09/2014 13:00, Ralph Droms a écrit :
>> separate table of prefixes and prefix lengths kept separate from
>> the table of addresses ? Consensus appears to be saying "yes,
>> that's how it should be".
>>
>> So any system using an address needs to lookup the prefix
>> associated with that address in order to get the prefix length -
>> rather than have it stored alongside the address itself. I can see
>> that it's (in data terms) "cleaner" as it removes duplication. But
>> is it "cleaner" overall to add an extra redirection to get the
>> check every time an address is removed to see if the prefix is
>> still in use by another address (in which case keep it), or not (in
>> which case remove it ?)
>>
> I've worked on the code for an IPv6 stack, but I'm not familiar with
> the internals of any of the popular commercial stacks, so I'll ask:
> when does an implementation need to have the prefix length
> information?

The question is right.

A simple answer is to say that it is just like in IPv4.  The same 
reasons an IPv4 stack uses the netmask is the reasons why IPv6 stack 
uses it.

If I remember correctly, the prefix length of an address may help to:
- determine which output interface to use for an outgoing packet
- determine whether to ND resolve the address of the dst in the
   outgoing packet or rather look first for a local route to it and
   subsequently resolve the address of a gw. ("on-link determination").

In a Mobile IPv6 stack one needs to tell whether a configured address 
falls within the prefix received in an RA or not.  This is not specified 
how to do, but the most precise is to have the prefix length of the 
address, the prefix length of the prefix, and succeed only if both equal 
bits and equal lengths.

In a PMIPv6 stack one needs to tell whether the src address of a 
received packet falls in a certain prefix.  This works but always 
assumes that 64 magic.

In the SLAAC specification there are some places saying that an address 
configured by SLAAC (which does have a prefix length) must be compared 
against a prefix received in an RA.

But I agree code inspection may ultimately indicate the use - or no need 
- of prefix length of an address.

Alex

   My understanding is that "prefix length" only makes
> sense in the context of a prefix, so I'm curious about when it would
> be used in an implementation.
>
>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 14:49:25 +0200

Le 10/09/2014 14:03, Hemant Singh (shemant) a écrit :
> The analysis below is an ipv4 perspective looking at ipv6.  Please
> read RFC 5942 and see rules for on-link determination.  Only a PIO in
> the RA or a Redirect message are means to signal a prefix as on-link.
> If the RA does not include a PIO, all destinations are off-link.

What if there is no RA?   For example a link made of many Hosts but no 
router sending RA.  Is RFC5942 covering this case?  Because 
implementations are capable of doing it.  For example an IP subnet in a 
vehicle which is disconnected from the Internet.

What if the RA is very rare (every 10minutes) and the sensor node needs 
to send packets as soon as it wakes up and then sleep.  Will it be 
unable to determine who's on-link until receiving an RA?

Alex

>
> Hemant
>
> -----Original Message----- From: dhcwg
> [mailto:[email-masked]] On Behalf Of Simon Hobson Sent:
> Wednesday, September 10, 2014 7:40 AM To: dhcwg Subject: Re: [dhcwg]
> Prefix-length of an assigned address, in a DHCPv6 message
>
>
> Surely, when "a device" needs to send a packet - it needs to know if
> it is to a local neighbour which it'll need to find out about via
> neighbour discovery), or if it's remote in which case it needs to
> decide which of the available router(s) to send it via. Given an IP
> address, it needs to know how many bits of that are prefix, and how
> many are device address - hence it needs to know the prefix length.
>
> So the prefix length is either stored with the address assigned to an
> interface, or it's stored in a separate table and the code needs to
> do a table search to get the prefix length it needs in order to send
> packets from whatever address the sending service is trying to use.
>
> Or am I missing some "magic" where the device (or specifically the
> packet sending code) doesn't need to know where the split between
> prefix and host part of an address is in order to make the on-link vs
> router decision ?
>

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 13:59:11 +0100

Alexandru Petrescu <[email-masked]> wrote:

> What if there is no RA?   For example a link made of many Hosts but no router sending RA.  Is RFC5942 covering this case?  Because implementations are capable of doing it.  For example an IP subnet in a vehicle which is disconnected from the Internet.

Then it only needs link-local addresses which are considered on-link. From teh RFC mentioned :
> In IPv6, by default, a host treats only the link-local prefix as on-link

> What if the RA is very rare (every 10minutes) and the sensor node needs to send packets as soon as it wakes up and then sleep.  Will it be unable to determine who's on-link until receiving an RA?

Presumably it caches it's network config while asleep. Otherwise, when it wakes up then it must reconfigure it's interfaces.
Besides, isn't there a means of soliciting for routers rather than waiting for broadcasts ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 15:10:53 +0200

Le 10/09/2014 14:59, Simon Hobson a écrit :
>> What if there is no RA?   For example a link made of many Hosts but
>> no router sending RA.  Is RFC5942 covering this case?  Because
>> implementations are capable of doing it.  For example an IP subnet
>> in a vehicle which is disconnected from the Internet.
>
> Then it only needs link-local addresses which are considered
> on-link.

YEs and no.

No, in that the Hosts may be multi-interfaced and as such could not
distinguish between them once they're up.   Whose fe80::/10's interface
to put this fe80::1-addressed packet to?

Or otherwise, to which interface to try to resolve the IP address of 
this outgoing packet?

>> What if the RA is very rare (every 10minutes) and the sensor node
>> needs to send packets as soon as it wakes up and then sleep.  Will
>> it be unable to determine who's on-link until receiving an RA?
>
> Presumably it caches it's network config while asleep. Otherwise,
> when it wakes up then it must reconfigure it's interfaces. Besides,
> isn't there a means of soliciting for routers rather than waiting for
> broadcasts ?

YEs, right caching while asleep, or preceding outgoing packets by RS.

But it may look strange to loose the ability to manually configure stuff 
and rely on the automaticity of SLAAC/DHCP (I confess to me it looks 
strange).  In IPv4 there was always the possibility to manually 
configure addresses without lifetimes, without responses from servers.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 14:15:22 +0100

On 10 Sep 2014, at 14:10, Alexandru Petrescu <[email-masked]> wrote:

> Or otherwise, to which interface to try to resolve the IP address of this outgoing packet?

That's a function of Neighbour Discovery (ND) and isn't confined to the example you gave - it's common to ALL situations where you have multi-homed hosts, and why a neighbour specification includes the interface it can be reached on as well as it's address.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 15:37:32 +0200

Le 10/09/2014 15:15, Simon Hobson a écrit :
>> No, in that the Hosts may be multi-interfaced and as such could
>> not distinguish between them once they're up.   Whose fe80::/10's
>> interface to put this fe80::1-addressed packet to?
>>
> That's a function of Neighbour Discovery (ND) and isn't confined to
> the example you gave - it's common to ALL situations where you have
> multi-homed hosts, and why a neighbour specification includes the
> interface it can be reached on as well as it's address.

Right, sorry, that's right, I was replying wrongly on something which 
diverges.

The worry I have is about the cited RFC making the on-link determination 
to come only when RA or Redirect is present.

IPv6 implementations determine on-linkicity even if RA/Redirect is absent.

This may indeed be an inheritance from IPv4 that I personally appreciate 
because it allows to set up a network quickly manually.  Just blind 
one's eyes and s/he'll type ifconfig 1::1/128 on one screen and ifconfig 
1::2/128 on the other and there it pings.  Can't get any easier network 
setup than that, it's the same as in IPv4.

If on the other hand we tell that, compared to IPv4, first s/he has to 
configure radvd, first get a publicly assigned prefix, first set up a 
NAT46 server, etc etc, then we complicate network setup.

But yes, this is diverging from main topic, which is whether or not it 
is worth putting in the DHCP the prefix length of the assigned address.

Alex

---

From: [email-masked]
Date: Wed, 10 Sep 2014 15:52:53 +0200 (CEST)

> The analysis below is an ipv4 perspective looking at ipv6.  Please read RFC 5942 and see rules for on-link determination.  Only a PIO in the RA or a Redirect message are means to signal a prefix as…

That explanation completely excludes static routes.

On my home server, I am connected on a link where no RA is used, and 
the IPv6 address (and prefix length) is statically configured.

This works just fine (and I certainly *expect* it to do so).

Any IPv6 rules for prefix length need to cover the case of static
routes and no RA.

Steinar Haug, AS 2116

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 09:55:02 -0400

> Any IPv6 rules for prefix length need to cover the case of static

I think static routes must also include a length of the prefix for that route, for consistency with the rest of the addressing and forwarding model.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 09:55:07 -0400

> Trouble is, it's the first time I've come across that information - and I at least have an interest in working with IPv6. I can't help thinking that an awful lot of trouble is brewing away - heck,…

I'm glad Hemant was able to clarify the situation for you.

Taking the next step, in the abstract, a host records the list of prefixes (and associated lengths) and matches the dst addr in an outbound datagram against that list of prefixes to determine if the destination is on link or, if not, which router to use as a next hop.

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 10 Sep 2014 15:54:56 +0200

> setup than that, it's the same as in IPv4.
Most hosts I have seen that have any IPv6 implemented take the link
local address fe80::xxx.

I don't see the need for anything else? More addresses get added when
routers send their RAs or by DHCP6.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 15:17:47 +0100

> I think static routes must also include a length of the prefix for that route, for consistency with the rest of the addressing and forwarding model.

But not for the default route.

So, say you have a device at 2001:470:xxxx:xxxx::2/64 and route of default via 2001:470:xxxx:xxxx::1 dev eth0, no RA running, then reading the RFC the system is not allowed to work out that other addresses starting with 2001:470:xxxx:xxxx are local ? Something I had failed to notice.

Though to be honest, while my first reaction was "this is my setup" - I then remember that I do have RA running, but some devices are statically addressed.

While it is somewhat off topic now, it has certainly been educational !

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 10:22:50 -0400

On Sep 10, 2014, at 8:41 AM 9/10/14, Alexandru Petrescu <[email-masked]> wrote:

> A simple answer is to say that it is just like in IPv4.  The same reasons an IPv4 stack uses the netmask is the reasons why IPv6 stack uses it.
> 

The prefix length is associated with the *prefix*, not the address.

An address is "in" a prefix if the prefix and address match for the leftmost prefix-length bits *of the prefix*.  So, in all these cases, the prefix is in a list of prefixes for a link, and a dst addr is compared to the each entry in the list, using the length associated with the prefix.

It has to be this way to accommodate prefixes of varying lengths in the stack.

> 
> In a Mobile IPv6 stack one needs to tell whether a configured address falls within the prefix received in an RA or not.  This is not specified how to do, but the most precise is to have the prefix length of the address, the prefix length of the prefix, and succeed only if both equal bits and equal lengths.

Why is the prefix length of the address needed?  Is the restriction about prefix and address length matching included somewhere in the spec?

> 
> In a PMIPv6 stack one needs to tell whether the src address of a received packet falls in a certain prefix.  This works but always assumes that 64 magic.

Again, why is the length of the address needed?

> 
> In the SLAAC specification there are some places saying that an address configured by SLAAC (which does have a prefix length) must be compared against a prefix received in an RA.

A SLAAC address is composed of a fixed prefix and a locally generated

Thought experiment - rather than assuming an address has a prefix, try to explain all of these use cases assuming the length is associated with the prefix.  Remember that all these lists of prefixes can include prefixes of different lengths and the usual rule is "longest match" to determine which prefix to select...

> 
> But I agree code inspection may ultimately indicate the use - or no need - of prefix length of an address.
> 
> Alex
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 10:27:08 -0400

Looks like I clicked on "send" too soon.

A SLAAC address is composed of a fixed prefix and a locally generated IID.  It's still a 128-bit address with no inherent "prefix length", and is used in prefix table lookups just like any other address.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 16:44:32 +0200

> routers send their RAs or by DHCP6.

Right, ll addresses work ok, except they're difficult to remember when 
trying to ping because they're ending in this fffe-inserted MAC address.

Whereas an 1::1 parameter of ifconfig is easier to remember when need to 
type on the other screen.  It's the same behaviour as one does 
192.168.1.1 on one screen and .2 on the other.

This works only if on-link determination is possible w/o RA or Redirect, 
and subsequently if a prefix length is attached manually to an IP address.

Think the scenario where one tries to configure a just unwrapped WiFi 
Access Point.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 16:47:20 +0200

Le 10/09/2014 15:55, Ralph Droms a écrit :
>>> The analysis below is an ipv4 perspective looking at ipv6.
>>> Please read RFC 5942 and see rules for on-link determination.
>>> Only a PIO in the RA or a Redirect message are means to signal a
>>> prefix as on-link.   If the RA does not include a PIO, all
>>> destinations are off-link.
>>
>> Thanks, it makes more sense now ! Trouble is, it's the first time
>> I've come across that information - and I at least have an interest
>> in working with IPv6. I can't help thinking that an awful lot of
>> trouble is brewing away - heck, I keep coming across IT
>> professionals with no grasp of IPv4 basics :(
>
> Taking the next step, in the abstract, a host records the list of
> prefixes (and associated lengths) and matches the dst addr in an
> outbound datagram against that list of prefixes to determine if the
> destination is on link or, if not, which router to use as a next
> hop.

If the dst is on-link, then supposedly there is an on-link prefix 
present in that list of prefixes.  Absent RA, who added that prefix in 
that list of prefixes?

Alex
>
>>
>> Having had the "fun" of how stateful firewalls screw up networks
>> that rely on redirects, I just hope some of the vendors have read
>> that RFC. Why do I have a sense of foreboding ...
>>

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 15:59:15 +0100

Alexandru Petrescu <[email-masked]> wrote:

> Think the scenario where one tries to configure a just unwrapped WiFi Access Point.

Hopefully vendors will add mDNS alongside IPv6 - those that do will get a reputation for being easy to config, those that don't will get a bad reputation. And then there are those who'll ignore all that and supply a config utility that does it all.

IMO, link-local addresses and mDNS answer most such scenarios adequately.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 11:01:23 -0400

On Sep 10, 2014, at 10:47 AM 9/10/14, Alexandru Petrescu <[email-masked]> wrote:

> If the dst is on-link, then supposedly there is an on-link prefix present in that list of prefixes.  Absent RA, who added that prefix in that list of prefixes?

The on-link prefix is assumed to be in the list of prefixes; doesn't need to be added from some external source.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 17:02:45 +0200

Le 10/09/2014 17:01, Ralph Droms a écrit :
>>>>> Please read RFC 5942 and see rules for on-link
>>>>> determination. Only a PIO in the RA or a Redirect message are
>>>>> means to signal a prefix as on-link.   If the RA does not
>>>>> include a PIO, all destinations are off-link.
>>>>
>>>> Thanks, it makes more sense now ! Trouble is, it's the first
>>>> time I've come across that information - and I at least have an
>>>> interest in working with IPv6. I can't help thinking that an
>>>> awful lot of trouble is brewing away - heck, I keep coming
>>>> across IT professionals with no grasp of IPv4 basics :(
>>>
>>> Taking the next step, in the abstract, a host records the list
>>> of prefixes (and associated lengths) and matches the dst addr in
>>> an outbound datagram against that list of prefixes to determine
>>> if the destination is on link or, if not, which router to use as
>>> a next hop.
>>
>> present in that list of prefixes.  Absent RA, who added that prefix
>> in that list of prefixes?
>
> The on-link prefix is assumed to be in the list of prefixes; doesn't
> need to be added from some external source.

Ok, I think that is when the prefix length of the address comes in.

Alex

>
>>
>> Alex
>>>
>>>>
>>>> Having had the "fun" of how stateful firewalls screw up
>>>> networks that rely on redirects, I just hope some of the
>>>> vendors have read that RFC. Why do I have a sense of foreboding
>>>> ...
>>>>
>>>> _______________________________________________ dhcwg mailing
>>>> list [email-masked]
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2014 11:23:28 -0400

> Ok, I think that is when the prefix length of the address comes in.

I disagree.  The link-local prefix has a length (/64 or /10, depending on whether you believe the middle bits of the prefix must be zero).  Link-local addresses don't need a length.

Sorry to be so pedantic about all this (comes from a couple of previous jobs).  I think the concepts are important, especially as relates to updates to DHCPv6 to carry prefixes and prefix lengths (and *not* prefix lengths for addresses)...

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 10 Sep 2014 17:23:11 +0200

> present in that list of prefixes.  Absent RA, who added that prefix in
I might be wrong here but my understanding is the the specific ll
address (fe80::xxx) inherently IS on-link?
The 1::x assigned by your ifconfig call is not inherently on-line?

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 10 Sep 2014 11:24:17 -0400

> in that list of prefixes?

Absent RA, you would have to add the prefix in manually via static
configuration.  In IPv6, this step is separate from IPv6 address
configuration on the interface.

Conceptually, when you configure an IPv4 address + subnet mask, you
are really configuring two separate things--the 32-bit IPv4 address on
the interface, and an implicit on-link prefix in the list of prefixes
(routing table), also called a "direct route" or "directly attached
subnet route" which is derived by applying the subnet mask to the IPv4
address.  These two actions are almost always done together with a
single configuration action in popular OS'es, although they don't have
to be.  Hence one configuration of IPv4 address + subnet mask on an
interface ends up deriving two separate things: the interface address
(which has no inherent prefix length) + routing table entry (which has
the network prefix + prefix length derived from IPv4 address + subnet
mask, and a next-hop of "directly attached to this interface").

With IPv6, these two concepts are separate.  There is no more implicit
direct subnet route for Global addresses.  Instead, all destinations
are assumed to be remote by default, and you need to separately
configure a route (default route or otherwise) to reach any other
destinations, local (on-link) or remote (off-link via a router).
Given these two separate concepts, it makes no sense to think of a
subnet mask or prefix length attached to an IPv6 address configured on
an interface, because there is not supposed to be any implicit
calculation of an on-link prefix (directly attached subnet route).

It seems that the above conceptual differences are often missed by
those who assume IPv6 works the same way as IPv4, even to the point
that many popular OS'es blur the differences and still attach a prefix
length to an IPv6 interface address in the user interface.  But such
implementations should technically treat any DHCPv6 or SLAAC
configured address to have an implicit prefix length of /128 (or
really there shouldn't be a prefix length on the interface address at
all), with the RA PIO supplying the list of prefixes and their lengths
and on-link status to the routing table.  Any assumption of /64 or
otherwise is just wrong.

I think it would be useful to have DHCPv6 be a source of the
Prefix-Information-Option to populate the routing table on hosts as an
alternative to RA or static configuration.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 17:27:29 +0200

Le 10/09/2014 16:22, Ralph Droms a écrit :
>>>> separate table of prefixes and prefix lengths kept separate
>>>> from the table of addresses ? Consensus appears to be saying
>>>> "yes, that's how it should be".
>>>>
>>>> associated with that address in order to get the prefix length
>>>> - rather than have it stored alongside the address itself. I
>>>> can see that it's (in data terms) "cleaner" as it removes
>>>> duplication. But is it "cleaner" overall to add an extra
>>>> redirection to get the information ? Not to mention the
>>>> "management overhead" of having to check every time an address
>>>> is removed to see if the prefix is still in use by another
>>>> address (in which case keep it), or not (in which case remove
>>>> it ?)
>>>>
>>> I've worked on the code for an IPv6 stack, but I'm not familiar
>>> with the internals of any of the popular commercial stacks, so
>>> I'll ask: when does an implementation need to have the prefix
>>> length information?
>>
>> The question is right.
>>
>> reasons an IPv4 stack uses the netmask is the reasons why IPv6
>> stack uses it.
>>
>> If I remember correctly, the prefix length of an address may help
>> to: - determine which output interface to use for an outgoing
>> packet - determine whether to ND resolve the address of the dst in
>> the outgoing packet or rather look first for a local route to it
>> and subsequently resolve the address of a gw. ("on-link
>> determination").
>
> An address is "in" a prefix if the prefix and address match for the
> leftmost prefix-length bits *of the prefix*.  So, in all these cases,
> the prefix is in a list of prefixes for a link, and a dst addr is
> compared to the each entry in the list, using the length associated
> with the prefix.
>
>> In a Mobile IPv6 stack one needs to tell whether a configured
>> address falls within the prefix received in an RA or not.  This is
>> not specified how to do, but the most precise is to have the prefix
>> length of the address, the prefix length of the prefix, and succeed
>> only if both equal bits and equal lengths.
>
> Why is the prefix length of the address needed?  Is the restriction
> about prefix and address length matching included somewhere in the
> spec?

No, I don't think it is in the spec.

> Again, why is the length of the address needed?

Maybe it  is not needed.

[...]
> Thought experiment - rather than assuming an address has a prefix,
> try to explain all of these use cases assuming the length is
> associated with the prefix.

But this is difficult!

Is 1::1/64 an address?  A prefix?

If it is an address, then the prefix length 64 is obviously associated 
with it.

If it is a prefix, then it is hard to say it is 'the same' as 1::/64.

> Remember that all these lists of
> prefixes can include prefixes of different lengths and the usual rule
> is "longest match" to determine which prefix to select...

The longest match works ok when there are routes in an arbitrary routing 
table.

But it works less ok when the set of things to select from are tunnels, 
there is no default, and there's always precisely 1 which corresponds to 
the criteria.  In these the exact match would work better.

Alex

>>> sense in the context of a prefix, so I'm curious about when it
>>> would be used in an implementation.
>>>
>>>
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 17:29:55 +0200

Le 10/09/2014 16:59, Simon Hobson a écrit :
> Hopefully vendors will add mDNS alongside IPv6 - those that do will
> get a reputation for being easy to config, those that don't will get
> a bad reputation. And then there are those who'll ignore all that and
> supply a config utility that does it all.

Config utility is not good because it gets deprecated after a few years 
of service.  The Access Point is still there but the tool can no longer 
be found.

> IMO, link-local addresses and mDNS answer most such scenarios

Hmm, I agree about mDNS and automating, but I think the simplest setups 
are those that are first done by administrators and which dont involve 
protocols.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 10 Sep 2014 17:25:00 +0100

> Sorry to be so pedantic about all this (comes from a couple of previous jobs).  I think the concepts are important, especially as relates to updates to DHCPv6 to carry prefixes and prefix lengths (…

I don't think you have anything to apologise for. This thread, while somewhat off-topic, has certainly cleared up some stuff that I wasn't aware of - which means I can now try and pass on that education. Sometimes it's important to be pedantic about details.

Chuck Anderson <[email-masked]> wrote:

> (routing table), ...
> With IPv6, these two concepts are separate. ...
> 
> length to an IPv6 interface address in the user interface.

I think you've hit the nail on the head there. The bigger problem is that I don't recall having seen any "IPv6 primer" type sites where it's even pointed out, let alone detailed. If I knew of a good site that clearly and simply laid out these differences then I'd be happy to evangelise it.

Alexandru Petrescu <[email-masked]> wrote:

> Config utility is not good because it gets deprecated after a few years of service.  The Access Point is still there but the tool can no longer be found.

I agree, but not for that reason. I just hate having to fire up a Windows (because the utilities are almost entirely Windows based) VM and loads some software to do a basic config task. With my work hat on, I use a variety of kit and I'd end up with a lot of different utilities all doing pretty well the same job but in different annoying ways.

> Hmm, I agree about mDNS and automating, but I think the simplest setups are those that are first done by administrators and which dont involve protocols.

I also agree - it will be interesting to see how things pan out.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Sep 2014 16:33:27 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Wednesday, September 10, 2014 8:49 AM
To: [email-masked]
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

>router sending RA.  Is RFC5942 covering this case?

No, but neither do RFC 4861 and RFC 4862. 

>Because implementations are capable of doing it.  For example an IP subnet in a vehicle which is disconnected from the Internet.

If a network does not have default router(s), then the hosts have no default router to send traffic to.  Thus the hosts uses a manual/config file setting or what have you that tell the nodes to send traffic directly to destinations.  

>What if the RA is very rare (every 10minutes) and the sensor node needs to send packets as soon as it wakes up and then sleep.  Will it be unable to determine who's on-link >until receiving an RA?

No issue with your use case.  The RA includes a Router Lifetime which is up to 9000 secs.  The sensor node knows its default router is valid up till 150 minutes. 

Hemant

---

From: [email-masked]
Date: Wed, 10 Sep 2014 20:17:10 +0200 (CEST)

> I think static routes must also include a length of the prefix for that route, for consistency with the rest of the addressing and forwarding model.

Absolutely. Statically configured interfaces and static routes, both
with prefix length specified, must be handled.

Steinar Haug, AS 2116

---

From: [email-masked]
Date: Wed, 10 Sep 2014 20:37:00 +0200 (CEST)

> calculation of an on-link prefix (directly attached subnet route).

I'm afraid thinking of the IPv6 address and prefix length together is
simply *far* too convenient. And especially as long as this is how it
is done in IPv4, that conceptual difference probably won't really
penetrate until IPv4 is more or less forgotten.

> length to an IPv6 interface address in the user interface.

Absolutely. And I *want* the OSes to hide that difference. I *want*
IPv4 and IPv6 configuration to be as similar as possible.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Sep 2014 11:04:49 +0200

Le 10/09/2014 17:24, Chuck Anderson a écrit :
[...]
> mask, and a next-hop of "directly attached to this interface").

Yes - these two actions (configuring an adddress and a prefix in the 
routing table for the connected route) are _almost always_ done together 
by simply stating address/prefixlen.

The majority of cases is:
- typing ifconfig address which results in a rt entry too.
- using SLAAC.
- using RA[PIO/prefixlen] and DHCP[address].

But there are cases where these two actions are not done together:
- use RA[no PIO, but router lifetime for defroute] and DHCP[address].

In this latter case there is no prefix length communicated to the Host.

It may of course be argued that the latter is a configuration error, or 
that the Host wrongly implements the concept of prefix length.

It may also be argued that this situation may be a lack in specifications.

Alex

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Sep 2014 07:53:51 -0400

On Sep 11, 2014, at 5:04 AM 9/11/14, Alexandru Petrescu <[email-masked]> wrote:

> Yes - these two actions (configuring an adddress and a prefix in the routing table for the connected route) are _almost always_ done together by simply stating address/prefixlen.

But, I argue that its important that we keep these two actions separate in the abstract, because combining them causes confusion as I explain below.

> - typing ifconfig address which results in a rt entry too.

Right, but note that according to my theory of operation, automatically adding an inferred routing table entry from a configured address is incorrect.  The routing table entries, in the abstract, should be added explicitly and independently of the configured addresses.

> - using SLAAC.

Again, in theory, the SLAAC prefix is implicitly always in the routing table, so no explicit entry should be needed when configuring a SLAAC address

> - using RA[PIO/prefixlen] and DHCP[address].

Here the two actions are explicitly separate: RA/PIO causes the routing table entry to be added while DHCP/IA_NA assigns addresses to an interface.

> In this latter case there is no prefix length communicated to the Host.

Right, and that situation is perfectly OK.  No addresses (aside from link-local) will be found to be on-link, and all addresses will be forwarded through the default route.

> 
> It may of course be argued that the latter is a configuration error, or that the Host wrongly implements the concept of prefix length.
> 

It's not a problem - perhaps unusual, but it's a perfectly serviceable configuration.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Sep 2014 10:18:11 -0400

> Right, but note that according to my theory of operation, automatically adding an inferred routing table entry from a configured address is incorrect.  The routing table entries, in the abstract, s…

This is indeed the key point.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Sep 2014 11:22:31 +0200

Le 11/09/2014 13:53, Ralph Droms a écrit :
>> Le 10/09/2014 17:24, Chuck Anderson a écrit : [...]
>>> Conceptually, when you configure an IPv4 address + subnet mask,
>>> you are really configuring two separate things--the 32-bit IPv4
>>> address on the interface, and an implicit on-link prefix in the
>>> list of prefixes (routing table), also called a "direct route" or
>>> "directly attached subnet route" which is derived by applying the
>>> subnet mask to the IPv4 address.  These two actions are almost
>>> always done together with a single configuration action in
>>> popular OS'es, although they don't have to be.  Hence one
>>> configuration of IPv4 address + subnet mask on an interface ends
>>> up deriving two separate things: the interface address (which has
>>> no inherent prefix length) + routing table entry (which has the
>>> network prefix + prefix length derived from IPv4 address +
>>> subnet mask, and a next-hop of "directly attached to this
>>> interface").
>>
>> Yes - these two actions (configuring an adddress and a prefix in
>> the routing table for the connected route) are _almost always_ done
>> together by simply stating address/prefixlen.
>
> But, I argue that its important that we keep these two actions
> separate in the abstract, because combining them causes confusion as
> I explain below.
>
>>
>> The majority of cases is: - typing ifconfig address which results
>> in a rt entry too.
>
> Right, but note that according to my theory of operation,
> automatically adding an inferred routing table entry from a
> configured address is incorrect.  The routing table entries, in the
> abstract, should be added explicitly and independently of the
> configured addresses.

Ok.  But if ifconfig does not specify a prefix length, and PIO is absent 
from RA, what should one insert in the rt entry?

Insert nothing?  Insert a rt entry with plen 0, or 128?

This is needed, because there is at least one neighboring router on this 
link (ptp link) and it should be reached via a connected route, not the 
default route.

Alex

>
>> - using SLAAC.
>
> Again, in theory, the SLAAC prefix is implicitly always in the
> routing table, so no explicit entry should be needed when configuring
> a SLAAC address
>
> Here the two actions are explicitly separate: RA/PIO causes the
> routing table entry to be added while DHCP/IA_NA assigns addresses to
> an interface.
>
>>
> Right, and that situation is perfectly OK.  No addresses (aside from
> link-local) will be found to be on-link, and all addresses will be
> forwarded through the default route.
>
>>
>> It may of course be argued that the latter is a configuration
>> error, or that the Host wrongly implements the concept of prefix
>> length.
>>
>>> With IPv6, these two concepts are separate.  There is no more
>>> implicit direct subnet route for Global addresses.  Instead, all
>>> destinations are assumed to be remote by default, and you need to
>>> separately configure a route (default route or otherwise) to
>>> reach any other destinations, local (on-link) or remote (off-link
>>> via a router). Given these two separate concepts, it makes no
>>> sense to think of a subnet mask or prefix length attached to an
>>> IPv6 address configured on an interface, because there is not
>>> supposed to be any implicit calculation of an on-link prefix
>>> (directly attached subnet route).
>>>
>>> It seems that the above conceptual differences are often missed
>>> by those who assume IPv6 works the same way as IPv4, even to the
>>> point that many popular OS'es blur the differences and still
>>> attach a prefix length to an IPv6 interface address in the user
>>> interface.  But such implementations should technically treat any
>>> DHCPv6 or SLAAC configured address to have an implicit prefix
>>> length of /128 (or really there shouldn't be a prefix length on
>>> the interface address at all), with the RA PIO supplying the list
>>> of prefixes and their lengths and on-link status to the routing
>>> table.  Any assumption of /64 or otherwise is just wrong.
>>>
>>> Prefix-Information-Option to populate the routing table on hosts
>>> as an alternative to RA or static configuration.
>>>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 12 Sep 2014 10:23:02 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, September 12, 2014 5:23 AM
To: Ralph Droms
Cc: dhcwg
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

>Ok.  But if ifconfig does not specify a prefix length, and PIO is absent from RA, what should one insert in the rt entry?

An RA with no PIO does not update the Prefix List on the host .  However, the Default Router List on the host is updated for a router on receiving an RA.  

>Insert nothing?  Insert a rt entry with plen 0, or 128?

128.  Recall, by default, IPv6 assumes no internal structure in the IPv6 address assigned to an interface.  

>This is needed, because there is at least one neighboring router on this link (ptp link) and it should be reached via a connected route, not the default route.

I don't understand your network topology.   The link is a p2p link.  The router is also a neighbor.  Thus the router is at the other end of the p2p link.  The host sends traffic to the default router.   If I missed anything, please send us ascii text of your topology with IPv6 addresses.

Hemant

---

From: Simon Hobson <[email-masked]>
Date: Fri, 12 Sep 2014 11:46:21 +0100

> I don't understand your network topology.   The link is a p2p link.  The router is also a neighbor.  Thus the router is at the other end of the p2p link.  The host sends traffic to the default rout…

As I read it, he has "a network" with various routers etc. A node on this network has a P-t-P link to another router (which presumably may have other networks attached to it). Eg, on a corporate network, a leased line between two sites which presents as a serial interface. On this node, the default route is not via this P-t-P link.

In the IPv4 world, one would set this link up as a numbered link (eg 192.168.1.0/30) and each end would have an implicit route to the device on the other - ie 192.168.1.1 would have an implicit (subnet) route allowing it to reach 192.168.1.2 and vice-versa. AFter that, routes may be added to direct specific traffic via the node at the other end of the link (eg a.b.c.0/24 via 192.168.1.2)

From my understanding of the conversation, in the IPv6 world :
1) The two ends do not have to have addresses in the same "subnet" - ie the addresses used could be completely unrelated and come from different prefixes/assignments.
2) In the absence of an automated mechanism (ie RA), each device needs configuring with an explicit route to the other via this interface/link.
and
3) step 2 should not be by inferring a route from the address & prefix as would normally be the case in IPv4.
Step 3 being my newly acquired knowledge from this thread.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Sep 2014 07:20:59 -0400

> This is needed, because there is at least one neighboring router on this link (ptp link) and it should be reached via a connected route, not the default route.

So, in theory, there are actually two independent actions:

1) add the local address to the interface
2) add the prefix to the list of on-link prefixes for the link

One way to accomplish the two actions would be through two separate CLI calls.  If I understand your question correctly, an invocation of ifconfig with no prefix length would only add the local address to the interface and would not modify the list of on-link prefixes.  A second invocation of ifconfig, with new syntax, would add the prefix to the list of on-link prefixes. 

The two actions, as Jinmei-san has suggests in the interests of brevity, are currently specified by a single call to ifconfig in which the syntax 2001:DB8:1:1::1/64 performs both actions:

1) add 2001:DB8:1:1::1 to the local interface
2) infer the prefix 2001:DB8:1:1::/64 from the syntax and add that prefix to the list of on-link prefixes for that link

Note that the on-link prefix is the only routing information available.  Anything other information about other prefixes that should be forwarded through this router would come from elsewhere, such as redirect messages.

Also note that, as we've discussed, the role of the prefix length in the address structure in many implementations is unclear and confusing the issue at this point.

---

From: [email-masked]
Date: Fri, 12 Sep 2014 14:14:36 +0200 (CEST)

> One way to accomplish the two actions would be through two separate
> CLI calls.

Certainly possible in theory - though I would regard this as a pretty
awful user interface.

Steinar Haug, AS 2116

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 12 Sep 2014 12:42:12 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Friday, September 12, 2014 6:46 AM
To: dhcwg
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

>As I read it, he has "a network" with various routers etc. A node on this network has a P-t-P link to another router (which presumably may have other networks attached to it). Eg, on a corporate network, a leased line >between two sites which presents as a serial interface. On this node, the default route is not via this P-t-P link.

Got it.  As others have said, ipv6 address configuration is an orthogonal step to ipv6 route configuration.  The node has to add an entry to the routing table for the remote peer using the longest prefix between the peers.   Then there is no routing issue with sending/receiving packets between these two p2p peers.   Routing works using the longest-prefix match.  That is why on p2p links folks prefer to use a /127 prefix in IPv6 and use a /31 prefix in IPv4 so that no other route on the node can overlap with the p2p link and screw up routing.  To forward a packet, once a route lookup (L3 forwarding) succeeds, the Neighbor Cache is involved in L2 forwarding.  The node has no entry for the remote peer in the Prefix List.  Thus the node forwards the packet to the default router.  The default router was learnt from the RA with no PIO.

Hemant

---

From: Simon Hobson <[email-masked]>
Date: Fri, 12 Sep 2014 14:59:27 +0100

Hemant Singh (shemant) <[email-masked]> wrote:

> The node has to add an entry to the routing table for the remote peer using the longest prefix between the peers.

Surely it should be (in the general case) a specific route to the peer node via the interface. Ie :
<some long IPv6 address>/128 via <serial port identifier>

You seem to be having the same problem I had - equating "on link" with in the same prefix (subnet)

Consider if (say) you used 2001:400::1 and 2001:500::1 as the two peer addresses - assuming the two sites had allocations from two completely separate providers. You'd need a (if I've got my maths right) 47 bit prefix to match both addresses - and then you'd have a route for a big chunk of the public address space going where it shouldn't.

Now, if you confine yourself to addresses which can be matched with a /127 mask then it's different - but AIUI now that's not necessary.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Sep 2014 16:53:36 +0200

Le 12/09/2014 12:23, Hemant Singh (shemant) a écrit :
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Friday, September 12, 2014 5:23 AM To: Ralph Droms Cc: dhcwg Subject:
> Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6
> message
>
>
>> Ok.  But if ifconfig does not specify a prefix length, and PIO is
>> absent from RA, what should one insert in the rt entry?
>
> An RA with no PIO does not update the Prefix List on the host .
> However, the Default Router List on the host is updated for a router
> on receiving an RA.
>
> 128.

But 128 means that address only - it is the equivalent of a loopback, 
can not be used to go elsewhere.

An entry address/128 in a routing table means that only that address can 
be reached via that route, not any other address.

> Recall, by default, IPv6 assumes no internal structure in the
> IPv6 address assigned to an interface.

Right, IPv6 doesnt assume, but IPv6 implementations does have a data 
structure with a prefixlen next to the inet6_addr.

>> This is needed, because there is at least one neighboring router on
>> this link (ptp link) and it should be reached via a connected
>> route, not the default route.
>
> I don't understand your network topology.   The link is a p2p link.
> The router is also a neighbor.  Thus the router is at the other end
> of the p2p link.  The host sends traffic to the default router.   If
> I missed anything, please send us ascii text of your topology with
> IPv6 addresses.

I was also surprised to see a cellular link on which there are actually 
two routers (receive two different RAs with two different link-local src 
addresses).  So it is more like a point-to-[point,point] link.

But that's an aside.

The idea of a connected route in the rt entry is to reach the global 
address of the router via that rt entry, and not via the default  route.

The default route is used to reach all other hosts on the Internet, and 
not necessarily the immediately connected Router.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Sep 2014 17:08:13 +0200

Le 12/09/2014 14:42, Hemant Singh (shemant) a écrit :
> Friday, September 12, 2014 6:46 AM To: dhcwg Subject: Re: [dhcwg]
>> As I read it, he has "a network" with various routers etc. A node
>> on this network has a P-t-P link to another router (which
>> presumably may have other networks attached to it). Eg, on a
>> corporate network, a leased line >between two sites which presents
>> as a serial interface. On this node, the default route is not via
>> this P-t-P link.
>
> Got it.  As others have said, ipv6 address configuration is an
> orthogonal step to ipv6 route configuration.

Right.

Is there a case where address configuration MUST NOT be accompanied by
adding a route in the routing table?

In my experience there is no such case.  With each added address on an
interface, new rt entries appear.

> The node has to add an entry to the routing table for the remote peer
> using the longest prefix between the peers.   Then there is no
> routing issue with sending/receiving packets between these two p2p
> peers.   Routing works using the longest-prefix match.

Ok.

> That is why on p2p links folks prefer to use a /127 prefix in IPv6

I wonder whether 127 may be a better prefixlength-by-default than 128?

Alex

> and use a /31 prefix in IPv4 so that no other route on the node can
> overlap with the p2p link and screw up routing.  To forward a packet,
> once a route lookup (L3 forwarding) succeeds, the Neighbor Cache is
> involved in L2 forwarding.  The node has no entry for the remote peer
> in the Prefix List.  Thus the node forwards the packet to the default
> router.  The default router was learnt from the RA with no PIO.
>
> Hemant
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Sep 2014 17:16:33 +0200

Le 12/09/2014 13:20, Ralph Droms a écrit :
>>>>> Conceptually, when you configure an IPv4 address + subnet
>>>>> mask, you are really configuring two separate things--the
>>>>> 32-bit IPv4 address on the interface, and an implicit on-link
>>>>> prefix in the list of prefixes (routing table), also called a
>>>>> "direct route" or "directly attached subnet route" which is
>>>>> derived by applying the subnet mask to the IPv4 address.
>>>>> These two actions are almost always done together with a
>>>>> single configuration action in popular OS'es, although they
>>>>> don't have to be.  Hence one configuration of IPv4 address +
>>>>> subnet mask on an interface ends up deriving two separate
>>>>> things: the interface address (which has no inherent prefix
>>>>> length) + routing table entry (which has the network prefix +
>>>>> prefix length derived from IPv4 address + subnet mask, and a
>>>>> next-hop of "directly attached to this interface").
>>>>
>>>> Yes - these two actions (configuring an adddress and a prefix
>>>> in the routing table for the connected route) are _almost
>>>> always_ done together by simply stating address/prefixlen.
>>>
>>> separate in the abstract, because combining them causes confusion
>>> as I explain below.
>>>
>>>>
>>>> The majority of cases is: - typing ifconfig address which
>>>> results in a rt entry too.
>>>
>>> configured address is incorrect.  The routing table entries, in
>>> the abstract, should be added explicitly and independently of
>>> the configured addresses.
>>
> 1) add the local address to the interface 2) add the prefix to the
> list of on-link prefixes for the link

YEs, and I think whereas the latter can be done w/o the first the 
vice-versa never seen: didnt see a case where adding an address to an 
interface without also inserting an rt entry.

> CLI calls.  If I understand your question correctly, an invocation of
> ifconfig with no prefix length would only add the local address to
> the interface and would not modify the list of on-link prefixes.  A
> second invocation of ifconfig, with new syntax, would add the prefix
> to the list of on-link prefixes.
>
> The two actions, as Jinmei-san has suggests in the interests of
> brevity, are currently specified by a single call to ifconfig in
> which the syntax 2001:DB8:1:1::1/64 performs both actions:
>
> 1) add 2001:DB8:1:1::1 to the local interface 2) infer the prefix
> 2001:DB8:1:1::/64 from the syntax and add that prefix to the list of
> on-link prefixes for that link
>
> Note that the on-link prefix is the only routing information
> available.  Anything other information about other prefixes that
> should be forwarded through this router would come from elsewhere,
> such as redirect messages.

I agree.

> Also note that, as we've discussed, the role of the prefix length in
> the address structure in many implementations is unclear and
> confusing the issue at this point.

YEs, it is confusing.

Alex

>>> routing table, so no explicit entry should be needed when
>>> configuring a SLAAC address
>>>
>>> routing table entry to be added while DHCP/IA_NA assigns
>>> addresses to an interface.
>>>
>>>>
>>>> But there are cases where these two actions are not done
>>>> together: - use RA[no PIO, but router lifetime for defroute]
>>>> and DHCP[address].
>>>>
>>> Right, and that situation is perfectly OK.  No addresses (aside
>>> from link-local) will be found to be on-link, and all addresses
>>> will be forwarded through the default route.
>>>
>>>>
>>>> error, or that the Host wrongly implements the concept of
>>>> prefix length.
>>>>
>>>>> With IPv6, these two concepts are separate.  There is no
>>>>> more implicit direct subnet route for Global addresses.
>>>>> Instead, all destinations are assumed to be remote by
>>>>> default, and you need to separately configure a route
>>>>> (default route or otherwise) to reach any other destinations,
>>>>> local (on-link) or remote (off-link via a router). Given
>>>>> these two separate concepts, it makes no sense to think of a
>>>>> subnet mask or prefix length attached to an IPv6 address
>>>>> configured on an interface, because there is not supposed to
>>>>> be any implicit calculation of an on-link prefix (directly
>>>>> attached subnet route).
>>>>>
>>>>> It seems that the above conceptual differences are often
>>>>> missed by those who assume IPv6 works the same way as IPv4,
>>>>> even to the point that many popular OS'es blur the
>>>>> differences and still attach a prefix length to an IPv6
>>>>> interface address in the user interface.  But such
>>>>> configured address to have an implicit prefix length of /128
>>>>> (or really there shouldn't be a prefix length on the
>>>>> interface address at all), with the RA PIO supplying the
>>>>> list of prefixes and their lengths and on-link status to the
>>>>> routing table.  Any assumption of /64 or otherwise is just
>>>>> wrong.
>>>>>
>>>>> Prefix-Information-Option to populate the routing table on
>>>>> hosts as an alternative to RA or static configuration.
>>>>>
>>>>> _______________________________________________ dhcwg
>>>>> mailing list [email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 12 Sep 2014 16:01:16 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, September 12, 2014 11:08 AM
To: [email-masked]
Subject: Re: [dhcwg] Prefix-length of an assigned address, in a DHCPv6 message

>I wonder whether 127 may be a better prefixlength-by-default than 128?

The reason I said 128 is because the IPv6 address has no internal structure.  Routing on the node doesn't care if the an address on an interface is provisioned with a /128 or /64 or /127, etc.   For setting up of any subnet, one needs at least one bit for the network vs. host bits.  That is why the /127 is the smallest IPv6 subnet.  However, a /127 has to be used with caution since /127 also happens to be the anycast address.   See RFC6164.

An example for what routing entries are created when an interface on a router is configured for an IPv6 address is included below.  I have used my Cisco router. 

interface foo
ipv6 address 2001:DB8:3800:909::1/64

router#sh ipv6 route | include 2001:DB8:3800:909
C   2001:DB8:3800:909::/64 [0/0]
L   2001:DB8:3800:909::1/128 [0/0]
bruschi#

The codes on a Cisco router are included below 

Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
       NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
       a - Application

Hemant

---

From: Simon Hobson <[email-masked]>
Date: Fri, 12 Sep 2014 17:08:14 +0100

Alexandru Petrescu <[email-masked]> wrote:

> But 128 means that address only - it is the equivalent of a loopback, can not be used to go elsewhere.
> 
> An entry address/128 in a routing table means that only that address can be reached via that route, not any other address.

No, it means that that single address can be reached via that route. It does not preclude other addresses being routed via it.

In the case of a P-t-P link, you'd want a host route to the single device at the other end of the link - just the one address (ie a /128). As I read the RFC mentioned earlier, it does not matter that it won't be in the same prefix (subnet in IPv4 terminology) since IPv6 uses a different concept of "on-link" where directly contactable neighbours do not have to be in the same prefix as the address being used to talk to them.

Once you have a route to that single address (ie the router at the other end of the link), then you can add (statically or via a routing protocol) routes for the remote network via the router.

> Right, IPv6 doesnt assume, but IPv6 implementations does have a data structure with a prefixlen next to the inet6_addr.

But from the previous discussions it seems that the implementations are "wrong".
I had to read the RFC and some of the earlier messages in this thread more than once to get my head round it. The concept of "locally connected" is different to "in the same subnet" which we are used to with IPv4. Instead the concept of locally connected is "the address is within *any* prefix listed as attached to the interface" - or a router tells us by redirect that it's local. The prefixes should come from the attached routers - not be inferred from configuring IP addresses.

---

From: [email-masked]
Date: Fri, 12 Sep 2014 18:19:59 +0200 (CEST)

> I had to read the RFC and some of the earlier messages in this thread more than once to get my head round it. The concept of "locally connected" is different to "in the same subnet" which we are us…

But this doesn't work if there *is* no attached router. Explicitly
configuring address *and* prefix length still works.

Steinar Haug, AS 2116

---

From: Simon Hobson <[email-masked]>
Date: Fri, 12 Sep 2014 17:26:53 +0100

> configuring address *and* prefix length still works.

How about "configuring address and prefix" is how it's supposed to be done. It still doesn't give the address itself a prefix length.

It's looks very much like the IPv6 "team" have come up with some new concepts, but those building the implementations haven't grasped them - so have carried over "we always did it this way" methods from IPv4. Specifically, still in the UI associating an address as itself having a prefix length, when in fact it's the prefix that has a length.

From the UI PoV it's messy, but given the idea that having multiple addresses is "the norm" for IPv6, I can see the logic behind it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Sep 2014 18:29:42 +0200

Le 12/09/2014 18:08, Simon Hobson a écrit :
>> But 128 means that address only - it is the equivalent of a
>> loopback, can not be used to go elsewhere.
>>
>> An entry address/128 in a routing table means that only that
>> address can be reached via that route, not any other address.
>
> No, it means that that single address can be reached via that route.

Yes.

> It does not preclude other addresses being routed via it.

No.  A /128 route in the rt is a 'host-based' route, and it does
preclude another address to be reached via it.

> In the case of a P-t-P link, you'd want a host route to the single
> device at the other end of the link - just the one address (ie a
> /128).

Yes.

> As I read the RFC mentioned earlier, it does not matter that it
> won't be in the same prefix (subnet in IPv4 terminology) since IPv6
> uses a different concept of "on-link" where directly contactable
> neighbours do not have to be in the same prefix as the address being
> used to talk to them.

I didnt know that.

Ok, and the /128 address of this route is not concerned by the manual
configuration of the address on the Client, it's simply another address.

> Once you have a route to that single address (ie the router at the
> other end of the link), then you can add (statically or via a routing
> protocol) routes for the remote network via the router.

Sure.

>> Right, IPv6 doesnt assume, but IPv6 implementations does have a
>> data structure with a prefixlen next to the inet6_addr.
>
> But from the previous discussions it seems that the implementations
> are "wrong". I had to read the RFC and some of the earlier messages
> in this thread more than once to get my head round it. The concept of
> "locally connected" is different to "in the same subnet" which we are
> used to with IPv4.

Yes, that is what is said.

I personally think being too remote from IPv4 may not be advantageous. 
Or maybe side-effects will to import it from IPv6 to IPv4 (multi-link 
subnets as well as multi-subnet links).

If we say that implementations are wrong, we are going far because 
implementations say that whereas an interface has an address and a 
prefix length, DHCP/RA-wo-PIO gives it only the address; they're thus 
free to set the prefixlen to whatever someone wants.  Not knowing what 
to put there often results in that being 64.

This too is different than IPv4.

Alex

  Instead the concept of locally connected is "the
> address is within *any* prefix listed as attached to the interface" -
> or a router tells us by redirect that it's local.

> The prefixes should come from the attached routers - not be inferred
> from configuring IP addresses.
>

---

From: [email-masked]
Date: Fri, 12 Sep 2014 20:56:29 +0200 (CEST)

> How about "configuring address and prefix" is how it's supposed to be done. It still doesn't give the address itself a prefix length.

Agreed. But to somebody used to IPv4, it works - and is understandable.

> It's looks very much like the IPv6 "team" have come up with some new concepts, but those building the implementations haven't grasped them - so have carried over "we always did it this way" methods…

I sincerely hope that the UIs *don't* change :-)

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 13 Sep 2014 15:50:42 +0200

> I sincerely hope that the UIs *don't* change :-)

Yes, the description of UI behaviour in this discussion is to express 
how important is the prefix length to an address (CLI and UI all need a 
prefix length value when assigning an address to an interface).

The implementations of address auto-configuration protocols often use 
these UI and CLI commands to assign the parameters to the Host, rather 
than complex ioctls/netlinks, and hence their dependency on the 
parameters of these tools.

We can say that the UI/CLI tools are right and hence the protocol 
implementations need to adapt; or we can say the reverse - i.e. the 
protocol implementation is right and the UI/CLI tools MUST NOT use a 
prefix-length.

This latter option was used in the past.  The result is that currently 
ifconfig no longer requires the prefix length parameter, but invents 
'128' for it.

This per se has some problems.  For example, a rt entry A/128 means 
actually _self_.  But there is already ::1 to mean _self_ (loopback 
address, RFC4291).  Another example problem is that others may use /127 
instead.

Alex

> Steinar Haug, AS 2116

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 13 Sep 2014 15:54:36 +0200

I was pointed out in private about 2 other earlier discussions about 
this same topic:

"prefix length determination for DHCPv6" 2007
https://www.ietf.org/mail-archive/web/dhcwg/current/msg07412.html

"prefix length option for DHCPv6" 2011
https://www.ietf.org/mail-archive/web/dhcwg/current/msg11543.html

But there seems to be no draft discussing this problem, or offering 
potential solutions.

Alex

---

---

From: [email-masked]
Date: Sat, 13 Sep 2014 17:16:49 +0200 (CEST)

> ifconfig no longer requires the prefix length parameter, but invents 

*Some* Unix/ifconfig versions do. FreeBSD 9.3 ifconfig, for instance,
uses a /64 if prefix length is not specified. This is arguably wrong
(but probably also follows POLA - everybody "knows" that a LAN segment
is a /64). It is also explicitly documented as a /64:

  prefixlen len
          (Inet6 only.)  Specify that len bits are reserved for subdividing
          networks into sub-networks.  The len must be integer, and for
          syntactical reason it must be between 0 to 128.  It is almost
          always 64 under the current IPv6 assignment rule.  If the parame-
          ter is omitted, 64 is used.

Steinar Haug, AS 2116