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

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Apr 2015 10:28:05 +0200

Le 01/04/2015 04:07, Ted Lemon a écrit :
> 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,

To me it does not look very much ok; it looks as an intention to tell to 
not use DHCPv6 to allocate addresses.

Why would a Client configure an unreachable /128 on its interface?

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 1 Apr 2015 11:58:11 +0100

>>> any prefix length except /128.

+1, looks clear, concise and not open to misinterpretation.

> To me it does not look very much ok; it looks as an intention to tell to not use DHCPv6 to allocate addresses.
> 

No and "it doesn't"

It looks like your problem is that you have not yet managed the jump in mindset from the IPv4 world (all IPs have an associated subnet, and IP+mask == reachability information) to the IPv6 world where an address is an address<period>. I took me some time, and it was only after a similar discussion here that the penny dropped for me. IMO that's part of the adoption problem - lots of people have become "familiar" (even if not technically competent !) with IPv4, and the jump to IPv6 isn't just a matter of adding a few bits to the address.

In the IPv4 world, you get an address and subnet mask. From that you work out the range of addresses in the same subnet, and from that you infer reachability information. Ie (in the absence of further configuration), if the address is in the same subnet you infer "on link" and do local discovery (ARP), if the address isn't in the same subnet you infer "not local" and send the packet via a router.

In the IPv6 world it's somewhat different.
You get one or more addresses by various means - self assigned link local, self assigned from range in advertised prefix  from a router, assigned by DHCP, manually configured. Specifically, the address(es) you have should not (apart from the link local etc prefixes) be used to infer reachability of other devices).
From separate sources, you get one or more prefixes that are active on your network. Note that for example, you could get a number of prefixes from more than one router - eg you have two routers, two internet services, two prefixes.
When you want to send a packet, the only consideration (over simplification, but go with it) is "is the other device on the local link ?" You answer that by the simple question : is the destination IP within one of the prefixes I've been told is on this link (and I'm allowed to use ND to find) ? If the answer is yes then you can use ND to find the other device - it does not matter one jot whether the IP address you decide to use is a /128, a /64, or something else. I assume (I'm no expert) that if A can talk to B using ND to locate it, then that infers that B is allowed to use the fact that A directly contacted it to infer that A is directly contactable - I'll leave that for one of the experts to clarify.

As I was corrected earlier, the RA may indicate that a prefix is not to be treated as "on link". It may well be that the network doesn't support device-device communications directly - access networks (eg ADSL) come to mind where each user has a point-point link back to the central hub and ND may not be supported to find other nodes on other links. Thus using "address + mask" to infer direct reachability is just wrong.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Apr 2015 07:20:26 -0400

> On Apr 1, 2015, at 6:58 AM, Simon Hobson <[email-masked]> wrote:
> 
> 

In my opinion, "IPv6 addresses obtained from IA_NA or IA_TA MUST NOT be configured with any prefix length except /128." Is unnecessary and should be elided (see below)

> It looks like your problem is that you have not yet managed the jump in mindset from the IPv4 world (all IPs have an associated subnet, and IP+mask == reachability information) to the IPv6 world wh…

Seems to me those words I suggest should be dropped encourage this linkage between an IPv6 address and a prefix length.  As Simon points out, The concept of configuring an address with a prefix length is a holdover from IPv4 and this text should not perpetuate the misconception.

We've been around this discussion before, and I understand some operating system CLIs incorrectly require a prefix length when an IPv6 address is configured.  It may even be the case that some stacks associate a prefix length with an assigned address rather than keeping reach ability separate from address assignment.  If text about prefix length with an assigned address is included in the text, additional words explaining this critical detail should be included.

- Ralph

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Apr 2015 13:28:52 +0200

Simon,

Reading you I think I misunderstood what is meant by 'reachable' and
'unreachable'.  You seem to imply that 'reachable' is a neighbor,
whereas I think 'reachable'  is from a neighbor or from the Internet
(like when we say that a 192. address is not reachable/contactable,
whereas a Globally Unique Address GUA _is_ reachable).

In that sense, maybe the text could be clarified to say: "Addresses
received via DHCPv6 are typically absent from the Neighbor Cache"
(instead of "not have reachability informnation".)

BTW, 'reachability' was absent last time I checked in a paper dictionary.

For clarification see below.

Alex

Le 01/04/2015 12:58, Simon Hobson a écrit :
>>>> 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,
>

To me it plainly negates any usefulness of DHCP-allocated addresses by
stating they are unreachable.

>> To me it does not look very much ok; it looks as an intention to
>> tell to not use DHCPv6 to allocate addresses.
>>
> It looks like your problem is that you have not yet managed the jump
> in mindset from the IPv4 world (all IPs have an associated subnet,
> and IP+mask == reachability information) to the IPv6 world where an
> address is an address<period>.
>
> I took me some time, and it was only after a similar discussion here
>  that the penny dropped for me. IMO that's part of the adoption
> problem - lots of people have become "familiar" (even if not
> technically competent !) with IPv4, and the jump to IPv6 isn't just a
> matter of adding a few bits to the address.

That is a fault in the IPv6 specification, not in the IPv4-skilled'
thoughts.

Ideally they were perfectly similiar modulo the 96 bits.

> In the IPv4 world, you get an address and subnet mask. From that you
> work out the range of addresses in the same subnet, and from that you
> infer reachability information.

So that is meant by 'reachability'?  The neighbor reachability?  I
thought it is Internet reachability.

> Ie (in the absence of further configuration), if the address is in
> the same subnet you infer "on link" and do local discovery (ARP), if
> the address isn't in the same subnet you infer "not local" and send
> the packet via a router.

So that is also 'reachable', but not neighbor.

> In the IPv6 world it's somewhat different. You get one or more
> addresses by various means - self assigned link local, self assigned
> from range in advertised prefix  from a router, assigned by DHCP,
> manually configured. Specifically, the address(es) you have should
> not (apart from the link local etc prefixes) be used to infer
> reachability of other devices).

This is again neighbor-reachability (not Internet reachability) right?

>> From separate sources, you get one or more prefixes that are
>> active on your network. Note that for example, you could get a
>> number of prefixes from more than one router - eg you have two
>> routers, two internet services, two prefixes.
>
> When you want to send a packet, the only consideration (over
> simplification, but go with it) is "is the other device on the local
> link ?" You answer that by the simple question : is the destination
> IP within one of the prefixes I've been told is on this link (and I'm
> allowed to use ND to find) ? If the answer is yes then you can use ND
> to find the other device - it does not matter one jot whether the IP
> address you decide to use is a /128, a /64, or something

Distinction: ok for /64, but if it's a /128 then it wouldn't have
neighbors (/128 can only be on one end, and that something can't be a link).

On another hand, a /128 on an interface is ok as long as there is an
corresponding /128 in the routing tables.  There is reachability from
everyone who gets there through such routers: on the same Ethernet
("link"?) or across the Internet.  In this respect it's precisely like
with IPv4 /32s.

> else. I assume (I'm no expert) that if A can talk to B using ND to
> locate it, then that infers that B is allowed to use the fact that A
>  directly contacted it to infer that A is directly contactable - I'll
>  leave that for one of the experts to clarify.

SO this contactable would be the reachable we talk about.

> As I was corrected earlier, the RA may indicate that a prefix is not
> to be treated as "on link".

That is another artifact that is artificial.  Indeed RAs have this
on-link and off-link flag for a prefix, but it sounds unnatural.  If
it's not on a link then it's on a what.

> It may well be that the network doesn't support device-device
> communications directly - access networks (eg ADSL) come to mind
> where each user has a point-point link back to the central hub and
> ND may not be supported to find other nodes on other links. Thus
> using "address + mask" to infer direct reachability is just wrong.

So, one would not think an unreachable address is of any use at all. (be
its reachability inferred solely from address or from both address/mask)

Alex

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

---

From: Simon Hobson <[email-masked]>
Date: Wed, 1 Apr 2015 14:21:49 +0100

> whereas a Globally Unique Address GUA _is_ reachable).

You make a good point there. Yes, I've been using "reachable" as meaning "I can directly send a packet to that device".

> Ideally they were perfectly similiar modulo the 96 bits.

I disagree.
There are many things "wrong" in IPv4 - or at least very suboptimal. AIUI it was never intended to be used as it ended up being used when it was first defined. While it can certainly be argued that IPv6 is "too complicated", the decision was taken (rightly IMO) to take the transition as an opportunity to engineer a "new" protocol that takes into account the decades of experience - does some things "better", does some things "differently", and does a fair few things that were difficult before.

> So that is also 'reachable', but not neighbor.

But it may well be a neighbour. It's not that uncommon to have multiple IPv4 subnets on one link. To handle this means either sending all inter-subnet traffic through a router, or configuring additional routing table entries on each device.

> This is again neighbor-reachability (not Internet reachability) right?

Yes

> neighbors (/128 can only be on one end, and that something can't be a link).

NO You **CAN** have a "/128" and have neighbours. Well actually, the "/128" is an artificial construct required to work around the implementations which (incorrectly) require every address to have a subnet mask. If correctly implemented, you have "an address" (or multiple addresses, but lets just consider one for now).

Separately to any address(es) you have, you have a table of how to send packets to other addresses. Your own address does not have to be in that list.

It's been mentioned that one thread originated from a comment in some code along the lines of "what do I use for a prefix length - until someone comes up with something I'll use 64". That's an implementation issue - and I think it'll be a long time before the Linux world manages to unravel several decades of built in logic to separate addresses and prefixes/reachability information.

> its reachability inferred solely from address or from both address/mask)

You've probably highlighted the main issue - one of terminology, and I think I'm as guilty as anyone of being a bit sloppy. I *think* the terminology is "on-link" meaning you can directly communicate with that other device (use ND to find it's physical address, MAC in ethernet like networks), and "off-link" meaning that you cannot directly communicate with it and must go via a router.

It would probably help if one of the experts clarified this.

On an ethernet network, two devices with completely unrelated addresses may directly communicate as long as they have a means of finding out about each other. This is where the RA provided prefix lists (with their on-link flag) come in - by configuring the routing tables. Note that a prefix only needs one table entry, whether you have 1, 100, 100,000 addresses on the interface.

On the other hand, there are probably networks where the end-points all have addresses which are in the same prefix, but which cannot directly communicate end-point to end-point without going via the hub. Granted these probably all use a /64 prefix for each link, that's my experience so far in getting connected (via my ISPs trial, and currently via a Hurricane Electric tunnel).
It may not be a fundamental feature of the underlying technology - I manage some wireless kit at work which has the option of enforcing client separation (preventing end-points from directly communicating with each other). It's quite conceivable that someone may use such a feature for security - prevent direct node-node communications, but allow indirect communications via some security appliance. Again, using "address+prefix" to infer that you can directly contact a node will produce incorrect results.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 1 Apr 2015 10:21:53 -0700

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

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

One other, radical option, mainly for food for thoughts (or rants):

- deprecate RFC4943: if the client employed the "on-link assumption",
  /128 without default router would work perfectly.  While RFC4943
  discusses several different problems, my understanding is that the
  principal issue was that we could introduce annoying delay on a dual
  stack host with a global IPv6 address but without a default router
  until it falls back to a reachable IPv4 destination.  But the latest
  practice is that just killing the on-link assumption wasn't enough
  and we need something more sophisticated (or uglier) techniques like
  the happy eyeball.  With such latest practice, I wonder whether the
  "on-link assumption" might not be as bad as when RFC4943 was
  written.

Assuming this is too radical/controversial/bad to be accepted, though,
I'll then focus on the text Lorenzo proposed (later in this thread):

  Addresses received via DHCPv6 do not have any associated reachability
  information. In order to 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.

I agree with this statement per se, but I think this is not
sufficient, since it doesn't (clearly) answer the question of what the
operator should do if they want to use DHCPv6-based address assignment
in an isolated single-link (or "subnet") network.  The
"architecturally correct" answer will be that they should deploy a
node (which would probably be collocated on the same node as the
DHCPv6 server) that sends RAs with router lifetime being 0 and with
appropriate on-link prefix(es).  This may be obvious for those
protocol-savvy people, but I suspect it's too subtle and should be
explained explicitly for many ordinary people.  Whether this should be
in 3315bis or some other DHCPv6-related document is a different
question, though.

--
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 09:02:22 +0200

Le 01/04/2015 15:21, Simon Hobson a écrit :
>> Reading you I think I misunderstood what is meant by 'reachable'
>> and 'unreachable'.  You seem to imply that 'reachable' is a
>> neighbor, whereas I think 'reachable'  is from a neighbor or from
>> the Internet (like when we say that a 192. address is not
>> reachable/contactable, whereas a Globally Unique Address GUA _is_
>> reachable).
>
> You make a good point there. Yes, I've been using "reachable" as
> meaning "I can directly send a packet to that device".

Ok, directly meaning to not go through a router, be on same link.  It
may to invoke ND for it, though.  So this NC absence for a /128 is not
necessarily explaining your directly.

[...]
> But it may well be a neighbour. It's not that uncommon to have
> multiple IPv4 subnets on one link. To handle this means either
> sending all inter-subnet traffic through a router, or configuring
> additional routing table entries on each device.

So that is is a neighbor in Ethernet terms, but is not a neighbor in ND
terms.

[...]
> NO You **CAN** have a "/128" and have neighbours.

These are Ethernet neighbors, but they are not ND neighbors.  ND works
with a multicast scope.  Whoever is in that scope is a neighbor,
otherwise it is not a neighbor.  Ethernet neighbors are all people
present on a VLAN or a on a hub and there may be multiple
distinguishable IP multicast scopes there, although a single Ethernet
multicast scope is in a VLAN (or in a hub).

> Well actually, the "/128" is an artificial construct required to
> work around the implementations which (incorrectly) require every
> address to have a subnet mask. If correctly implemented, you have
> "an address" (or multiple addresses, but lets just consider one for
> now).
>
> Separately to any address(es) you have, you have a table of how to
> send packets to other addresses. Your own address does not have to be
> in that list.

Ok.

> It's been mentioned that one thread originated from a comment in some
> code along the lines of "what do I use for a prefix length - until
> someone comes up with something I'll use 64".

That is a DHCP client suite - the guy does not know what to put there,
he needs help.  Until that help arrives he puts 64, and it works.

That 64 is something not good at all because it forbids CIDR in IPv6.
We are not there yet to sense how CIDR is important in IPv6, but as this
IPv6 started it looks as CIDR is going to be important.

> That's an implementation issue - and I think it'll be a long time
> before the Linux world manages to unravel several decades of built in
> logic to separate addresses and prefixes/reachability information.

I tend to agree.  Other times things may move really fast.

>>> where each user has a point-point link back to the central hub
>>> and ND may not be supported to find other nodes on other links.
>>> Thus using "address + mask" to infer direct reachability is just
>>>  wrong.
>>
>> So, one would not think an unreachable address is of any use at
>> all. (be its reachability inferred solely from address or from both
>> address/mask)
>
> You've probably highlighted the main issue - one of terminology, and
>  I think I'm as guilty as anyone of being a bit sloppy. I *think* the
>  terminology is "on-link" meaning you can directly communicate with
> that other device (use ND to find it's physical address, MAC in
> ethernet like networks), and "off-link" meaning that you cannot
> directly communicate with it and must go via a router.

SO why is RA talking at all about off-link information on this link?  I
thought RAs are not allowed to talk about other things than what's
happening on this link.

For example, there is no means to inform a Router that a certain prefix
is active on this link and should inform this directly-attached other
link about its prefix.

There is no means to propagate a prefix received in an RA (or any other
information in an RA) to other networks.

What's the use of this 'off-link' in RA?  (other than telling Hosts to
not care about it).

> It would probably help if one of the experts clarified this.

I agree.

Alex

>
> On an ethernet network, two devices with completely unrelated
> addresses may directly communicate as long as they have a means of
> finding out about each other. This is where the RA provided prefix
> lists (with their on-link flag) come in - by configuring the routing
>  tables. Note that a prefix only needs one table entry, whether you
> have 1, 100, 100,000 addresses on the interface.
>
> On the other hand, there are probably networks where the end-points
> all have addresses which are in the same prefix, but which cannot
> directly communicate end-point to end-point without going via the
> hub. Granted these probably all use a /64 prefix for each link,
> that's my experience so far in getting connected (via my ISPs trial,
>  and currently via a Hurricane Electric tunnel). It may not be a
> fundamental feature of the underlying technology - I manage some
> wireless kit at work which has the option of enforcing client
> separation (preventing end-points from directly communicating with
> each other). It's quite conceivable that someone may use such a
> feature for security - prevent direct node-node communications, but
> allow indirect communications via some security appliance. Again,
> using "address+prefix" to infer that you can directly contact a node
>  will produce incorrect results.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 09:13:35 +0200

Le 01/04/2015 19:21, 神明達哉 a écrit :
> appropriate on-link prefix(es).

I agree that a recommendation should be given about - if - the DHCPv6 is
used to allocate addresses. Currently neither spec nor deployment is
functioning correctly when DHCPv6 is in place.

But, a Router-DHCPv6Server with router lifetime 0 and on-link prefix
will make think the Host this is not a default router and it should
SLAAC its address (maybe in addition to requesting one from DHCPv6). Is
this what is meant by the above?

Another suggestion on another hand is to have DHCPv6 deliver a prefix
length together with the address, and a default route. That'd be a form
of independence, and avoid '/64' CIDR-breaking assumptions.

Or maybe just add prefixlen to DHCPv6 and see how deployment goes, and
check back later.

Alex

   This may be obvious for those

---

From: Simon Hobson <[email-masked]>
Date: Thu, 2 Apr 2015 08:20:42 +0100

> So that is is a neighbor in Ethernet terms, but is not a neighbor in ND

Eh ?
How is it not a neighbour in ND terms ?

> otherwise it is not a neighbor.

OK, so you send out your multicast packet, it arrives at another node, that node responds. How is that not a neighbour ?

>> It would probably help if one of the experts clarified this.

At this point, I've been looking at RFC 4861  http://tools.ietf.org/html/rfc4861
Here are a couple of definitions from it which might clear things up a little, terminology wise :-)

   reachability
               - whether or not the one-way "forward" path to a neighbor
                 is functioning properly.  In particular, whether
                 packets sent to a neighbor are reaching the IP layer on
                 the neighboring machine and are being processed
                 properly by the receiving IP layer.  For neighboring
                 routers, reachability means that packets sent by a
                 node's IP layer are delivered to the router's IP layer,
                 and the router is indeed forwarding packets (i.e., it
                 is configured as a router, not a host).  For hosts,
                 reachability means that packets sent by a node's IP
                 layer are delivered to the neighbor host's IP layer.

That pretty much seems to me to be saying that for nodes, reachability means "I can send a packet on this link and it will arrive at the neighbour without the help of a router".

   on-link     - an address that is assigned to an interface on a
                 specified link.  A node considers an address to be on-
                 link if:

                    - it is covered by one of the link's prefixes (e.g.,
                      as indicated by the on-link flag in the Prefix
                      Information option), or

                    - a neighboring router specifies the address as the
                      target of a Redirect message, or

                    - a Neighbor Advertisement message is received for
                      the (target) address, or

                    - any Neighbor Discovery message is received from
                      the address.

   off-link    - the opposite of "on-link"; an address that is not
                 assigned to any interfaces on the specified link.

Which again seems to be saying that if an address is in any prefix given to me in an RA with the right flag set, OR if I hear from another node via ND, then the address is on-link.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Apr 2015 16:26:43 +0900

On Wed, Apr 1, 2015 at 10:21 PM, Simon Hobson <[email-masked]>
wrote:

> Well actually, the "/128" is an artificial construct required to work
> around the implementations which (incorrectly) require every address to
> have a subnet mask. If correctly implemented, you have "an address" (or
> multiple addresses, but lets just consider one for now).
>

Actually, I don't see it as incorrect, but rather as a convenience.
"2001:db8::1/64" is a compact notation that allows one string to express
both an address (2001:db8::1) and a directly-connected route
(2001:db8::/64). The special case "2001:db8::1/128" a special case that
expresses only the address.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Apr 2015 16:37:09 +0900

On Thu, Apr 2, 2015 at 2:21 AM, 神明達哉 <[email-masked]> wrote:
>
> it doesn't (clearly) answer the question of what the

That is the correct answer, yes. By itself, an IPv6 address assigned via
IA_NA or IA_TA cannot be used for anything. Perhaps we can just clarify it
here by noting the following:

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 destinations are reachable on-link as a result of
receiving an IA_NA or IA_TA. In order to communicate to any destination
that is not a link-local address, the host must also have obtained
reachability information by other means such as a Router Advertisement or
manual configuration.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 2 Apr 2015 10:09:44 +0100

Something has just occurred to me ...
From memory (and I stand to be corrected), (IPv6) clients don't use DHCP unless they get RAs with the managed flag set ?
So if there are no routers, there'll be no RAs, so no managed flag, so clients won't use DHCP to get addresses.

Does that therefore mean that the case mentioned earlier - how to use DHCP assigned addresses without any prefix information from RAs - is moot since the absence of routers implies that DHCP won't get used ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 11:14:13 +0200

Le 02/04/2015 09:20, Simon Hobson a écrit :
>>> sending all inter-subnet traffic through a router, or
>>> configuring additional routing table entries on each device.
>>
>> So that is is a neighbor in Ethernet terms, but is not a neighbor
>> in ND terms.
>
> Eh ? How is it not a neighbour in ND terms ?

Right, I think I was wrong on that.

>
>
>> [...]
>>>> Distinction: ok for /64, but if it's a /128 then it wouldn't
>>>> have neighbors (/128 can only be on one end, and that something
>>>> can't be a link).
>>>
>> These are Ethernet neighbors, but they are not ND neighbors.  ND
>> works with a multicast scope.  Whoever is in that scope is a
>> neighbor, otherwise it is not a neighbor.
>
> OK, so you send out your multicast packet, it arrives at another
> node, that node responds. How is that not a neighbour ?

Right.

I think I meant to say they are not neighbors on the same subnet,
although yes they are neighbors in ND terms and neighbors in the same
Ethernet.

In that sense, one can't have an address with prefixlen /128 and have
any neighbor in that /128 subnet, there is no place left.  Someone with
a /127 could have only one other neighbor (these are the point to point
links).

One could say that one has an address A with prefix length /128, and be
in a /64 subnet.  But that would make little sense if any to have a
prefix length /128 and be in a /64 subnet, because 128!=64.

> At this point, I've been looking at RFC 4861
> http://tools.ietf.org/html/rfc4861 Here are a couple of definitions
> from it which might clear things up a little, terminology wise :-)
>
> reachability - whether or not the one-way "forward" path to a
> neighbor is functioning properly.

Thanks for the pointer.  I can tell that this is not what is meant by
reachability in other contexts, like in Mobile IP.

A "forward" path to a neighbor makes little sense because that path is
0-hop away, forward is same as backward in most links, although some
assymmetry in bandwidth may be felt on wireless links.

> In particular, whether packets sent to a neighbor are reaching the IP
> layer on the neighboring machine and are being processed properly by
> the receiving IP layer. For neighboring routers, reachability means
> that packets sent by a node's IP layer are delivered to the router's
> IP layer, and the router is indeed forwarding packets (i.e., it is
> configured as a router, not a host).

I think it means routers that specifically are IP neighbors to that
Host, not just arbitrary neighboring routers.

I think "node's IP layer" is actually meant to say "Host's IP layer",
because a "node" can be either a "Router" or a "Host" or both (RFC ref).

> For hosts, reachability means that packets sent by a node's IP layer
> are delivered to the neighbor host's IP layer.

And unreachability means that node's IP layer are _not_ delivered to the
neighbor host's IP layer?

> That pretty much seems to me to be saying that for nodes,
> reachability means "I can send a packet on this link and it will
> arrive at the neighbour without the help of a router".

The help of a router could happen in at least two ways: forward and ICMP
redirect: which one do you think?  Second, do you think that when a
router _is_ involved then we can call the two neighbors to be "unreachable"?

> specified link.  A node considers an address to be on- link if:
>
> - it is covered by one of the link's prefixes (e.g., as indicated by
>  the on-link flag in the Prefix Information option), or
>
> - a neighboring router specifies the address as the target of a
> Redirect message, or
>
> - a Neighbor Advertisement message is received for the (target)
> address, or
>
> - any Neighbor Discovery message is received from the address.
>

This off-link definition is not self-contained - it does not use a
"specified link."

We never say that address A-and-link1 is off-link.

Saying A is off-link is not a correct use of the definion above because
it does not specify the "specified link".

> Which again seems to be saying that if an address is in any prefix
> given to me in an RA with the right flag set, OR if I hear from
> another node via ND, then the address is on-link.

This is just an appearance.

The term off-link is used several times throughout RFC4861 without 
actually respecting its own definition in that RFC proper.

For example, the RFC says:
> A router acting on behalf of a mobile node that has moved off-link
> could potentially act as a proxy for the mobile node.

The term "off-link" is used, but the "specified link" (per definition) 
is not present.  Moreover, the definition tells "off-link" is an 
"address", whereas in this use this "off-link" is simply a qualifier of 
the mouvement.

We can understand the phrase, the node moved out of the link, off of the 
link; but the term "off-link" is not well defined.

Furthe, RFC says:
>     L              1-bit on-link flag.  When set, indicates that this
>                      prefix can be used for on-link determination.  When
>                      not set the advertisement makes no statement about
>                      on-link or off-link properties of the prefix.  In
>                      other words, if the L flag is not set a host MUST
>                      NOT conclude that an address derived from the
>                      prefix is off-link.  That is, it MUST NOT update a
>                      previous indication that the address is on-link.

This definition means that it means nothing.  It gives no indication. 
It's just like the M flag.

If L then something, otherwise nothing.  This is not what me as 
implementer would like to see.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Thu, 2 Apr 2015 12:52:22 +0100

Alexandru Petrescu <[email-masked]> wrote:

> any neighbor in that /128 subnet, there is no place left.

That's correct, but it doesn't really matter.
What matters is "can we find the other node" and "can the other node find us". For example, I could come up with a rather bizarre network where every device has a random address but I assign no prefixes to it. Each device will (initially) have no concept of what other devices may be "local" to it - so every connection will have to be made via a router - ie to start off with, every other address but our own is "off-link".
Assuming the router knows about the other devices, when we open a connection by sending packets to the router, the router can tell us (via a redirect) about the other node being on-link. At this point, we then know to use ND to find the other node and it becomes on-link to us for as long as the neighbour information is kept active. This doesn't need *ANY* prefix information at all - only knowledge of a router we can use to send our packets out.

As I say, that's a rather contrived situation. For something a bit more run of the mill ... lets consider two subnets on the same link. When determining if the destination is on-link, we only need the destination address and a list of prefixes - our own address does not matter. If the destination address is within any of the prefixes we've been told is on-link, then we use ND to find it and talk to it. Once we've contacted that other device, it now knows that we're here - regardless of whether we are even in any of the prefixes.

> it does not specify the "specified link".

I'm not quite sure what you're saying here. Any on/off-link determination has to be done per link. For a multihomed device, there will be other nodes that are on-link for one interface and off-link for another.
So we should in fact be saying things like "A is on-link for interface foo" and "A is off-link for interface bar". However, I think most of us are used to omitting certain information when working at higher levels - eg if I type "ping  <some address>" I normally won't specify an interface (link) to be used - I let the system work that out. So my only consideration would be "Is A on-link for any of my interfaces, or is it off-link for all of them". Of course there are times when it does matter, and then I'll specify either an interface or source address*.

* I actually tend to do that a lot on our own internal networks (mix of public and RFC1918) - for "historical reasons" we have some not very complicated but very irritating restrictions.

> The term off-link is used several times throughout RFC4861 without actually respecting its own definition in that RFC proper.
> 
> The term "off-link" is used, but the "specified link" (per definition) is not present.  Moreover, the definition tells "off-link" is an "address", whereas in this use this "off-link" is simply a qualifier of the mouvement.
> 
> We can understand the phrase, the node moved out of the link, off of the link; but the term "off-link" is not well defined.

Again, I think context is everything. For something that's "moved off-link", we can infer that it's no longer on the link it used to be on. If it were to appear "on-link" for some other link then that complicates matters, but I don't think that in context it is wrong.

> This definition means that it means nothing.  It gives no indication. It's just like the M flag.
> 
> If L then something, otherwise nothing.  This is not what me as implementer would like to see.

I can only see one issue - and without having digested the RFC I don't know if it's addressed.
If an RA sets the L bit, and then unsets it later, the above says that we carry on treating the prefix as local. How often is this likely to happen in practice ? I'm not sure I can envisage a network where it supports ND, but then changes (without any host links going down) into one where ND no longer works.

What comes to mind is if an RA from one router sets it, another router sends RA with it unset, and then the first router goes/has the prefix removed/whatever. Does a node keep track of which RAs it got from each router, does it then say that the prefix is now not local because the RA that set it as local has stopped and there's no other RA that has it set ?
Conversely, if the above said that getting an RA with the L bit clear means you have to update the prefix information, the next question would be "what about multiple RAs for the same prefix with different states for the L bit ?"

As for "do nothing" being untenable - isn't that what a lot of programming is about ? Ie "if <condition> then do <something>". In this case it seems simple enough - if we get an RA with L set, and we already have a prefix in the table (for that link) with it unset, then set it in our table". The mechanism for it getting unset is for the prefix to get removed from the table = which will happen if the link "goes down", or if we stop getting any RAs with the prefix. As above, I can't think of any situation (other than admin cock-up !) where there would be any need to unset the local flag in the prefix table.

---

From: Karl Auer <[email-masked]>
Date: Thu, 02 Apr 2015 20:52:20 +1100

> So if there are no routers, there'll be no RAs, so no managed flag, so clients won't use DHCP to get addresses.

I think people have been working on that for a bit, but my reading of
the RFC says that's wrong. The managed bit is informative only -
"addresses are available for this link via DHCP". There is no obligation
on the host to use DHCP to obtain an address. Same for the "O" flag - it
simply informs hosts on the link that ancillary information is available
via DHCP, there is no obligation on a host to obtain ancillary
information via DHCP.

Others have interpreted it as you did - that the presence of the M and O
flags impose a requirement that hosts use DHCP to obtain addresses and
ancillary information, I think that is wrong, because it leaves open
what the *absence* of those flags means. If an RA comes past with no M
flag, does a host have to drop it's DHCP-acquired address(es)
immediately? Or should it let them die naturally, i.e. wait out the
preferred and valid lifetimes it obtained with the addresses? What
should a host do if it obtained (say) nameserver information via DHCP
and an RA comes past with no M and no O flag? Should it forget its
nameserver information?

Treating the DHCP flags as informative avoids all those questions - once
an address is obtained via DHCP, you follow the rules - time it out
according to the preferred and valid lifetimes, just like any other
address.

Interpreting those flags as anything other than informative opens a
major can of worms. But TBH I have not been following recent discussion
on the matter, so maybe the worms have been tamed.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

---

From: Simon Hobson <[email-masked]>
Date: Thu, 2 Apr 2015 15:00:47 +0100

On 2 Apr 2015, at 10:52, Karl Auer <[email-masked]> wrote:

> on the host to use DHCP to obtain an address.

I was assuming it's the other way round - unless you see an RA with a managed flag, then DHCP isn't available or isn't to be used. I'll confess that other than a very brief attempt some time ago, I've not tried DHCPv6 - when I tried it, devices* didn't seem to get an address and from watching discussion on other lists I put 2+2 together and got the answer 5, you need the managed flag in an RA for a node to use DHCP.

* In particular my Mac which didn't even seem to attempt to get an address.

That was a while ago, and I've not had the time to try it again since - home is working, and lets just say there's little enthusiasm for IPv6 at work :-(

However, where I am uneasy is the concept of "information" like this. A node can figure out whether there's a DHCP server present or not. Having a flag that says DCHP is available but you don't have to use it is not very meaningful IMO - it doesn't say anything more than what can be inferred by the presence of a DHCP server.
Or have I missed something ?

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 2 Apr 2015 15:01:10 +0000

> On Apr 2, 2015, at 10:00 AM 4/2/15, Simon Hobson <[email-masked]> wrote:
> 
> 

The semantics of the M/O bits - and, please, let's not revisit that /dev/null discussion? - are, at this point, informative only.  RFC 7084, for example, specifies that a CE router uses DHCPv6 on its WAN link regardless of whether or not it receives an RA with the M bit set.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 19:23:21 +0200

Le 02/04/2015 13:52, Simon Hobson a écrit :
>>>>>> Distinction: ok for /64, but if it's a /128 then it
>>>>>> wouldn't have neighbors (/128 can only be on one end, and
>>>>>> that something can't be a link).
>>>>>
>>>> These are Ethernet neighbors, but they are not ND neighbors.
>>>> ND works with a multicast scope.  Whoever is in that scope is
>>>> a neighbor, otherwise it is not a neighbor.
>>>
>> although yes they are neighbors in ND terms and neighbors in the
>> same Ethernet.
>>
>> In that sense, one can't have an address with prefixlen /128 and
>> have any neighbor in that /128 subnet, there is no place left.
>
> That's correct, but it doesn't really matter. What matters is "can we
> find the other node" and "can the other node find us".

Ok, so.

> For example, I could come up with a rather bizarre network where
> every device has a random address but I assign no prefixes to it.

Ok.

> Each device will (initially) have no concept of what other devices
> may be "local" to it - so every connection will have to be made via
> a router - ie to start off with, every other address but our own is
> "off-link".

This is too tortuous to my mind.  It means that the address is not on
any link and it is not "off-link" in that RFC's terms either.

It could have better been "off subnet" or "out of any subnet".

> Assuming the router knows about the other devices, when we open a
> connection by sending packets to the router, the router can tell us
> (via a redirect) about the other node being on-link. At this point,
> we then know to use ND to find the other node and it becomes on-link
>  to us for as long as the neighbour information is kept active. This
>  doesn't need *ANY* prefix information at all - only knowledge of a
> router we can use to send our packets out.

Well, yes and no.

Yes in that it can work as you describe.  And that prefix lengths must
be there during that operation.  The lenghts involves are /128 and /0.
If they are not there it does not work.  In this sense: yes, a DHCPv6
/128 allocation to a Client can easily mean that Client _is_ reachable. 
  (this is how some point-to-point links work anyways).

No in that Redirect does not tell whether somebody is onlink or not, it
just redirects to a better first-hop router, which will presumably be
that other neighbor-on-link (but not neighbor-on-same-subnet):
RFC says:
>
> 4.5. Redirect Message Format
>
>
> Routers send Redirect packets to inform a host of a better first-hop
> node on the path to a destination.  Hosts can be redirected to a
> better first-hop router but can also be informed by a redirect that
> the destination is in fact a neighbor.

"in fact a neighbor"?  It is a neighbor on the same link, but it is not
a neighbour in the same subnet, because there is no subnet.  Is a 
neighbor "on-link"?  We dont know.

In fact, this entire terminology of "on-link determination" is not
described anywhere.  You have some bits here and there about who
contributes to it, but there is no section telling that is the on-link
determination operation.  With hands empty you  can only  suppose what
it is, and implement in a certain manner (longest match dst to rt table
entries, if found then ND dst and send packet to that MAC otherwise ND
the default router's IP address and send packet to that other MAC
address).  That's how I believe it should be but no document tells how
it should be.  It just says "on-link determination".

> As I say, that's a rather contrived situation. For something a bit
> more run of the mill ... lets consider two subnets on the same link.
>  When determining if the destination is on-link, we only need the
> destination address and a list of prefixes - our own address does not
> matter. If the destination address is within any of the prefixes
> we've been told is on-link,

When I type "route -6" there are some routes but there is not one that
says "this is on-link, this is not on-link".

> then we use ND to find it and talk to it. Once we've contacted that
> other device, it now knows that we're here - regardless of whether we
> are even in any of the prefixes.

Yes.

>>> - it is covered by one of the link's prefixes (e.g., as indicated
>>> by the on-link flag in the Prefix Information option), or
>>>
>> Saying A is off-link is not a correct use of the definion above
>> because it does not specify the "specified link".
>
> I'm not quite sure what you're saying here. Any on/off-link
> determination has to be done per link.

What is precisely the "on-link determination"? (some RFC section titled 
so that I missed?)

> For a multihomed device, there will be other nodes that are on-link
> for one interface and off-link for another. So we should in fact be
> saying things like "A is on-link for interface foo" and "A is
> off-link for interface bar".

Ok.

> However, I think most of us are used to omitting certain information
>  when working at higher levels - eg if I type "ping  <some address>"
> I normally won't specify an interface (link) to be used - I let the
> system work that out.

And, of course, it can figure it out only if it is not link-local.  If
you ping an LL address you have to say a -I iface because the computer 
can't determine the interface from its rt table (it has an fe80::/10 
entry for each interface).

> So my only consideration would be "Is A on-link for any of my
> interfaces, or is it off-link for all of them". Of course there are
> times when it does matter, and then I'll specify either an interface
> or source address*.

I can understand your interpretation in your setting.

In my setting I avoid saying something is "on-link" or "off-link",
because I know people have different understandings for each.

>
> * I actually tend to do that a lot on our own internal networks (mix
>  of public and RFC1918) - for "historical reasons" we have some not
> very complicated but very irritating restrictions.
>
>>> Which again seems to be saying that if an address is in any
>>> prefix given to me in an RA with the right flag set, OR if I hear
>>> from another node via ND, then the address is on-link.
>>
>>> A router acting on behalf of a mobile node that has moved
>>> off-link could potentially act as a proxy for the mobile node.
>>
>> The term "off-link" is used, but the "specified link" (per
>> definition) is not present.  Moreover, the definition tells
>> "off-link" is an "address", whereas in this use this "off-link" is
>>  simply a qualifier of the mouvement.
>>
>> We can understand the phrase, the node moved out of the link, off
>> of the link; but the term "off-link" is not well defined.
>
> Again, I think context is everything. For something that's "moved
> off-link", we can infer that it's no longer on the link it used to be
> on. If it were to appear "on-link" for some other link then that
> complicates matters, but I don't think that in context it is wrong.

It is not wrong, it is just misleading and not self-containing; it is
not implementable in an interoperable manner.

>
>> Furthe, RFC says:
>>> L              1-bit on-link flag.  When set, indicates that
>>> this prefix can be used for on-link determination.  When not set
>>> the advertisement makes no statement about on-link or off-link
>>> properties of the prefix.  In other words, if the L flag is not
>>> set a host MUST NOT conclude that an address derived from the
>>> prefix is off-link.  That is, it MUST NOT update a previous
>>> indication that the address is on-link.
>>
> I can only see one issue - and without having digested the RFC I
> don't know if it's addressed. If an RA sets the L bit, and then
> unsets it later, the above says that we carry on treating the prefix
>  as local. How often is this likely to happen in practice ? I'm not
> sure I can envisage a network where it supports ND, but then changes
>  (without any host links going down) into one where ND no longer
> works.
>
> What comes to mind is if an RA from one router sets it, another
> router sends RA with it unset, and then the first router goes/has the
> prefix removed/whatever. Does a node keep track of which RAs it got
> from each router, does it then say that the prefix is now not local
> because the RA that set it as local has stopped and there's no other
> RA that has it set ? Conversely, if the above said that getting an RA
> with the L bit clear means you have to update the prefix information,
> the next question would be "what about multiple RAs for the same
> prefix with different states for the L bit ?"

Right, the dynamics of the L bit are hardly known.  I dont see it, and I
dont set it.

>
> As for "do nothing" being untenable - isn't that what a lot of
> programming is about ?

Right, sorry, I miss-wrote that if statement.

I meant to say that when L is unset we dont know what to do (we dont
know whether that is onlink or offlink).  As such it's sent for no
reason and should be ignored.

> Ie "if <condition> then do <something>". In this case it seems simple
> enough - if we get an RA with L set, and we already have a prefix in
> the table (for that link) with it unset, then set it in our table".

But the spec does not tell that you should do it that way.  It says if L
is unset then you dont know.

 > The mechanism for it getting unset is
> for the prefix to get removed from the table = which will happen if
> the link "goes down", or if we stop getting any RAs with the prefix.
> As above, I can't think of any situation (other than admin cock-up
> !) where there would be any need to unset the local flag in the
> prefix table.

There is no reason for that.  Entries will expire by themselves anyways, 
no need to announce going down.  Expiration can be planned be quicker by 
using shorter lifetimes, too.

Sorry for bashing too much at this.  I remember a long discussion about 
the L bit and the conclusion is so inconclusive that since then I still 
do not see the L bit unset.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 19:38:11 +0200

Le 02/04/2015 16:00, Simon Hobson a écrit :
>>> From memory (and I stand to be corrected), (IPv6) clients don't
>>> use DHCP unless they get RAs with the managed flag set ? So if
>>> there are no routers, there'll be no RAs, so no managed flag, so
>>> clients won't use DHCP to get addresses.
>>
>> I think people have been working on that for a bit, but my reading
>> of the RFC says that's wrong. The managed bit is informative only -
>> "addresses are available for this link via DHCP". There is no
>> obligation on the host to use DHCP to obtain an address.
>
> I was assuming it's the other way round - unless you see an RA with
> a managed flag, then DHCP isn't available or isn't to be used.

The way I see it is  like this: if M flag is set then there is no prefix
in RA, and DHCPv6 is there.  This makes sense, and it is implemented in
a cellular system.

There are still problems with this (def route missing, prefixlen
missing, DNS missing, etc), and I keep complaining about it at both
places: IETF and to operator.  IETF made 'M' unclear, made
DHCPv6-defroute to be architecturally wrong; Operator puts little trust
in DHCPv6' future.  That's how the situation stands.

> I'll confess that other than a very brief attempt some time ago, I've
> not tried DHCPv6 - when I tried it, devices* didn't seem to get an
> address and from watching discussion on other lists

I can say that with linux and bsd there are multiple opensource DHCPv6
implementations maintained and advancing.  I even heard of a new one
called kea.

> I put 2+2 together and got the answer 5, you need the managed flag
> in an RA for a node to use DHCP.

Right.  And I know RA implemementations that do.

> * In particular my Mac which didn't even seem to attempt to get an

Is there a DHCPv6 client for MAC?

> That was a while ago, and I've not had the time to try it again
> since - home is working, and lets just say there's little enthusiasm
> for IPv6 at work :-(

Right.  At other places there is much enthusiasm for DHCPv6 because it
ressembles to DHCPv4 for its controlling features.  Also,  since a /64
prefix surprisingly means much less than 2^64 addresses, and means one
and single subnet - only DHCPv6 can solve that.

> However, where I am uneasy is the concept of "information" like
> this. A node can figure out whether there's a DHCP server present or
> not. Having a flag that says DCHP is available but you don't have to
> use it is not very meaningful IMO - it doesn't say anything more
> than what can be inferred by the presence of a DHCP server.

I agree.

Certainly just like RS discovers routers the DHCPv6 Solicit discovers
DHCPv6 Servers, there is no difference.  I guess an M/O flag should be
removed altogether.

Alex

  Or have I
> missed something ?

---

From: 神明達哉 <[email-masked]>
Date: Thu, 2 Apr 2015 11:05:56 -0700

At Thu, 02 Apr 2015 09:13:35 +0200,

[...]
> this what is meant by the above?

Not at all.  I didn't mean to say anything about SLAAC in the above
"architecturally correct answer".

> of independence, and avoid '/64' CIDR-breaking assumptions.

That would lead to a long standing debate of whether DHCPv6 should
propagate on-link prefix and/or default route information, and I tried
to avoid that part of discussion as I knew it would never converge:-)
In any case if we really want to discuss it again, it would be better
to do it outside the scope of 3315bis.

--
jinmei

---

From: 神明達哉 <[email-masked]>
Date: Thu, 2 Apr 2015 11:13:57 -0700

At Thu, 2 Apr 2015 16:37:09 +0900,

> information. In order avoid the problems described in [RFC4943], hosts MUST
                       ^ missing 'to' again:-)
> reachability information by other means such as a Router Advertisement or

It looks good to me.  I think a paragraph like this is good enough for
the purpose of rfc3315bis.  Anything beyond that (including the
never-ending discussion of whether DHCPv6 should provide on-link
prefix information) should better be discussed separately, outside the
scope of 3315bis; otherwise the rfc3315bis work will never be complete.

--
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Apr 2015 20:15:37 +0200

Le 02/04/2015 20:05, 神明達哉 a écrit :
> At Thu, 02 Apr 2015 09:13:35 +0200, Alexandru Petrescu
> <[email-masked]> wrote:
>
>>> sufficient, since it doesn't (clearly) answer the question of
>>> what the operator should do if they want to use DHCPv6-based
>>> address assignment in an isolated single-link (or "subnet")
>>> network.  The "architecturally correct" answer will be that they
>>> should deploy a node (which would probably be collocated on the
>>> same node as the DHCPv6 server) that sends RAs with router
>>> lifetime being 0 and with appropriate on-link prefix(es).
> [...]
>> But, a Router-DHCPv6Server with router lifetime 0 and on-link
>> prefix will make think the Host this is not a default router and it
>> should SLAAC its address (maybe in addition to requesting one from
>> DHCPv6). Is this what is meant by the above?
>

I misread then, sorry.

>> Another suggestion on another hand is to have DHCPv6 deliver a
>> prefix length together with the address, and a default route.
>> That'd be a form of independence, and avoid '/64' CIDR-breaking
>> assumptions.
>
> propagate on-link prefix and/or default route information, and I
> tried to avoid that part of discussion as I knew it would never
> converge:-)

Ok.

> In any case if we really want to discuss it again, it would be
> better to do it outside the scope of 3315bis.

I am not really saying we'd need to discuss it, unless we really want it
and it's simple to achieve.

It would be very simple to achieve having prefixlen in DHCPv6 address
allocations, be it just an option.

Alex

> -- jinmei

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 2 Apr 2015 18:27:20 +0000

> On Apr 2, 2015, at 2:15 PM 4/2/15, Alexandru Petrescu <[email-masked]> wrote:
> 

No.  There is no such thing as a prefix length on an address.

If DHCPv6 were to carry reachability information - and that is an unlikely hypothetical that I *really* don't care to discuss here - it must be in the form of a list of on-link prefixes, entirely disjoint from any assigned addresses.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Apr 2015 15:06:18 -0400

> The semantics of the M/O bits - and, please, let's not revisit that /dev/null discussion? - are, at this point, informative only.  RFC 7084, for example, specifies that a CE router uses DHCPv6 on i…

Hm, but it still depends on the RA for reachability information, correct?

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 2 Apr 2015 20:42:49 +0000

> On Apr 2, 2015, at 3:06 PM 4/2/15, Ted Lemon <[email-masked]> wrote:
> 

As far as I know, yes.

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 2 Apr 2015 20:47:26 +0000

Folks should read RFC5942.  See section 4, bullet 1. 

Hemant

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
Sent: Thursday, April 02, 2015 4:43 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Microphone comment about DHCPv6 address prefix length

As far as I know, yes.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Apr 2015 17:01:32 -0400

> Folks should read RFC5942.  See section 4, bullet 1. 

Oh, nice.   That might be a better reference to use.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 2 Apr 2015 21:13:24 +0000

> On Apr 2, 2015, at 5:01 PM 4/2/15, Ted Lemon <[email-masked]> wrote:
> 

Agreed.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 2 Apr 2015 22:40:23 +0100

Alexandru Petrescu <[email-masked]> wrote:

> be there during that operation.

Why ? What is a prefix doing for us in this scenario ? We can work with absolutely no prefix list whatsoever as long as the router redirects tell us about neighbours that are directly reachable.

> If they are not there it does not work.

Yes it will. We don't need a prefix to talk to the router, and we don't need one to talk about a neighbour we've already found.

> a neighbour in the same subnet, because there is no subnet.  Is a neighbor "on-link"?  We dont know.

Yes we do. See RFC4681 again.

...

And see Sec 4.5 that you quoted - the router can tell us that a host is local to us - it on-link.

> described anywhere.

RFC4681

> You have some bits here and there about who
> it should be.

So you want the standard to say how it should be done, not just what should be done ?
There's no "longest match" requirement - if the address is within any prefix marked as local then the address is considered on-link. You can do the "run down the list thing" and just stop at the first match - no need to find multiple matches, do longest match, etc.

> says "this is on-link, this is not on-link".

That's showing the result of a specific implementation which may or may not reflect the internal tables directly - and for which I believe we have already identified does not "do things correctly". On my systems, I see entries for "my own address" /128, and for the subnet prefix /64 which since I stopped radvd will have come from adding the interface IPv6 address.

>>>> - any Neighbor Discovery message is received from the address.
...
> What is precisely the "on-link determination"? (some RFC section titled so that I missed?)

The section already quoted ?

> you ping an LL address you have to say a -I iface because the computer can't determine the interface from its rt table (it has an fe80::/10 entry for each interface).

Yes, I think we all agree that link-local addresses are a special case - and not relevant to this thread.

> because I know people have different understandings for each.

But surely the correct thing to do is to use the same terminology as specified in the RFC ? The RFC where both terms are defined.

> not implementable in an interoperable manner.

I disagree.
It's merely stating that a router could proxy for a mobile device that's left the network.
Operation of mobility is defined elsewhere - and it does not in any way affect the topic of this thread. As far as our node is concerned, if a router is proxying for a mobile device, then we treat it the same was as we'd treat the device it's proxying for. The same questions apply to determine if it's on-link - so I think it's a non-problem. There simply is nothing whatsoever to implement (on a general node that isn't taking part in mobility) to cater for this.

> reason and should be ignored.

Look at it this way. If the flag is set then you do something. If it's not set then you just leave existing settings alone. I'm afraid I can't see what the problem is with that.

> There is no reason for that.  Entries will expire by themselves anyways, no need to announce going down.  Expiration can be planned be quicker by using shorter lifetimes, too.

Unless the RAs are still advertising the prefix - in that case an entry won't expire, so there is no mechanism for unsetting the local flag in the node's prefix table. But as I said, other than an admin having accidentally set it when it shouldn't be, I can't see a situation where a prefix could legitimately change from local to not local without some event (such as interface going down momentarily) happening that causes the prefix table for that link to be flushed.
In the same way, i can't really see it changing the other way either - other than by having two routers and one of them is incorrectly configured.

So in reality, the process is going to be as simple as get an RA, add the prefix(es) or refresh the timer if it already exists. And if the L flag is set, then make sure it's set in our table. Unless someone comes up with something else, I believe that really is it.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Apr 2015 12:56:42 +0200

In your previous mail you wrote:

>  Right. Perhaps we should leave the details to the RFCs where they are
>  specified? Proposed text:
>  
>  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

=> I fully disagree about the second part (second MUST NOT), in particular
for IA_NA's, because if DHCPv6 doesn't provide the info this doesn't
mean this is not available.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Apr 2015 14:11:57 +0200

>  +1, looks clear, concise and not open to misinterpretation.

=> -1 (just because it simply doesn't work in the real world).

>  > Why would a Client configure an unreachable /128 on its interface?

=> good question (:-).

> work ou ut the range of addresses in the same subnet, and from that
> you infer reachability information. Ie (in the absence of further
> configuration), if the address is in the same subnet you infer "on
> link" and do local discovery (ARP), if the address isn't in the
> same subnet you infer "not local" and send the packet via a router.

=> even I share your "IPv6 is not IPv4 with longer addresses" idea
IMHO you missed 2 critical points:
 - many IPv6 tools are just derived from the corresponding IPv4 versions
  so you can't say the IPv4 way is just plainly wrong and must be
  ignored. BTW older versions of Linuxes had the same problem...

 - most users of DHCPv6 adopted it because they use(d) DHCPv4 so
  I am afraid your argument is not the best one for the intented
  people (:-).

>  In the IPv6 world it's somewhat different.

=> IMHO you are simply reopening the SLAAC vs DHCPv6 issues in the
worst possible way. Please be a bit more flexible and help (vs.
be dogmatic and explain you have the truth and all others are wrong :-).

Regards

---

From: Simon Hobson <[email-masked]>
Date: Sun, 5 Apr 2015 13:49:06 +0100

> be dogmatic and explain you have the truth and all others are wrong :-).

I've not mentioned SLAAC (other than in passing), and I've certainly made no suggestion either way as to the relative merits of any approach to configuring addresses. If you are going to criticise someone, then please get your facts right when doing it.

> mean this is not available.

What you appear to be saying is that we can throw the DHCP derived info in a pot with <unspecified other info> to derive something that isn't needed. And it appears a big driver behind that is the "we've always had a subnet with an address, several implementations have done it that way, and so it's the only way to do it regardless of whether it's the best way or not".

Or, that's the way we've always done it and we're not prepared to change.

Is that not inflexible dogma ?

So now, (off list) I've been accused of applying "this implementation is the only way to do it" and (on list) being dogmatic against that way of doing it.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Apr 2015 08:59:20 -0400

> mean this is not available.

So:

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 used to form an implicit prefix with a length other than 128.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Apr 2015 21:29:11 +0200

>  reachability information by other means such as a Router Advertisement or

=> far better than previous second MUST NOT proposal... If you still want
a /128 in the text it should be enough to add a "without reachability
information" condition.

Regards

PS: the reference for "reachability information" is RFC 4861. It is where
one can get definitions for a prefix, on/off-link, reachability itself,
etc. And BTW the answer to the address which belongs to 2 prefixes problem
(longest prefix match, section 2.1).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Apr 2015 21:54:47 +0200

>  to do it outside the scope of 3315bis.

=> +1

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Apr 2015 22:07:16 +0200

>  Folks should read RFC5942.  See section 4, bullet 1. 

=> good catch!

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Apr 2015 09:33:03 +0900

> MUST NOT be used to form an implicit prefix with a length other than 128.

LGTM, except as Hemant says, I'd replace the "In order avoid the problems
described in [RFC4943]," with "As specified by [RFC5942] section 4,"

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 12:30:46 +0200

Le 02/04/2015 20:27, Ralph Droms (rdroms) a écrit :
>>>>> network.  The "architecturally correct" answer will be that
>>>>> they should deploy a node (which would probably be collocated
>>>>> on the same node as the DHCPv6 server) that sends RAs with
>>>>> router lifetime being 0 and with appropriate on-link
>>>>> prefix(es).
>>> [...]
>>>> prefix will make think the Host this is not a default router
>>>> and it should SLAAC its address (maybe in addition to
>>>> requesting one from DHCPv6). Is this what is meant by the
>>>> above?
>>>
>>> Not at all.  I didn't mean to say anything about SLAAC in the
>>> above "architecturally correct answer".
>>
>> I misread then, sorry.
>>
>>>>  That'd be a form of independence, and avoid '/64'
>>>> CIDR-breaking assumptions.
>>>
>>> That would lead to a long standing debate of whether DHCPv6
>>> should propagate on-link prefix and/or default route
>>> information, and I tried to avoid that part of discussion as I
>>> knew it would never converge:-)
>>
>> Ok.
>>
>> I am not really saying we'd need to discuss it, unless we really
>> want it and it's simple to achieve.
>>
>> It would be very simple to achieve having prefixlen in DHCPv6
>> address allocations, be it just an option.
>
> If DHCPv6 were to carry reachability information - and that is an
> unlikely hypothetical that I *really* don't care to discuss here -
> it must be in the form of a list of on-link prefixes, entirely
> disjoint from any assigned addresses.

That is a flexible way.  We can imagine that Server could tell client 1
or more prefixes to be 'on-link', almost in the same  way as the RA
tells it so.

On another hand, this will continue the difficulty for the Client to
decide which address belongs to which prefix.  This is a complex operation.

Were the server to indicate precisely which allocated address 'belong'
to which prefix then task would be easier to the Client.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 12:35:07 +0200

The section says:
> 4. Host Rules
>
>
>    A correctly implemented IPv6 host MUST adhere to the following rules:
>
>    1.  The assignment of an IPv6 address -- whether through IPv6
>        stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
>        or manual configuration -- MUST NOT implicitly cause a prefix
>        derived from that address to be treated as on-link and added to
>        the Prefix List.  A host considers a prefix to be on-link only
>        through explicit means, such as those specified in the on-link
>        definition in the Terminology section of [RFC4861] (as modified
>        by this document) or via manual configuration.  Note that the
>        requirement for manually configured addresses is not explicitly
>        mentioned in [RFC4861].

Well, the linux stack implementation does not act that way. Adding an
address on an interface implies a routing table entry is added too.

When the above paragraph was written - which flavor of IP stack was 
considered?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 19:37:06 +0900

> address on an interface implies a routing table entry is added too.

Not true. It acts that way if you specify a prefix length of 128.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 13:03:33 +0200

Le 02/04/2015 23:40, Simon Hobson a écrit :
>>> Assuming the router knows about the other devices, when we open
>>> a connection by sending packets to the router, the router can
>>> tell us (via a redirect) about the other node being on-link. At
>>> this point, we then know to use ND to find the other node and it
>>>  becomes on-link to us for as long as the neighbour information
>>> is kept active. This doesn't need *ANY* prefix information at all
>>> - only knowledge of a router we can use to send our packets out.
>>
>> Well, yes and no.
>>
>> Yes in that it can work as you describe.  And that prefix lengths
>> must be there during that operation.
>
> Why ?

I meant a prefix length, not just a prefix.

This is what you seemed to say as well: use prefix length value 128.

> What is a prefix doing for us in this scenario ? We can work with
> absolutely no prefix list whatsoever as long as the router redirects
> tell us about neighbours that are directly reachable.

I agree.

> Yes it will. We don't need a prefix to talk to the router, and we
> don't need one to talk about a neighbour we've already found.

But we need the prefix length value to be there, and valued at 128.

>> No in that Redirect does not tell whether somebody is onlink or
>> not, it just redirects to a better first-hop router, which will
>> presumably be that other neighbor-on-link (but not
>> neighbor-on-same-subnet): RFC says:
>>>
>>> Routers send Redirect packets to inform a host of a better
>>> first-hop node on the path to a destination.  Hosts can be
>>> redirected to a better first-hop router but can also be informed
>>>  by a redirect that the destination is in fact a neighbor.
>>
>> "in fact a neighbor"?  It is a neighbor on the same link, but it is
>> not a neighbour in the same subnet, because there is no subnet. Is
>> a neighbor "on-link"?  We dont know.
>
> Yes we do. See RFC4861 again.
>

We have no definition that tells that a 'neighbor' is 'on-link' and
moreover, 'on the same link'.

We know intuitively from IPv4, that a neighbor is in the same subnet as
self, i.e in the same prefix/prefixlen.

We know several subnets (prefixes) can be on the same link.

So, two neighbors on the same link are also neighbors on the same subnet?

> RFC4861

There is no section in that RFC4861 that tells how to implement "on-link
determination".  You have some bits here and there, but it is not enough
and at times unclear.

(compare, for example, with DAD which is fully specified in its own
unique place in rfc4862 section 5.4 titled "DAD").

>> You have some bits here and there about who contributes to it, but
>>  there is no section telling that is the on-link determination
>> operation.  With hands empty you  can only  suppose what it is, and
>> implement in a certain manner (longest match dst to rt table
>> entries, if found then ND dst and send packet to that MAC otherwise
>> ND the default router's IP address and send packet to that other
>> MAC address).  That's how I believe it should be but no document
>> tells how it should be.
>

Yes, like DAD.

> There's no "longest match" requirement - if the address is within
> any prefix marked as local then the address is considered on-link.

What does it mean to be within?

> You can do the "run down the list thing" and just stop at the first
> match - no need to find multiple matches, do longest match, etc.

What is a match?

>> When I type "route -6" there are some routes but there is not one
>> that says "this is on-link, this is not on-link".
>
> That's showing the result of a specific implementation which may or
> may not reflect the internal tables directly - and for which I
> believe we have already identified does not "do things correctly".

Ah?  I didnt know that?  Deprecating the 'route' command now after all
these years?  Serious?

> On my systems, I see entries for "my own address" /128, and for the
> subnet prefix /64 which since I stopped radvd will have come from
> adding the interface IPv6 address.

Yes.

>>>>> on-link     - an address that is assigned to an interface on
>>>>>  a specified link.  A node considers an address to be on-
>>>>> link if:
>>>>>
>>>>> - it is covered by one of the link's prefixes (e.g., as
>>>>> indicated by the on-link flag in the Prefix Information
>>>>> option), or
>>>>>
>>>>> - a neighboring router specifies the address as the target of
>>>>> a Redirect message, or
>>>>>
>>>>> - a Neighbor Advertisement message is received for the
>>>>> (target) address, or
>>>>>

Sorry, I dont see.  There are several paragraphs in RFC4861 which talk
'on-link determination', but are not grouped together.

[...]
> But surely the correct thing to do is to use the same terminology as
>  specified in the RFC ? The RFC where both terms are defined.

They are wrong.  They don't say 'subnet'.  And 'subnet' is what people use.

>>>> "off-link" is an "address", whereas in this use this "off-link"
>>>> is simply a qualifier of the mouvement.
>>>>
>>>> We can understand the phrase, the node moved out of the link,
>>>> off of the link; but the term "off-link" is not well defined.
>>>
>>> Again, I think context is everything. For something that's
>>> "moved off-link", we can infer that it's no longer on the link it
>>> used to be on. If it were to appear "on-link" for some other link
>>> then that complicates matters, but I don't think that in context
>>> it is wrong.
>>
>> It is not wrong, it is just misleading and not self-containing; it
>>  is not implementable in an interoperable manner.
>
> I disagree. It's merely stating that a router could proxy for a
> mobile device that's left the network. Operation of mobility is
> defined elsewhere - and it does not in any way affect the topic of
> this thread.

This is little right as well.

The mobility operation (Mobile IPv6) has it that the proxying operation
is done by somebody else than the Router.  And that RFC defining
mobility never says 'off-link'.

(besides, as simply as 'proxying' may seem, there are at least two:
- 'proxy ND RFC4389' means to pass through an untouched and an
   otherwise link-scoped message like an NS.
- 'proxy ND RFC6275' means to set somebody else's IP address in an NA
   containing the MAC address of self.)

> As far as our node is concerned, if a router is proxying for a mobile
> device, then we treat it the same was as we'd treat the device it's
> proxying for. The same questions apply to determine if it's on-link -
> so I think it's a non-problem. There simply is nothing whatsoever to
> implement (on a general node that isn't taking part in mobility) to
> cater for this.

The problem is in the use of the term 'off-link'.

You seem to assume that 'off-link' only qualifies a movement.

But other people believe 'off-link' means something else.  I.e. one
could have an RA containing a prefix that is 'off-link'.  That has
nothing to do with movement, because when the node moved the prefix is
still on-link.

>>>>> this prefix can be used for on-link determination.  When not
>>>>> set the advertisement makes no statement about on-link or
>>>>> off-link properties of the prefix.  In other words, if the L
>>>>> flag is not set a host MUST NOT conclude that an address
>>>>> derived from the prefix is off-link.  That is, it MUST NOT
>>>>> update a previous indication that the address is on-link.
>>>>
>>> unsets it later, the above says that we carry on treating the
>>> prefix as local. How often is this likely to happen in practice ?
>>> I'm not sure I can envisage a network where it supports ND, but
>>> then changes (without any host links going down) into one where
>>> ND no longer works.
>>>
>>> router sends RA with it unset, and then the first router goes/has
>>> the prefix removed/whatever. Does a node keep track of which RAs
>>> it got from each router, does it then say that the prefix is now
>>> not local because the RA that set it as local has stopped and
>>> there's no other RA that has it set ? Conversely, if the above
>>> said that getting an RA with the L bit clear means you have to
>>> update the prefix information, the next question would be "what
>>> about multiple RAs for the same prefix with different states for
>>> the L bit ?"
>
>> I meant to say that when L is unset we dont know what to do (we
>> dont know whether that is onlink or offlink).  As such it's sent
>> for no reason and should be ignored.
>
> Look at it this way. If the flag is set then you do something. If
> it's not

If the flag is not set you dont know whether you have to do something or
not.

What should the stack do with the 'off-link' prefix received in an RA?
If it has a particular meaning ('off-link') then the stack should
off-link-something.  Otherwise it doesnt mean anything.

> set then you just leave existing settings alone. I'm afraid I can't
> see what the problem is with that.

The problem is that a bit is defined that is not used and always
transported.

>>> The mechanism for it getting unset is for the prefix to get
>>> removed from the table = which will happen if the link "goes
>>> down", or if we stop getting any RAs with the prefix. As above, I
>>> can't think of any situation (other than admin cock-up !) where
>>> there would be any need to unset the local flag in the prefix
>>> table.
>>
>> There is no reason for that.  Entries will expire by themselves
>> anyways, no need to announce going down.  Expiration can be planned
>> be quicker by using shorter lifetimes, too.
>
> Unless the RAs are still advertising the prefix - in that case an
> entry won't expire, so there is no mechanism for unsetting the local
>  flag in the node's prefix table.

If you want to make a prefix disappear set the respective router's
lifetime to a smaller value and after that time stop advertising it.  IT
will disappear from everyone else's caches.

Advertising it 'off-link' is not the right way to achieve disappearance.

> But as I said, other than an admin having accidentally set it when it
> shouldn't be, I can't see a situation where a prefix could
> legitimately change from local to not local without some event (such
>  as interface going down momentarily)

I agree.

> happening that causes the prefix table for that link to be flushed.
> In the same way, i can't really see it changing the other way either
> - other than by having two routers and one of them is incorrectly
> configured.
>
> So in reality, the process is going to be as simple as get an RA, add
> the prefix(es) or refresh the timer if it already exists. And if the
> L flag is set, then make sure it's set in our table. Unless someone
> comes up with something else, I believe that really is it.

Sure, we can see.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 13:12:39 +0200

Le 05/04/2015 21:29, Francis Dupont a écrit :
>> [RFC4943], hosts MUST NOT assume that any IPv6 destinations are
>> reachable on-link as a result of receiving an IA_NA or IA_TA. In
>> order to communicate to any destination that is not a link-local
>> address, the host must also have obtained reachability information
>> by other means such as a Router Advertisement or manual
>> configuration.
>
> => far better than previous second MUST NOT proposal... If you still
> want a /128 in the text it should be enough to add a "without
> reachability information" condition.
>
> Regards
>
> PS: the reference for "reachability information" is RFC 4861. It is
> where one can get definitions for a prefix, on/off-link, reachability
> itself, etc. And BTW the answer to the address which belongs to 2
> prefixes problem (longest prefix match, section 2.1).

That section says:
> longest prefix match - the process of determining which prefix (if
> any) in a set of prefixes covers a target address.  A target address
> is covered by a prefix if all of the bits in the prefix match the
> left-most bits of the target address.  When multiple prefixes cover
> an address, the longest prefix is the one that matches.

Except that it does not say what happens when multiple prefixes have the
same length (the common '64'); it does not say how to do when prefix
lengths are absent; it does not say how to use ancillary parameters such
next-hop gw or iface.

Alex

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 8 Apr 2015 11:38:39 +0000

> On Apr 8, 2015, at 6:30 AM 4/8/15, Alexandru Petrescu <[email-masked]> wrote:
> 

It is the correct way to inform an IPv6 stack of on-link prefixes and assigned addresses, exactly as an RA informs an IPv6 stack of on-link prefixes.

> decide which address belongs to which prefix.  This is a complex operation.

It is a required operation.  The design of IPv6 is that the stack matches a destination address against a list of prefixes, each of which has an associated length, to determine the longest match.

> to which prefix then task would be easier to the Client.

It is an incorrect shortcut to derive a prefix from a length associated with an address.

- Ralph

PS This message is likely my last post on the matter, which is now revisiting very old topics that have been discussed at length in 6man and elsewhere.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 8 Apr 2015 12:46:05 +0100

> But we need the prefix length value to be there, and valued at 128.

This, IMO, is where the problem lies. If you have a mindset that an address always has a [ subnet length | prefix length ] then there's always a problem with having an address without one. Part of this is that "we've always linked them", and I suspect it's rather heavily embedded in implementations that you can't have one without the other.
Ie, we're used (in the IPv4 world) to configuring an IP address, with it's subnet mask/length, and having a routing table entry automatically created.

But if for a moment you can ignore what current implementations do and what we've been used to - then we don't need a prefix attached to an address, we only need a list of prefixes we know how to reach directly and a list of routers to use for addresses that aren't within the first list.

So I take your statement to really mean "our current implementations can't cope without a prefix length, so we'll simulate not having one by using /128". I can agree with that if expressed in those terms, for the simple reason that we're not going to rework decades of code development overnight - so in the meantime we need to shoehorn one thing (addresses without prefixes) into another (structures that marry a prefix with every address).

Since I'm very much "not an expert" in IPv6 (especially it's history), I really don't know how much was implementations leading the standards (ie was all this specified before the implementations were done), or implementations going down the road of "it's IPv4 with more bits" due to lack of knowledge of the differences, or implementations going down the road of "we need to do it the old way or it's too much work to do it at all".

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Apr 2015 09:37:48 -0400

On 4/8/15 7:46 AM, Simon Hobson wrote:
> 
> Since I'm very much "not an expert" in IPv6 (especially it's
> history), I really don't know how much was implementations leading
> the standards (ie was all this specified before the implementations
> were done), or implementations going down the road of "it's IPv4 with
> more bits" due to lack of knowledge of the differences, or
> implementations going down the road of "we need to do it the old way
> or it's too much work to do it at all".
> 

I will take my AD hat off and show my gray hair...

During much of the early IPv6 standardization work, a variety of groups
were pumping out implementations as the specs were being written.  I am
aware of at least two different groups that were trying to minimize code
development by taking existing IPv4 stack software, copying data
structures/functions/libraries, and then modifying them to handle IPv6.
 This caused some IPv6 implementations to inherit the IPv4
mindset/paradigm.  I can very much see that situation re-occurring here
with the prefix length discussion.

IMO, DHCPv6 allocates a 128-bit IPv6 address to a node's interface.  The
RAs on that link will tell the node the prefixes in use on the link and
routers to use to reach addresses off the link.

Regards,
Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 22:53:15 +0900

> routers to use to reach addresses off the link.

What he said.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 17:03:09 +0200

Le 08/04/2015 12:37, Lorenzo Colitti a écrit :
> On Wed, Apr 8, 2015 at 7:35 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>

YEs and no.

Yes: if you add an address on an interface by using ifconfig and don't
specify a prefix length, the prefix length will be 128 by programmer's wish.

No: if you do specify a prefixlen, or if you dont specify a prefix
length, an entry will be added anyways in the routing table (the
specified preflen in the first case, /128 in the 2nd case).

That is to say that even if specifications (RFC5942 section 4 bullet1
"Host Rule number 1" tells that Host "MUST NOT implicitly cause a prefix
derived from that address to be treated as on-link and added to the
Prefix List." is not implemented.

If a programmer implements that Rule then programmer has no means to
write a coherent "longest prefix match", because there is no prefix length.

Moreover, a programmer porting an IPv4 implementation to IPv6 will have
no means to put something in the "subnet mask" fields, if the prefixlen
is absent.

Alex

---

From: Ralph Droms <[email-masked]>
Date: Wed, 8 Apr 2015 11:16:22 -0400

> On Apr 8, 2015, at 9:53 AM 4/8/15, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Apr 8, 2015 at 10:37 PM, Brian Haberman <[email-masked]> wrote:

Agreed ... precisely and concisely correct.

- Ralph

---

From: Simon Hobson <[email-masked]>
Date: Wed, 8 Apr 2015 16:38:57 +0100

> write a coherent "longest prefix match", because there is no prefix length.

But there is - the stack will have a list of prefixes which are to be considered local to this link. Any address configured on this interface does **NOT** have to be within one of those prefixes.

Put another way, you do not need a prefix associated with a configured address on your own interface to work out if a completely unrelated address (that of the destination for a new connection) is within a list of prefixes associated with that interface.

> no means to put something in the "subnet mask" fields, if the prefixlen

That is indeed an issue - but then there are many other things a programmer must do when writing/porting an application for IPv6.
For many, just "making the fields bigger" will do - and then (as previously discussed) a workaround might be to just use /128 as a dummy value. For an application that accepts incoming connections on multiple interfaces and address, then replies using the same address, I imagine the IPv6 stack will deal with the technicalities of getting the reply back to the right place*.

Even for applications making outbound connections, I assume they'll just use the default address unless told otherwise, and the stack will take care of the routing.

* I'm thinking about details like "if the source address is in prefix X, then send it via router Y which provided the RA containing prefix X". Particularly important for networks with multiple internet connections (and separate provider aggregated prefixes).

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 17:55:22 +0200

Le 08/04/2015 17:16, Ralph Droms a écrit :
>> On Wed, Apr 8, 2015 at 10:37 PM, Brian Haberman
>> <[email-masked]> wrote: IMO, DHCPv6 allocates a 128-bit
>> IPv6 address to a node's interface.  The RAs on that link will
>> tell the node the prefixes in use on the link and routers to use
>> to reach addresses off the link.
>>
>> What he said.
>

I disagree.  Almost entirely.

There must be a way for DHCP to work by itself, without assistance from RA.

A particular network I connect to tries to satisfy everyone (RA and
DHCP) and the result is... not beautiful: there are two routers on the
link: one sends the RA the other serves DHCP.

This result (have two routers on same link - one for RA, one for DHCP)
was not the goal of a RA-w-DHCP discussion, I guess.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 8 Apr 2015 17:00:37 +0100

> Put another way, you do not need a prefix associated with a configured address on your own interface to work out if a completely unrelated address (that of the destination for a new connection) is…

As an example, if you wish to send a packet to 2001:DB8:1::1 and you are told (via an RA) that 2001:DB8:1::/48 is on-link, then do you have enough information to determine if the destination address is on-link ?
Answer - yes you do.
All you need to do is the simple logical operations we're familiar with from the IPv4 world - mask the address with the prefix length derived subnet mask, if the result matches then the address is "in" the prefix. Logical AND 2001:DB8::1 with ffff:ffff:ffff:: and you get 2001:DB8::, compare 2001:DB8:1:: with 2001:DB8:1:: and you'll find that it matches.

Note that I didn't tell you what source address I was assuming - because it doesn't matter. It may or may not be in this prefix, or indeed any prefix advertised as being on-link for this interface. It could, for example, be 2001:DB8:1234::5678 which is *not* in the same prefix as the destination address.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 8 Apr 2015 17:07:34 +0100

> There must be a way for DHCP to work by itself, without assistance from RA.

I agree. I don't recall seeing anything that says a device can fall back to assuming everything is local (and hence find it by ND) if there are no RA provided prefixes - or more importantly, no routers present. As previously mentioned, the network will work fine without any prefixes if the router(s) either forward the packets or provide redirects informing the hosts that the other host they are talking to is on-link.

> was not the goal of a RA-w-DHCP discussion, I guess.

Err, what ?

You have described *ONE* router and *ONE* server. The two could be on the same device - there is no fundamental reason why the router (offering RAs) cannot be on the same device as the DHCP server.
If you have **CHOSEN** to run two devices to provide the services then that is up to you - it is not imposed by the standards.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 18:18:28 +0200

Le 08/04/2015 18:00, Simon Hobson a écrit :
> I wrote:
>
>>> If a programmer implements that Rule then programmer has no means
>>> to write a coherent "longest prefix match", because there is no
>>> prefix length.
>>
>> But there is - the stack will have a list of prefixes which are to
>>  be considered local to this link. Any address configured on this
>> interface does **NOT** have to be within one of those prefixes.
>>
>> Put another way, you do not need a prefix associated with a
>> configured address on your own interface to work out if a
>> completely unrelated address (that of the destination for a new
>> connection) is within a list of prefixes associated with that
>> interface.
>
> As an example, if you wish to send a packet to 2001:DB8:1::1 and you
>  are told (via an RA) that 2001:DB8:1::/48 is on-link, then do you
> have enough information to determine if the destination address is
> on-link ? Answer - yes you do.

YEs you do, I agree.

> All you need to do is the simple logical operations we're familiar
> with from the IPv4 world - mask the address with the prefix length
> derived subnet mask, if the result matches then the address is "in"
> the prefix. Logical AND 2001:DB8::1 with ffff:ffff:ffff:: and you
> get 2001:DB8::, compare 2001:DB8:1:: with 2001:DB8:1:: and you'll
> find that it matches.

YEs, it works because you have that prefixlen from the RA.

> Note that I didn't tell you what source address I was assuming -
> because it doesn't matter. It may or may not be in this prefix, or
> indeed any prefix advertised as being on-link for this interface. It
>  could, for example, be 2001:DB8:1234::5678 which is *not* in the
> same prefix as the destination address.

Right.

But let me reply with another example: it should be possible to manually
assign an address on an interface, manually assign the default route,
have no RA at all, and still be able to ping the Internet.

If this manual operation (assign address, default route) does not work,
one depends a lot on that RA be there and be correct.  Configuring RAs
on routers is an additional operation which rarely exists in IPv4; it
has its own quirks different enough to fear.

Alex
PS: I am also a supporter of IPv4 RAs without which some other context
wont work (mobility).

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2015 18:23:56 +0200

Le 08/04/2015 18:07, Simon Hobson a écrit :
> I agree. I don't recall seeing anything that says a device can fall
> back to assuming everything is local (and hence find it by ND) if
> there are no RA provided prefixes - or more importantly, no routers
> present. As previously mentioned, the network will work fine without
>  any prefixes if the router(s) either forward the packets or provide
>  redirects informing the hosts that the other host they are talking
> to is on-link.

Or if sysadmin manually decides who's on link (insert entries in routing
table).

>> A particular network I connect to tries to satisfy everyone (RA
>> and DHCP) and the result is... not beautiful: there are two routers
>> on the link: one sends the RA the other serves DHCP.
>>
>> This result (have two routers on same link - one for RA, one for
>> DHCP) was not the goal of a RA-w-DHCP discussion, I guess.
>
> Err, what ?
>
> You have described *ONE* router and *ONE* server.

Ok, it's two MAchines: one sends the RA the other sends the DHCP
Advertise.  It's a point-to-point link (cellular).

> The two could be on the same device - there is no fundamental reason
> why the router (offering RAs) cannot be on the same device as the
> DHCP server.

There are two different src addresses in the RA and in the DHCP
Advertise.  Why would the DHCP server use a different src address than
the Router sending the RA if not because there were two different
machines on the same link?

> If you have **CHOSEN** to run two devices to provide the services
> then that is up to you - it is not imposed by the standards.

But no, this is wrong.  If you want to provide reliability with RAs
there are ways  for two Routers on same link send same RA in a reliable
manner.  If you want reliability with DHCP there are ways to have
multiple reliable DHCP servers on same link.

But there is no way to achieve reliability between RA and DHCP.  If the
RA machine falls down the DHCP server can not provide same information
(not as of today, some parameters are still RA-only whereas others are
still DHCP-only).

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 8 Apr 2015 20:13:12 +0100

> have no RA at all, and still be able to ping the Internet.

I don't recall reading anywhere that you cannot do that - but as I say, I'm no expert. But that still does not mean you need to provide the prefix as part of the address. So to do those three things, you'd do three things :
add an address
add a prefix (if needed)
add a router (again, I don't know if manually configuring routes is considered unsupported or not, but I know it works in Debian and I can't see any reason not to allow it even if it is the hardest way to configure a network (in the general case))

But the discussion was specifically about DHCP - so manual configuration is out of the scope of the thread.

> Advertise.  It's a point-to-point link (cellular).

But you miss the point. There is nothing to stop both services being part of one appliance - if they aren't then it's because for whatever reason the architect of that network decided to make them separate.

> machines on the same link?

There are some good reasons to do that. One is to make services more portable.
Eg, if you run a machine with multiple services, then you might run each service on a different IP. That way, should you decide to move one service, you take the IP away to the new home for the service and leave the rest of the services as is - saves all the *fun* of getting all the users to be using the same updated DNS entries from the moment you move the service. Switchover takes only as long as the router needs to update it's ARP/neighbour cache.

> (not as of today, some parameters are still RA-only whereas others are

I don't quite follow there - but it's by design that the information provided by RAs and DHCP are different, specifically that DHCP doesn't provide the prefix information.

Wether you have one router & one DHCP server, or multiple routers and multiple DHCP servers - there is (of course) the issue of co-ordinating them so that if one of your internet connections goes down, you stop giving clients addresses in a prefix that's only usable via that connection. That's not really any different to the IPv4 world when using public addresses.
But if the routers are redundant in that they both provide routing for the same prefix(es), then I see no issue.

Perhaps you could clarify what the perceived issue is ?

---

From: [email-masked]
Date: Thu, 09 Apr 2015 06:46:56 +0200 (CEST)

> have no RA at all, and still be able to ping the Internet.

Of course. And a sensible OS (e.g. FreeBSD) will indeed let you do that. 

Steinar Haug, AS 2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Apr 2015 14:12:30 +0900

> Of course. And a sensible OS (e.g. FreeBSD) will indeed let you do that.

So will Linux.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 07:45:18 +0200

Le 09/04/2015 06:46, [email-masked] a écrit :
>> But let me reply with another example: it should be possible to
>> manually assign an address on an interface, manually assign the
>> default route, have no RA at all, and still be able to ping the
>> Internet.
>

Will the OS also add a plen /128 whenever sysadmin types "ifconfig add
address" w/o specifying a plen?  And will it add an entry in the rt
table for that /128 address?  (linux does both).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 07:45:56 +0200

Le 09/04/2015 07:12, Lorenzo Colitti a écrit :
>
> On 9 Apr 2015 1:51 pm, <[email-masked] <mailto:[email-masked]>> wrote:
> manually

And linux will add a /128 plen whenever sysadmin types "ifconfig add 
address" w/o telling a plen.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Apr 2015 14:50:11 +0900

On Thu, Apr 9, 2015 at 2:45 PM, Alexandru Petrescu <
[email-masked]> wrote:

> address" w/o specifying a plen?

Yes. Internally, the OS always represents addresses with prefix lengths.
This is a more general representation than just an address. An address of
prefix length /128 is an address with no implicit route, an address of
prefix length != /128 is an address without an implicit route.

> And will it add an entry in the rt table for that /128 address?  (linux
> does both).
>

Of course it does. That's necessary for things to work. It has to to add a
route pointing at the loopback interface, otherwise it wouldn't know that
if someone wants to send a packet to that address, it should send it on
loopback, and if it receives a packet for that address, it knows to deliver
that packet to UDP/TCP/... sockets.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 07:58:36 +0200

Le 08/04/2015 21:13, Simon Hobson a écrit :
> I don't recall reading anywhere that you cannot do that - but as I
> say, I'm no expert.

Well, with ifconfig (for example): one can add an address like this:
"ifconfig add address" or like this:
"ifconfig add address/plen".

In the former case, even though the sysadmin does not add a plen the
programmer behind will add a plen /128 to that address, and will add an
entry in the rt table for that.

> But that still does not mean you need to provide the prefix as part
> of the address.

In the above example the sysadmin does not need to provide a prefix but
the stack (linux) will add a /128 because so the programmer wants.

> So to do those three things, you'd do three things :
>
> add an address
>
> add a prefix (if needed)
>
> add a router (again, I don't know if manually configuring routes is
> considered unsupported or not, but I know it works in Debian and I
> can't see any reason not to allow it even if it is the hardest way to
> configure a network (in the general case))

I agree.  But the system will add a plen if the sysadmin doesnt.

> But the discussion was specifically about DHCP - so manual
> configuration is out of the scope of the thread.

I agree - this discussion is about auto-configuration.  But
auto-configuration comes _after_ configuration.  If the manual
configuration says that a plen is needed then the auto-configuration
must provide one.

>>>> A particular network I connect to tries to satisfy everyone
>>>> (RA and DHCP) and the result is... not beautiful: there are two
>>>>  routers on the link: one sends the RA the other serves DHCP.
>>>>
>>>> This result (have two routers on same link - one for RA, one
>>>> for DHCP) was not the goal of a RA-w-DHCP discussion, I guess.
>>>
>>> Err, what ?
>>>
> But you miss the point. There is nothing to stop both services being
>  part of one appliance - if they aren't then it's because for
> whatever reason the architect of that network decided to make them
> separate.

I missed it a bit, yes.  I mentioned reliability in this discussion
because in other discussions I am told reliability is the reason to have
both RA and DHCP in place.

There are other reasons to have both RA and DHCP in place in a cellular
network:
- accept as many as possible clients; some clients do only RA, whereas
   others do DHCP+RA.
- deliver a DNS server to clients who dont implement DNS-in-RA option.
- some cellular interface kinds and their drivers support DHCP others
   dont.

>>> The two could be on the same device - there is no fundamental
>>> reason why the router (offering RAs) cannot be on the same device
>>> as the DHCP server.
>>
>> Advertise.  Why would the DHCP server use a different src address
>> than the Router sending the RA if not because there were two
>> different machines on the same link?
>
> There are some good reasons to do that. One is to make services more
>  portable. Eg, if you run a machine with multiple services, then you
>  might run each service on a different IP. That way, should you
> decide to move one service, you take the IP away to the new home for
> the service and leave the rest of the services as is - saves all the
>  *fun* of getting all the users to be using the same updated DNS
> entries from the moment you move the service. Switchover takes only
> as long as the router needs to update it's ARP/neighbour cache.

Ok, switchover, load balancing...

But switchover and load balancing is easier when same protocol is
involved rather than two entirely different protocols (SLAAC and DHCP).
  The implementations of a same protocol rely on a same database
structure which are easier to synchronize during load balancing, switch
over, traffic offloading.

>>> If you have **CHOSEN** to run two devices to provide the
>>> services then that is up to you - it is not imposed by the
>>> standards.
>>
>> But no, this is wrong.  If you want to provide reliability with
>> RAs there are ways  for two Routers on same link send same RA in a
>>  reliable manner.  If you want reliability with DHCP there are ways
>>  to have multiple reliable DHCP servers on same link.
>>
>> But there is no way to achieve reliability between RA and DHCP. If
>>  the RA machine falls down the DHCP server can not provide same
>> information (not as of today, some parameters are still RA-only
>> whereas others are still DHCP-only).
>
> I don't quite follow there - but it's by design that the information
>  provided by RAs and DHCP are different, specifically that DHCP
> doesn't provide the prefix information.

YEs, and this design is wrong.  The design should allow for any
information to be in RA and any information to be in DHCP.

Reluctance to include some kind of information in RA, or in DHCP, has
little solid grounds.

> Wether you have one router & one DHCP server, or multiple routers and
> multiple DHCP servers - there is (of course) the issue of
> co-ordinating them so that if one of your internet connections goes
> down, you stop giving clients addresses in a prefix that's only
> usable via that connection. That's not really any different to the
> IPv4 world when using public addresses. But if the routers are
> redundant in that they both provide routing for the same prefix(es),
>  then I see no issue.

Yes, but coordination is easier when same kinds of databases (config
files) are used.

It's easier to coordinate between two dhcpd.conf files than between an
radvd.conf and and a dhcpd.conf contents.

> Perhaps you could clarify what the perceived issue is ?

The issue is that the principle of mandatory RA+DHCP (as opposed to
solely RA, or solely DHCP) leads to two different Routers in practice,
when a single one would have been sufficient.  A cost issue.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 08:10:41 +0200

Le 09/04/2015 07:50, Lorenzo Colitti a écrit :
> On Thu, Apr 9, 2015 at 2:45 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Ok, so the plen is needed anyways.

That's why a DHCP client invents there a 64, because it is needed. Were
it provided by DHCP protocol then the client would not need to invent it.

> Internally, the OS always represents addresses with prefix lengths.

Ok, so that's the way it should be. A prefix length is needed. Either it
is provided by sysadmin in CLI or by protocol. Otherwise the programmer
will always invent one (be it 64 or 128).

> This is a more general representation than just an address. An address
> of prefix length /128 is an address with no implicit route, an address
> of prefix length != /128 is an address without an implicit route.

('implicit' route? It's the same as 'host-based route' in your parlance?)

Whether the plen is 128 or 64, and whether it is told in cli or not, it
will always end as a routing table entry whenever an address is added.

>     And will it add an entry in the rt table for that /128 address?
>     (linux does both).
>
>
> Of course it does. That's necessary for things to work. It has to to
> add a route pointing at the loopback interface, otherwise it wouldn't
> know that if someone wants to send a packet to that address, it
> should send it on loopback, and if it receives a packet for that
> address, it knows to deliver that packet to UDP/TCP/... sockets.

Ok, so a plen is needed at least because the loopback iface is needed
for this 128 description. But loopback iface is not absolutely necessary
to talk locally to an address of self.

(remark if the sysadmin says add addr/64 then there is still a rt table
entry and there is no route to the loopback iface. And still one can
ping locally even though there is no /128 to the loopback interface
(send a packet to that address, receives for that address, deliver that
to UDP sockets).)

In all cases, a plen is needed.

Alex

---

From: [email-masked]
Date: Thu, 09 Apr 2015 08:14:27 +0200 (CEST)

> There must be a way for DHCP to work by itself, without assistance from RA.

As of today, there is no way to get DHCPv6 to work by itself, witout a
router (and RAs). I find this situation somewhat depressing - but it's
been like this for many years. Every attempt to change this has been
shot down.

So, as far as I can see, you cannot connect a bunch of computers to a
simple (unmanaged) Ethernet switch, configure one of them as a DHCPv6
server, and have the computers communicating using the DHCPv6 assigned
addresses:

- Addresses assigned by DHCPv6 are single addresses which say nothing
about reachability or on/off-link. There is no way to specify this using
DHCPv6.

- Furthermore, also frustrating DHCPv6 for address management, there is
no way to transmit the MAC addresses of the DHCPv6 clients to the DHCPv6
server, thus making any attempts to correlate DHCPv4 and DHCPv6 address
assignments difficult.

Yes, I am fully aware of RFC 6939 (Client Link-Layer Address Option in
DHCPv6) and of the DUID-LLT and DUID-LL formats. However,

- The RFC 6939 link layer address option is only used by DHCPv6 relay
agents.

- DHCPv6 servers are explicitly prohibited from "peeking inside" DUIDs
(even if some servers actually offer this functionality):

"Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality.  Clients and servers MUST NOT in any
other way interpret DUIDs." (RFC 3315 ch. 9)

Steinar Haug, AS 2116

---

From: [email-masked]
Date: Thu, 09 Apr 2015 08:16:48 +0200 (CEST)

> (not as of today, some parameters are still RA-only whereas others are

If you want reliability: Use redundant routers (both sending RAs) which
are also both DHCP relay agents.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 08:36:40 +0200

> on-link ? Answer - yes you do. All you need to do is the simple
> logical operations we're familiar with from the IPv4 world - mask
> the address with the prefix length derived subnet mask, if the
> result matches then the address is "in" the prefix. Logical AND
> 2001:DB8::1 with ffff:ffff:ffff:: and you get 2001:DB8::, compare
> 2001:DB8:1:: with 2001:DB8:1:: and you'll find that it matches.

This is exact matching on a specified plen.  W/o a plen specified the
operation is not that straightforward.  So a plen is absolutely necessary.

"longest-match": when plen1 and plen2 are present (plen2 is longer), and
an address matches on plen2 on each of the prefixes - which prefix
should be selected as the one containing the address?  This is difficult
to say, since there is no spec.

In a sense, the prefix whose length is plen2 should be used, because
that is the "longest".  But in another sense, the prefix whose length is
plen1 also matches on the same number of bits.

The problem can be sensed when setting a prefix 2001:db8::/63 and a
2001:db8::/64 (two different prefixes, yet it is hard to tell which one
'contains' the address 2001:db8::1).

(for recall see the definition of rf4861:
>    longest prefix match
>                - the process of determining which prefix (if any) in a
>                  set of prefixes covers a target address.  A target
>                  address is covered by a prefix if all of the bits in
>                  the prefix match the left-most bits of the target
>                  address.  When multiple prefixes cover an address, the
>                  longest prefix is the one that matches.)

> could, for example, be 2001:DB8:1234::5678 which is *not* in the same
> prefix as the destination address.

I agree.

Alex

---

From: [email-masked]
Date: Thu, 09 Apr 2015 08:43:01 +0200 (CEST)

> table for that /128 address?  (linux does both).

Checking on a couple of FreeBSD 10.1 servers in the lab here:

1. Adding an IPv6 address with no prefix specified (eg: ifconfig em0
inet6 2001:db8:1::1) results in an address with /64 prefix being
installed (and added to the routing table), and other hosts within the
same /64 are reachable.

2. Adding an IPv6 address with /128 prefix specified (eg: ifconfig em0
inet6 2001:db8:1::1/128) results in an address with /128 prefix being
installed (and added to the routing table). Obviously no other hosts
are reachable.

I'll let others argue whether the behavior in 1) is against the RFCs or
not. Speaking only for myself, I find it very sensible and practical.
Yes, I am aware of RFC 5942.

Steinar Haug, AS 2116

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Apr 2015 08:54:25 +0100

> the stack (linux) will add a /128 because so the programmer wants.

As I read things, a big part of your argument is "on ${OS of choice} prefixes are required and routes automatic, therefore the standard is wrong to say otherwise". It reminds me of certain other areas in the IT world where vendors with vested interests effectively tell the standards body "we've implemented this, make your standard fit"

FWIW, I can see the other side, but I'm convinced by the argument that says an address is separate from prefixes declared as on-link and routes.
We can work around the requirement for a prefix by specifying /128 - IIRC the argument was how to word this to say it can be done, but it's wrong to have to do it, ie say it without appearing to condone it's use and so encourage people to do implementations that require a prefix.
Using /128 also works around the other implementation issue - by avoiding the automatic addition of a route for the prefix.

> about reachability or on/off-link. There is no way to specify this using

FWIW I would support there being an option to send the list of prefixes - note that this is different from specifying a prefix length for an address. AIUI a large part of the reason for separating the functions is to do with large organisation where different groups handle address management (ie DHCP) and another group handles routing - with an inference being that the two groups exist in isolation. IME (only in small/medium businesses) is of doing both roles myself - and even where they are separate groups, neither can operate in isolation from the others (no good assigning addresses from a prefix that isn't routed to that network !).

> server, thus making any attempts to correlate DHCPv4 and DHCPv6 address

It's not just IPv4-IPv6 correlation. As I've expressed before, until vendors generate a DUID at the factory, store it in non-volatile memory in the device, print it on a barcode on the side of the box, and all OSs/DHCP clients use it - then it's both less useful, and less stable than a MAC address as an identifier.
I see the need for a system wide UID, but I don't see the support appearing for it.

As an aside, I once worked in a place with Apollo Domain systems. In those, the system identity was so closely tied to the network hardware address that replacing a NIC or moving a disk between machines involved a routine to update the file id for every file on the system. At least this is how I vaguely recall it being told to me.

> operation is not that straightforward.  So a plen is absolutely necessary.

I'm struggling to see if you genuinely are missing the point or trolling.
Yes, a prefix length is necessary **FOR THE DESTINATION**, it is not necessary for our own address. No-one is talking about not having a prefix length for prefixes we are told are attached to the link (ie on-link).

> to say, since there is no spec.

Assuming for one moment that there are no duplicate/overlapping prefixes across different interfaces, then it doesn't actually matter one jot whether you do longest wins, shortest wins, first match found wins, or even random. If the destination address matches *ANY* on-link prefix then the node is directly reachable via that link. The question we are answering is "can we directly reach that node", and that is "yes" if the node address is in any prefix on the link - the answer isn't a specific prefix, just a yes or no.

The only case I can think of where this breaks down is if there is a broken network config - with multiple networks with overlapping IP ranges. In that case, you may find that the destination address matches one or more on-link prefixes on more than one link. IMO that is broken (addresses not globally unique) and I see no reason not to leave it to the implementer to do what they want - whether that's longest match first, shortest match first, or something else.
In theory, if a node is reachable via either link, then it shouldn't matter which interface is used - one option might be to prefer higher performance (eg gigabit wired ethernet) over lower performance (eg wifi). An obvious situation this can arise is when connected to the same LAN via wired ethernet and wifi.
If there are overlapping prefixes on multiple networks, but a node is only reachable via one of them, then that's a recipe for bigger problems and with the abundance of IPv6 addresses should be easily avoided.

I'll finish by tossing in something to think about. You complain a lot about the complication of doing multiple prefix matches, which wins, etc.
If we go down the route of saying every address has an associated prefix, then if we add (say) 20 addresses to an interface* then we've added 20 prefixes. Now, instead of matching against the one (or small number) of on-link prefixes explicitly configured, you have 20 prefixes to test - 19 tests are redundant as they should all give the same answer.
The alternative is that when adding addresses, you have to figure out if there is already a prefix in the table and not add duplicates; and when deleting an address, the harder task of working out if this is the last address with that prefix and only deleting the prefix if it is. If you do that logic, then you are implicitly doing what you appear to be arguing against - treating the addresses and prefixes (routing table entries) as separate entities.

* I see multiple addresses becoming a lot more common. I've been in IT long enough to remember when each web site needed it's own address, and using browsers without the new fangled host header support. These days, there are still browsers that don't fully support multiple SSL enabled sites on one IP. The extensions for both of these are in effect workarounds to avoid using multiple addresses - there are arguments** for going back to multiple addresses with the abundance of IPv6.

** Most of these relate to identity and accountability. Eg, when a site sends out an email, if each site uses a different address then there's no issue as to who sent it, no problems with being blacklisted because "a neighbour" on the same server sent spam, no problems being blacklisted because you don't have the right reverse DNS, etc, etc.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 11:10:23 +0200

Le 09/04/2015 09:54, Simon Hobson a écrit :
>> In the above example the sysadmin does not need to provide a
>> prefix but the stack (linux) will add a /128 because so the
>> programmer wants.
>
> As I read things, a big part of your argument is "on ${OS of choice}
> prefixes are required and routes automatic, therefore the standard is
> wrong to say otherwise".

${OS} bsd and linux contain the stacks which are fundamental of pretty
much everything out there.

> It reminds me of certain other areas in the IT world where vendors
> with vested interests effectively tell the standards body "we've
> implemented this, make your standard fit"

I am not a vendor with vested interests.  I am writing after years of
experience with these things.

> FWIW, I can see the other side, but I'm convinced by the argument
> that says an address is separate from prefixes declared as on-link
> and routes.

That is in specifications, yes.

> We can work around the requirement for a prefix by specifying /128 -
> IIRC the argument was how to word this to say it can be done, but
> it's wrong to have to do it, ie say it without appearing to condone
> it's use and so encourage people to do implementations that require
> a prefix. Using /128 also works around the other implementation issue
> - by avoiding the automatic addition of a route for the prefix.

My argument is the following:
- architecturally an address has no prefixl ength
- implementations need prefix length
- some implementations default to 64 others to 128
- prefixlen should be delivered by DHCP too
- recommending 128 as default preflen is not necessary

> [email-masked] wrote:
>
>> As of today, there is no way to get DHCPv6 to work by itself,
>> witout a router (and RAs). I find this situation somewhat
>> depressing - but it's been like this for many years. Every attempt
>> to change this has been shot down.
>>
>> So, as far as I can see, you cannot connect a bunch of computers
>> to a simple (unmanaged) Ethernet switch, configure one of them as
>> a DHCPv6 server, and have the computers communicating using the
>> DHCPv6 assigned addresses:
>>
>> - Addresses assigned by DHCPv6 are single addresses which say
>> nothing about reachability or on/off-link. There is no way to
>> specify this using DHCPv6.
>
> FWIW I would support there being an option to send the list of
> prefixes - note that this is different from specifying a prefix
> length for an address.

Ok.

We may specify it as a triplet [prefix/len; id; address] so that a
Client is told by the server which address is contained by which prefix,
so it does not have to think longest-match.  A quick manner to encode
this triplet itno a message is to use an address and a prefixlen only
(many protocols do that).

> AIUI a large part of the reason for separating the functions is to do
> with large organisation where different groups handle address
> management (ie DHCP) and another group handles routing - with an
> inference being that the two groups exist in isolation. IME (only in
>  small/medium businesses) is of doing both roles myself - and even
> where they are separate groups, neither can operate in isolation from
> the others (no good assigning addresses from a prefix that isn't
> routed to that network !).

I agree.

>> - Furthermore, also frustrating DHCPv6 for address management,
>> there is no way to transmit the MAC addresses of the DHCPv6
>> clients to the DHCPv6 server, thus making any attempts to correlate
>> DHCPv4 and DHCPv6 address assignments difficult.
>
> It's not just IPv4-IPv6 correlation. As I've expressed before, until
> vendors generate a DUID at the factory, store it in non-volatile
> memory in the device, print it on a barcode on the side of the box,
> and all OSs/DHCP clients use it - then it's both less useful, and
> less stable than a MAC address as an identifier. I see the need for
> a system wide UID, but I don't see the support appearing for it.
>
> As an aside, I once worked in a place with Apollo Domain systems. In
> those, the system identity was so closely tied to the network
> hardware address that replacing a NIC or moving a disk between
> machines involved a routine to update the file id for every file on
> the system. At least this is how I vaguely recall it being told to
> me.
>
>
>
>> Le 08/04/2015 18:00, Simon Hobson a écrit : [...]
>>> As an example, if you wish to send a packet to 2001:DB8:1::1 and
>>> you are told (via an RA) that 2001:DB8:1::/48 is on-link, then do
>>> you have enough information to determine if the destination
>>> address is on-link ? Answer - yes you do. All you need to do is
>>> the simple logical operations we're familiar with from the IPv4
>>> world - mask the address with the prefix length derived subnet
>>> mask, if the result matches then the address is "in" the prefix.
>>> Logical AND 2001:DB8::1 with ffff:ffff:ffff:: and you get
>>> 2001:DB8::, compare 2001:DB8:1:: with 2001:DB8:1:: and you'll
>>> find that it matches.
>>
>> This is exact matching on a specified plen.  W/o a plen specified
>> the operation is not that straightforward.  So a plen is
>> absolutely necessary.
>

Not trolling.

> Yes, a prefix length is necessary **FOR THE DESTINATION**, it is not
> necessary for our own address. No-one is talking about not having a
> prefix length for prefixes we are told are attached to the link (ie
> on-link).

Look - whenever adding an address on an interface you have to use a
prefixlen.

If you add an address on an interface manually then the system invents
an arbitrary one for you (64 or 128); if by using SLAAC you get the plen
from the RA.  If using DHCP you still get it from RA.  It all depends on
this RA.  This is not normal.

>> "longest-match": when plen1 and plen2 are present (plen2 is
>> longer), and an address matches on plen2 on each of the prefixes -
>> which prefix should be selected as the one containing the address?
>> This is difficult to say, since there is no spec.
>
> Assuming for one moment that there are no duplicate/overlapping
> prefixes across different interfaces, then it doesn't actually
> matter one jot whether you do longest wins, shortest wins, first
> match found wins, or even random. If the destination address matches
> *ANY* on-link prefix then the node is directly reachable via that
> link. The question we are answering is "can we directly reach that
> node", and that is "yes" if the node address is in any prefix on the
> link - the answer isn't a specific prefix, just a yes or no.
>
> The only case I can think of where this breaks down is if there is a
> broken network config - with multiple networks with overlapping IP
> ranges. In that case, you may find that the destination address
> matches one or more on-link prefixes on more than one link. IMO that
> is broken (addresses not globally unique) and I see no reason not to
> leave it to the implementer to do what they want - whether that's
> longest match first, shortest match first, or something else. In
> theory, if a node is reachable via either link, then it shouldn't
> matter which interface is used - one option might be to prefer
> higher performance (eg gigabit wired ethernet) over lower performance
> (eg wifi). An obvious situation this can arise is when connected to
> the same LAN via wired ethernet and wifi. If there are overlapping
> prefixes on multiple networks, but a node is only reachable via one
> of them, then that's a recipe for bigger problems and with the
> abundance of IPv6 addresses should be easily avoided.

I read your text.  I understand it somehow.  We can see  later.

Alex

>
>
>
> I'll finish by tossing in something to think about. You complain a
> lot about the complication of doing multiple prefix matches, which
> wins, etc. If we go down the route of saying every address has an
> associated prefix, then if we add (say) 20 addresses to an
> interface* then we've added 20 prefixes. Now, instead of matching
> against the one (or small number) of on-link prefixes explicitly
> configured, you have 20 prefixes to test - 19 tests are redundant as
> they should all give the same answer. The alternative is that when
> adding addresses, you have to figure out if there is already a prefix
> in the table and not add duplicates; and when deleting an address,
> the harder task of working out if this is the last address with that
> prefix and only deleting the prefix if it is. If you do that logic,
> then you are implicitly doing what you appear to be arguing against -
> treating the addresses and prefixes (routing table entries) as
> separate entities.
>
> * I see multiple addresses becoming a lot more common. I've been in
> IT long enough to remember when each web site needed it's own
> address, and using browsers without the new fangled host header
> support. These days, there are still browsers that don't fully
> support multiple SSL enabled sites on one IP. The extensions for
> both of these are in effect workarounds to avoid using multiple
> addresses - there are arguments** for going back to multiple
> addresses with the abundance of IPv6.
>
> ** Most of these relate to identity and accountability. Eg, when a
> site sends out an email, if each site uses a different address then
> there's no issue as to who sent it, no problems with being
> blacklisted because "a neighbour" on the same server sent spam, no
> problems being blacklisted because you don't have the right reverse
> DNS, etc, etc.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Apr 2015 19:18:01 +0900

> I'll let others argue whether the behavior in 1) is against the RFCs or

Actually, it's so clearly a violation of RFC 5942 section 4 that there's no
argument to be had. :-)

       the Prefix List.

> Speaking only for myself, I find it very sensible and practical.
>

Whether you find it sensible and practical does not change the fact that it
is incorrect.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Apr 2015 11:21:34 +0100

<snip>
> Look - whenever adding an address on an interface you have to use a

Then you are forever doomed to not understand IPv6 and be complaining that "it's wrong".
Because when adding an address you do **NOT** need to specify a prefix length - when adding an address **on an incorrect implementation** you need to provide one **only for the convenience of that implementation**, because it is **NOT** required in any way whatsoever for correct operation of IPv6.

Until you can separate what is actually needed, vs what certain implementations need, then you will never "get it". It did take me a while, and some explaining from others on this list before I "got it" - until then I thought like you and worked on the basis that what I was using (ie implementations in Linux) was "right".

I can fully see why the implementations are as they are - as Brian Haberman pointed out yesterday, people would have been rushing to get something working, and refactoring existing code is by far the easiest way to do that. Getting from where we are, to standards compliant will be an interesting challenge - deprecating certain things and persuading everyone to update everything that uses the old interface to update their software. The pragmatist in me thinks that perhaps it's not really necessary to rebuild all the code to not use prefix lengths with addresses - just default to /128 prefix lengths and throw out a warning message if anything different is set might be enough.

> this RA.  This is not normal.

In the IPv6 world it **IS** normal. IPv6 =/= IPv4. You may have many years working with such systems, but that seems to be part of your problem - a reluctance or inability to accept that IPv6 is different to IPv4 by design. We can argue about whether those design decisions are right or not, but that is the design.

Your position indicates that you are still stuck in IPv4 thinking where "IP address plus subnet mask == reachability information for neighbours". That's only true for certain network technologies (such as ethernet), and it's only true for single subnets.

There are, as pointed out in some of the RFCs/drafts you've read, networks where having an IP address in the same subnet/prefix as the destination does not make that destination directly reachable. In those cases, using "IP+subnet/prefix == reachability information" breaks.

In the IPv6 world, it is considered "normal" for there to be multiple prefixes and for hosts to have multiple addresses. Having a single prefix is merely a case of that multiple being one". Except in the special case of that multiple being one, using "IP+subnet/prefix == reachability information" breaks.

I'll give a further example of how I understand things are supposed to work - and why "old style" thinking doesn't work.

Lets say we have two (or more) internet providers, and unless we're big enough to go and get our own AS number etc, then we'll get different prefixes from each. In the normal case, each host is likely to be multihomed - having an address from each prefix, and we'll publish AAAA records for each address.
Each provider has a router, and each router provides an RA for the prefix(es) it serves. This is important - as I think you are assuming that all routers send the same list of prefixes. Each node aggregates the RA supplied prefixes to build it's prefix table.
Using ${some process}, each node will work out which traffic to send via each router (and which source address to use) - this is something I'm not 100% comfortable with, having been used to having routers make that decision.

Now lets say one provider goes offline. The router detects this (or is offline itself) and so RAs for the prefix(es) from that provider stop. When caches time out, each node will remove those prefixes from it's prefix table. Thus when a provider goes offline, the nodes using any prefix(es) from that provider will stop doing so - and in addition, nodes will also stop treating those prefixes as local.

So even though a DHCP server may still be handing out addresses in that prefix, or the hosts may be manually configured with them, they won't actually be used. Everything should fall back to using other addresses published for services/servers.

On the other hand, if you hand out **A** list of prefixes with DHCP - when a provider goes down, your network becomes "randomly broken" as nodes try to use addresses that are no longer valid. You have to detect the failed service, and update the DHCP configuration, and wait (perhaps days) for nodes to renew and get the update.
Alternatively, if DHCP doesn't do it, you have to manually configure each node to know about all the prefixes - and manually update them if a prefix is no longer valid.
Or you potentially have locally reachable neighbours communicating via two external connections if they are in different prefixes.

I hope it's obvious that for a situation like this, the separation of address assignment and routing information is "a good thing". It lets the routing dynamically update, without having to build "interesting" couplings between different services, and also operating quickly without the instability and risk from short DHCP lease times.

It doesn't address the issue of updating the outward facing DNS to remove the offline prefix - but that would be a problem no matter how the network addressing/routing was done. Between the service going down, and the DNS updates going out, clients will experience delays if they happen to try a "dead" address first before falling back and trying another address (they'll get a list of AAAA records, not just one) - but they will connect.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 13:23:22 +0200

Le 09/04/2015 12:21, Simon Hobson a écrit :
> Then you are forever doomed to not understand IPv6 and be
> complaining that "it's wrong". Because when adding an address you do
> **NOT** need to specify a prefix length - when adding an address **on
> an incorrect implementation** you need to provide one **only for the
> convenience of that implementation**, because it is **NOT** required
> in any way whatsoever for correct operation of IPv6.

Ok.

Is '128' the correct prefixlen to add to an address when putting it on
an interface?  Or is 64 the correct prefixlen?

Alex

>
> Until you can separate what is actually needed, vs what certain
> implementations need, then you will never "get it". It did take me a
> while, and some explaining from others on this list before I "got
> it" - until then I thought like you and worked on the basis that what
> I was using (ie implementations in Linux) was "right".
>
> I can fully see why the implementations are as they are - as Brian
> Haberman pointed out yesterday, people would have been rushing to
> get something working, and refactoring existing code is by far the
> easiest way to do that. Getting from where we are, to standards
> compliant will be an interesting challenge - deprecating certain
> things and persuading everyone to update everything that uses the
> old interface to update their software. The pragmatist in me thinks
> that perhaps it's not really necessary to rebuild all the code to not
> use prefix lengths with addresses - just default to /128 prefix
> lengths and throw out a warning message if anything different is set
> might be enough.
>
>
>> If you add an address on an interface manually then the system
>> invents an arbitrary one for you (64 or 128); if by using SLAAC
>> you get the plen from the RA.  If using DHCP you still get it from
>> RA. It all depends on this RA.  This is not normal.
>
> In the IPv6 world it **IS** normal. IPv6 =/= IPv4. You may have many
> years working with such systems, but that seems to be part of your
> problem - a reluctance or inability to accept that IPv6 is different
> to IPv4 by design. We can argue about whether those design decisions
> are right or not, but that is the design.
>
> Your position indicates that you are still stuck in IPv4 thinking
> where "IP address plus subnet mask == reachability information for
> neighbours". That's only true for certain network technologies (such
> as ethernet), and it's only true for single subnets.
>
> There are, as pointed out in some of the RFCs/drafts you've read,
> networks where having an IP address in the same subnet/prefix as the
> destination does not make that destination directly reachable. In
> those cases, using "IP+subnet/prefix == reachability information"
> breaks.
>
> In the IPv6 world, it is considered "normal" for there to be
> multiple prefixes and for hosts to have multiple addresses. Having a
> single prefix is merely a case of that multiple being one". Except in
> the special case of that multiple being one, using "IP+subnet/prefix
> == reachability information" breaks.
>
>
> I'll give a further example of how I understand things are supposed
> to work - and why "old style" thinking doesn't work.
>
> Lets say we have two (or more) internet providers, and unless we're
> big enough to go and get our own AS number etc, then we'll get
> different prefixes from each. In the normal case, each host is
> likely to be multihomed - having an address from each prefix, and
> we'll publish AAAA records for each address. Each provider has a
> router, and each router provides an RA for the prefix(es) it serves.
> This is important - as I think you are assuming that all routers send
> the same list of prefixes. Each node aggregates the RA supplied
> prefixes to build it's prefix table. Using ${some process}, each node
> will work out which traffic to send via each router (and which
> source address to use) - this is something I'm not 100% comfortable
> with, having been used to having routers make that decision.
>
> Now lets say one provider goes offline. The router detects this (or
> is offline itself) and so RAs for the prefix(es) from that provider
> stop. When caches time out, each node will remove those prefixes
> from it's prefix table. Thus when a provider goes offline, the nodes
> using any prefix(es) from that provider will stop doing so - and in
> addition, nodes will also stop treating those prefixes as local.
>
> So even though a DHCP server may still be handing out addresses in
> that prefix, or the hosts may be manually configured with them, they
> won't actually be used. Everything should fall back to using other
> addresses published for services/servers.
>
> On the other hand, if you hand out **A** list of prefixes with DHCP
> - when a provider goes down, your network becomes "randomly broken"
> as nodes try to use addresses that are no longer valid. You have to
> detect the failed service, and update the DHCP configuration, and
> wait (perhaps days) for nodes to renew and get the update.
> Alternatively, if DHCP doesn't do it, you have to manually configure
> each node to know about all the prefixes - and manually update them
> if a prefix is no longer valid. Or you potentially have locally
> reachable neighbours communicating via two external connections if
> they are in different prefixes.
>
> I hope it's obvious that for a situation like this, the separation
> of address assignment and routing information is "a good thing". It
> lets the routing dynamically update, without having to build
> "interesting" couplings between different services, and also
> operating quickly without the instability and risk from short DHCP
> lease times.
>
> It doesn't address the issue of updating the outward facing DNS to
> remove the offline prefix - but that would be a problem no matter
> how the network addressing/routing was done. Between the service
> going down, and the DNS updates going out, clients will experience
> delays if they happen to try a "dead" address first before falling
> back and trying another address (they'll get a list of AAAA records,
> not just one) - but they will connect.
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Apr 2015 07:30:01 -0400

> On Apr 9, 2015, at 7:23 AM 4/9/15, Alexandru Petrescu <[email-masked]> wrote:
> 

Neither.  There is *no* prefix length associated with an address.  The prefix lengths are associated with the *prefixes* assigned to the link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 13:42:04 +0200

Le 09/04/2015 13:30, Ralph Droms a écrit :
>>>> Look - whenever adding an address on an interface you have to
>>>> use a prefixlen.
>>>
>>> complaining that "it's wrong". Because when adding an address
>>> you do **NOT** need to specify a prefix length - when adding an
>>> address **on an incorrect implementation** you need to provide
>>> one **only for the convenience of that implementation**, because
>>> it is **NOT** required in any way whatsoever for correct
>>> operation of IPv6.
>>
>> Ok.
>>
>> Is '128' the correct prefixlen to add to an address when putting
>> it on an interface?  Or is 64 the correct prefixlen?
>
> Neither.  There is *no* prefix length associated with an address. The
> prefix lengths are associated with the *prefixes* assigned to the
> link.

This means that either there are no correct implementations of IPv6 out
there, or that a prefix must always assigned when an address is assigned.

If this latter then we absolutely want DHCP - which assigns addresses -
to also assign prefixes with their lengths.

Is there something blocking this?

Alex

>>> implementations need, then you will never "get it". It did take
>>> me a while, and some explaining from others on this list before
>>> I "got it" - until then I thought like you and worked on the
>>> basis that what I was using (ie implementations in Linux) was
>>> "right".
>>>
>>> I can fully see why the implementations are as they are - as
>>> Brian Haberman pointed out yesterday, people would have been
>>> rushing to get something working, and refactoring existing code
>>> is by far the easiest way to do that. Getting from where we are,
>>> to standards compliant will be an interesting challenge -
>>> deprecating certain things and persuading everyone to update
>>> everything that uses the old interface to update their software.
>>> The pragmatist in me thinks that perhaps it's not really
>>> necessary to rebuild all the code to not use prefix lengths with
>>> addresses - just default to /128 prefix lengths and throw out a
>>> warning message if anything different is set might be enough.
>>>
>>>
>>>>  invents an arbitrary one for you (64 or 128); if by using
>>>> SLAAC you get the plen from the RA.  If using DHCP you still
>>>> get it from RA. It all depends on this RA.  This is not
>>>> normal.
>>>
>>> In the IPv6 world it **IS** normal. IPv6 =/= IPv4. You may have
>>> many years working with such systems, but that seems to be part
>>> of your problem - a reluctance or inability to accept that IPv6
>>> is different to IPv4 by design. We can argue about whether those
>>> design decisions are right or not, but that is the design.
>>>
>>> where "IP address plus subnet mask == reachability information
>>> for neighbours". That's only true for certain network
>>> technologies (such as ethernet), and it's only true for single
>>> subnets.
>>>
>>> networks where having an IP address in the same subnet/prefix as
>>> the destination does not make that destination directly
>>> reachable. In those cases, using "IP+subnet/prefix ==
>>> reachability information" breaks.
>>>
>>> multiple prefixes and for hosts to have multiple addresses.
>>> Having a single prefix is merely a case of that multiple being
>>> one". Except in the special case of that multiple being one,
>>> using "IP+subnet/prefix == reachability information" breaks.
>>>
>>>
>>> I'll give a further example of how I understand things are
>>> supposed to work - and why "old style" thinking doesn't work.
>>>
>>> Lets say we have two (or more) internet providers, and unless
>>> we're big enough to go and get our own AS number etc, then we'll
>>> get different prefixes from each. In the normal case, each host
>>> is likely to be multihomed - having an address from each prefix,
>>> and we'll publish AAAA records for each address. Each provider
>>> has a router, and each router provides an RA for the prefix(es)
>>> it serves. This is important - as I think you are assuming that
>>> all routers send the same list of prefixes. Each node aggregates
>>> the RA supplied prefixes to build it's prefix table. Using
>>> ${some process}, each node will work out which traffic to send
>>> via each router (and which source address to use) - this is
>>> something I'm not 100% comfortable with, having been used to
>>> having routers make that decision.
>>>
>>> Now lets say one provider goes offline. The router detects this
>>> (or is offline itself) and so RAs for the prefix(es) from that
>>> provider stop. When caches time out, each node will remove those
>>> prefixes from it's prefix table. Thus when a provider goes
>>> offline, the nodes using any prefix(es) from that provider will
>>> stop doing so - and in addition, nodes will also stop treating
>>> those prefixes as local.
>>>
>>> So even though a DHCP server may still be handing out addresses
>>> in that prefix, or the hosts may be manually configured with
>>> them, they won't actually be used. Everything should fall back
>>> to using other addresses published for services/servers.
>>>
>>> On the other hand, if you hand out **A** list of prefixes with
>>> DHCP - when a provider goes down, your network becomes "randomly
>>> broken" as nodes try to use addresses that are no longer valid.
>>> You have to detect the failed service, and update the DHCP
>>> configuration, and wait (perhaps days) for nodes to renew and
>>> get the update. Alternatively, if DHCP doesn't do it, you have
>>> to manually configure each node to know about all the prefixes -
>>> and manually update them if a prefix is no longer valid. Or you
>>> potentially have locally reachable neighbours communicating via
>>> two external connections if they are in different prefixes.
>>>
>>> I hope it's obvious that for a situation like this, the
>>> separation of address assignment and routing information is "a
>>> good thing". It lets the routing dynamically update, without
>>> having to build "interesting" couplings between different
>>> services, and also operating quickly without the instability and
>>> risk from short DHCP lease times.
>>>
>>> It doesn't address the issue of updating the outward facing DNS
>>> to remove the offline prefix - but that would be a problem no
>>> matter how the network addressing/routing was done. Between the
>>> service going down, and the DNS updates going out, clients will
>>> experience delays if they happen to try a "dead" address first
>>> before falling back and trying another address (they'll get a
>>> list of AAAA records, not just one) - but they will connect.
>>>
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>

---

From: [email-masked]
Date: Thu, 09 Apr 2015 13:56:36 +0200 (CEST)

> Is there something blocking this?

DHCPv6 IA_NA can assign an address, no prefix length.
DHCPv6 IA_PD can assign a prefix.

Neither of them can assign a default gateway / specify on-link prefixes.

DHCPv6 *hosts* will normally not ask for IA_PD.

Steinar Haug, AS 2116

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2015 08:02:36 -0400

> other way interpret DUIDs." (RFC 3315 ch. 9)

The "explicit prohibition" that you are referring to is for the purposes of using the MAC address inside the DUID as a protocol element.   There is nothing wrong with you inferring something from the DUID if you want.   The problem would arise if you used the MAC address contained in the DUID, and not the DUID, as the key that uniquely identified the address assignment.

As for the client link address, if there is no relay agent, then the DHCP server can just scrape the layer two address off of the packet--there's no need to send it twice.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Apr 2015 21:12:18 +0900

> there, or that a prefix must always assigned when an address is assigned.

No, there's a third choice: assigning an address can be implemented by
assigning a prefix of length /128.

> to also assign prefixes with their lengths.

That does not follow at all.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2015 08:15:42 -0400

> there, or that a prefix must always assigned when an address is assigned.

What makes an implementation correct or incorrect is not the details of how it is implemented, but rather whether or not it conforms to the specification.   An implementation that treats an IPv6 address it receives from DHCPv6 as having no associated prefix length will behave correctly.   One that treats it as having an associated prefix length will not.   So assuming that what you have said about FreeBSD is correct, FreeBSD will exhibit incorrect behavior in some situations, imputing reachability to addresses that are not reachable and failing to communicate with such hosts.

This is easy to test: set up two links each with a DHCP relay and a router that is advertising a default route but no prefixes, and that is routing between the two links.   Have the DHCP server issue IP addresses to both links from the same /64 prefix.   Configure a Linux box and a FreeBSD box on each link with a DHCP client.   Now try to communicate between the two Linux boxes, between the two FreeBSD boxes, and between a Linux box on one link and a FreeBSD box on the other link.

What you will see is that the Linux boxes will succeed in communicating, and the FreeBSD boxes will not be able to communicate either with each other or with Linux boxes on the other link, but _will_ be able to communicate with the Linux box on the same link.

So, again assuming that what you've reported about FreeBSD is correct, the FreeBSD box doesn't conform to the specification.

All of this discussion about how Linux imputes a /128 and FreeBSD imputes a /64 is irrelevant, because you're talking about details of how the stack is implemented, not about the _behavior_ of the stack.

---

From: [email-masked]
Date: Thu, 09 Apr 2015 14:20:21 +0200 (CEST)

> The "explicit prohibition" that you are referring to is for the purposes of using the MAC address inside the DUID as a protocol element.   There is nothing wrong with you inferring something from t…

It feels a bit like discussing "How many angels can dance on the head
of a pin?"  If I use the MAC address for the purpose of correlating
IPv4 and IPv6 address assignments, but use DUID to identify the
address assignment, the protocol police won't go after me? :-)

In any case, if RFC 3315 meant to say that there is nothing wrong in
inferring MAC address from DUID (as long as it's not used as a key to
identify the address assignment), I think the section quoted above
needs to be clarified.

Steinar Haug, AS 2116

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Apr 2015 13:40:53 +0100

> identify the address assignment), I think the section quoted above

I agree, what the RFC says, and what Ted says (no offence intended), are mutually exclusive. We've had this discussion before as well :-/
But then it's not necessarily all that helpful as only DUID-LL and DUID-LLT have a readable MAC address - and these aren't generally used by "desktop" level devices (ie computers).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Apr 2015 09:02:28 -0400

> address assignment, the protocol police won't go after me? :-)

This represents a bit of a mischaracterization of what it means for a standard to say something.   When you see a MUST in a standard, it's intended to ensure that different implements interoperate correctly and behave correctly.   That's _all_ it means.   The only protocol police that exists is harsh reality: if you use the MAC address and not the DUID as a key, you will experience interop problems.  But if you are just trying to do correlation between DHCPv4 and DHCPv6, and there's no _protocol_ change, there is no reason not to do it.

> identify the address assignment), I think the section quoted above

RFC 3315 is specifying the protocol, so it is correct in what it says.   Just remember that all of the MUSTs and SHOULDs are for interop purposes and don't go any farther than that, and you should be okay.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Apr 2015 16:57:21 +0200

Le 09/04/2015 14:12, Lorenzo Colitti a écrit :
> On Thu, Apr 9, 2015 at 8:42 PM, Alexandru Petrescu

That is not specified.  Would you think consensus can be found to write 
down that statement of the 3rd choice?

> That does not follow at all.

If the 3rd choice above is not done (specify that assigning an address 
can be implemented by assigning a prefix of length /128) then what else 
would in your opinion follow?

Or should we leave it there: non-existent implementations of true IPv6.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Apr 2015 00:36:21 +0900

On Thu, Apr 9, 2015 at 11:57 PM, Alexandru Petrescu <
[email-masked]> wrote:

> If the 3rd choice above is not done (specify that assigning an address can
> be implemented by assigning a prefix of length /128) then what else would
> in your opinion follow?
>

As Ted keeps saying, what's important is not how you configure the
implementation, but how it behaves.

If configuring an address on a host causes the host to think that the whole
of the address' /64 is on link, then the host is behaving incorrectly. If
configuring an address on a host does not cause the host to believe that
any other addresses are on link, then the host is behaving correctly,
regardless of whether the host displays the address as "2001:db8::1",
"2001:db8::1/128", "2001:0db8:0:00:0:0:0000:00/onetwentyeight", or
"20010db8000000000000000000000001 80".

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 10:19:15 +0200

Le 09/04/2015 17:36, Lorenzo Colitti a écrit :
> On Thu, Apr 9, 2015 at 11:57 PM, Alexandru Petrescu
>     If the 3rd choice above is not done (specify that assigning an
>     address can be implemented by assigning a prefix of length /128)
>     then what else would in your opinion follow?
>

I disagree: RFCs should specify behaviour. Programmer should use it as a
precise first-hand guide on how to implement. Some place for imagination
of the programmer should be left of course, and the spec language should
be independent of the programming language also.

Plen is not a thing to be left to imagination.

> If configuring an address on a host causes the host to think that the
> whole of the address' /64 is on link, then the host is behaving
> incorrectly. If configuring an address on a host does not cause the host
> to believe that any other addresses are on link, then the host is
> behaving correctly, regardless of whether the host displays the address
> as "2001:db8::1", "2001:db8::1/128",
> "2001:0db8:0:00:0:0:0000:00/onetwentyeight", or

I agree, address/plen this is just a notation, for when there is a
hidden prefix; and the address in itself does not have a plen associated.

But here I ask whether or not /128 is the correct prefix length to be
assumed when the prefix length is not specified?

You seem to say that /128 is the correct prefix length to be assumed
when a prefix length is not specified.

But I disagree with that: /128 is not the right prefix length to be
assumed when a prefix length is not specified.

Because, in one particular cellular deployment the RA does not provide
the plen, and the address is provided by DHCP. In this, one wants the
assumed plen to be /127 or shorter (and certainly not 128) because there
are two ends in that subnet (the Client and the Router). At times there
are 3 ends in that subnet (the Client and two Routers): then the 
assumed' plen should be /126 or shorter.

For these reasons, the plen should be told and not assumed.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 10:27:13 +0200

Le 09/04/2015 14:15, Ted Lemon a écrit :
>> This means that either there are no correct implementations of IPv6
>> out there, or that a prefix must always assigned when an address is
>> assigned.
>
> What makes an implementation correct or incorrect is not the details
>  of how it is implemented, but rather whether or not it conforms to
> the specification.   An implementation that treats an IPv6 address it
> receives from DHCPv6 as having no associated prefix length will
> behave correctly.   One that treats it as having an associated prefix
> length will not.

Both linux and bsd assume an associated prefix length.  Some dhclient too.

> So assuming that what you have said about FreeBSD is correct,
> FreeBSD will exhibit incorrect behavior in some situations, imputing
> reachability to addresses that are not reachable and failing to
> communicate with such hosts.

I agree.

> This is easy to test: set up two links each with a DHCP relay and a
> router that is advertising a default route but no prefixes, and that
>  is routing between the two links.   Have the DHCP server issue IP
> addresses to both links from the same /64 prefix.   Configure a Linux
> box and a FreeBSD box on each link with a DHCP client.   Now try to
> communicate between the two Linux boxes, between the two FreeBSD
> boxes, and between a Linux box on one link and a FreeBSD box on the
> other link.
>
> What you will see is that the Linux boxes will succeed in
> communicating, and the FreeBSD boxes will not be able to communicate
>  either with each other or with Linux boxes on the other link, but
> _will_ be able to communicate with the Linux box on the same link.
>
> So, again assuming that what you've reported about FreeBSD is
> correct, the FreeBSD box doesn't conform to the specification.

(fyi Steinar reported the bsd ifconfig, to be confirmed).

I would not blame BSD for that.  In some cases what BSD seems to be
doing (assume /64 instead of linux's /128 when no plen is given) makes
work ok other things which wouldnt work if it were assumed 128.

Also, if we are to take RFCs by letter, both BSD and linux violate
RFC5942 section 4 bullet 1 "MUST NOT implicitly cause a prefix
derived from that address to be treated as on-link and added to      the
Prefix List."

Linux violates that because linux too causes a prefix to be derived from
that address as it adds an entry to the rt table (in linux there are 2
entries in the rt table added: one for the real interface and one for
the loopback).

To me this is a point where it is not stacks (bsd or linux) that are in
error - they need something to put there and simply dont know what.

Alex

>
> All of this discussion about how Linux imputes a /128 and FreeBSD
> imputes a /64 is irrelevant, because you're talking about details of
>  how the stack is implemented, not about the _behavior_ of the
> stack.
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Apr 2015 17:31:54 +0900

> assumed when the prefix length is not specified?

Yes, it is the correct prefix length. It is correct because it is the only
prefix length that includes nothing except the address itself. Thus, it is
the only prefix length that conforms with RFC 5942 section 4.1:

       assignment of an IPv6 address [...] MUST NOT implicitly cause a
prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.

> are 3 ends in that subnet (the Client and two Routers): then the assumed'
> plen should be /126 or shorter.
>

In that deployment you will need to find a way to add an on-link prefix.
Unlike DHCPv4, DHCPv6 does not do this and has never done this. You can do
this with an RA containing a Prefix Information option with L=1, A=0; the
relevant text in RFC 4861 is:

   [ADDRCONF] may impose certain restrictions on the prefix length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, the
   prefix length is still valid for on-link determination when combined
   with other flags in the prefix option.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 09:41:21 +0100

Alexandru Petrescu <[email-masked]> wrote:

> are 3 ends in that subnet (the Client and two Routers): then the assumed' plen should be /126 or shorter.
> 

You still don't make a case for the spec being wrong.
Why doesn't the RA contain a prefix length ?
Why can't the implementation work without it ?

Without going and having a detailed read (I'm supposed to be at work !), if a device gets an RA is it allowed to assume that the router it gets it from is on-link for the interface it received the RA on ? If the spec doesn't allow for that then it needs changing, but otherwise getting an RA is sufficient for the client to communicate - regardless of the IPs on the client and router (they do **NOT** have to be in the same prefix, unlike IPv4).

It looks like you still have not grasped the fundamental difference that in the IPv6 world "address + prefix length does not equal reachability information" and "in same prefix" is absolutely not required for two devices to directly communicate.

> error - they need something to put there and simply dont know what.

Yes they are in error. As previously pointed out, the logical approach would have been to refactor the IPv4 code - thus dragging along legacy assumptions for the ride.
The "easy fix" would be to force all addresses to be /128 - then the incorrect operations (adding a route entry for the prefix) becomes a null operation. That's an easy fix for the DHCP client - just add a /128 prefix length to keep the tools happy.

Going back to your example, if the client assumed a /64 prefix - could one mobile device then talk *directly* to any other mobile device in that prefix ? If not sending the packet to the router, but just doing ND to find the other device on the *broadcast* network.
I assume the answer is no. And that's the issue this "don't assume (direct) reachability" bit is there to fix - not all networks support end-device to end-device communications even if they are in the same prefix. It's directly mentioned in the pre-amble to both the RFCs that have been previously mentioned.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Apr 2015 11:02:25 +0200 (CEST)

> Why can't the implementation work without it ?

Any valid IPv6 with DHCPv6 support implementation should work correctly in 
the face of the following:

RA received with no on-link prefix, with M=1.
IA_NA asked for and received.

Now, the client should have an address on the interace, answer ND 
reachability questions for this address, and then if it needs to send 
traffic, send all of it to the default gw implied by the RA received.

On the gateway, there is a /something configured (that matches the DHCPv6 
IA_NA scope) so the router has no problem to send traffic to multiple 
devices on its interface. I just doesn't announce this /something as being 
on-link. None of these devices will try to send traffic to each other 
unless the router is configured to send ICMPv6 redirects (which in this 
scenario is unlikely because the reason for the setup would be that one 
actually wants all traffic to go via the router for some reason).

"ip -6 r l" on the IA_NA device would most likely (it was 3-4 years since 
I did this last so I don't remember exactly) show a /128 on the interface 
and a default route towards the default gateway learnt from RA.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 11:49:27 +0200

Le 10/04/2015 10:31, Lorenzo Colitti a écrit :
> On Fri, Apr 10, 2015 at 5:19 PM, Alexandru Petrescu
> Yes, it is the correct prefix length. It is correct because it is the
> only prefix length that includes nothing except the address itself.
> Thus, it is the only prefix length that conforms with RFC 5942 section 4.1:
>
> Unlike DHCPv4, DHCPv6 does not do this and has never done this.

Why?

Does DHCPv6 know that sometimes RA is not usable at all?

> You can
> do this with an RA containing a Prefix Information option with L=1, A=0;
> the relevant text in RFC 4861 is:
>

Things are not that simple.

In that deployment there are two RAs each issued by a different router, 
on a same link.  One RA contains the prefix of the link (plen 64).  But 
it is sent only once when the link is put up and never again.

Soliciting an RA leads to the 2nd router responding, and that second RA 
contains no prefix.

These RAs are not sent periodically, just once at the beginning, and 
when solicited.  There are reasons for it to act so, e.g. avoid channel 
occupancy and others.

But DHCPv4 and DHCPv6 respond ok to all kinds of DHCP messages.  Were 
DHCPv6 to provide the plen all could be fine.

Alex

---

From: [email-masked]
Date: Fri, 10 Apr 2015 12:18:36 +0200 (CEST)

> Does DHCPv6 know that sometimes RA is not usable at all?

DHCPv6 was designed to be dependent on RA. You may disagree about
that decision (I certainly do) - but that's the situation today.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 12:30:52 +0200

Le 10/04/2015 12:18, [email-masked] a écrit :
>>> In that deployment you will need to find a way to add an on-link
>>> prefix. Unlike DHCPv4, DHCPv6 does not do this and has never
>>> done this.
>>
>> Why?
>>
> DHCPv6 was designed to be dependent on RA.

But it was not designed to work when RA itself fails.

For example, Prefix Information Option (PIO) is just an option to be in
RA.  Some RAs carry it but others dont.

Other parameters in RA like lifetime values, curr hop limit, are always
there (not optional).

Whatever is optionally absent in RA should be optionally present in
DHCP, otherwise the whole design fails.

> You may disagree about that decision (I certainly do) - but that's
> the situation today.

It is not a happy situation to be in.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 13:14:08 +0200

Le 10/04/2015 10:41, Simon Hobson a écrit :
>> But here I ask whether or not /128 is the correct prefix length to
>> be assumed when the prefix length is not specified?
>>
>> You seem to say that /128 is the correct prefix length to be
>> Because, in one particular cellular deployment the RA does not
>> provide the plen, and the address is provided by DHCP. In this,
>> one wants the assumed plen to be /127 or shorter (and certainly
>> not 128) because there are two ends in that subnet (the Client and
>> the Router). At times there are 3 ends in that subnet (the Client
>> and two Routers): then the assumed' plen should be /126 or
>> shorter.
>>
> You still don't make a case for the spec being wrong. Why doesn't
> the RA contain a prefix length ?

Because the sysadmin did not put one there.

There are two RAs on this link, coming from two different routers.

The first RA is sent only once, when the interface comes up.  It does
not contain plen.  Never again later.

The second RA is sent unicast whenever solicited, but contains no prefix.

There are reasons to be so.  One that I can imagine is that it takes
less bandwidth (the RA containing a prefix is two times larger than w/o
a prefix).  There are other reasons there, but that's the way it is.

> Why can't the implementation work without it ?

The current implementation uses dhclient to acquire an address.  DHCPv6
does not provide a plen.  That dhclient thus uses a plen to be 64.  That
64 breaks RFC5942 section 4 bullet 1.  The plen is a must when adding an
address on an interface.

Other implementations prefer plen 128 instead of 64.  That 128 breaks a
neighboring relationship: the host does find a neighbor in its rt table
while the neighbor routers are there.

> Without going and having a detailed read (I'm supposed to be at work
> !), if a device gets an RA is it allowed to assume that the router
> it gets it from is on-link for the interface it received the RA on ?

Yes.  For that to work it will need to add an entry in its routing table
to tell it so.  That is happily the default route.  This is ok.

> If the spec doesn't allow for that then it needs changing, but
> otherwise getting an RA is sufficient for the client to communicate
> - regardless of the IPs on the client and router (they do **NOT**
> have to be in the same prefix, unlike IPv4).

Yes, it is sufficient to communicate with that router and with the 
Internet, if that's a default route.

The problem is not there.

The problem is that the RA does not contain a prefix, and the address is 
given by DHCP w/o a plen.

> It looks like you still have not grasped the fundamental difference
> that in the IPv6 world "address + prefix length does not equal
> reachability information" and "in same prefix" is absolutely not
> required for two devices to directly communicate.

YEs, and I refuse maybe to grasp it.

The reason is that IPv6 must work as IPv4 as much as possible.

If this plen were such a bad thing then why dont we remove it from 
DHCPv4?  IPv4 RA could deliver it instead.

Alex

>> doing (assume /64 instead of linux's /128 when no plen is given)
>> makes work ok other things which wouldnt work if it were assumed
>> 128.
>>
>> Linux violates that because linux too causes a prefix to be
>> derived from that address as it adds an entry to the rt table (in
>> linux there are 2 entries in the rt table added: one for the real
>> interface and one for the loopback).
>>
>> To me this is a point where it is not stacks (bsd or linux) that
>> are in error - they need something to put there and simply dont
>> know what.
>
> Yes they are in error. As previously pointed out, the logical
> approach would have been to refactor the IPv4 code - thus dragging
> along legacy assumptions for the ride. The "easy fix" would be to
> force all addresses to be /128 - then the incorrect operations
> (adding a route entry for the prefix) becomes a null operation.
> That's an easy fix for the DHCP client - just add a /128 prefix
> length to keep the tools happy.
>
> Going back to your example, if the client assumed a /64 prefix -
> could one mobile device then talk *directly* to any other mobile
> device in that prefix ? If not sending the packet to the router, but
> just doing ND to find the other device on the *broadcast* network. I
> assume the answer is no. And that's the issue this "don't assume
> (direct) reachability" bit is there to fix - not all networks
> support end-device to end-device communications even if they are in
> the same prefix. It's directly mentioned in the pre-amble to both the
> RFCs that have been previously mentioned.
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 13:16:48 +0200

> length to keep the tools happy.

I would not agree with that either.

/128 plen on an address makes no sense.  There are neighbors to that 
address on that interface; their common prefix should be used instead of 
/128.

/128 is a hack which works in some cases.

Alex

> (direct) reachability" bit is there to fix - not all networks support
> end-device to end-device communications even if they are in the same
> prefix. It's directly mentioned in the pre-amble to both the RFCs
> that have been previously mentioned.
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 07:55:39 -0400

> be independent of the programming language also.

The RFCs specify the behavior of the host on the network, not the user interface of the host.   You are trying to argue about a user interface issue here.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 07:59:50 -0400

> RA.  Some RAs carry it but others dont.

It is a valid configuration for the router not to advertise any prefixes on the link, but just a default route.   It's not only valid, but potentially useful.   Referring to this as a configuration error or as "when the RA itself fails" is precisely the disconnect we seem to be having.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 14:21:59 +0200

Le 10/04/2015 13:59, Ted Lemon a écrit :
>> For example, Prefix Information Option (PIO) is just an option to
>> be in RA.  Some RAs carry it but others dont.
>
> It is a valid configuration for the router not to advertise any
> prefixes on the link, but just a default route.

That (the default route) is not mandatory in RA either.

> It's not only valid, but potentially useful.   Referring to this as a
> configuration error or as "when the RA itself fails" is precisely the
> disconnect we seem to be having.

I meant to say that cases where RA does to offer what the Host expects.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 14:27:37 +0200

Le 10/04/2015 13:55, Ted Lemon a écrit :
>>> As Ted keeps saying, what's important is not how you configure
>>> the implementation, but how it behaves.
>>
>> I disagree: RFCs should specify behaviour. Programmer should use
>> it as a precise first-hand guide on how to implement. Some place
>> for imagination of the programmer should be left of course, and
>> the spec language should be independent of the programming
>> language also.
>
> The RFCs specify the behavior of the host on the network, not the
> user interface of the host.   You are trying to argue about a user
> interface issue here.

This is not just UI here.

An /128 entry in a routing table for an address assigned by DHCP makes
no sense.  A rt entry is made to be compared with a dst address, not
with a src address.

Alex

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 10 Apr 2015 12:27:35 +0000

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, April 10, 2015 8:22 AM
To: Ted Lemon
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Microphone comment about DHCPv6 address prefix length

> I meant to say that cases where RA does to offer what the Host expects.

Sorry, I haven't been reading all emails on this thread.   However, for the question above, if the RA includes no PIO, then the router is signally each destination is off-link - send traffic to the default router.

Hemant

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 13:42:12 +0100

> a prefix).  There are other reasons there, but that's the way it is.

Actually, I see nothing wrong with that.

> The current implementation uses dhclient to acquire an address.
> DHCPv6 does not provide a plen.

Correct, that is by design.

> That dhclient thus uses a plen to be 64.  That

Please try in your mind to separate the two things.
A prefix length is **NOT** in any way required in order to have an IPv6 address.
The **CLIENT UI IMPLEMENTATION** requires that one be specified.

That a client uses a /64 is **WRONG**. The client is broken and you should be targeting your efforts at the vendor to get that fixed. If the client implementation either used /128 (a hack), or better still did not try to associate prefixes with addresses (significant code redesign), then it would most likey "just work" out of the box.

> while the neighbor routers are there.

Actually, /128 is correct.
The device will communicate with the default gateway it's learned from the RA, and **IFF** the network supports it and the router is correctly configured, it will learn of directly reachable neighbours via ICMP redirects from the router. If it cannot directly communicate with other devices (which is quite possible on such a radio system) then it is correct that no on-link prefixes are specified in the RAs.

> The problem is that the RA does not contain a prefix, and the address is given by DHCP w/o a plen.

But there is no problem there, the problem is in your mind.

> The reason is that IPv6 must work as IPv4 as much as possible.

I can see your point, but IPv6 is **NOT** "IPV4 with extra address bits".
There were lots of things wrong, or at least suboptimal, in IPv4 - IPv6 is an opportunity to start afresh and fix some of those. We may not like some of the changes (I'm not a fan of some), but they are changed and that's that.

So far, your argument is boiling down to "I don't like change" - with a pinch of "our system doesn't work because the standard don't match our incorrect setup". (where "incorrect setup" includes the client that applies a prefix length that it should not be doing).

Alexandru Petrescu <[email-masked]> wrote:

> /128 plen on an address makes no sense.  There are neighbors to that address on that interface; their common prefix should be used instead of /128.

But it makes perfect sense if you understand that devices do not have to be in the same prefix to communicate with each other, AND that addresses are separate from the routing table. As explained before, the "is address in a prefix" decision needs only the **destination** address and the **on-link** prefix list - it needs no information about what prefix(es) our own address(es) are or are not members of.

> /128 is a hack which works in some cases.

Yes it is. It's a hack that works around incorrect implementations.

> no sense.  A rt entry is made to be compared with a dst address, not

Correct, but this is an artefact of having to use a /128 prefix length in order to work around the incorrect implementation. The /128 route to our own address is, as you say, completely superfluous - but it doesn't actually break anything. It is not required by the specs.

The destination routes *should* be populated according to RAs received. If there are no on-link prefixes supplied by RA, then there should be no prefix table entries implying direct reachability of neighbours. There may well be neighbour routes as a result of ICMP redirects from a router - if the network supports that and the router is configured for it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 15:13:13 +0200

Le 10/04/2015 14:42, Simon Hobson a écrit :
[...]

>> That dhclient thus uses a plen to be 64.  That 64 breaks RFC5942
>> section 4 bullet 1.  The plen is a must when adding an address on
>> an interface.
>
> Please try in your mind to separate the two things. A prefix length
> is **NOT** in any way required in order to have an IPv6 address. The
> **CLIENT UI IMPLEMENTATION** requires that one be specified.
>
> That a client uses a /64 is **WRONG**. The client is broken and you
> should be targeting your efforts at the vendor to get that fixed.

The software writer asks this "if not 64 then what else"?

>> Other implementations prefer plen 128 instead of 64.  That 128
>> breaks a neighboring relationship: the host does find a neighbor
>> in its rt table while the neighbor routers are there.
>

But it is less correct to set an entry in the rt table for an address
allocated for self.  The rt table is for destination not for sources.

> The device will communicate with the default gateway it's learned
> from the RA, and **IFF** the network supports it and the router is
> correctly configured, it will learn of directly reachable neighbours
> via ICMP redirects from the router.

ICMP redirects from the router are ok, but some times routers dont issue
ICMP redirects (it's the case here).

> If it cannot directly communicate with other devices (which is quite
>  possible on such a radio system) then it is correct that no on-link
>  prefixes are specified in the RAs.

Maybe yes.

But it's hard to demand implementation of ICMP redirect.  Maybe that
stack does not implement it, maybe it's filtered out for firewalling.
With firewalling, it's illogic to forbid IPv4 ICMP Redirects, but allow
IPv6 ICMP Redirects.

It's simpler to have it in dhcp.

> But there is no problem there, the problem is in your mind.

No no, I have a deployment problem.  I hack around with 64 and 128 on
interfaces to just make it work for IPv6, whereas all works fine with IPv4.

>>> It looks like you still have not grasped the fundamental
>>> difference that in the IPv6 world "address + prefix length does
>>> not equal reachability information" and "in same prefix" is
>>> absolutely not required for two devices to directly communicate.
>>

Well it should.  And DHCPv6 plen is only part of the differences.  All
these translate in heavy workload in making IPv6 work.  Or maybe people
like that workload?

> There were lots of things wrong, or at least suboptimal, in IPv4

I beg to disagree.  IPv4 works out of the box everywhere and that is the
first requirement.  IPv6 is an add-on that pretends to be different and
hence harder to deploy.

> IPv6 is an opportunity to start afresh and fix some of those.

Maybe it was so in the past.  IPv4 also evolved a lot and many things
work better now than 20 years ago.

> We may not like some of the changes (I'm not a fan of some), but
> they are changed and that's that.
>
> So far, your argument is boiling down to "I don't like change" -
> with

I am not in a situation to not liking change.  I do propose IPv6 to
everyone.

The situation I am in is that many customers ask IPv4 and I suggest them
IPv6 together with it.

But, to get through, firewalling is the first thing that must be
precisely the same in IPv6 as in IPv4.  Because IPv4 firewalling is
tried and true and works and we dont want new IPv6 attacks for the sake
of migrating to IPv6.

Or, firewalling is the same in IPv6 as in IPv4 only when the protocols
are the same.

Alex

>> /128 plen on an address makes no sense.  There are neighbors to
>> that address on that interface; their common prefix should be used
>> instead of /128.
>
> But it makes perfect sense if you understand that devices do not
> have to be in the same prefix to communicate with each other, AND
> that addresses are separate from the routing table. As explained
> before, the "is address in a prefix" decision needs only the
> **destination** address and the **on-link** prefix list - it needs no
> information about what prefix(es) our own address(es) are or are not
> members of.
>
>> An /128 entry in a routing table for an address assigned by DHCP
>> makes no sense.  A rt entry is made to be compared with a dst
>> address, not with a src address.
>
> Correct, but this is an artefact of having to use a /128 prefix
> length in order to work around the incorrect implementation. The
> /128 route to our own address is, as you say, completely superfluous
> - but it doesn't actually break anything. It is not required by the
> specs.
>
> The destination routes *should* be populated according to RAs
> received. If there are no on-link prefixes supplied by RA, then
> there should be no prefix table entries implying direct reachability
> of neighbours. There may well be neighbour routes as a result of
> ICMP redirects from a router - if the network supports that and the
> router is configured for it.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Apr 2015 15:23:24 +0200 (CEST)

> interfaces to just make it work for IPv6, whereas all works fine with IPv4.

Your problem is that you're trying to do something that violates the IPv6 
fundamental design, and your solution to this is to say that DHCPv6 should 
be changed.

You're asking for a fundamental change in the way IPv6 was designed, and 
you haven't given a good reason for this, other than to wave hands and say 
you need it to be this way.

If you want IPv6 to work as you expect in IPv4, you need to send RAs with 
prefix and default gateway. DHCPv6 IA_NA was never intended to work on its 
own. If you want to hack around, I encourage you to implement proprietary 
options in DHCPv6 to signal to your special client what it needs to do for 
your special use-case, and then you implement enough support for this in 
your client.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Apr 2015 09:23:55 -0400

> no sense.  A rt entry is made to be compared with a dst address, not

Hmm... I have an application running on my machine that communicates
with another application on my machine.  I can't use the DHCPv6-assigned
address as a destination address for communication between these
applications???

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Apr 2015 22:54:51 +0900

> address as a destination address for communication between these

You can. Every implementation I've seen will configure things so that if
you assign an IP address to an interface, packets sent to that IP address
are looped back to the IP stack instead of sent on that interface.

RFC 6724 Rule 1, if you are trying to talk to an address that is assigned
to your host, you will always use that address.

So yes, if all you have is a DHCPv6 address, you can use that to talk
between applications on the same machine. That's not very useful though -
you can use ::1 for that too. You can also talk to link-local addresses,
which is only marginally more useful.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Apr 2015 09:58:13 -0400

Hi Lorenzo,

> which is only marginally more useful.

I pretty much agree with everything you wrote.  I was just trying to
point out a valid reason to Alex why a device should add a route table
entry for a DHCPv6-assigned address with a prefix length of 128.

Regards,
Brian

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 15:34:43 +0100

> The software writer asks this "if not 64 then what else"?

Which is fair enough.
The "correct" answer is that there is no prefix length<period>.
Given that the tools incorrectly require one, then the useful answer is "if the tools demand one, then use /128 which should fudge things enough to work correctly.

> allocated for self.  The rt table is for destination not for sources.

We're talking about how to "make things work properly in the face of incorrect implementations. You are right that adding a route to ourselves with a /128 prefix isn't correct - it's a side effect of having to provide a prefix length when one does not exist. However, having such a route doesn't actually break anything.

> ICMP redirects (it's the case here).

Then the router must forward the packets. It **MUST** do one or the other, *OR* you must have a network that supports direct communication AND supply the right RAs.
This is sounding like "we set it up wrong but it's the standard's fault it doesn't work".

> With firewalling, it's illogic to forbid IPv4 ICMP Redirects, but allow

If a router is even half way to being a decent router then it'll handle redirects - as they do for IPv4. If it can't handle fundamental things, then it's not correct to call it a "router".
Again, this is an implementation vs standard issue - and it's not the standard that's the problem here. And yet again, if you configure it to not do something then that's your issue.

> first requirement.

Complete and utter bulls**t.
IPv4 certainly does not work properly out of the box everywhere. There are a **LOT** of hacks on various networks needed to make stuff work - it appears you have little experience outside of "broadcast capable, ethernet like" networks or you wouldn't make such a statement.

> IPv6 is an add-on that pretends to be different and hence harder to deploy.

It is a new protocol, it is not pretending to be different, it *IS* different.

> work better now than 20 years ago.

But regardless of how some tweaks may be done, the fundamental design cannot be changed without breaking every existing implementation. This is a good argument for getting IPv6 right - before it gets to the "can't change anything without breaking the internet" stage (actually, I think we're more or less past that for the basics now).

> Or, firewalling is the same in IPv6 as in IPv4 only when the protocols

There's no significant difference between firewalling IPv6 and IPv4. Some details yes, but fundamentally it's the same process.

Mikael Abrahamsson <[email-masked]> wrote:

> Your problem is that you're trying to do something that violates the IPv6 fundamental design, and your solution to this is to say that DHCPv6 should be changed.
> 
> You're asking for a fundamental change in the way IPv6 was designed, and you haven't given a good reason for this, other than to wave hands and say you need it to be this way.
> 
> If you want IPv6 to work as you expect in IPv4, you need to send RAs with prefix and default gateway. DHCPv6 IA_NA was never intended to work on its own. If you want to hack around, I encourage you to implement proprietary options in DHCPv6 to signal to your special client what it needs to do for your special use-case, and then you implement enough support for this in your client.

+1

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 10:46:19 -0400

> no sense.  A rt entry is made to be compared with a dst address, not

We do not specify data structures on operating systems any more than we specify user interfaces.   Should we require the use of red/black trees for routing tables?   Binary trees?   Heap sort/binary search?

The answer is that we do not do things like that not only because it would be inappropriate, but because the debate about which algorithm to select would never end.   Just like this discussion.   Please stop.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 17:03:36 +0200

> address as a destination address for communication between these

YEs you could, but wouldnt the ::1 be better for that app on that machine?

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 16:08:18 +0100

> YEs you could, but wouldnt the ::1 be better for that app on that machine?

Not always.
There are many reasons why connecting to a non-loopback address makes sense. Not least is where you've configured certain services to only listen on certain addresses.
But his question wasn't one needing an answer - it was pointing out the error in your logic.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 17:14:33 +0200

Le 10/04/2015 16:34, Simon Hobson a écrit :
>>> That a client uses a /64 is **WRONG**. The client is broken and
>>> you should be targeting your efforts at the vendor to get that
>>> fixed.
>>
> Which is fair enough. The "correct" answer is that there is no prefix
> length<period>. Given that the tools incorrectly require one, then
> the useful answer is "if the tools demand one, then use /128 which
> should fudge things enough to work correctly.

Again - if you put there 128 you loose all your neighbors.

Alex

>>>> breaks a neighboring relationship: the host does find a
>>>> neighbor in its rt table while the neighbor routers are there.
>>>
>> But it is less correct to set an entry in the rt table for an
>> address allocated for self.  The rt table is for destination not
>> for sources.
>
> We're talking about how to "make things work properly in the face of
> incorrect implementations. You are right that adding a route to
> ourselves with a /128 prefix isn't correct - it's a side effect of
> having to provide a prefix length when one does not exist. However,
> having such a route doesn't actually break anything.
>
>> ICMP redirects from the router are ok, but some times routers dont
>> issue ICMP redirects (it's the case here).
>
> Then the router must forward the packets. It **MUST** do one or the
> other, *OR* you must have a network that supports direct
> communication AND supply the right RAs. This is sounding like "we set
> it up wrong but it's the standard's fault it doesn't work".
>
>>> If it cannot directly communicate with other devices (which is
>>> quite possible on such a radio system) then it is correct that no
>>> on-link prefixes are specified in the RAs.
>>
>> Maybe yes.
>>
>> But it's hard to demand implementation of ICMP redirect.  Maybe
>> that stack does not implement it, maybe it's filtered out for
>> firewalling. With firewalling, it's illogic to forbid IPv4 ICMP
>> Redirects, but allow IPv6 ICMP Redirects.
>
> If a router is even half way to being a decent router then it'll
> handle redirects - as they do for IPv4. If it can't handle
> fundamental things, then it's not correct to call it a "router".
> Again, this is an implementation vs standard issue - and it's not the
> standard that's the problem here. And yet again, if you configure it
> to not do something then that's your issue.
>
>> I beg to disagree.  IPv4 works out of the box everywhere and that
>> is the first requirement.
>
> Complete and utter bulls**t. IPv4 certainly does not work properly
> out of the box everywhere. There are a **LOT** of hacks on various
> networks needed to make stuff work - it appears you have little
> experience outside of "broadcast capable, ethernet like" networks or
> you wouldn't make such a statement.
>
>
>
>> Maybe it was so in the past.  IPv4 also evolved a lot and many
>> things work better now than 20 years ago.
>
> But regardless of how some tweaks may be done, the fundamental design
> cannot be changed without breaking every existing implementation.
> This is a good argument for getting IPv6 right - before it gets to
> the "can't change anything without breaking the internet" stage
> (actually, I think we're more or less past that for the basics now).
>
>> precisely the same in IPv6 as in IPv4.  Because IPv4 firewalling
>> is tried and true and works and we dont want new IPv6 attacks for
>> the sake of migrating to IPv6.
>>
>> Or, firewalling is the same in IPv6 as in IPv4 only when the
>> protocols are the same.
>
> There's no significant difference between firewalling IPv6 and IPv4.
> Some details yes, but fundamentally it's the same process.
>
>
>
>
>> Your problem is that you're trying to do something that violates
>> the IPv6 fundamental design, and your solution to this is to say
>> that DHCPv6 should be changed.
>>
>> You're asking for a fundamental change in the way IPv6 was
>> designed, and you haven't given a good reason for this, other than
>> to wave hands and say you need it to be this way.
>>
>> If you want IPv6 to work as you expect in IPv4, you need to send
>> RAs with prefix and default gateway. DHCPv6 IA_NA was never
>> intended to work on its own. If you want to hack around, I
>> encourage you to implement proprietary options in DHCPv6 to signal
>> to your special client what it needs to do for your special
>> use-case, and then you implement enough support for this in your
>> client.
>
> +1
>
>
>
>

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 16:35:53 +0100

> Again - if you put there 128 you loose all your neighbors.

Now listen carefully. NO YOU DO NOT<period>
If you use a /128, the system will **CORRECTLY** use the information it is given to determine which addresses are directly reachable neighbours. It really is as simple as that.
Your problem is that you have what sound like an improperly configured network and you won't accept that the answer is to properly configure it rather than "fix" the standards.

Sticking with your cellular network. When a node A is configured with an address, and node B is configured with an address, should nodes A and B be able to send packets directly to each other ? Ie, is it a broadcast network like ethernet, or is it a unicast network where each device can only talk to the base router ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 17:41:33 +0200

Le 10/04/2015 17:35, Simon Hobson a écrit :
>>> Which is fair enough. The "correct" answer is that there is no
>>> prefix length<period>. Given that the tools incorrectly require
>>> one, then the useful answer is "if the tools demand one, then use
>>> /128 which should fudge things enough to work correctly.
>>
> Now listen carefully. NO YOU DO NOT<period> If you use a /128, the
> system will **CORRECTLY** use the information it is given to
> determine which addresses are directly reachable neighbours. It
> really is as simple as that. Your problem is that you have what sound
> like an improperly configured network and you won't accept that the
> answer is to properly configure it rather than "fix" the standards.
>
> Sticking with your cellular network. When a node A is configured with
> an address, and node B is configured with an address, should nodes A
> and B be able to send packets directly to each other ? Ie, is it a
> broadcast network like ethernet, or is it a unicast network where
> each device can only talk to the base router ?

It's a unicast that tends to become broadcast more and more (get rid of 
pppd).

A is the Client (smartphone), B and C are two routers on that link with 
two different ll addresses, in the infrastructure.

That would be a /126.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 16:48:05 +0100

Alexandru Petrescu <[email-masked]> wrote:

> It's a unicast that tends to become broadcast more and more (get rid of pppd).
> 
> A is the Client (smartphone), B and C are two routers on that link with two different ll addresses, in the infrastructure.
> 
> That would be a /126.

Not necessarily. They could all be /128, they could be in a /64, or they could be in a /56, or they could be in a /48, or ...

Now please answer the question I asked - and in case it wasn't clear enough I'll change it slightly.
If two end devices (say smartphone A and smartphone B) are connected to your network, does the network technology allow them to directly communicate (ie direct A-B) or does communication have to go via a router (ie A-R-B) ? Ignore addressing, whether it's IPv4 or IPv6, at the lowest network level - can they directly exchange packets ?

And if they can, are the restrictions (such as them having to be "signed in" with the same cell/controller) for it to work, or will it work regardless of the device location/the cell it's signed in with/ etc ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 18:08:06 +0200

Le 10/04/2015 17:48, Simon Hobson a écrit :
>>> Sticking with your cellular network. When a node A is configured
>>> with an address, and node B is configured with an address,
>>> should nodes A and B be able to send packets directly to each
>>> other ? Ie, is it a broadcast network like ethernet, or is it a
>>> unicast network where each device can only talk to the base
>>> router ?
>>
>> A is the Client (smartphone), B and C are two routers on that link
>> with two different ll addresses, in the infrastructure.
>>
>> That would be a /126.
>
> Not necessarily. They could all be /128, they could be in a /64, or
> they could be in a /56, or they could be in a /48, or ...

We know that only three IP addresses are there.  The longest prefix
stringing them would be a /126.  Other plens like /48 and /64 are also
possible but would represent an enormous address waste.  And yes,
everything could be /128 in this Internet.  But host-based routes have
inconvenients that I suppose well known.

(and yes I know consensus considers there are enough /64s out there)

> Now please answer the question I asked - and in case it wasn't clear
> enough I'll change it slightly. If two end devices (say smartphone A
> and smartphone B) are connected to your network, does the network
> technology allow them to directly communicate (ie direct A-B) or
> does communication have to go via a router (ie A-R-B) ? Ignore
> addressing, whether it's IPv4 or IPv6, at the lowest network level -
> can they directly exchange packets ?

I can answer you by digging something, but I dont know why you ask.

Intuitevely, that is where cellular systems go: A talk directly to B at
IP layer.  Link-layer packets may continue go to R for
some time and maybe (just maybe) one day they won't, although it is unsure.

> And if they can, are the restrictions (such as them having to be
> "signed in" with the same cell/controller) for it to work, or will
> it work regardless of the device location/the cell it's signed in
> with/ etc ?

That I couldnt know, because I would need a special traffic analyzer to
show these link-layer headers - I dont have that and I dont want to get one.

Why is this related to our discussion on prefix lengths?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 12:08:41 -0400

> Again - if you put there 128 you loose all your neighbors.

Okay, so if I understand you, what you are saying is that if you install a /128 route to the IA_NA address, then that will remove any route to that a narrower prefix containing that /128.   But that's not true.   The /128 route will only match the one IP address that it was added for; if there is already a route for the /64 that contains the /128, then installing the /128 will not prevent the /64 from working, and you will be able to communicate with your neighbors just fine.

However, if all you have is the IA_NA, then addresses that are in that /64 are not guaranteed to be on-link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 18:18:10 +0200

Le 10/04/2015 18:08, Ted Lemon a écrit :
> Okay, so if I understand you, what you are saying is that if you
> install a /128 route to the IA_NA address, then that will remove any
> route to that a narrower prefix containing that /128.   But that's
> not true.

Right (although I am not saying that a route is removed).

> The /128 route will only match the one IP address that it was added
> for;

YEs.

> if there is already a route for the /64 that contains the /128,

who put that /64 route there?  The faulty dhclient?  DHCP doesnt, RA doesnt.

> then installing the /128 will not prevent the /64 from working, and
> you will be able to communicate with your neighbors just fine.

Yes.  But if you install a /128 you will not install a /64 too;
because nobody tells you to install a /64.

It is in that sense that you lose your neighbors: you dont install a 64
because that RFC tells you you must not deduce and install a 64 if all
you get is an address from DHCP.

> However, if all you have is the IA_NA, then addresses that are in
> that /64 are not guaranteed to be on-link.

Yes.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 17:26:01 +0100

> who put that /64 route there?  The faulty dhclient?  DHCP doesnt, RA doesnt.

RA **WILL** if it's configured to. Eg, on an ethernet network, if you are using a /64 on it, then your RA would specify that that prefix is on-link and the OS stack will then add a route to the /64  - or more correctly, add the /64 prefix to it's list of known prefixes, which will most likely manifest itself in the UI as a "route".
Or it could have been manually configured by an administrator.

> because nobody tells you to install a /64.

If the RA tells you to, you install it. If the administrator manually configures it, then you install it.

>> that /64 are not guaranteed to be on-link.

Which is why you **MUST NOT** deduce that when getting an address, other addresses in the prefix you infer applies to it are directly reachable.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Apr 2015 17:33:08 +0100

Alexandru Petrescu <[email-masked]> wrote:

> possible but would represent an enormous address waste.

No, you still will not let go of that IPv4 thinking.
You could have thousands of end devices on the network, all using addresses from one /64 prefix.

> Why is this related to our discussion on prefix lengths?

It's related to why you think things are broken. Now we find that you do not even know how the network works. If you don't know fundamentals like that, then you cannot say things are broken.

You do not need a protocol analyser - you should be able to answer the question. Can subscriber device A send a packet directly to subscriber device B, under all circumstances ? Can device A find device B by broadcast, or does it need to be told the hardware address to use by a third party (ie router) ?

You **NEED** to know things like this, if you can describe your network, someone can probably tell you what's wrong - though that's out of scope for this list, it's effectively where this thread has been going for 2 days.
If someone explains what is wrong and how to fix it, perhaps then you'll accept that the concepts you are being told actually do work !
If you can't describe *your* network, then there's no point carrying on the discussion - because we don't know for you.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 18:43:04 +0200

Le 10/04/2015 18:26, Simon Hobson a écrit :
> RA **WILL** if it's configured to.

It's configured to be sent only once, and only at the beginning of the
connection process.  After that, the subsequent RAs dont have a plen.

It's as if you put up and down your interface to see an RA/plen.

This is ok for smartphones who browse the web now and then, but it is
less ok for computer permanently connected on cellular links.

Of course - one could ask the network operator to put /64 in all
subsequent RAs.  But there are reasons for that request to get rejected,
and I already told you some of these reasons.

Btw, there may be other reasons for the operator to reject putting a /64
in each DHCP message as well, I dont know.

> Eg, on an ethernet network, if you are using a /64 on it, then your
> RA would specify that that prefix is on-link and the OS stack will
> then add a route to the /64  - or more correctly, add the /64 prefix
> to it's list of known prefixes, which will most likely manifest
> itself in the UI as a "route". Or it could have been manually
> configured by an administrator.

Yes and yes.

>>> then installing the /128 will not prevent the /64 from working,
>>> and you will be able to communicate with your neighbors just
>>> fine.
>>
> If the RA tells you to, you install it. If the administrator
> manually configures it, then you install it.

The RA tells it so just once.  If you lose that once then it's lost
forever.  You can solicit other RAs, you get them, but they dont have
prefixes in them.

> Which is why you **MUST NOT** deduce that when getting an address,
> other addresses in the prefix you infer applies to it are directly
> reachable.

I do not infer any prefix or prefixlen from an address.  I want to be
told the prefixlen.  I dont want to imagine one.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2015 19:04:34 +0200

Le 10/04/2015 18:33, Simon Hobson a écrit :
[...]
> You do not need a protocol analyser - you should be able to answer
> the question. Can subscriber device A send a packet directly to
> subscriber device B, under all circumstances ?

YEs it can but what do you mean by 'directly'.

> Can device A find device B by broadcast, or does it need to be told
> the hardware address to use by a third party (ie router) ?

In principle, A should be able to try to find B by multicasting an NS.
I would need to check whether a Redirect is present but I havent seen
any up to now.  There are MLD REPORTs about joining these local groups.

But of course this being a cellular system, and evolving as we speak,
quirks are present here and there, like IEEE-allocated MAC addresses for
3GPP interfaces, using all 24 bits 0 on the interface specific.

> You **NEED** to know things like this, if you can describe your
> network, someone can probably tell you what's wrong - though that's
> out of scope for this list, it's effectively where this thread has
> been going for 2 days. If someone explains what is wrong and how to
> fix it, perhaps then you'll accept that the concepts you are being
> told actually do work ! If you can't describe *your* network, then
> there's no point carrying on the discussion - because we don't know
> for you.

Let me clarify - I do not ask anybody to debug this deployment.  It
works for the purposes it is designed.  It is a huge step forward from
before.  It has other advantages over other cellular systems, like
offering simultaneous IPv4 and IPv6.

I tell you how things happen there to explain why RA is not something
that is always there.

In Ethernet in general one is right to assume RA/plen always there.  But
that is not the case for e.g. some particular cellular system.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Apr 2015 12:00:24 -0700

At Thu, 09 Apr 2015 13:42:04 +0200,

> there, or that a prefix must always assigned when an address is assigned.

It seems to me that several things are conflated:

A. Externally visible behavior of an implementation (e.g., whether one
   implementation can reach another after some kind of events like
   getting an RA or DHCP-based address assignment)
B. Internal implementation details to realize the behavior
C. Operational interface exposed to the user of an implementation

In general, my understanding is that if we talk about "correctness" in
terms of protocol conformance, only point A matters.  Some
implementations may have something ugly in their implementation
details due to, e.g., historical constraints, but as long as
externally visible behavior conforms to what the protocol
specification states, it's generally considered "correct".

In that sense I believe most of existing implementations are actually
correct in terms of address and prefix relationship.

I don't know much about Linux internal, but BSD variants clearly
separate the concepts of address and prefix in the kernel internal
(you can see the latter by 'ndp -p'), and determine whether a
particular destination is directly reachable just on the prefix
information.

You can indeed specify the "prefix length" when you manually configure
an address, but this is actually a shortcut of manually configuring an
address (which doesn't have a concept of prefix length) and manually
configuring an on-link prefix derived from the address and the prefix
length.

I admit there may still be some confusing part, especially in user
interfaces (e.g., in retrospect, it was a bad idea to use the default
value of 64 for prefix length in BSD's ifconfig implementation), but
it's not because implementors didn't understand the spec or the spec
was unclear, but mainly due to technical compromise between protocol
purity and compatibility/meeting expectations of legacy users.

I also tend to agree that there's some gap to be filled in the sense
of protocol discussion: today it's not very clear how to manage an
isolated network using DHCPv6-based address assignment.  (Although
IMO this should be outside of rfc3315bis) just saying "run an
RA-advertising server/router" is probably not enough at least in
practice.  Also, if there's really a common case where running an
RA-advertising node isn't feasible (I don't think the operational cost
is a critical reason - if it's really needed it shouldn't be that
difficult to unify that feature in a DHCPv6 server implementation),
there may actually be a technical gap that has to be filled with some
protocol extensions.  Only then it makes sense to discuss a specific
solution like providing on-link prefix information via DHCPv6.

>From the discussion so far, I wasn't even convinced whether you
deployment example proves the need for *some* protocol enhancements.
Simply repeating the need for a specific solution of 'prefix-info by
DHCPv6' without even persuading others on the problem won't get us
anywhere.

So, if I may, my suggestion for you is to write an I-D explaining why
you cannot deploy your network with a router (or any node) that keeps
advertising RAs.  If it's convincing enough we can then move on to the
next step.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 15:53:57 -0400

> you get is an address from DHCP.

No, in that case you never had any neighbors.   There is no event that can be described as "losing your neighbors."

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Apr 2015 16:04:36 -0400

> 3GPP interfaces, using all 24 bits 0 on the interface specific.

Alex, Simon is talking about what happens at layer 1 and 2, not at layer 2.5.   And what happens at layers 1 and 2 is that handsets do not communicate, because they do not have dependable propagation.  Handset A, in order to talk to handset B, sends its packet to router R, which forwards it to handset B.   Handsets never communicate directly with each other.   This is true not only of cellular networks, but also of wifi infrastructure networks.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 11 Apr 2015 10:39:38 +0100

On 10 Apr 2015, at 18:04, Alexandru Petrescu <[email-masked]> wrote:

> Let me clarify - I do not ask anybody to debug this deployment.

Well actually, indirectly you are. Because you are adamant that the standards are wrong because **YOUR DEPLOYMENT** doesn't work properly - and you are not prepared to accept that perhaps the standards are right *IFF* the deployment is done properly. I am certain that your deployment is wrong, because several things you have said about it do not make sense.
* Note: deployment includes the clients.

Now, taking a few things said, adding what (not a lot) I know about cellular and radio systems (architecturally, treat them as a hub and spoke arrangement with a load of P-P links), and this is what I think should be happening.

You have a base infrastructure with router(s), DHCP server(s), and of course - all the radio gear and pipes to hook it all together.

A subscriber comes along and signs in with the network. The back end system (through whatever means) determines an IPv6 address for the client. This address (**NO** prefix) is delivered to the client (via PPP or DHCP or something else according to the technology in use) which configures it on it's interface.
The client addresses may be determined in many ways. Most likely, the simplest will be a single /56 or /48 block across the whole network. It may also be a /64 or /56 across a smaller part of the network (say a region managed by one management node). That is a design issue for whoever creates it.

Alongside this, the router(s) may or may not send an unsolicited RA. Because the clients can't realistically talk directly to all other clients in the prefix, any RAs sent do **NOT** contain any on-link prefixes. The RAs will of course contain router information.

At this point, the client is now a working IPv6 node. It has an IPv6 address, it does not think any other IPv6 addresses are "on-link", and it knows the address of at least one router it can use to send packets.
Note that the client has just two pieces of information : it's address, and the address of a router. It has **NO** prefixes configured.

When the client wants to communicate with the DHCP server, it sends it's renewal packet to the router. In such a setup, I'd expect that to be handled by a relay agent rather than being attached to the link directly. The router will either relay the packet (relay agent), or it will forward it. In the unlikely event that the client node can actually send packets directly to the DHCP server without going through the router, then the router will send an ICMP redirect and the node will then know that the server is on-link.

The client will need to periodically send Router Solicitation messages to get fresh RAs. As you point out, for a client that's only active intermittently, this is probably more efficient that the router broadcasting them all the time.

Normal internet traffic will of course just go out through the router.

Should one client node wish to talk to another client node, then things get more interesting. In the general case, I would not expect this to be possible - it would be inefficient to allow one client to send a broadcast (multicast) message out across your whole network and to all other subscribers ! So my expectation is that all traffic would go via the gateway router regardless of destination.
However, if client-client communication is possible and allowed - which might be possible in a subset of cases such as both clients attached to same cell tower - then if the router determines that this is possible, it may send an ICMP redirect to one of the clients informing it that the other client is directly reachable. I would doubt if this would be allowed at all though for various management and technical reasons.

> that is not the case for e.g. some particular cellular system.

So you are now allowing for the prefix length to not be there, after spending several days arguing that it **MUST** be there and refusing to listen to reason.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Apr 2015 10:38:15 +0200

Le 10/04/2015 21:53, Ted Lemon a écrit :
>> It is in that sense that you lose your neighbors: you dont install
>> a 64 because that RFC tells you you must not deduce and install a
>> 64 if all you get is an address from DHCP.
>
> No, in that case you never had any neighbors.   There is no event
> that can be described as "losing your neighbors."
>
>

Losing ability to have neighbors (run ND).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Apr 2015 10:39:47 +0200

Le 10/04/2015 22:04, Ted Lemon a écrit :
>> In principle, A should be able to try to find B by multicasting an
>> NS. I would need to check whether a Redirect is present but I
>> havent seen any up to now.  There are MLD REPORTs about joining
>> these local groups.
>>
>> But of course this being a cellular system, and evolving as we
>> speak, quirks are present here and there, like IEEE-allocated MAC
>> addresses for 3GPP interfaces, using all 24 bits 0 on the
>> interface specific.
>
> Alex, Simon is talking about what happens at layer 1 and 2, not at
> layer 2.5.   And what happens at layers 1 and 2 is that handsets do
> not communicate, because they do not have dependable propagation.
> Handset A, in order to talk to handset B, sends its packet to router
> R, which forwards it to handset B.   Handsets never communicate
> directly with each other.   This is true not only of cellular
> networks, but also of wifi infrastructure networks.

I agree.  At layer 1 and 2 that's how it acts in cellular and wifi,
(although ND is on top of them and considers them neighbors.)

(and there are exceptions like D2D, LTE Direct and IBSS).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Apr 2015 11:23:55 +0200

Le 11/04/2015 11:39, Simon Hobson a écrit :
> Well actually, indirectly you are. Because you are adamant that the
> standards are wrong because **YOUR DEPLOYMENT** doesn't work
> properly - and you are not prepared to accept that perhaps the
> standards are right *IFF* the deployment is done properly. I am
> certain that your deployment is wrong, because several things you
> have said about it do not make sense. * Note: deployment includes the
> clients.
>
>
> Now, taking a few things said, adding what (not a lot) I know about
> cellular and radio systems (architecturally, treat them as a hub and
> spoke arrangement with a load of P-P links), and this is what I think
> should be happening.
>
>
> You have a base infrastructure with router(s), DHCP server(s), and
> of course - all the radio gear and pipes to hook it all together.
>
> A subscriber comes along and signs in with the network. The back end
> system (through whatever means) determines an IPv6 address for the
> client. This address (**NO** prefix) is delivered to the client (via
> PPP or DHCP or something else according to the technology in use)
> which configures it on it's interface. The client addresses may be
> determined in many ways. Most likely, the simplest will be a single
> /56 or /48 block across the whole network. It may also be a /64 or
> /56 across a smaller part of the network (say a region managed by
> one management node). That is a design issue for whoever creates it.
>
> Alongside this, the router(s) may or may not send an unsolicited RA.
> Because the clients can't realistically talk directly to all other
> clients in the prefix, any RAs sent do **NOT** contain any on-link
> prefixes. The RAs will of course contain router information.
>
> At this point, the client is now a working IPv6 node. It has an IPv6
> address, it does not think any other IPv6 addresses are "on-link",
> and it knows the address of at least one router it can use to send
> packets. Note that the client has just two pieces of information :
> it's address, and the address of a router. It has **NO** prefixes
> configured.

Sure, it works.

The problems are the following: (1) all cell operators I am aware of
only deliver only a /64, not shorter.  As such that handset can't be
used for clean tethering.

(2) the setting you describe precludes the use of Neighbor Discovery.
We want ND to work on these links.  The new generation of drivers make
that ptp link loook as if it were an Ethernet link, use ND.  This
tendency is very pronounced.

> When the client wants to communicate with the DHCP server, it sends
> it's renewal packet to the router.

Yes.

> In such a setup, I'd expect that to be handled by a relay agent
> rather than being attached to the link directly.

I'd expect it too, but no, no Relay.  Because the src address of the
DHCP Advertise is a link-local address. (if it were a relay the src
would have been a global address of the Server).

Cellular deployments of IPv6 have an additional distinct legs of DHCP 
for DHCPv6 Prefix Delegation.

I find this cumbersome (two distinct legs of DHCP) - the straight
way would be to use a DHCP topology with Server and Relay. But of course
there may be other reasons for these two distinct legs, that I am not 
aware of.

> The router will either relay the packet (relay agent), or it will
> forward it. In the unlikely event that the client node can actually
> send packets directly to the DHCP server without going through the
> router, then the router will send an ICMP redirect and the node will
> then know that the server is on-link.

There's no redirect in my link.  But technologically it should be possible.

> The client will need to periodically send Router Solicitation
> messages to get fresh RAs. As you point out, for a client that's
> only active intermittently, this is probably more efficient that the
>  router broadcasting them all the time.

YEs, but there is more to that.

The refreshing RAs come from different source than the initial RA, and
the refreshing RA is half the size of the initial RA (contains no
prefix/plen).

And there are Clients needing hours-long continuous connections.

YEs.

> Should one client node wish to talk to another client node, then
> things get more interesting. In the general case, I would not expect
> this to be possible - it would be inefficient to allow one client to
> send a broadcast (multicast) message out across your whole network
> and to all other subscribers !

No, this is old view.

The reason applies only if we talk broadcast.

But with multicast that worry disappears.

Handsets interested to listen to ND will join that multicast group.

> So my expectation is that all traffic would go via the gateway router
> regardless of destination. However, if client-client communication is
> possible and allowed - which might be possible in a subset of cases
> such as both clients attached to same cell tower - then if the router
> determines that this is possible, it may send an ICMP redirect to one
> of the clients informing it that the other client is directly
> reachable.

I agree with you in a certain sense.

But, using ND and prefixes instead of ICMP Redirect host-based routes
has certain advantages, like small routing tables and aggregated routes.

The small world of interfaces of cellular networks slowly moves towards
this ND-capable behaviour hiding the point-to-point nature.

It has a great advantage in that LTE Direct and Device-to-Device
communications without tower become easily possible, supportable.

> I would doubt if this would be allowed at all though for various
> management and technical reasons.

Yes, there are reasons like that, e.g. the spectrum is licensed so it
must be very well controlled (large investment is at stake), and
security and identification on a per-identifier basis.

>> In Ethernet in general one is right to assume RA/plen always
>> there. But that is not the case for e.g. some particular cellular
>> system.
>
> So you are now allowing for the prefix length to not be there, after
> spending several days arguing that it **MUST** be there and refusing
> to listen to reason.

I meant to say in Ethernet RA containing plen is always there.

In cellular systems RA containing a plen is not always there.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Apr 2015 22:43:50 +0300

Le 10/04/2015 22:00, 神明達哉 a écrit :
[...]

> particular destination is directly reachable just on the prefix

Yes.  Linux has a similar command to display structures of ND.

> You can indeed specify the "prefix length" when you manually
> configure an address, but this is actually a shortcut of manually
> configuring an address (which doesn't have a concept of prefix
> length) and manually configuring an on-link prefix derived from the
> address and the prefix length.
>
> interfaces (e.g., in retrospect, it was a bad idea to use the
> default value of 64 for prefix length in BSD's ifconfig
> implementation), but it's not because implementors didn't understand
> the spec or the spec was unclear, but mainly due to technical
> compromise between protocol purity and compatibility/meeting
> expectations of legacy users.

On my side, I also think there is much confusion.

Even in Windows: one can not manually set an address without stating a 
prefixlength (named "subnet mask").

> RA-advertising node isn't feasible (I don't think the operational
> cost is a critical reason - if it's really needed it shouldn't be
> that difficult to unify that feature in a DHCPv6 server
> implementation), there may actually be a technical gap that has to be
> filled with some protocol extensions.  Only then it makes sense to
> discuss a specific solution like providing on-link prefix information
> via DHCPv6.
>

Right.

> So, if I may, my suggestion for you is to write an I-D explaining
> why you cannot deploy your network with a router (or any node) that
> keeps advertising RAs.  If it's convincing enough we can then move on
> to the next step.

Ok; I will need co-authors.

Alex

> -- JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 09:52:26 +0900

> Ok; I will need co-authors.

Before you start writing a document... what is the reason that you can't do
this?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 13:33:35 +0300

Le 15/04/2015 03:52, Lorenzo Colitti a écrit :
> On Wed, Apr 15, 2015 at 4:43 AM, Alexandru Petrescu
> Before you start writing a document... what is the reason that you can't
> do this?

BEfore answering that - do we agree that the plen is mandatory?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 19:38:23 +0900

> BEfore answering that - do we agree that the plen is mandatory?

plen of what? Of an address? Of an on-link prefix?

Mandatory for what?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 13:43:53 +0300

Le 15/04/2015 13:38, Lorenzo Colitti a écrit :
> On Wed, Apr 15, 2015 at 7:33 PM, Alexandru Petrescu
>                  keeps advertising RAs.  If it's convincing enough we
>         can then
>                  move on
>                  to the next step.
>
>

Whenever assigning an address to some computer a plen must be given as 
well (a decimal value between 1 and 128).  Do we agree with this?

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 15 Apr 2015 12:06:05 +0100

Alexandru Petrescu <[email-masked]> wrote:

> Whenever assigning an address to some computer a plen must be given as well (a decimal value between 1 and 128).  Do we agree with this?

No. Because it is not.
The fact that some (most ?) implementations require it for historical/compatibility reasons does not make it so.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 20:16:08 +0900

> well (a decimal value between 1 and 128).  Do we agree with this?

Even if we did agree, it wouldn't really matter, because the IETF does not
standardize node user interfaces. It primarily standardizes node behaviour.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 15 Apr 2015 12:24:54 +0100

Lorenzo Colitti <[email-masked]> wrote:

> Even if we did agree, it wouldn't really matter, because the IETF does not standardize node user interfaces. It primarily standardizes node behaviour.

But I think Alexandru's argument is that a node cannot operate if it has an address without a prefix length - that's behaviour rather than user interface.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 14:33:02 +0300

Le 15/04/2015 14:06, Simon Hobson a écrit :
>> Whenever assigning an address to some computer a plen must be
>> given as well (a decimal value between 1 and 128).  Do we agree
>> with this?
>
> No. Because it is not. The fact that some (most ?) implementations
> require it for historical/compatibility reasons does not make it so.

An address does not have a prefixlen.  A prefixlen for that address is
required in order to behave and determine neighbordhood relationships 
("on-link determination RFC4861") and optimizations such as reducing 
search times and routing table sizes.  An implicit prefixlen is valued 
at 128 on some node user interface, and 64 on another node user 
interface.  An explicit prefixlen may be specified by RA.

Hm?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 20:33:27 +0900

On Wed, Apr 15, 2015 at 8:24 PM, Simon Hobson <[email-masked]>
wrote:

> > Even if we did agree, it wouldn't really matter, because the IETF does
> not standardize node user interfaces. It primarily standardizes node
> behaviour.
>
> But I think Alexandru's argument is that a node cannot operate if it has
> an address without a prefix length - that's behaviour rather than user
> interface.

If it can't, then it's in violation of RFC 5942, no?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Apr 2015 07:39:28 -0400

> BEfore answering that - do we agree that the plen is mandatory?

No.   All you need is a default route.   Prefix length is optional.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 20:41:36 +0900

On Wed, Apr 15, 2015 at 8:33 PM, Alexandru Petrescu <
[email-masked]> wrote:

> A prefixlen for that address is required in order to behave and determine
> neighbordhood relationships ("on-link determination RFC4861")

No. What is required to determine which nodes are directly reachable on
link-via neighbour discovery is not the prefix length of the address. What
is required is *an on-link prefix*.

The prefix is not required to be associated with the address, though some
implementations may couple the two together.

If the destination address matches one of the on-link prefixes,
communication happens directly, via ND. If it does not, communication must
happen through a router.

and optimizations such as reducing search times and routing table sizes.
> An implicit prefixlen is valued at 128 on some node user interface, and 64
> on another node user interface.  An explicit prefixlen may be specified by
> RA.
>

No. An RA may specify an on-link prefix. It does not specify the prefix
length of any addresses.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 15:04:42 +0300

Lorenzo - I am trying to understant you to improve text.

Le 15/04/2015 14:41, Lorenzo Colitti a écrit :
> On Wed, Apr 15, 2015 at 8:33 PM, Alexandru Petrescu
>     A prefixlen for that address is required in order to behave and
>     determine neighbordhood relationships ("on-link determination RFC4861")
>
>
> No. What is required to determine which nodes are directly reachable
> on link-via neighbour discovery is not the prefix length of the
> address. What is required is *an on-link prefix*.
>
> The prefix is not required to be associated with the address, though
>  some implementations may couple the two together.

Do you think a prefix that is not associated with the address will help
on-link determination?

> communication happens directly, via ND.

Dont you think it is not necessary that a plen (be it 128) be associated 
with that address
(not the plen of the onlink prefix) in order to realize that (mis)match 
operation?  Or you think that plen (128) is not necessary?

> If it does not, communication
> must happen through a router.
>
>     and optimizations such as reducing search times and routing table
>     sizes.  An implicit prefixlen is valued at 128 on some node user
>     interface, and 64 on another node user interface.  An explicit
>     prefixlen may be specified by RA.
>
>

Ok.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 15:40:47 +0300

> No.   All you need is a default route.   Prefix length is optional.

Ok, that's an exception that should be mentioned.

(but even with the default route there is an address and an associated
  plen - ::/0 - the '::' and the '/0' _are_ specified in RFC and are not
  assumed differently by different implementations, like they were in
  the past when the default route was 2000::/3 by some implementations.)

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Apr 2015 08:45:02 -0400

> Ok, that's an exception that should be mentioned.

No, it's not an exception.   It's the point: prefix and IP address are orthogonal.   Unrelated.   There is no connection between the two.   Maybe you have prefixes, maybe you don't.   Maybe you have an IP address in those prefixes, maybe you don't.   This whole conversation is based on the idea that there is some definite connection between an IP address and an on-link prefix, and that is simply not the case.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 15:47:56 +0300

Le 15/04/2015 15:45, Ted Lemon a écrit :
> No, it's not an exception.   It's the point: prefix and IP address
> are orthogonal.   Unrelated.   There is no connection between the
> two.   Maybe you have prefixes, maybe you don't.   Maybe you have an
> IP address in those prefixes, maybe you don't.   This whole
> conversation is based on the idea that there is some definite
> connection between an IP address and an on-link prefix, and that is
> simply not the case.

Ted - is the plen of the default route specified?

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2015 12:55:47 +0000

It is the default (last resort) ... So it would be /0 to match anything. Longest match is usually used - hence it is the lowest priority route. This is networking 101.

- Bernie (from iPad)

> On Apr 15, 2015, at 8:48 AM, Alexandru Petrescu <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 22:29:23 +0900

On Wed, Apr 15, 2015 at 9:04 PM, Alexandru Petrescu <
[email-masked]> wrote:

>  you think a prefix that is not associated with the address will help
>>
> on-link determination?

On-link determination is independent from the IP addresses on the system.
Whether an address is on-link or not is a function of the destination
prefix the address is in, regardless of what IP addresses you have.
Example: you can have prefix 2001:db8::/64 be on-link on a particular
interface, but you might only have a link-local address on that interface.

> operation?  Or you think that plen (128) is not necessary?

No, whether a specific address is on-link or not does not depend on what IP
addresses you have.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Apr 2015 09:30:25 -0400

> Ted - is the plen of the default route specified?

Are you kidding?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 16:34:23 +0300

>> Ted - is the plen of the default route specified?

No, sorry, and not trolling.

The plen associated with the address of the next-hop gw in the rt table 
_is_ specified: it is /0.  Before being specified various
implementations of linux and bsd were doing various things with 
2000::/3.  There are reasons for /3 instead of /0, at least because all 
addresses currently specified by the IPv6 Addressing Architecture RFC 
says that all addresses start with binary 001.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 22:37:03 +0900

> _is_ specified: it is /0.  Before being specified various

That's irrelevant. The default route is not on link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 16:42:06 +0300

Le 15/04/2015 16:37, Lorenzo Colitti a écrit :
> On Wed, Apr 15, 2015 at 10:34 PM, Alexandru Petrescu
>     The plen associated with the address of the next-hop gw in the rt
>     table _is_ specified: it is /0.  Before being specified various
>
>

Right, the prefix of the default route is not on link.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 16:53:25 +0300

Le 15/04/2015 16:34, Alexandru Petrescu a écrit :
> table _is_ specified: it is /0.

(I meant the plen of the prefix, not of the address of the next-hop).

Alex

   Before being specified various
> 2000::/3.  There are reasons for /3 instead of /0, at least because
> all addresses currently specified by the IPv6 Addressing Architecture
> RFC says that all addresses start with binary 001.
>
> Alex
>
>>
>>
>>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2015 14:08:03 +0000

Hi:

Please remove [email-masked] if you want to continue this discussion
privately. But it is time to stop this useless debate on the dhcwg mailing
list.

If there is further discussion on this topic that includes the dhcwg, I
will moderate future posts from the senders for a period (and block any on
this topic).

Thank you for your attention to this matter.

- Bernie

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 23:10:14 +0900

> privately. But it is time to stop this useless debate on the dhcwg mailing

Acknowledged.

Bernie, do you know what happened to the suggested text that was posted
reams of messages back? Do we need to salvage it and move it to another
thread?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2015 14:15:05 +0000

See http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68.

- Bernie

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 15, 2015 at 10:10 AM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: Alexandru Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] Microphone comment about DHCPv6 address prefix length

On Wed, Apr 15, 2015 at 11:08 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Please remove [email-masked]<mailto:[email-masked]> if you want to continue this discussion
privately. But it is time to stop this useless debate on the dhcwg mailing
list.

Acknowledged.

Bernie, do you know what happened to the suggested text that was posted reams of messages back? Do we need to salvage it and move it to another thread?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Apr 2015 17:16:33 +0300

I agree this is not a 3315bis issue.

Alex

Le 15/04/2015 17:15, Bernie Volz (volz) a écrit :
> From: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> To: Bernie Volz <[email-masked] <mailto:[email-masked]>>
> Cc: Alexandru Petrescu <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Please remove [email-masked] <mailto:[email-masked]> if you want to
>     continue this discussion