Subject: [dhcwg] Microphone comment about DHCPv6 address prefix length

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 15:17:04 -0500

On ticket #68: I said we should clarify that implementations should
configure IPv6 addresses as /128.

An address by itself has no prefix length. Writing an address with a prefix
length (e.g., 2001:db8::1/127) means "an IP address, and an on-link route
of prefix length X containing the IP address" (e.g., 2001:db8::1 and
2001:db8::/127). DHCPv6 hands out only addresses, but not any sort of link
information, so there is no route. If we want to write that as prefix
length + subnet mask, then that means /128.

Perhaps because this is not how IPv4 works, this seems to trip people up
all the time, even in WGs like v6ops. So I think it should be documented in
the section that defines IA_NA.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Mar 2015 22:56:55 +0100

>  configure IPv6 addresses as /128.

=> a /128 address is useless so it is not the right solution.

>  length + subnet mask, then that means /128.

=> I agree the prefix information should come by another way. You can
even argue it should be /128 by default but your proposal simply
breaks address configuration.

>  the section that defines IA_NA.

=> I agree to write the IA_NA carries no prefix length, but not to
write a /128 MUST or SHOULD be configured.

Regards

[email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 27 Mar 2015 00:18:09 +0100 (CET)

> => a /128 address is useless so it is not the right solution.

Why is it useless? I have successfully had devices that had a /128 on the 
interface (IA_NA) and a default route (from RA). This works just fine. 
It's a legitimate deployment scenario.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 18:39:39 -0500

> breaks address configuration.

I think  these two statements are in conflict.   If the prefix configuration is coming from somewhere else, than that is where the prefix length will come from.   On Linux the way this would look is that you'd configure the IPv6 address with a width of /128, meaning just an address, and you'd configure the prefix which presumably contains that address with whatever length was advertised, hopefully /64.   Because of this, using /128 for the address is exactly the right thing to do.

However, really IPv6 addresses do not have prefix widths.   Advertised prefixes have widths. So what I just described with respect to Linux is just how Linux does it, and probably doesn't belong in a standard.

> write a /128 MUST or SHOULD be configured.

So if I understand this correctly, what you mean is that we should simply say that IP addresses don't have prefix lengths.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 18:45:48 -0500

On 26 Mar 2015 6:39 pm, "Ted Lemon" <[email-masked]> wrote:
>
> So if I understand this correctly, what you mean is that we should simply
say that IP addresses don't have prefix lengths.

We need to say that obtaining an IPv6 address MUST NOT cause the client to
configure any reachability information beyond the single IP address
assigned.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 22:53:07 -0500

On Mar 26, 2015, at 6:45 PM, Lorenzo Colitti <[email-masked]> wrote:
> We need to say that obtaining an IPv6 address MUST NOT cause the client to configure any reachability information beyond the single IP address assigned.

Oh, yes, that's a good way to address the issue.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Mar 2015 17:13:39 +0100

>  It's a legitimate deployment scenario.

=> the key is in "and a default route (from RA)". Alone the IA_NA
doesn't provide enough information, and in the common case the prefix
length (got from RA) is known and the prefix on-line the /128 is bad.

I discussed a bit with Lorenzo: we don't disagree about the problem
(i.e., DHCPv6 provides the address and nothing about the prefix) but
about the wording for its solution in the 3315bis:
 - say nothing (RFC 3315): doesn't really hide the problem and
  for sure doesn't help

 - say use /64: it works well in the current real world but be serious,
  it is clearly *not* an option for 3315bis! Nor a long term solution.

 - say use /128 (Lorenzo): IMHO far to be enough (or with other words
  it relies on a separation between address and route which is not
  the common way things are implemented).

 - explain the problem and give /128 as the default/fallback: the thing
  to do. Now there are some text to write...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Mar 2015 17:18:34 +0100

In your previous mail you wrote:

>  However, really IPv6 addresses do not have prefix widths.   Advertised
>  prefixes have widths. So what I just described with respect to Linux is
>  just how Linux does it, and probably doesn't belong in a standard.

=> yes Linux doesn't reflect the common way it is done.

>  So if I understand this correctly, what you mean is that we should
>  simply say that IP addresses don't have prefix lengths.

=> it is true but it doesn't help: there is a problem to solve and
IMHO the specs should explain it a bit more even it should not
(and can not) provide an "universal" solution.

Thanks

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 27 Mar 2015 18:31:33 +0100 (CET)

>  the common way things are implemented).

How are things implemented?

>  to do. Now there are some text to write...

Well, for me it's obvious that it should work the way I described it. 
IA_NA means "adress" which in IPv6 is a /128. It doesn't come with any 
prefix. Prefix and routing come with RAs, not DHCPv6.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Mar 2015 17:51:12 +0000

I think this is the correct direction. No prefix information for addresses is provided by DHCPv6 and a client that needs a prefix to add an address to an interface must derive this from RA information (Prefix Information) or other configuration. If no prefix is available that "contains" the address, a /128 must be used.

- Bernie (from iPad)

> On Mar 27, 2015, at 11:13 AM, Francis Dupont <[email-masked]> wrote:
> 
>  to do. Now there are some text to write

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Mar 2015 19:18:46 +0100

>  How are things implemented?

=> address and prefix length are used together in an atomic operation.
BTW I believe what was implemented in older versions of Linux...

>  prefix. Prefix and routing come with RAs, not DHCPv6.

=> I am old enough to understand the world won't be as I'd like so
now it is time to provide something usable by the whole community...
A proposal:
 - IA_NA (*) provides only an address. When needed (**) this address
  SHOULD (***) be combined with prefix information as prefix length
  from another source (****), and if none is available the address
  SHOULD (*****) be handled as a /128.

(*) it applies to IA_TA too? perhaps we have to use a more generic
wording but the place where this text is inserted matters too.
(**) IMHO the wording is loose enough to accomodate all cases.
(***) IMHO a SHOULD is enough.
(****) we can add another means not DHCPv6 but IMHO it could be overkilling
(*****) again SHOULD is enough as there is no real other choice and
 the "another source" catches options as everything is online and /64
 by manual configuration (:-).

Of course any proposal to improvement the wording will be wellcome.
BTW there should be a tracker number so I suggest to change the subject
(I apologize to be too lazy now to do this).

Regards

PS: too many "as", s/as/, e.g.,/ for the first one (prefix length)?

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Mar 2015 19:23:59 +0100

In your previous mail you wrote:

>  I think this is the correct direction. No prefix information for addresses =
>  is provided by DHCPv6 and a client that needs a prefix to add an address to=
>   an interface must derive this from RA information (Prefix Information) or =
>  other configuration. If no prefix is available that "contains" the address,=
>   a /128 must be used.

=> my proposal goes the way with a different (and subject to improvement)
wording even IMHO it says the same thing.

Regards

---

From: Simon Hobson <[email-masked]>
Date: Sun, 29 Mar 2015 13:15:09 +0100

Francis Dupont <[email-masked]> wrote:

>  SHOULD (***) be combined with prefix information ...

But if we've agreed that address and prefix are separate things, and as per a previous discussion, "in same subnet" (ala IPv4) is *NOT* the way to determine "on link"*, then ...
This effectively saying "if your broken implementation requires it ..." which is further encouraging continuation (or even new instances) of broken implementations.

Surely the wording should be more strong that an implementation that requires a prefix in order to make use of an address is broken**.

* As I vaguely recall the previous thread during which I "saw the light". In the absence of any routers then ND is the only way to find other locally attached nodes. If there is information from RAs, then this tells you the subnet(s) that are locally attached (which may or may not include the device's own address) - and ND is still required to actually contact other nodes.
All the subnet information from the RAs (or other information) tells you is a shortcut to whether to use ND or go via a router in order to send your packet.

** Yes I know how things are done in Linux. It's understandable how, given the close coupling between address and subnet in IPv4, the two could be closely linked such that address+subnet implies a routing table entry. I fear that unravelling that to correctly handle IPv6 could be difficult and time consuming given the number of different places such a coupling is implied.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Mar 2015 21:39:58 +0900

On Sun, Mar 29, 2015 at 9:15 PM, Simon Hobson <[email-masked]>
wrote:

> * As I vaguely recall the previous thread during which I "saw the light".
> In the absence of any routers then ND is the only way to find other locally
> attached nodes.

Actually, no: since RFC 4943, in the absence of ND or other routing
information there is no way to contact other locally attached nodes.

Hence my suggested wording that configuring an address MUST NOT cause the
client to configure any reachability information beyond the single IP
address assigned.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 30 Mar 2015 16:24:16 +0100

Lorenzo Colitti <[email-masked]> wrote:

>> * As I vaguely recall the previous thread during which I "saw the light". In the absence of any routers then ND is the only way to find other locally attached nodes.

> Actually, no: since RFC 4943, in the absence of ND or other routing information there is no way to contact other locally attached nodes.

Err, isn't that what I wrote (in different terms) ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Mar 2015 20:27:15 +0200

Le 27/03/2015 18:51, Bernie Volz (volz) a écrit :
> I think this is the correct direction. No prefix information for
> addresses is provided by DHCPv6 and a client that needs a prefix to
> add an address to an interface must derive this from RA information
> (Prefix Information) or other configuration. If no prefix is
> available that "contains" the address, a /128 must be used.

And, in particular, what if there are two different prefixes advertised 
by the RA and each can be qualified as "containing" the address - which 
one should be the one?  Maybe the longest matching one, or maybe the 
last one that fit during the search operation.

Alex

>> - explain the problem and give /128 as the default/fallback: the
>> thing to do. Now there are some text to write
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Mar 2015 20:28:12 +0200

> BTW I believe what was implemented in older versions of Linux...

in some recent implementation of DHCP the prefix length is assumed to be 
64, commented by the programmer waiting for guidance.

Alex

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Mar 2015 14:33:58 -0400

On Mar 30, 2015, at 2:28 PM, Alexandru Petrescu <[email-masked]> wrote:
> in some recent implementation of DHCP the prefix length is assumed to be 64, commented by the programmer waiting for guidance.

Right, this is what triggered the discussion.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 30 Mar 2015 20:28:29 +0100

Alexandru Petrescu <[email-masked]> wrote:

> And, in particular, what if there are two different prefixes advertised by the RA and each can be qualified as "containing" the address - which one should be the one?  Maybe the longest matching one, or maybe the last one that fit during the search operation.

Does it matter ?
Presumably the "correct" way to handle this is to install a "directly connected" route for each prefix - presumably this is most likely to happen if the prefixes come from different sources and one or other could be removed at any time.
If the destination address of the packet is within *any* prefix with a directly connected route then the device should use ND to locate the device. If not then it needs to send the packet via a router.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Mar 2015 06:05:10 +0900

On Tue, Mar 31, 2015 at 4:28 AM, Simon Hobson <[email-masked]>
wrote:

> Presumably the "correct" way to handle this is to install a "directly
> connected" route for each prefix - presumably this is most likely to happen
> if the prefixes come from different sources and one or other could be
> removed at any time.
> If the destination address of the packet is within *any* prefix with a
> directly connected route then the device should use ND to locate the
> device. If not then it needs to send the packet via a router.

Yes. In addition to that, the point I was trying to make is that if there
is no router, then there is no locally-attached prefix (except fe80::/64),
and the node can't send the packet.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 31 Mar 2015 15:55:45 +0200

On 3/30/15, Simon Hobson <[email-masked]> wrote:
>> And, in particular, what if there are two different prefixes advertised by
>> the RA and each can be qualified as "containing" the address - which one
>> should be the one?  Maybe the longest matching one, or maybe the last one
>> that fit during the search operation.
>
> Does it matter ?
> directly connected route then the device should use ND to locate the device.

I presume your phrasing does imply "taking into the account the value
of the on-link flag" ?

Because if the prefix does not have the on-link bit set, then you can
*not* by default use the ND to talk to another node within that prefix
- not unless you get a redirect that instructs you to talk to that
node directly.

--a

> If not then it needs to send the packet via a router.
>

---

From: Simon Hobson <[email-masked]>
Date: Tue, 31 Mar 2015 20:03:55 +0100

> - not unless you get a redirect that instructs you to talk to that

Err yes. TBH that's more detail than I'm familiar with - so I'll have to leave you more knowledgable people to sort the details ;-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Apr 2015 09:42:50 +0900

On Wed, Apr 1, 2015 at 4:03 AM, Simon Hobson <[email-masked]> wrote:

> Err yes. TBH that's more detail than I'm familiar with - so I'll have to
> leave you more knowledgable people to sort the details ;-)

Right. Perhaps we should leave the details to the RFCs where they are
specified? Proposed text:

Addresses received via DHCPv6 do not have any associated reachability
information. In order avoid the problems described in [RFC4943], hosts MUST
NOT assume that any IPv6 addresses are reachable on-link as a result of
receiving an IA_NA or IA_TA; IPv6 addresses obtained from IA_NA or IA_TA
MUST NOT be configured with any prefix length except /128.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Mar 2015 22:07:47 -0400

On Mar 31, 2015, at 8:42 PM, Lorenzo Colitti <[email-masked]> wrote:
> Addresses received via DHCPv6 do not have any associated reachability information. In order avoid the problems described in [RFC4943], hosts MUST NOT assume that any IPv6 addresses are reachable on-link as a result of receiving an IA_NA or IA_TA; IPv6 addresses obtained from IA_NA or IA_TA MUST NOT be configured with any prefix length except /128.

This looks okay, although "the problem described in RFC 4943" would be better as a plural, since there is more than one problem described in RFC 4943, and I think all of them are relevant.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Apr 2015 11:21:27 +0900

On Wed, Apr 1, 2015 at 11:07 AM, Ted Lemon <[email-masked]> wrote:

> > In order avoid the problems described in [RFC4943]
>
> This looks okay, although "the problem described in RFC 4943" would be
> better as a plural, since there is more than one problem described in RFC
> 4943, and I think all of them are relevant.
>

It was already plural. Though "in order avoid the problems" should be "in
order to avoid the problems".

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Mar 2015 22:28:01 -0400

On Mar 31, 2015, at 10:21 PM, Lorenzo Colitti <[email-masked]> wrote:
> It was already plural. Though "in order avoid the problems" should be "in order to avoid the problems".

Oops, sorry.   Dunno how I read that wrong, but you are indeed correct.