Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Dec 2013 11:38:03 -0600

Hi Andrew,

Thanks for writing this draft. It is interesting and useful.

I have a few comments:

1. There is another draft,
https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem
what is the relation between these two drafts?
2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G
links, the standard requires SLAAC.
3. The document is missing a discussion on another aspect of this issue,
i.e. RA options, such as in RFC 4191 and the corresponding DHCP option in
http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05.
Adding this to your draft is recommended.
4. Lastly, your .txt document prints two pages for each page you have, I
think there is some formatting issue.

Regards,

Behcet

On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko <[email-masked]>wrote:

> Hello all,
>
> Finally I managed to comb a little bit and finally submit the doc that
> aims to compare RAs with DHCPv6 which emerged from the discussion on this
> list a few weeks ago.
>
> I'll be very happy to hear any comments, suggestions, flames, etc.
>
> --a
>
>
> p.s. The "realtime changes" repository is at: https://github.com/ayourtch/
> ra-dhcpv6, in case you want to send the feedback via a pull request :)
>
> ---------- Forwarded message ----------
> Date: Wed, 27 Nov 2013 04:52:14 -0800
> From: [email-masked]
> To: Andrew Yourtchenko <[email-masked]>
> Subject: New Version Notification for
>     draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>
>
> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt
> has been successfully submitted by Andrew Yourtchenko and posted to the
> IETF repository.
>
> Filename:        draft-yourtchenko-ra-dhcpv6-comparison
> Revision:        00
> Title:           A comparison between the DHCPv6 and RA based host
> configuration
> Creation date:   2013-11-27
> Group:           Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-
> dhcpv6-comparison-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-yourtchenko-ra-
> dhcpv6-comparison
> Htmlized:        http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-
> comparison-00
>
>
> Abstract:
>    This document attempts to make a balanced comparison between the RA-
>    based and DHCPv6-based host configuration mechanisms.  It compares
>    the two on different aspects, e.g: underlying media assumptions,
>    coordination, locality, etc.  and highlights the strong and weak
>    sides of both protocols for each scenario.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 4 Dec 2013 01:36:13 +0000

Hi, Behcet

1. There is another draft, https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem
what is the relation between these two drafts?
[Bing] As a co-author of the above mentioned draft, I think the scope of the two drafts is different.
Draft-ietf-v6ops-dhcpv6-slaac-problem focuses on address configuration, while Andrew's draft makes a more general comparison between ND and DHCPv6.
As we know, there always be argument of things should be done through RA Options or DHCPv6 options, so I think this draft is aiming to provide some guidance on this general issue.

(Andrew, please correct me if I misunderstand your draft.)

Regards,
Bing

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 4 Dec 2013 10:45:47 +0100 (CET)

Hi Behcet,

> what is the relation between these two drafts?

IIRC The draft I wrote came out of the discussion of the above draft (in 
fact I accidentally hijacked the thread there :) - 
there were the usual two strong opinions "this needs to be there" and "this does 
not need to be there", so I decided to try to write up a balanced 
overall comparison - especially that this type of question comes up a lot 
in many contexts outside the IETF.

> 2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G links, the standard requires SLAAC.

Great catch! I added the new section to the "running head" version of the 
doc on the github. Thank you!

> 3. The document is missing a discussion on another aspect of this issue, i.e. RA options, such as in RFC 4191 and the corresponding DHCP option in

Could you suggest a one-paragraph wording for such a discussion ? Your 
comment triggered another idea in my head re options, but I would like to 
hear you first so I do not skew what you wanted to say - maybe they are 
different ideas.

> 4. Lastly, your .txt document prints two pages for each page you have, I think there is some formatting issue.

Indeed. Thanks! Weird, I just used the xml2rfc with the default settings, 
and the boilerplate came from template generator... Maybe I need to 
update it. I've created an issue onto the github repo for it, will take 
care of it.

--a

> 
> Regards,
> 
> Behcet
> 
> 
> On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko <[email-masked]> wrote:
>       Hello all,
>
>       Finally I managed to comb a little bit and finally submit the doc that aims to compare RAs with DHCPv6 which emerged from the discussion on this list a few weeks ago.
>
>       p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ra-dhcpv6, in case you want to send the feedback via a pull request :)
>
>       Title:           A comparison between the DHCPv6 and RA based host configuration
>       URL:             http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>       Status:          http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison
>       Htmlized:        http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00
> 
>
>       Abstract:
>       Please note that it may take a couple of minutes from the time of submission

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 4 Dec 2013 10:52:36 +0100 (CET)

Hi Bing,

On Wed, 4 Dec 2013, Liubing (Leo) wrote:

> Draft-ietf-v6ops-dhcpv6-slaac-problem focuses on address configuration, while Andrew’s draft makes a more general comparison between ND and DHCPv6.
> 

I think yours is maybe an even laconic description than I've just sent in 
the other mail. Thank you!

I've marked this down as an 
"issue" on github https://github.com/ayourtch/ra-dhcpv6/issues/3 , 
it's maybe a good thing to discuss the relationship between the two.

--a

---

From: 神明達哉 <[email-masked]>
Date: Wed, 4 Dec 2013 09:58:29 -0800

At Wed, 27 Nov 2013 14:06:03 +0100 (CET),

> I'll be very happy to hear any comments, suggestions, flames, etc.

A minor point: this paragraph of Section 2.9 would need some editorial
cleanup:

   On the other hand, it could be argued down to a choice of API:
   writing programs handling RA options like RDNSS is no harder than
   writing DHCPv6 client in terms of socket API.  As long as the system
   supports RFC3542 you should be able to write a portable RA "client"
   pretty easily (meaning as easy/hard as writing some UDP client
   program).  For example, FreeBSD's rtsold supports RDNSS and (AFAIK)
   only relies on the RFC3542 APIs.  Also, since DHCP is trickier than
   other UDP applications in some points (it's more sensitive to which
   interface to use, and in some cases you need to make sure the source
   address is link-local, etc), it's quite likely that you'll need
   something like unusual APIs like RFC3542 or some non-portable system
   dependent interface to write a standard-compliant DHCP(v6) client.
   So, overall, I'd say the programming difficulty regarding UDP (DHCP)
   vs ICMP (RS/RA) is marginal.

In that it contains some too-informal phrases like "AFAIK" or "I'd
say".  It looks like a mostly verbatim copy of some email message:-)

--
JINMEI, Tatuya

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Dec 2013 14:50:21 -0600

Hi Andrew,

Please see inline.

Regards,

Behcet

On Wed, Dec 4, 2013 at 3:45 AM, Andrew Yourtchenko <[email-masked]>wrote:

>> 1. There is another draft, https://datatracker.ietf.org/
>> doc/draft-ietf-v6ops-dhcpv6-slaac-problem
> fact I accidentally hijacked the thread there :) - there were the usual two
> strong opinions "this needs to be there" and "this does not need to be
> there", so I decided to try to write up a balanced overall comparison -
> especially that this type of question comes up a lot in many contexts
> outside the IETF.
>
>
Sure.
Here is my text (two paragraphs instead of one :-)) Please feel free to add
more, I believe other people, e.g. Brian Carpenter can also help.

The issue is delivering routes to the hosts. RFC 4191 defines Router
Advertisement extensions for communicating default router preferences and
more-
   specific routes from routers to hosts. The draft on IPv6 RA Options for
Next Hop Routes, draft-sarikaya-6man-rfc4191bis-00 proposes some new  Router
   Advertisement options for configuring next hop routes on the mobile
   or fixed nodes.

DHCP can also be used for delivering routes, as in
draft-ietf-mif-dhcpv6-route-option-05. DHCPv6 Route Options can be defined
basically to mimic the RA options defined in RFC 4191 as well as with some
extensions such as the next hop address. DHCP approach claims the advantage
of being applicable to configuring the routers, e.g. residential
   gateways (RG) or Customer Premises Equipment (CPE) as well as the hosts.

> and the boilerplate came from template generator... Maybe I need to update
> it. I've created an issue onto the github repo for it, will take care of it.
>
> --a
>
>
>
>> Regards,
>>
>> Behcet
>>
>>
>>       Finally I managed to comb a little bit and finally submit the doc
>> that aims to compare RAs with DHCPv6 which emerged from the discussion on
>> this list a few weeks ago.
>>
>>       p.s. The "realtime changes" repository is at:
>> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the
>> feedback via a pull request :)
>>
>>       URL:             http://www.ietf.org/internet-
>> drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>>       Status:          http://datatracker.ietf.org/
>> doc/draft-yourtchenko-ra-dhcpv6-comparison
>>       Htmlized:        http://tools.ietf.org/html/
>> draft-yourtchenko-ra-dhcpv6-comparison-00
>>
>>
>>       Abstract:

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 5 Dec 2013 11:33:16 +0100 (CET)

> say".  It looks like a mostly verbatim copy of some email message:-)

You are absolutely correct - it's a mostly verbatim copy-paste that needs 
to be rephrased. I think I grabbed it from your conversation with Lorenzo 
:-) I've captured this into https://github.com/ayourtch/ra-dhcpv6/issues/4

Thanks a lot! :)

--a

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Dec 2013 14:14:54 +0100

Thanks for the draft.  IMHO it goes in a good direction to compare what
can be done with DHCPv6 vs RA.

I have some comments.

> DHCPv6 needs at least 2 packets.  RA is just one packet.

This varies.  It is mainly yes.

But, an initial exchange is at minimum 4 DHCPv6 messages (including a
costly discovery), whereas a DAD-less operation would be a single RA
message (forgetting the initial MLD 'join').

> There is one additional reason for the DHCPv6 to be slower.

One of the reasons DHCPv4/v6 may be slower lies in the discovery phase.
  Every discovery phase takes some time.  Old DHCPv4 implementations take
too much time, as do old WiFi 'scanning' operations (another discovery).

Better implementations of the discovery phases take shorter time, yet
they are extremely lengthy compared to what agreed numbers and multicast
join/leave operations can achieve.

> An RA-based protocol interaction may influence host's routing.  A
> DHCPv6-based interaction today can not influence the host's routing
> - it was specifically denied any and all involvement into routing.
[...]
> FIXME: This section needs further debates, clarifications, and a
> rewrite.  Discussion welcome.

There is an ongoing discussion in the DHC WG about this.  Namely about
routing at DHCP Relay during Prefix Delegation.  Implementations
consider seriously 'snooping' and adding routing table entries at Relay
during DHCP operations.  Standards e.g. BBF require a solution to this
problem.

There were several drafts and presentations during recent 2-3 years.
Most recent draft is at
draft-petrescu-relay-route-pd-problem-00.txt

> Regarding RA for routing and DHCP for addressing, what people care
> about is connectivity.  What I need as an operator is a protocol
> (preferably a single protocol because that is simpler) which will
> enable my boxes to gain the connectivity they need.  Whether you
> call this routing or providing a default gateway, I don't much mind.
> Look, there's too much ideology going on here.  The IETF is being
> dazzled by the sight of multiple lan segments and multiple egress
> gateways without realising that these are the minority
> configuration. All this effort is going into optimising ipv6 address
> / lan autoconfiguration for these unusual scenarios without heeding
> the sober reality that most people, service providers and enterprises
> are only ever going to want to have a single defgw per lan segment,
> and that by far the most common deployment scenario will be a single
> lan segment per organisation.
>
> Wireless?  My smartphone already has two radios and a physical
> interface, connected to multiple providers.  How exactly do you then
> configure a "single defgw per lan segment" (without draft-troan-
> homenet-sadr-01)
>
> I'm aware that this viewpoint will be regarded as retrograde, and
> that a bunch of people on this list will probably sit there, rolling
> their eyes and thinking: "yeah, and 640k was enough for everyone".
> Just bear in mind that added complexity is not necessarily a good
> thing.  The support costs are high and the return on effort is
> dubious at best.  IOW, the IETF is optimising a corner case.

This and later paragraphs read as a story I can understand but it would
need reformulation to become less personal.

Then...

In the past we strived to build a table comparing the parameters which
RA configures vs. the parameters which DHCP configures.  The value was
in finding which parameters are the exclusive domain of one or the other
in current RFCs.

For example, Prefix Delegation is only specified for DHCPv6 (not for
RA), whereas the MTU parameter, and default router parameters (IP
address, MAC address) are only for the RA (not for DHCP).

Alex

Le 27/11/2013 14:06, Andrew Yourtchenko a écrit :
> that aims to compare RAs with DHCPv6 which emerged from the
> discussion on this list a few weeks ago.
>
> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013
> 04:52:14 -0800 From: [email-masked] To: Andrew Yourtchenko
> <[email-masked]> Subject: New Version Notification for
> has been successfully submitted by Andrew Yourtchenko and posted to
> the IETF repository.
>
> Filename:     draft-yourtchenko-ra-dhcpv6-comparison Revision:
> 00 Title:         A comparison between the DHCPv6 and RA based host
> configuration Creation date:     2013-11-27 Group:         Individual
> Submission Number of pages: 12 URL:
> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>
>
> Status:
> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison
>
>
Htmlized:
> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00
>
>
> Abstract: This document attempts to make a balanced comparison
> between the RA- based and DHCPv6-based host configuration mechanisms.
> It compares the two on different aspects, e.g: underlying media
> assumptions, coordination, locality, etc.  and highlights the strong
> and weak sides of both protocols for each scenario.
>
>
>
>
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat _______________________________________________
> v6ops mailing list [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 5 Dec 2013 13:34:53 +0000

This is an issue to clarify in this document (it may already be clear, but that was one area I need to confirm in a reread) - it old compares address assignment mechanisms, not prefix delegation. There's no alternative for prefix delegation, so nothing to compare with. The routing issues for PD are a bit different than for addresses.

- Bernie (from iPad)

> On Dec 5, 2013, at 8:15 AM, "Alexandru Petrescu" <[email-masked]> wrote:
>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 5 Dec 2013 15:40:01 +0100 (CET)

Thanks a lot for the comments!

inline...

On Thu, 5 Dec 2013, Alexandru Petrescu wrote:

> costly discovery),

What about Rapid Commit ? I was under impression there you can do the 
address assignment with just two messages.

By "Costly" I assume you mean the "takes a long time because of the 
long inbuilt timeouts", as in the paragraph further below, I comment 
there.

> whereas a DAD-less operation would be a single RA

No, it would be an RS-RA sequence - *unless* either RA interval is every 
few seconds or the host is lucky enough to be connected just before the 
periodic RA is sent.

(I

> too much time, as do old WiFi 'scanning' operations (another discovery).

I found this snippet in RFC3315 interesting:

"A client MUST collect Advertise messages for the first RT seconds,
    unless it receives an Advertise message with a preference value of
    255.  The preference value is carried in the Preference option
    (section 22.8).  Any Advertise that does not include a Preference
    option is considered to have a preference value of 0.  If the client
    receives an Advertise message that includes a Preference option with
    a preference value of 255, the client immediately begins a client-
    initiated message exchange (as described in section 18) by sending a
    Request message to the server from which the Advertise message was
    received.  If the client receives an Advertise message that does not
    include a Preference option with a preference value of 255, the
    client continues to wait until the first RT elapses.  If the first RT
    elapses and the client has received an Advertise message, the client
    SHOULD continue with a client-initiated message exchange by sending a
    Request message.
"

This means that in the case of a single-server, the discovery phase can be 
shortened by having the Preference of 255 - thus to be able to reduce the 
discovery process ? (I need to test if the hosts actually do this IRL, I 
suspect they do not).

> join/leave operations can achieve.

... "in the case of 0% packet loss".

Add any packet loss and a single-packet scheme of RA becomes 
fragile and the worst case is dramatically worse than that of the DHCP.

> draft-petrescu-relay-route-pd-problem-00.txt

Yes, the Prefix Delegation is a completely special beast! I reread the 
RFC3633 - it does not even talk about DHCP servers - it talks about 
routers quite explicitly!

I will try to reflect this somehow, created the 
https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks!

> need reformulation to become less personal.

Yes, it is almost un-edited copy-paste from the emails, with ultra-light 
editing for the first pass.

> address, MAC address) are only for the RA (not for DHCP).

Do you have somewhere this work ? I would be happy to incorporate it. 
Else, maybe it's worth to start rebuilding it in the appendix.

I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6.

--a

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Dec 2013 16:06:04 +0100

Alexandru,

> address, MAC address) are only for the RA (not for DHCP).

that's because prefix delegation is a stateful operation that requires per requesting router / client binding state.
the general principle is "DHCPv6 can give different information to different clients, RA give the same information to everyone."

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Dec 2013 16:13:37 +0100

> address assignment with just two messages.

I guess so yes.  I doubt though it is the most used mode.  Of course, 
one would just say Rapid Commit in this draft and it would be sufficient 
at this level.

> By "Costly" I assume you mean the "takes a long time because of the long
> inbuilt timeouts", as in the paragraph further below, I comment there.

Yes.

The longer the timeouts the higher the chances to discover something. 
The shorter the timeouts the higher the chances to miss some important 
server.

> few seconds or the host is lucky enough to be connected just before the

Yes, but there is an additional thing.

The multicast RA works only if the Host has first subscribed to that 
group.  And that needs an additional initial message from the Host to 
everybody else (the MLD 'join').

Basically, if the Host does not send that MLD message it will not 
receive the periodic multicast RA either.

> This means that in the case of a single-server, the discovery phase can
> be shortened by having the Preference of 255 - thus to be able to reduce
> the discovery process ? (I need to test if the hosts actually do this
> IRL, I suspect they do not).

I guess yes, the paragraph above reflects a good way for DHCP behaviour 
to approach that ideal of a single exchange.

> Add any packet loss and a single-packet scheme of RA becomes fragile and
> the worst case is dramatically worse than that of the DHCP.

I agree.

> routers quite explicitly!

I think the PD RFC defines a Delegating Router to be a DHCP Server, and 
then only talks DR.

> Else, maybe it's worth to start rebuilding it in the appendix.

There is this paragraph only in draft-mouton-mif-dhcpv6-drlo-02
>    In addition to the default router address, lifetime and link-layer
>    address, the neighbor discovery mechanism also provides MTU, hop
>    limit, reachable time, retransmission timer[...]

But I would very well see a table like this:

                      |       Configured by       |
                      +-------------+-------------+
   Parameter on Host  |    DHCP     |      RA     |
   -------------------+-------------+-------------+
   Default Router IP  |             |      X      |
   -------------------+-------------+-------------+
   Default Router MAC |             |      X      |
   -------------------+-------------+-------------+
   Global Address     |     X       | X (w/ other)|
   -------------------+-------------+-------------+
   Delegated Prefix   |     X       |             |
   -------------------+-------------+-------------+
   Link MTU           |             |      X      |
   -------------------+-------------+-------------+
   Hop Limit          |             |      X      |
   -------------------+-------------+-------------+
   Link's reachable   |             |      X      |
   time, retr timer   |             |             |
   -------------------+-------------+-------------+
   DNS Resolver       |     X       |      X      |
   -------------------+-------------+-------------+

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Dec 2013 16:19:17 +0100

Le 05/12/2013 16:06, Ole Troan a écrit :
> Alexandru,
>
>> For example, Prefix Delegation is only specified for DHCPv6 (not
>> for RA), whereas the MTU parameter, and default router parameters
>> (IP address, MAC address) are only for the RA (not for DHCP).
>
> that's because prefix delegation is a stateful operation that
> requires per requesting router / client binding state. the general
> principle is "DHCPv6 can give different information to different
> clients, RA give the same information to everyone."

YEs, I agree.

Alex

(and, as with all preceding points it is also a yes/no matter.

The address assignment (not only Prefix Delegation) DHCP is also a
stateful matter needing binding state about the requester.

Yes, the RA also (not only DHCP) can give different information to
different clients, as may be used in Proxy Mobile IPv6 (the MAG gives a 
different prefix to each Host and the MAG emitting the RA keeps state 
about that assignment).)
> cheers, Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Dec 2013 16:04:46 +0000

Hi,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, December 05, 2013 7:19 AM
> To: Ole Troan
> Cc: V6 Ops List
> Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 

This is true for multicast RAs, but unicast RAs can give different
information to different clients.

Thanks - Fred
[email-masked]

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 5 Dec 2013 17:24:10 +0100 (CET)

On Thu, 5 Dec 2013, Alexandru Petrescu wrote:

> I guess so yes.  I doubt though it is the most used mode.  Of course, one 
> would just say Rapid Commit in this draft and it would be sufficient at this 
> level.

Yeah - thanks, since it was a tiny change I made the edit to XML directly: 
https://github.com/ayourtch/ra-dhcpv6/commit/e5c01b6135f0c08c988189718fad24778843e4a6#diff-d6f2c9835b8f2c82e0ca00aad009d0cb

> The longer the timeouts the higher the chances to discover something. The 
> shorter the timeouts the higher the chances to miss some important server.
>

If anyone who reads this sentence has seen more than 3 answers on a
DHCP client with standard deviation of RTT of more than 1 second, please 
tell me more about the circumstances you saw it in.

(The reason for asking it in this way I think in the DHCP case it would be 
more a pathology than a feature, contrary to e.g. mDNS case discovery 
where while you are waiting maybe a new service has arrived on the network 
- but, I would like to understand better what I missed in my assessment).

(NB: not including the "pathologically reliable" link-layer scenario, 
which tries to achieve 0% packet loss by retransmitting over a course of 
a minute, I put a separate issue for it).

> The multicast RA works only if the Host has first subscribed to that group. 
> And that needs an additional initial message from the Host to everybody else 
> (the MLD 'join').
>
> Basically, if the Host does not send that MLD message it will not receive the 
> periodic multicast RA either.

Given the destination of periodic RAs is the all-nodes multicast, this 
statement would be in conflict with:

http://tools.ietf.org/html/rfc3810:

The link-scope all-nodes multicast address, (FF02::1), is handled as
    a special case.  On all nodes -- that is all hosts and routers,
    including multicast routers -- listening to packets destined to the
    all-nodes multicast address, from all sources, is permanently enabled
    on all interfaces on which multicast listening is supported.  No MLD
    messages are ever sent regarding neither the link-scope all-nodes
    multicast address, nor any multicast address of scope 0 (reserved) or
    1 (node-local).

http://www.ietf.org/rfc/rfc4541.txt:

    In IPv6, the data forwarding rules are more straight forward because
    MLD is mandated for addresses with scope 2 (link-scope) or greater.
    The only exception is the address FF02::1 which is the all hosts
    link-scope address for which MLD messages are never sent.  Packets
    with the all hosts link-scope address should be forwarded on all
    ports.

So, I think an all-routers destined RS + all-host destined RA is the 
"timely minimum", whereas the single periodic RA is  the "absolute 
minimum", and the DHCPv6 case the 2 packet exchange is both.

> I guess yes, the paragraph above reflects a good way for DHCP behaviour to 
> approach that ideal of a single exchange.
>

ok. I think I already added that text, but I wanted to test if this 
"really" works and is practically configurable on at least one 
implementation - then it could become a reasonable BCP for a network that 
wants to have the best user experience.

> I think the PD RFC defines a Delegating Router to be a DHCP Server, and then 
> only talks DR.

Ah, ok I missed that. So, indeed there *are* cases that "router==dhcp server".

>> https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks!

[snip]

> There is this paragraph only in draft-mouton-mif-dhcpv6-drlo-02

Thanks!

> But I would very well see a table like this:

Makes sense. I've added this into the "issue" and will XMLify / 
add reference later.

Thanks a lot!

--a

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Dec 2013 11:53:13 -0600

On Thu, Dec 5, 2013 at 9:06 AM, Ole Troan <[email-masked]> wrote:

> that's because prefix delegation is a stateful operation that requires per
> requesting router / client binding state.
> the general principle is "DHCPv6 can give different information to
> different clients, RA give the same information to everyone."
>
>
Unless RA is sent on a point-to-point link.

Behcet

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 5 Dec 2013 11:50:00 -0800 (PST)

----- Original Message -----

> From: Alexandru Petrescu <[email-masked]>
> To: Ole Troan <[email-masked]>
> Cc: V6 Ops List <[email-masked]>
> Sent: Friday, 6 December 2013 2:19 AM

RAs can be used to distribute client specific parameters, for the parameters that RAs carry, as has been implemented in the widely deployed radvd open source RA daemon (see the 'clients' option).

A mechanism to distribute these client specific RA parameters to routers isn't commonly available, however RADIUS could be used for that purpose, similar to how RADIUS is being used to distribute parameters to a router located DHCPv6 server.

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Dec 2013 20:52:30 +0100

[...]

> A mechanism to distribute these client specific RA parameters to routers isn't commonly available, however RADIUS could be used for that purpose, similar to how RADIUS is being used to distribute p…

yes, I was talking about the general operation of the protocol.

cheers,
Ole

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 5 Dec 2013 12:19:46 -0800 (PST)

Hi,

Some criticisms/comments/questions on these pieces of text relating to layer 2/wifi multicast reliablity:

"This is where the peer-to-peer, acknowledged nature of DHCPv6 may be
beneficial - on a crowded large-scale WiFi, without special tricks to ensure the reliable delivery of multicast packets, you simply will not get the SLAAC working because the multicast RAs will get crunched by the interference."
I'd think that if multicast is unreliable enough to cause RAs to fail to be delivered often enough, then anything which relies on multicast traffic is also likely to fail, which would include neighbor discovery. So regardless of if RAs were replaced with DHCPv6, the link is not going to provide reliable IPv6 operation, because IPv6 addresses cannot be reliably resolved to layer 2 addresses. 
MLD would probably fail too, so any routed multicast applications, even low bandwidth ones, wouldn't work either, as would MLD snooping based layer 2 forwarding optimisation.
DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that will probably be unreliable as well.

I don't think broadcasts on wifi are reliable, so IPv4 ARP would be failing too.

So if RAs are failing because of not reliable enough multicast then that is just one symptom of the link being overloaded, and there will be others.
One idea I've had for this sort of scenario would be for the link to operate as mostly an IPv6 over NBMA segment. The only multicasts on the link are RAs, providing the necessary NBMA operation parameters. It of course would require changes to clients and routers, but then again, so would using DHCPv6 for what RAs are used for today.

"Alternatively, in a very mobile environment and the RFC-compliant

router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in modulation, etc.  may eat way more bandwidth than if they were sent unicast."

The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a link can't handle 1 multicast every few seconds, it's also past the point of it's capacity (and as above, other multicast/broadcast would also be contributing to exceeding link capacity.)

Regards,
Mark.

----- Original Message -----
> From: Andrew Yourtchenko <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Thursday, 28 November 2013 12:06 AM
> Subject: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> Hello all,
> 
<snip>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Dec 2013 16:57:55 +0100

Le 05/12/2013 17:24, Andrew Yourtchenko a écrit :
[...]
>     multicast address, nor any multicast address of scope 0 (reserved) or

Hmmm... I may need to try this, because I doubt it.  Turn the machine 
on, while listening with another machine the packets emitted by the 
first.  If there is an MLD message before any other RS then the RFC 
deserves a comment.

>     with the all hosts link-scope address should be forwarded on all

This RFC deserves a comment: that is the all nodes address (not all hosts).

> minimum", and the DHCPv6 case the 2 packet exchange is both.

Hmm, it seems so... but I'd first check the above.

Anyways, your draft is right.

Alex

>> I guess yes, the paragraph above reflects a good way for DHCP
>> behaviour to approach that ideal of a single exchange.
>>
>
> implementation - then it could become a reasonable BCP for a network
> that wants to have the best user experience.
>
>> I think the PD RFC defines a Delegating Router to be a DHCP Server,
>> and then only talks DR.
>
> Makes sense. I've added this into the "issue" and will XMLify / add
> reference later.
>
> Thanks a lot!
>
> --a
>
>
>> Alex
>>
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Dec 2013 16:58:55 +0100

Le 05/12/2013 18:53, Behcet Sarikaya a écrit :
>
>
>
> On Thu, Dec 5, 2013 at 9:06 AM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Alexandru,
>
>     requires per requesting router / client binding state.

Yes, and depends what we call a point-to-point link.

Because there are point to point links which act so much as pure 
Ethernet (like CDC-Ethernet in 4G)...

Alex

>     [email-masked] <mailto:[email-masked]>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 6 Dec 2013 17:34:33 +0100 (CET)

Hi Mark,

On Thu, 5 Dec 2013, Mark ZZZ Smith wrote:

> beneficial - on a crowded large-scale WiFi, without special tricks to 
>ensure the reliable delivery of multicast packets, you simply will not 
>get the SLAAC working because the multicast RAs will get crunched by the 
>interference."
> I'd think that if multicast is unreliable enough to cause RAs to fail 
>to be delivered often enough, then anything which relies on multicast 
>traffic is also likely to fail, which would include neighbor discovery. 
>So regardless of if RAs were replaced with DHCPv6, the link is not going 
>to provide reliable IPv6 operation, because IPv6 addresses cannot be 
>reliably resolved to layer 2 addresses.
>
> MLD would probably fail too, so any routed multicast applications, even 
>low bandwidth ones, wouldn't work either, as would MLD snooping based 
>layer 2 forwarding optimisation.
>
> So if RAs are failing because of not reliable enough multicast then 
>that is just one symptom of the link being overloaded, and there will be 
>others.

I think I capture several points here, tell me if I get them correctly:

1) There are other protocols that use multicast that will fail.
2) Fix your link.

for (1): RA is probably the only one that does not incorporate a robust 
retransmit mechanism.

for (2): It's great if you can, but I'd like to have protocol work in all 
conditions. Especially that legacy IP does look more robust.

> One idea I've had for this sort of scenario would be for the link to 
>operate as mostly an IPv6 over NBMA segment. The only multicasts on the 
>link are RAs, providing the necessary NBMA operation parameters. It of 
>course would require changes to clients and routers, but then again, so 
>would using DHCPv6 for what RAs are used for today.

You can do this with no changes today.

Block traffic between the hosts (similar to private vlan), advertise 
prefixes as off-link, send all the traffic via the router on the wired 
side, block all the inbound ND from hosts except for the RS and 
NS sent to solicited node address of the router + destined to the router.

I tested this, it works like a charm - at least for the strawman browsing 
scenario.

> router, multicast solicited RAs might make a significant portion of 
> your traffic - which, due to a difference in modulation, etc.  may eat 
> way more bandwidth than if they were sent unicast."
>
> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a link 
>can't handle 1 multicast every few seconds, it's also past the point of 
>it's capacity (and as above, other multicast/broadcast would also be 
>contributing to exceeding link capacity.)

Modulation. Your multicast packets may take in the most extreme case 54x 
time more airtime than a unicast. This means 54x more probability it will 
be dropped. Also, forget the home wireless with one AP. Now imagine 
300-500 APs having to send these packets. You have 3 frequencies on 2.4Ghz 
spectrum that you can use. So remembering that the whole construct is 3D, 
you are *bound* to have some interference.

So, it can be quite delicate in the most extreme cases.

And again, I want the protocol to be deployable in the most extreme cases 
- especially when legacy IP survives them fine.

Yes, not everyone will have them.

But dismissing those cases just because they do not apply to one's
environment is incorrect.

And this is to me the whole point of the argument, which I would like to 
get back to, instead of trying to argue about the details:

Yes, RA-only operation is *fantastic* for some circumstances. I love it 
myself and do it whenever I can because this allows me to avoid doing 
boring work.

But I may be forced to do DHCPv6. For any of the reasons already present 
in the draft, pick one. And this means I am forced to do also RA, which 
is a pain.

I think the large part of the tussle comes from the people wanting to 
make the functionality of the RA/DHCPv6 more symmetric and being told 
"no".

And if we then tell them "Either use RA or no IPv6 for you" they say 
"fine, I choose no IPv6". And keep stacking on these NATs to support 
devices that "do not support IPv6" in that circumstances.

I think in this discussion are again getting into the argument of "the 
best solution" instead of trying to collect the properties of the RA and 
DHCP.

My position is that single best solution does not exist, because 
everyone's problems are slightly different. So, rather than preaching for 
everyone to adopt the single solution which is the best in one scenario 
and suboptimal in the other, we should be engineering a way to be able to 
apply different solutions in different circumstances without the 
overhead of double work.

--a

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 6 Dec 2013 17:01:22 -0800 (PST)

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Saturday, 7 December 2013 3:34 AM

Yes. 

> for (1): RA is probably the only one that does not incorporate a robust 

In the case of multicast RAs there are two independent reliability mechanisms used, one router side, one host side.

Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose knowledge of a router it has to miss 3 unsolicited multicast RAs in a row.

Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7).

I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as they only implement the second mechanism. For DHCPv6, neighbor discovery and MLD to be as robust as RAs, the DHCPv6 server and the hosts would have to also issue periodically unsolicited announcements of themselves so that other hosts and routers don't have to solicit for them, unless they have no existing knowledge of them.

(Should we add the ES-IS neighbor discovery model to IPv6 ND to make it more robust? ES-IS has hosts periodically multicast their presence to the link's routers, routers periodically multicast their presence to the hosts, hosts default to sending to their routers for all destinations, then routers sends a redirects to a host when the destination host is on the same link.).

> conditions.

That sound to me like an assertion that DHCPv6 is going to work in all conditions. Given that DHCPv6 server discovery is less reliable than RAs (because of the lack of unsolicited DHCPv6 server advertisements), how is moving RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs?

> Especially that legacy IP does look more robust.

So I'm curious why legacy IP is supposedly more robust? IPv4 uses broadcasts for ARP and DHCP server discovery. On these links where IPv4 "looks more robust" than IPv6, are broadcasts provided more reliable delivery than multicasts, in particular as broadcasts must be flooded to all hosts, where as multicasts can have their flooding scope limited using MLD snooping?

> I tested this, it works like a charm - at least for the strawman browsing 

Right, and doing that would solve the multicast capacity exhaustion problems that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), because it is a more extreme case of constraining where multicasts are sent than MLD snooping.

My Broadcast Multi-Access (BMA) link operating as NBMA suggestion wouldn't require both having available and enabling any link-layer special features to achieve the goal of significantly reducing multicast traffic. 

(Thinking about it, the recent Efficient ND proposal is perhaps a special case of operating a BMA link as an NBMA link for the Neighbor Discovery protocol. I'm starting to wonder if it might be better to just adopt this complete NBMA model over a BMA link and eliminate all link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the BMA link is operating in NBMA mode. The only multicasts would be unsolicited RAs, which, for a single router, could be only once every 30 minutes (15 minutes for two routers). I'd think that sort of interval would be adequate to address the concerns of multicasts consuming mobile device battery life.)

> you are *bound* to have some interference.

Are all of those 300-500 APs in a single broadcast/multicast domain i.e., one large link? That's convenient, but if multicasts/broadcasts aren't reliable enough, that suggests the link capacity is exhausted. Dividing the link up using routers to reduce multicast/broadcasts is and has been the common solution since broadcast multiaccess links were invented (which I think would be since around late 1970s when Ethernet was invented).

Moving to an NBMA model by effectively modelling the BMA link as a full mesh of virtual point-to-point links would probably be an alternative method of overcoming multicast/broadcast capacity limitations.

> - especially when legacy IP survives them fine.

How does it? Legacy IP uses broadcasts. 

> in the draft, pick one. And this means I am forced to do also RA, which 

So the objections I have are,

- I don't see how anything in DHCPv6 makes it dramatically more reliable than RAs, given that it too uses multicasts for DHCPv6 server discovery. Adding RA functions into DHCPv6 is described or asserted to be the panacea to all issues that RAs could suffer from, yet analysis shows it isn't.

- I think it would be better to incrementally tune and optimise the existing designed, standardised, code developed, code debugged and widely deployed mechanism (RAs) to overcome corner cases, and/or to adopt past developed methods such as IPv6 over NBMA, than to spend the next 5 to 10 years waiting for the design, standardisation, code development, code debugging and widespread deployment of RA functions to be incorporated into DHCPv6, and then also have to develop methods of conflict resolution when RAs and DHCPv6 options disagree (because they will, unless you don't plan to transition to DHCPv6 only until DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will have to co-exist on a link for many years if you can't demand or guarantee DHCPv6 RA functionality from the host implementations.)

- Using DHCPv6 for RA functionality won't eliminate one of the supposed causes of RA unreliability - multicast unreliability. All of DHCPv6, neighbor discovery and MLD would have to be made more robust against multicast unreliability to truly solve that problem.

- I'm for a single method that works adequately. DHCPv6 with RA options would probably qualify if we didn't already have a existing method. Existing methods that work are always better than non-existent ones that need to be developed, tested and ubiquitously deployed before they become significantly useful and can be assumed to be available.

> make the functionality of the RA/DHCPv6 more symmetric and being told 

The thing they need to demonstrate is that the costs of deploying a new and second mechanism that is near functionally equivalent to the first is worth the benefits. Given that the costs of developing and deploying RAs has already been paid, I think the benefits of using DHCPv6 for RA functions have to be very significant before the price should be paid. The benefits of DHCPv6 for RA functions now needs to be compelling. I don't think they are, otherwise I'd be quite happy to advocate for DHCPv6 for RA functions.

> devices that "do not support IPv6" in that circumstances.

I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will.

There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.

> apply different solutions in different circumstances without the 

A single solution that solves most cases is better than two different, near functionally equivalent solutions that solve the same cases. Multiple near-equivalent solutions create more code, more bugs and then require conflict resolution mechanisms, creating even more code and more bugs, with very little actual benefit.

There are multiple ways of solving the neighbor discovery/router discovery/host parameter configuration problem (read Radia Perlman's "Interconnections" book as a starting point, and then perhaps "Inside Appletalk", and also look into Novell's IPX and Network Directory Services.). They all have different trade-offs, but fundamentally the trade-offs aren't significantly different or compelling. Yet because there are multiple methods to solve these problems, does that justify implementing all of them because they each have some minor benefits over the others, that different people might prefer?

Regards,
Mark.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 7 Dec 2013 01:25:51 +0000

Mark:

The difference between DHCPv6 and RA multicast is the direction.

DHCPv6 multicast is client to server (or relay). This has far fewer problems in some networks because the first hop is typically on the wired portion of the network (and the destination multicast address is usually just joined by a few devices (relays and servers) - not all).

RA multicast is router to client(s). This has problems in distributing the traffic out to all of the clients over some networks.

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
Sent: Friday, December 06, 2013 8:01 PM
To: Andrew Yourtchenko (ayourtch)
Cc: [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

----- Original Message -----
> Subject: Re: [v6ops] New Version Notification for 
> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> Hi Mark,
> 
>>  Some criticisms/comments/questions on these pieces of text relating 
>>to
> layer 2/wifi multicast reliablity:
>> 
>>  beneficial - on a crowded large-scale WiFi, without special tricks 
>>to  ensure the reliable delivery of multicast packets, you simply will 
>>not  get the SLAAC working because the multicast RAs will get crunched 
>>by the  interference."
>>  I'd think that if multicast is unreliable enough to cause RAs to 
>>fail  to be delivered often enough, then anything which relies on 
>>multicast  traffic is also likely to fail, which would include neighbor discovery.
>> So regardless of if RAs were replaced with DHCPv6, the link is not 
>>going  to provide reliable IPv6 operation, because IPv6 addresses 
>>cannot be  reliably resolved to layer 2 addresses.
>> 
>>  MLD would probably fail too, so any routed multicast applications, 
>>even  low bandwidth ones, wouldn't work either, as would MLD snooping 
>>based  layer 2 forwarding optimisation.
>> 
>>  DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that 
>>will
> probably be unreliable as well.
>> 
>>that is just one symptom of the link being overloaded, and there will 
>>be  others.
> 

Yes. 

> 2) Fix your link.
> 
> for (1): RA is probably the only one that does not incorporate a 
> robust retransmit mechanism.
> 

> for (2): It's great if you can, but I'd like to have protocol work in 
> all conditions.

>>operate as mostly an IPv6 over NBMA segment. The only multicasts on 
>>the  link are RAs, providing the necessary NBMA operation parameters. 
>>It of  course would require changes to clients and routers, but then 
>>again, so  would using DHCPv6 for what RAs are used for today.
> 
> side, block all the inbound ND from hosts except for the RS and NS 
> sent to solicited node address of the router + destined to the router.
> 
> I tested this, it works like a charm - at least for the strawman 
> browsing scenario.
> 

>>  The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a 
>>link  can't handle 1 multicast every few seconds, it's also past the 
>>point
> of
> Modulation. Your multicast packets may take in the most extreme case 
> 54x time more airtime than a unicast. This means 54x more probability 
> it will be dropped. Also, forget the home wireless with one AP. Now 
> imagine
> 300-500 APs having to send these packets. You have 3 frequencies on 
> 2.4Ghz spectrum that you can use. So remembering that the whole 
> construct is 3D, you are *bound* to have some interference.
> 

> And this is to me the whole point of the argument, which I would like 
> to get back to, instead of trying to argue about the details:
> 
> Yes, RA-only operation is *fantastic* for some circumstances. I love 
> it myself and do it whenever I can because this allows me to avoid 
> doing boring work.
> 
> But I may be forced to do DHCPv6. For any of the reasons already 
> present in the draft, pick one. And this means I am forced to do also 
> RA, which is a pain.
> 

> best solution" instead of trying to collect the properties of the RA 
> and DHCP.
> 

> everyone's problems are slightly different. So, rather than preaching 
> for everyone to adopt the single solution which is the best in one 
> scenario and suboptimal in the other, we should be engineering a way 
> to be able to apply different solutions in different circumstances 
> without the overhead of double work.
> 

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 6 Dec 2013 18:07:15 -0800

> DHCPv6 multicast is client to server (or relay). This has far fewer problems in some networks because the first hop is typically on the wired portion of the network (and the destination multicast a…

You should study RA a little better.

> RA multicast is router to client(s). This has problems in distributing the traffic out to all of the clients over some networks.

Only some RA is done this way.

Clients starting up (and/or a client whose address is close to its lifetime) send an RS message to a multicast group joined by only a few. There are no "hops" because this is all link-local communication.

Routers then respond either with a multicast or a unicast RA.

As such, I think this provides at least the same reliability as DHCPv6 per your comments above, while also providing the additional robustness
you already attributed to all-hosts-multicast periodic RAs from the routers.

Owen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 6 Dec 2013 18:14:12 -0800 (PST)

Hi Bernie,

----- Original Message -----
> From: Bernie Volz (volz) <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; Andrew Yourtchenko (ayourtch) <[email-masked]>
> Sent: Saturday, 7 December 2013 12:25 PM
> Subject: RE: [v6ops] New Version Notification for	draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> Mark:
> 

That's a good point.

> DHCPv6 multicast is client to server (or relay). This has far fewer problems in 
> some networks because the first hop is typically on the wired portion of the 
> network (and the destination multicast address is usually just joined by a few 
> devices (relays and servers) - not all).
> 
> RA multicast is router to client(s). This has problems in distributing the 
> traffic out to all of the clients over some networks.
> 

I'd think in that case multicast RS / unicast RA response mechanism could be used. Perhaps the thing to tweak in RAs to better suit this scenario would be to change the default of responding to multicast RSes with a multicast RA to responding with a unicast RA, as allowed in 6.2.6 of RFC4861.

Thanks,
Mark.

>>>   "This is where the peer-to-peer, acknowledged nature of DHCPv6 
> may 
>>> be
>>>   I don't think broadcasts on wifi are reliable, so IPv4 ARP would 
> be
>>  failing too.
>>> 
> Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime or 3 * 
> MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose knowledge of 
> a router it has to miss 3 unsolicited multicast RAs in a row.
> 
> I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as they 
> only implement the second mechanism. For DHCPv6, neighbor discovery and MLD to 
> be as robust as RAs, the DHCPv6 server and the hosts would have to also issue 
> periodically unsolicited announcements of themselves so that other hosts and 
> routers don't have to solicit for them, unless they have no existing 
> knowledge of them.
> 
> (Should we add the ES-IS neighbor discovery model to IPv6 ND to make it more 
> robust? ES-IS has hosts periodically multicast their presence to the link's 
> routers, routers periodically multicast their presence to the hosts, hosts 
> default to sending to their routers for all destinations, then routers sends a 
> redirects to a host when the destination host is on the same link.).
> 
> 
> That sound to me like an assertion that DHCPv6 is going to work in all 
> conditions. Given that DHCPv6 server discovery is less reliable than RAs 
> (because of the lack of unsolicited DHCPv6 server advertisements), how is moving 
> RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs?
> 
> So I'm curious why legacy IP is supposedly more robust? IPv4 uses broadcasts 
> for ARP and DHCP server discovery. On these links where IPv4 "looks more 
> robust" than IPv6, are broadcasts provided more reliable delivery than 
> multicasts, in particular as broadcasts must be flooded to all hosts, where as 
> multicasts can have their flooding scope limited using MLD snooping?
> 
> 
>> 
> Right, and doing that would solve the multicast capacity exhaustion problems 
> that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), because it 
> is a more extreme case of constraining where multicasts are sent than MLD 
> snooping.
> 
> My Broadcast Multi-Access (BMA) link operating as NBMA suggestion wouldn't 
> require both having available and enabling any link-layer special features to 
> achieve the goal of significantly reducing multicast traffic. 
> 
> (Thinking about it, the recent Efficient ND proposal is perhaps a special case 
> of operating a BMA link as an NBMA link for the Neighbor Discovery protocol. 
> I'm starting to wonder if it might be better to just adopt this complete 
> NBMA model over a BMA link and eliminate all link-layer multicasts (ND, DHCPv6, 
> MLD), except RAs to announce the BMA link is operating in NBMA mode. The only 
> multicasts would be unsolicited RAs, which, for a single router, could be only 
> once every 30 minutes (15 minutes for two routers). I'd think that sort of 
> interval would be adequate to address the concerns of multicasts consuming 
> mobile device battery life.)
> 
> 
>>> 
> Are all of those 300-500 APs in a single broadcast/multicast domain i.e., one 
> large link? That's convenient, but if multicasts/broadcasts aren't 
> reliable enough, that suggests the link capacity is exhausted. Dividing the link 
> up using routers to reduce multicast/broadcasts is and has been the common 
> solution since broadcast multiaccess links were invented (which I think would be 
> since around late 1970s when Ethernet was invented).
> 
> Moving to an NBMA model by effectively modelling the BMA link as a full mesh of 
> virtual point-to-point links would probably be an alternative method of 
> overcoming multicast/broadcast capacity limitations.
> 
> - I don't see how anything in DHCPv6 makes it dramatically more reliable 
> than RAs, given that it too uses multicasts for DHCPv6 server discovery. Adding 
> RA functions into DHCPv6 is described or asserted to be the panacea to all 
> issues that RAs could suffer from, yet analysis shows it isn't.
> 
> - I think it would be better to incrementally tune and optimise the existing 
> designed, standardised, code developed, code debugged and widely deployed 
> mechanism (RAs) to overcome corner cases, and/or to adopt past developed methods 
> such as IPv6 over NBMA, than to spend the next 5 to 10 years waiting for the 
> design, standardisation, code development, code debugging and widespread 
> deployment of RA functions to be incorporated into DHCPv6, and then also have to 
> develop methods of conflict resolution when RAs and DHCPv6 options disagree 
> (because they will, unless you don't plan to transition to DHCPv6 only until 
> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will have to 
> co-exist on a link for many years if you can't demand or guarantee DHCPv6 RA 
> functionality from the host implementations.)
> 
> - Using DHCPv6 for RA functionality won't eliminate one of the supposed 
> causes of RA unreliability - multicast unreliability. All of DHCPv6, neighbor 
> discovery and MLD would have to be made more robust against multicast 
> unreliability to truly solve that problem.
> 
> - I'm for a single method that works adequately. DHCPv6 with RA options 
> would probably qualify if we didn't already have a existing method. Existing 
> methods that work are always better than non-existent ones that need to be 
> developed, tested and ubiquitously deployed before they become significantly 
> useful and can be assumed to be available.
> 
> 
> The thing they need to demonstrate is that the costs of deploying a new and 
> second mechanism that is near functionally equivalent to the first is worth the 
> benefits. Given that the costs of developing and deploying RAs has already been 
> paid, I think the benefits of using DHCPv6 for RA functions have to be very 
> significant before the price should be paid. The benefits of DHCPv6 for RA 
> functions now needs to be compelling. I don't think they are, otherwise 
> I'd be quite happy to advocate for DHCPv6 for RA functions.
> 
> 
> I don't think RAs are the single reason some people are resisting deploying 
> IPv6 at all. I think some people are resisting deploying IPv6 because it needs 
> to do one or both of two things for them - solve a foreseeable problem that will 
> effect them, or provide a tangible benefit. If it won't do either of those 
> things, then they don't currently see any value from the effort involved. 
> What are foreseeable problems or tangible benefits is completely up to the 
> perspective of the decision maker. Eventually they'll see value in it, and 
> deploy it. In some cases, some people who could deploy IPv6 may never see any 
> value in deploying it, so they never will.
> 
> There is no single answer to why people might resist deploying IPv6, no single 
> solution, and things that motivate people to deploy or not IPv6 may have nothing 
> to do with how IPv6 itself works.
> 
> 
> 
> A single solution that solves most cases is better than two different, near 
> functionally equivalent solutions that solve the same cases. Multiple 
> near-equivalent solutions create more code, more bugs and then require conflict 
> resolution mechanisms, creating even more code and more bugs, with very little 
> actual benefit.
> 
> There are multiple ways of solving the neighbor discovery/router discovery/host 
> parameter configuration problem (read Radia Perlman's 
> "Interconnections" book as a starting point, and then perhaps 
> "Inside Appletalk", and also look into Novell's IPX and Network 
> Directory Services.). They all have different trade-offs, but fundamentally the 
> trade-offs aren't significantly different or compelling. Yet because there 
> are multiple methods to solve these problems, does that justify implementing all 
> of them because they each have some minor benefits over the others, that 
> different people might prefer?
> 
> Regards,
> Mark.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 7 Dec 2013 02:25:29 +0000

Yes, I am aware of that - unicast RA from the router to the client is available. Just isn't clear now often it is used.

But, this doesn't address the periodic RAs normally sent by routers as those are multicast.

- Bernie

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 9:07 PM
To: Bernie Volz (volz)
Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

As such, I think this provides at least the same reliability as DHCPv6 per your comments above, while also providing the additional robustness you already attributed to all-hosts-multicast periodic RAs from the routers.

Owen

>>>   Some criticisms/comments/questions on these pieces of text 
>>> relating to
>>> to  ensure the reliable delivery of multicast packets, you simply 
>>> will not  get the SLAAC working because the multicast RAs will get 
>>> crunched by the  interference."
>>> even  low bandwidth ones, wouldn't work either, as would MLD 
>>> snooping based  layer 2 forwarding optimisation.
>>> 
>>>   So if RAs are failing because of not reliable enough multicast 
>>> then that is just one symptom of the link being overloaded, and 
>>> there will be  others.
>> 
>>>   One idea I've had for this sort of scenario would be for the link 
>>> to operate as mostly an IPv6 over NBMA segment. The only multicasts 
>>> on the  link are RAs, providing the necessary NBMA operation parameters.
>> prefixes as off-link, send all the traffic via the router on the 
>> wired side, block all the inbound ND from hosts except for the RS and 
> (Thinking about it, the recent Efficient ND proposal is perhaps a 
> special case of operating a BMA link as an NBMA link for the Neighbor 
> Discovery protocol. I'm starting to wonder if it might be better to 
> just adopt this complete NBMA model over a BMA link and eliminate all 
> link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the 
> BMA link is operating in NBMA mode. The only multicasts would be 
> unsolicited RAs, which, for a single router, could be only once every 
> 30 minutes (15 minutes for two routers). I'd think that sort of 
> interval would be adequate to address the concerns of multicasts 
> consuming mobile device battery life.)
> 
> 
>>> 
> - I think it would be better to incrementally tune and optimise the 
> existing designed, standardised, code developed, code debugged and 
> widely deployed mechanism (RAs) to overcome corner cases, and/or to 
> adopt past developed methods such as IPv6 over NBMA, than to spend the 
> next 5 to 10 years waiting for the design, standardisation, code 
> development, code debugging and widespread deployment of RA functions 
> to be incorporated into DHCPv6, and then also have to develop methods 
> of conflict resolution when RAs and DHCPv6 options disagree (because 
> they will, unless you don't plan to transition to DHCPv6 only until 
> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will 
> have to co-exist on a link for many years if you can't demand or 
> guarantee DHCPv6 RA functionality from the host implementations.)
> 
>> I think in this discussion are again getting into the argument of 
>> "the best solution" instead of trying to collect the properties of 
>> the RA and DHCP.
>>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 6 Dec 2013 18:39:05 -0800

I see unicast RAs from time to time on my network. Haven't delved too deeply into whether they come from the Juniper, Mikrotik, Linux, or all three.

Sorry, I stopped using $C here years ago because the power and cooling were getting out of hand compared to what I could do with much cheaper $M and $J boxes.

(This is my home network, 2620:0:930::/48. I'm not speaking of or for $DAYJOB at the moment).

Is a link-local multicast on WiFi implemented as multiple unicasts for some reason? If not, then I can't imagine it would be any worse than ARP.

Owen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 6 Dec 2013 19:10:36 -0800 (PST)

----- Original Message -----
> To: Owen DeLong <[email-masked]>
> Cc: Mark ZZZ Smith <[email-masked]>; Andrew Yourtchenko (ayourtch) <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Saturday, 7 December 2013 1:25 PM

As a router would have knowledge of the hosts it has sent unicast RAs to via its neighbor cache, for the purposes of NUD, a router could periodically unicast RAs directly to the individual hosts.

Regards,
Mark.

>>  DHCPv6 multicast is client to server (or relay). This has far fewer 
> problems in some networks because the first hop is typically on the wired 
> portion of the network (and the destination multicast address is usually just 
> joined by a few devices (relays and servers) - not all).
> 
> Clients starting up (and/or a client whose address is close to its lifetime) 
> send an RS message to a multicast group joined by only a few. There are no 
> "hops" because this is all link-local communication.
> 
> As such, I think this provides at least the same reliability as DHCPv6 per your 
> comments above, while also providing the additional robustness you already 
> attributed to all-hosts-multicast periodic RAs from the routers.
> 
> Owen
> 
>> 
>>  - Bernie
>> 
>>>>    "This is where the peer-to-peer, acknowledged nature of 
> DHCPv6 may 
>>>>  be
>>  In the case of multicast RAs there are two independent reliability 
> mechanisms used, one router side, one host side.
>> 
>>  Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime 
> or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose 
> knowledge of a router it has to miss 3 unsolicited multicast RAs in a row.
>> 
>>  I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as 
> they only implement the second mechanism. For DHCPv6, neighbor discovery and MLD 
> to be as robust as RAs, the DHCPv6 server and the hosts would have to also issue 
>>  (Should we add the ES-IS neighbor discovery model to IPv6 ND to make it 
> more robust? ES-IS has hosts periodically multicast their presence to the 
> link's routers, routers periodically multicast their presence to the hosts, 
> hosts default to sending to their routers for all destinations, then routers 
> sends a redirects to a host when the destination host is on the same link.).
>> 
>> 
>>  So I'm curious why legacy IP is supposedly more robust? IPv4 uses 
> broadcasts for ARP and DHCP server discovery. On these links where IPv4 
> "looks more robust" than IPv6, are broadcasts provided more reliable 
> delivery than multicasts, in particular as broadcasts must be flooded to all 
> hosts, where as multicasts can have their flooding scope limited using MLD 
> snooping?
>> 
>> 
>>> 
>>  Right, and doing that would solve the multicast capacity exhaustion 
> problems that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), 
> because it is a more extreme case of constraining where multicasts are sent than 
> MLD snooping.
>> 
>>  My Broadcast Multi-Access (BMA) link operating as NBMA suggestion 
> wouldn't require both having available and enabling any link-layer special 
> features to achieve the goal of significantly reducing multicast traffic. 
>> 
>>>>    your traffic - which, due to a difference in modulation, etc.  
> may 
>>>>  eat
>>  Are all of those 300-500 APs in a single broadcast/multicast domain i.e., 
> one large link? That's convenient, but if multicasts/broadcasts aren't 
>>  Moving to an NBMA model by effectively modelling the BMA link as a full 
> mesh of virtual point-to-point links would probably be an alternative method of 
>>  - I don't see how anything in DHCPv6 makes it dramatically more 
> reliable than RAs, given that it too uses multicasts for DHCPv6 server 
> discovery. Adding RA functions into DHCPv6 is described or asserted to be the 
> panacea to all issues that RAs could suffer from, yet analysis shows it 
> isn't.
>> 
>>  I don't think RAs are the single reason some people are resisting 
> deploying IPv6 at all. I think some people are resisting deploying IPv6 because 
> it needs to do one or both of two things for them - solve a foreseeable problem 
> that will effect them, or provide a tangible benefit. If it won't do either 
> of those things, then they don't currently see any value from the effort 
> involved. What are foreseeable problems or tangible benefits is completely up to 
> the perspective of the decision maker. Eventually they'll see value in it, 
> and deploy it. In some cases, some people who could deploy IPv6 may never see 
> any value in deploying it, so they never will.
>> 
>>  There is no single answer to why people might resist deploying IPv6, no 
> single solution, and things that motivate people to deploy or not IPv6 may have 
> nothing to do with how IPv6 itself works.
>> 
>> 
>> 
>>  There are multiple ways of solving the neighbor discovery/router 
> discovery/host parameter configuration problem (read Radia Perlman's

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sat, 7 Dec 2013 20:56:02 +0100 (CET)

On Fri, 6 Dec 2013, Mark ZZZ Smith wrote:

[snip]

>discovery. Adding RA functions into DHCPv6 is described or asserted to be 
>the panacea to all issues that RAs could suffer from, yet analysis shows 
>it isn't.

Adding RA functions to DHCP allows to get rid of RAs for the scenarios 
where you have to run DHCP, plain and simple.

>existing designed, standardised, code developed, code debugged and widely 
>deployed mechanism (RAs) to overcome corner cases, and/or to adopt past 
>developed methods such as IPv6 over NBMA, than to spend the next 5 to 10 
>years waiting for the design, standardisation, code development, code 
>debugging and widespread deployment of RA functions to be incorporated 
>into DHCPv6, and then also have to develop methods of conflict resolution 
>when RAs and DHCPv6 options disagree (because they will, unless you don't 
>plan to transition to DHCPv6 only until DHCPv6 RA functions are 
>ubiquitous. RAs and DHCPv6 RA functions will have to co-exist on a link 
>for many years if you can't demand or guarantee DHCPv6 RA functionality 
>from the host implementations.)

Conflict resolution is simple: fix your network. You are describing as a 
problem what isn't.

The http://xkcd.com/927/ is indeed a problem. But, this is a question of 
engineering, and using that as a blanket argument against DHCP-only 
operation is incorrect.

>causes of RA unreliability - multicast unreliability. All of DHCPv6, 
>neighbor discovery and MLD would have to be made more robust against 
>multicast unreliability to truly solve that problem.

Gee, we are stuck on the strawman ureliability - there are *other* reasons 
why one would want to use DHCP, thus being forced to run multiple 
protocols.

>would probably qualify if we didn't already have a existing method. 
>Existing methods that work are always better than non-existent ones that 
>need to be developed, tested and ubiquitously deployed before they become 
>significantly useful and can be assumed to be available.
>
>
> The thing they need to demonstrate is that the costs of deploying a new 
>and second mechanism that is near functionally equivalent to the first is 
>worth the benefits. Given that the costs of developing and deploying RAs 
>has already been paid, I think the benefits of using DHCPv6 for RA 
>functions have to be very significant before the price should be paid. 
>The benefits of DHCPv6 for RA functions now needs to be compelling. I 
>don't think they are, otherwise I'd be quite happy to advocate for DHCPv6 
>for RA functions.

For some, the benefit would be significant. For some - it 
won't be any benefit at all.

>deploying IPv6 at all. I think some people are resisting deploying IPv6 
>because it needs to do one or both of two things for them - solve a 
>foreseeable problem that will effect them, or provide a tangible benefit. 
>If it won't do either of those things, then they don't currently see any 
>value from the effort involved. What are foreseeable problems or tangible 
>benefits is completely up to the perspective of the decision maker. 
>Eventually they'll see value in it, and deploy it. In some cases, some 
>people who could deploy IPv6 may never see any value in deploying it, so 
>they never will.

It's not binary. You can represent as a number both the amount of pain 
that a given problem (or set of problems) causes, and the amount of pain 
that the big change in the network like adding a new protocol causes.

As soon as the first number is smaller than the second one, nothing gets 
done.

Judging by the feedback I get from talking with people, even the 
possibility of eventually eliminating RAs from their network might make 
the second number smaller for a nontrivial amount folks, whose situation 
dictates the DHCPv6.

> A single solution that solves most cases is better than two different,

That's the point. The single solution that solves most cases, does not 
exist. For a good part of the cases, you need to apply two solutions at 
once. Justifiably, the question is "why", given in legacy IP they did not 
need to do that.

--a

>near functionally equivalent solutions that solve the same cases. 
>Multiple near-equivalent solutions create more code, more bugs and then 
>require conflict resolution mechanisms, creating even more code and more 
>bugs, with very little actual benefit.
>
>"Interconnections" book as a starting point, and then perhaps "Inside 
>Appletalk", and also look into Novell's IPX and Network Directory 
>Services.). They all have different trade-offs, but fundamentally the 
>trade-offs aren't significantly different or compelling. Yet because 
>there are multiple methods to solve these problems, does that justify 
>implementing all of them because they each have some minor benefits over 
>the others, that different people might prefer?

---

From: Owen DeLong <[email-masked]>
Date: Sat, 7 Dec 2013 13:05:09 -0800

I don't see a need for or benefit from doing so. I think unicast RAs should only be sent in response to RS.

I do see a valid use case for hosts sending RS if they are getting close to their desired or valid timers.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 7 Dec 2013 13:22:58 -0800

> It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, and the amount of pain that the big change in the network like adding a new protocol causes.
> 
> As soon as the first number is smaller than the second one, nothing gets done.
> 
> Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6.
> 

I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's pretty trivial if you know enough to tune them properly.

If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing.

However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance.

>>> I think in this discussion are again getting into the argument of "the best solution" instead of trying to collect the properties of the RA and DHCP.
>>> everyone's problems are slightly different. So, rather than preaching for everyone to adopt the single solution which is the best in one scenario and suboptimal in the other, we should be engineering a way to be able to apply different solutions in different circumstances without the overhead of double work.
>> 
> That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that.

Actually, the problem is that people have conflated two different problems and like to pretend that they are one.

In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem.

RAs solve the problem of telling a host which routers are available on link.
RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list)

For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration.
For that, you need DHCPv6 which is a protocol designed to do host configuration.

While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments. Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for many years to come.

Owen

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 8 Dec 2013 02:55:41 +0000

>While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments.

Yeah, I don't think they should go either.

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Owen DeLong
Sent: Saturday, December 07, 2013 4:23 PM
To: Andrew Yourtchenko (ayourtch)
Cc: [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

Owen

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sun, 8 Dec 2013 07:25:51 +0100 (CET)

> However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance.

It's another protocol to run. It's not free.

That the price varies for different parties is a different matter.

> For that, you need DHCPv6 which is a protocol designed to do host configuration.

I think you nailed it here: With RA you *discover* the 
routers available on the link, with DHCP in legacy IP, you *configure* 
them.

In some case you don't want the hosts to "discover" anything - your 
network does not change, you know your router, and actually having a way 
to *configure* it is more robust and secure than having to *discover* 
it. Why take away the tool from the toolbox ?

Thanks for this, I think this is a very valuable point, I'll add it to the 
text - https://github.com/ayourtch/ra-dhcpv6/issues/9

>
> While I would like to see routing options added to DHCP for a variety 
>of reasons (mostly political and organizational rather than technical), I 
>do not for one second believe that eliminating RAs is useful in any 
>significant proportion of environments.
> Even if we made the changes you 
>are proposing, eliminating RAs would be unlikely in the vast majority of 
>circumstances, at least for many years to come.

First off, I am not proposing to eliminate the RAs, at least not just yet. :-)

I am proposing to stop blindly repeating "thou shall not eliminate RAs" 
mantra and explore with an open mind, what are the drivers behind people 
wanting to use DHCP-only, how hard would that be, and see on balance 
whether the juice is worth the squeeze.

Second, there are no IPv6-only enterprise networks today, so eliminating 
RA would be *trivial* in those environments that want to eliminate 
them, as soon as 1-2 mainstream OSes were to support it.

How ? Much the same as with DHCPv6-only networks today. Don't support 
the network's policy ? Fine, you are welcome to use your legacy IP stack 
until you do.

And in any case "taking many years to come" is not an argument for not 
doing things.

Case in point: IPv6 itself.

--a

---

From: Owen DeLong <[email-masked]>
Date: Sat, 7 Dec 2013 22:40:37 -0800

> It's another protocol to run. It's not free.

It seems free to me. I configure an address into my router and it starts announcing RAs.

> That the price varies for different parties is a different matter.

Fair enough, but it's free or very nearly free for the vast majority of parties.

> I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them.

No, with DHCP, you discovered what some remote host rumored them to be.

> In some case you don't want the hosts to "discover" anything - your network does not change, you know your router, and actually having a way to *configure* it is more robust and secure than having to *discover* it. Why take away the tool from the toolbox ?

Your host is always discovering things. IP doesn't work without discovery (at least not in any practical way for the vast majority of applications). In IPv4, ARP is used to discover the MAC address of adjacent hosts, for example. In IPv6, we use Neighbor Solicitation and Neighbor Advertisement to do roughly the same thing.

There are a number of advantages to finding out what routers are available to you FROM THE ROUTERS instead of getting rumors from some remote server which may or may not be accurate in general and certainly have a reasonable chance of being flat out wrong in the event of any failure condition.

A network that doesn't change is an amusing fallacy. I will agree that there are some networks which don't change until they do. However, I have yet to see a network that didn't change.

> Thanks for this, I think this is a very valuable point, I'll add it to the text - https://github.com/ayourtch/ra-dhcpv6/issues/9

If you do so, please do not misconstrue my remarks the way you have in this case.

>> Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for many years to come.
> 
> 

I didn't mean eliminating them in general. I meant that I am very hard pressed to imagine any scenario where a network would benefit from eliminating them other than certain environments that would probably be better suited to 6LOWPAN anyway.

> I am proposing to stop blindly repeating "thou shall not eliminate RAs" mantra and explore with an open mind, what are the drivers behind people wanting to use DHCP-only, how hard would that be, and see on balance whether the juice is worth the squeeze.

I've been through that exercise. I'm all for giving DHCP the ability to provide routing information. I've said as much on numerous occasions.

However, even on a network that is running "DHCP only" you gain nothing (at least in the vast majority of circumstances) and lose significant robustness if you turn off RAs.

> Second, there are no IPv6-only enterprise networks today, so eliminating RA would be *trivial* in those environments that want to eliminate them, as soon as 1-2 mainstream OSes were to support it.

That isn't true. I doubt seriously that there are no IPv6-only enterprise networks, but I accept that there are very few.

However, eliminating RA in those environments that want to eliminate them would not be trivial. You'd have to upgrade every desktop OS and every other dynamically configured device because in the current running code, DHCP doesn't work without an RA to tell it "go ask the DHCP server".

> How ? Much the same as with DHCPv6-only networks today. Don't support the network's policy ? Fine, you are welcome to use your legacy IP stack until you do.

There are no DHCPv6-only networks today.

> And in any case "taking many years to come" is not an argument for not doing things.

It is an argument against putting significant risk into a deployed codebase for a minuscule gain for a very small number of beneficiaries.

> Case in point: IPv6 itself.

IPv6 itself didn't involve deploying incompatible updates that will potentially interfere with a deployed operational protocol. The changes you are proposing (to make hosts do DHCP without bootstrapping it through the RA process) are different. Those are not at all unlikely to be problematic in a number of difficult to predict ways.

Personally, I would much rather see us focus on the following easily achievable goals that I think matter to a lot more people:

	1.	Provide more consistent guidance on the interactions of M, O, and A flags in RAs and how RAs should be processed.
	2.	Provide more consistent guidance on the interactions of RAs that disagree. While this is arguably a "broken network"
		condition, it is a form of brokenness where having a defined and deterministic mode of failure is more desirable than
		the current "depends on the host OS, phase of the moon, and 2d20 roll of the operator" scenario.
	3.	Add routing information to DHCP for those that want to use it.

Owen

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sun, 8 Dec 2013 07:44:21 +0100 (CET)

> Yeah, I don't think they should go either.

Again, I am *not* proposing to deprecate them.

I'm proposing to decriminalize the thinking of allowing to not use them.

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sun, 8 Dec 2013 09:34:51 +0100 (CET)

On Sat, 7 Dec 2013, Owen DeLong wrote:

>                         I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people
>                         are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable
>                         problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they
>                         don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is
>                         completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In
>                         some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will.
> 
>
>                   It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes,
>                   and the amount of pain that the big change in the network like adding a new protocol causes.
>
>                   Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their
>                   network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6.
> 
>
>             I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's
>             pretty trivial if you know enough to tune them properly.
>

That's the crux. It's free to you, so you make the leap "so it's free".

> Fair enough, but it's free or very nearly free for the vast majority of parties.

You need to take care:

1) that the RAs from the router reach the hosts.
2) that only the RAs from *your* router reach the hosts.

either of the two may be a non-issue for *you* but the induction that it's 
a non-issue for *everyone* is incorrect.

>
>                         There is no single answer to why people might resist deploying IPv6, no single solution, and things that
>                         motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.
> 
> 
>
>                               I think in this discussion are again getting into the argument of "the best solution" instead of
>                               trying to collect the properties of the RA and DHCP.
>                               everyone's problems are slightly different. So, rather than preaching for everyone to adopt the
>                               single solution which is the best in one scenario and suboptimal in the other, we should be
>                               engineering a way to be able to apply different solutions in different circumstances without the
>                               overhead of double work.
> 
>
>                   That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to
>                   apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that.
> 
>
>       In some case you don't want the hosts to "discover" anything - your network does not change, you know your router, and actually having a way to
>       *configure* it is more robust and secure than having to *discover* it. Why take away the tool from the toolbox ?
> 
> 
> Your host is always discovering things. IP doesn't work without discovery (at least not in any practical way for the vast majority of applications). In IPv4,
> ARP is used to discover the MAC address of adjacent hosts, for example. In IPv6, we use Neighbor Solicitation and Neighbor Advertisement to do roughly the same
> thing.
> 
> There are a number of advantages to finding out what routers are available to you FROM THE ROUTERS instead of getting rumors from some remote server which may
> or may not be accurate in general and certainly have a reasonable chance of being flat out wrong in the event of any failure condition.
> 

There are a number of advantages to NOT finding out from the routers that 
they are the routers in an unauthenticated manner.

The environments vary.

> If you do so, please do not misconstrue my remarks the way you have in this case.

Okay, I will not add you to the "acknowledgements", and will treat that 
idea as my own, FWIW.

> 
>
>             While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than
>             technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments.
> I didn't mean eliminating them in general. I meant that I am very hard pressed to imagine any scenario where a network would benefit from eliminating them
> other than certain environments that would probably be better suited to 6LOWPAN anyway.

Did you read the draft mentioned in the subject line ?

>
>       I am proposing to stop blindly repeating "thou shall not eliminate RAs" mantra and explore with an open mind, what are the drivers behind people
>       wanting to use DHCP-only, how hard would that be, and see on balance whether the juice is worth the squeeze.
> 
> 

Legacy IP runs fine with no RAs. Quite robustly.

>
>       Second, there are no IPv6-only enterprise networks today, so eliminating RA would be *trivial* in those environments that want to eliminate them,
>       as soon as 1-2 mainstream OSes were to support it.
> 
> 
> However, eliminating RA in those environments that want to eliminate them would not be trivial. You'd have to upgrade every desktop OS and every other
> dynamically configured device because in the current running code, DHCP doesn't work without an RA to tell it "go ask the DHCP server".

My OS upgrades itself every other week. And installs apps, bugfixes, and 
such. Autoupdate exists and works. In a stricter environment you have an 
IT department building the golden setups. The image lifecycle there is 3-5
years.

> There are no DHCPv6-only networks today.

I was using one just on Friday.

> IPv6 itself didn't involve deploying incompatible updates that will potentially interfere with a deployed operational protocol.

IPv6 is completely incompatible with the deployed operational IPv4, and in 
the rfc3484 case a broken IPv6 completely screws up your perfectly working 
IPv4.

> The changes you are proposing
> (to make hosts do DHCP without bootstrapping it through the RA process) 
>are different. Those are not at all unlikely to be problematic in a 
>number of difficult
> to predict ways.

Again, all I am proposing is to decriminalize the thinking about proposing 
DHCPv6-only operation and its implications, and be able to write it up for 
further balanced analysis.

If you have an opinion that is a useless activity - absolutely fine.

I registered that. Let's move on and if you do not have any comments on 
the text itself, we can wrap this sub-thread up.

> 1. Provide more consistent guidance on the interactions of M, O, and A flags in RAs and how RAs should be processed.

This is great - (though, if we were to use the argument you used 
previously - why bother ? it will anyway take forever to achieve the 
consistency). Documenting the existing behavior is a great start, anyway. 
draft-ietf-v6ops-dhcpv6-slaac-problem is awesome.

> the current "depends on the host OS, phase of the moon, and 2d20 roll of the operator" scenario.

This is indeed a broken network.

Use router priorities - it's an existing and deployed 
mechanism which trivially resolves the conflicts with no ambiguity and no 
code changes required. (Of course, assuming the host implements them and 
implements correctly).

> 3. Add routing information to DHCP for those that want to use it.

It will end up in the threads exactly like this one, just with different 
people.

--a

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Dec 2013 08:22:37 +1300

> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko <[email-masked]> wrote:

...
> No, with DHCP, you discovered what some remote host rumored them to be.

I don't think we should be having this argument. We should be
trying to write down objectively the type of scenarios where
DHCPv6 is applicable, the type of scenarios where RA-only is
applicable, and the type of scenarios where both (simultaneously)
are applicable.

There's no right or wrong answer here.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Sun, 8 Dec 2013 11:35:20 -0800

> 1) that the RAs from the router reach the hosts.

If they don't, you have a broken network and your other packets likely aren't reaching those hosts, either. Beyond that, that's why things get retried.

At least in the case of RAs, they only have to travel a single hop. DHCP is often much more remote. At its best, DHCP cannot be any better than in this regard.

> 2) that only the RAs from *your* router reach the hosts.

This is no different from the rogue DHCP server problem, so I am again, not impressed. An RA attacker has to be on-link. If you have hostile hosts on-link in your LAN, then you have bigger problems than rogue RA in most cases.

> either of the two may be a non-issue for *you* but the induction that it's a non-issue for *everyone* is incorrect.

It's not a non-issue, but DHCP has the same problems.

> There are a number of advantages to NOT finding out from the routers that they are the routers in an unauthenticated manner.

Then use SEND or turn of RA on your routers and deal with the consequences of having to statically configure routes on every host and/or run a routing protocol on every host.

I don't see any advantage to a route from an unauthenticated DHCP server over a route from an unauthenticated router.

> The environments vary.

Sure, but the basic principles involved do not.

> Okay, I will not add you to the "acknowledgements", and will treat that idea as my own, FWIW.

So you think it is better to misquote me out of context without attribution than to simply not misquote me out of context? Somehow I don't really see that as an improvement.

> Did you read the draft mentioned in the subject line ?

Yes, but I did not find it compelling.

> Legacy IP runs fine with no RAs. Quite robustly.

Legacy IP has numerous problems, actually. We've gotten used to coping with them. The fact that we have come to accept chronic pain is not a valid reason to avoid seeking proper medical treatment. Indeed, most of the problems you claim are specific to RA have variants that apply equally strongly to DHCP in both IPv6 and in Legacy IP.

> My OS upgrades itself every other week. And installs apps, bugfixes, and such. Autoupdate exists and works. In a stricter environment you have an IT department building the golden setups. The image lifecycle there is 3-5
> years.

I'm happy for you, but that's not the case for the vast majority of enterprises where Windows "autoupdate" is not so well trusted.

Talk to any IT department in any organization of substantial size and ask them if they have complete 100% control over the update cycle of absolutely every machine on the network. I'm willing to bet that not one of them can honestly answer that question in the affirmative. There's always some piece of software that someone deems critical to the enterprise at a high enough level which can't be updated for some reason. The longer an enterprise is in business and the larger it becomes, the more of these exceptional cases emerge.

> I was using one just on Friday.

How did you get the clients to ask the DHCP server for something without giving it an M|O Bit RA?

Arguably, said clients are not behaving according to the RFCs.

> IPv6 is completely incompatible with the deployed operational IPv4, and in the rfc3484 case a broken IPv6 completely screws up your perfectly working IPv4.

No, IPv6 is a completely separate protocol. Yes, there are certain ways to break name resolution for IPv4 with IPv6 misconfiguration, but that is because of the shared name service. IPv6 the protocol does _NOT_ interfere with IPv4 the protocol on the wire. The issues in RFC3484 are entirely related to DNS being shared between the two protocols.

>> (to make hosts do DHCP without bootstrapping it through the RA process) are different. Those are not at all unlikely to be problematic in a number of difficult
>> to predict ways.
> 
> Again, all I am proposing is to decriminalize the thinking about proposing DHCPv6-only operation and its implications, and be able to write it up for further balanced analysis.

In order to do DHCPv6-only operation, you need to modify clients such that they have some way other than RAs to determine which configuration method(s) they are to use. That is a fundamentally incompatible and dangerous change that could definitely have negative impacts.

> If you have an opinion that is a useless activity - absolutely fine.

To say the least. However, useless isn't enough to make me oppose it. I oppose it because beyond useless, it is also potentially dangerous.

> This is great - (though, if we were to use the argument you used previously - why bother ? it will anyway take forever to achieve the consistency). Documenting the existing behavior is a great start, anyway. draft-ietf-v6ops-dhcpv6-slaac-problem is awesome.

Because this actually impacts MANY organizations and users and is becoming a bigger problem, not a smaller one.

> Use router priorities - it's an existing and deployed mechanism which trivially resolves the conflicts with no ambiguity and no code changes required. (Of course, assuming the host implements them and implements correctly).

People make typos. Router configurations get out of sync. This is the real world. Knowing in advance how a host is going to deal with two routers of equal priority giving different messages would be useful. Having all hosts do the same thing would be even more useful, no?

> It will end up in the threads exactly like this one, just with different people.

It certainly has many times before. But at least that would be a useful feature that doesn't break anything.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 8 Dec 2013 11:38:41 -0800

> There's no right or wrong answer here.

In IPv6, as I read the RFCs, there's no valid way for a host to know that it is supposed to get information from a DHCPv6 server unless it receives an RA with the M and/or O bits set.

As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both.

The scenarios where RA-Only make sense are any scenario where you do not need greater control of the client configuration than Prefix information, routing information, and DNS resolver addresses and search strings.

In any scenario where you need to supply the host with more configuration information on a dynamic basis, DHCPv6 is also required.

Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc., these fall into the DHCPv6 realm.

It's really as simple as that as near as I can tell.

If you want to run without RAs, then you are into the realm of static configuration. I, personally, do not see this as a problem.

Owen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 8 Dec 2013 12:05:52 -0800 (PST)

----- Original Message -----
> To: Bernie Volz (volz) <[email-masked]>
> Sent: Sunday, 8 December 2013 5:44 PM
> of reasons (mostly political and organizational rather than technical), I do not 
> for one second believe that eliminating RAs is useful in any significant 
> proportion of environments.
>> 

Firstly, please stop using hyperbolic words such as "decriminalize" unless you actually mean them. I'd start to doubt your ability to create a balanced document if you think people advocating for leaving things as they are to be accusing others who want to change things to be criminals. It makes you sound like you're extremely subjective about this topic, and therefore will end up with an agenda to distort arguments against doing it to support your view.

People who really don't like RAs can switch them off and use static configuration. They can also switch off neighbor discovery and manually configure that to eliminate ND multicasts, and configure static multicast group membership to eliminate MLD multicasts. If their complaint is RA multicasts (which can be up to 30 minutes apart per the RFC advertisement interval), then I think their actual complaint is or should be all multicasts.

The point of RAs and DHCPv6 is automated configuration. To make automation work reliably you need to minimise and ideally remove options and parameters, because options and parameters can require human beings to make choices and to get them right, and that creates opportunities for human error. This includes errors in implementations of mechanisms to negotiate methods, options or parameters (see issues with misinterpretation of and between the M/O RA and PIO A options in "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-liu-bonica-dhcpv6-slaac-problem, as an example.)

Technical people like choice and flexibility, because I think they think about "what ifs" - "what if I was in this situation, what if I was in that situation, and what would I like to tweak to make it work." Non-technical end-users (usually our customers or at least our relatives), who far surpass us in numbers, don't care, shouldn't care and shouldn't have to care. They just want it to work, work reliably, and don't want to have to engage technical people to either make it work or call in assistance if it doesn't work or stops working. Choices, options and parameters make things more complex and therefore more fragile and less robust.

We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be wrong. DHCPv6 for default gateways would in the DHCPv6 relay scenario would require human entry of that information, creating the opportunity for human error, and potential conflict with what RAs are announcing.

Regards,

Mark.

>>>>  I don't think RAs are the single reason some people are 
> resisting deploying IPv6 at all. I think some people are resisting deploying 
> IPv6 because it needs to do one or both of two things for them - solve a 
> foreseeable problem that will effect them, or provide a tangible benefit. If it 
> won't do either of those things, then they don't currently see any value 
> from the effort involved. What are foreseeable problems or tangible benefits is 
> completely up to the perspective of the decision maker. Eventually they'll 
> see value in it, and deploy it. In some cases, some people who could deploy IPv6 
> may never see any value in deploying it, so they never will.
>>> 
>>>  It's not binary. You can represent as a number both the amount of 
> pain that a given problem (or set of problems) causes, and the amount of pain 
> possibility of eventually eliminating RAs from their network might make the 
> second number smaller for a nontrivial amount folks, whose situation dictates 
> the DHCPv6.
>>> 
>> 
>>  I find this very hard to believe. RAs are virtually automatic and free in 
> 99% of cases. If you feel the need to tune them, then that's pretty trivial 
> if you know enough to tune them properly.
>> 
>>  If you don't know what you are doing, then you can really mess yourself 
> up with RA tweaking that you shouldn't be doing.
>> 
>>  However, I do not advocate IETF breaking the internet just to prevent 
> people from breaking their LANs out of ignorance.
>> 
>>>>  There is no single answer to why people might resist deploying 
> IPv6, no single solution, and things that motivate people to deploy or not IPv6 
> may have nothing to do with how IPv6 itself works.
>>>> 
>>>> 
>>>> 
>>>>>  I think in this discussion are again getting into the argument 
> of "the best solution" instead of trying to collect the properties of 
> the RA and DHCP.
>>>>>  everyone's problems are slightly different. So, rather than 
> preaching for everyone to adopt the single solution which is the best in one 
> scenario and suboptimal in the other, we should be engineering a way to be able 
> to apply different solutions in different circumstances without the overhead of 
> double work.
>>>> 
>>>  That's the point. The single solution that solves most cases, does 
> not exist. For a good part of the cases, you need to apply two solutions at 
> once. Justifiably, the question is "why", given in legacy IP they did 
> not need to do that.
>> 
>>  For better or worse, to keep RAs very light weight, they do not provide a 
> complete or robust solution to host autoconfiguration.
>>  While I would like to see routing options added to DHCP for a variety of 
> reasons (mostly political and organizational rather than technical), I do not 
> for one second believe that eliminating RAs is useful in any significant 
> proportion of environments. Even if we made the changes you are proposing, 
> eliminating RAs would be unlikely in the vast majority of circumstances, at 
> least for many years to come.
>> 
>>  Owen
>> 
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Dec 2013 10:14:32 +1300

> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both.

Two comments on that:

a) Yes, where I wrote DHCPv6, I should have written "DHCPv6 with
minimal RA", with "Both" implying more-than-minimal RA.

b) IMHO we need to fix the ambiguity caused by the M/O bits'
current definition.

http://tools.ietf.org/html/draft-liu-6renum-dhcpv6-slaac-switching

In any case I'd like to see neutral analysis in the draft.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Dec 2013 17:31:34 -0500

On Dec 8, 2013, at 3:05 PM, Mark ZZZ Smith <[email-masked]> wrote:
> Firstly, please stop using hyperbolic words such as "decriminalize" unless you actually mean them.

First of all, I agree with this.   But secondly, let me point out that it is not a surprising thing to hear, because the debate on this has been fairly emotional.   I absolutely agree that we should keep this on a technical level, but please be understanding if the occasional reference to the painful history of this discussion pops out.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 9 Dec 2013 01:32:28 +0100 (CET)

On Sun, 8 Dec 2013, Ted Lemon wrote:

> First of all, I agree with this.   But secondly, let me point out that 
>it is not a surprising thing to hear, because the debate on this has been 
>fairly emotional.   I absolutely agree that we should keep this on a 
>technical level, but please be understanding if the occasional reference 
>to the painful history of this discussion pops out.
>

My apologies for what apparently is an excessively strong language.
English is my second language (albeit an old-time one, so it's hardly 
an excuse) and sometimes I can't measure correctly the exact impact my 
words may have. Sorry for this.

I don't have a hidden agenda to make RAs obsolete.

I have closed the issue on the github which caused the contention with 
Owen and will not pursue that area in the draft to avoid any conflict.

I'll make the edits to clear out the other outstanding issues, submit a 
new rev for the draft - and will leave it as such - just a URL to the 
draft is more than good enough to be used for referencing.

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 9 Dec 2013 01:36:18 +0100 (CET)

> We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be…

All very good points.

I agree with the majority of them.

Thanks a lot for the discussion.

--a

---

From: Owen DeLong <[email-masked]>
Date: Sun, 8 Dec 2013 21:20:06 -0800

> Technical people like choice and flexibility, because I think they think about "what ifs" - "what if I was in this situation, what if I was in that situation, and what would I like to tweak to make…

I don’t mind the flipper door, but I really hate it when people remove all the knobs. (The non-technical users shouldn’t open the flipper door).

> We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be…

It’s not hard at all. All you have to do is put a router on the network that is connected away from, instead of towards the internet and voila, you have arguably “wrong” RAs.

This won’t usually break anything because redirects usually work and even if they don’t, you just put unnecessary load on the network and the router that can’t forward the packets. However, if that router doesn’t know the correct address for the other routers, then your RAs will be truly wrong and things do break.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Dec 2013 10:12:44 +0100

Le 07/12/2013 03:39, Owen DeLong a écrit :
> I see unicast RAs from time to time on my network. Haven't delved too
> deeply into whether they come from the Juniper, Mikrotik, Linux, or
> all three.

The unicast RAs are there probably in response to a preceding NS or RS, 
which are themselves sometimes multicast, but could also be unicast.

Alex

>
> Sorry, I stopped using $C here years ago because the power and
> cooling were getting out of hand compared to what I could do with
> much cheaper $M and $J boxes.
>
> Is a link-local multicast on WiFi implemented as multiple unicasts
> for some reason? If not, then I can't imagine it would be any worse
> than ARP.
>
> Owen
>
>> Yes, I am aware of that - unicast RA from the router to the client
>> is available. Just isn't clear now often it is used.
>>
>> -----Original Message----- From: Owen DeLong
>> [mailto:[email-masked]] Sent: Friday, December 06, 2013 9:07 PM
>> To: Bernie Volz (volz) Cc: Mark ZZZ Smith; Andrew Yourtchenko
>> (ayourtch); [email-masked] Subject: Re: [v6ops] New Version
>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>> (fwd)
>>
>>
>>> DHCPv6 multicast is client to server (or relay). This has far
>>> fewer problems in some networks because the first hop is
>>> typically on the wired portion of the network (and the
>>> destination multicast address is usually just joined by a few
>>> RA multicast is router to client(s). This has problems in
>>> distributing the traffic out to all of the clients over some
>>> networks.
>>
>>
>> Clients starting up (and/or a client whose address is close to its
>> lifetime) send an RS message to a multicast group joined by only a
>> few. There are no "hops" because this is all link-local
>> communication.
>>
>> As such, I think this provides at least the same reliability as
>> DHCPv6 per your comments above, while also providing the additional
>> robustness you already attributed to all-hosts-multicast periodic
>> RAs from the routers.
>>
>> Owen
>>
>>>
>>> - Bernie
>>>
>>> -----Original Message----- From: v6ops
>>> [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith Sent:
>>> Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko
>>> (ayourtch) Cc: [email-masked] Subject: Re: [v6ops] New Version
>>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>>> (fwd)
>>>
>>>
>>>> From: Andrew Yourtchenko <[email-masked]> To: Mark ZZZ
>>>> Smith <[email-masked]> Cc: "[email-masked]"
>>>> <[email-masked]> Sent: Saturday, 7 December 2013 3:34 AM
>>>>> DHCPv6 may be beneficial - on a crowded large-scale WiFi,
>>>>> without special tricks to  ensure the reliable delivery of
>>>>> multicast packets, you simply will not  get the SLAAC working
>>>>> because the multicast RAs will get crunched by the
>>>>> interference." I'd think that if multicast is unreliable
>>>>> enough to cause RAs to fail  to be delivered often enough,
>>>>> then anything which relies on multicast  traffic is also
>>>>> likely to fail, which would include neighbor discovery. So
>>>>> regardless of if RAs were replaced with DHCPv6, the link is
>>>>> not going  to provide reliable IPv6 operation, because IPv6
>>>>> addresses cannot be  reliably resolved to layer 2 addresses.
>>>>>
>>>>> MLD would probably fail too, so any routed multicast
>>>>> applications, even  low bandwidth ones, wouldn't work either,
>>>>> as would MLD snooping based  layer 2 forwarding
>>>>> optimisation.
>>>>>
>>>>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so
>>>>> that will
>>>>> I don't think broadcasts on wifi are reliable, so IPv4 ARP
>>>>> would be
>>>> failing too.
>>>>>
>>>>> So if RAs are failing because of not reliable enough
>>>>> multicast then that is just one symptom of the link being
>>>>> overloaded, and there will be  others.
>>>>
>>>> for (1): RA is probably the only one that does not incorporate
>>>> a robust retransmit mechanism.
>>>>
>>>
>>> In the case of multicast RAs there are two independent
>>> reliability mechanisms used, one router side, one host side.
>>>
>>> Firstly, the router lifetime in the RA is to be set to
>>> AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1),
>>> meaning that for a host to lose knowledge of a router it has to
>>> miss 3 unsolicited multicast RAs in a row.
>>>
>>> I'd argue that DHCPv6, neighbor discovery and MLD are less
>>> robust, as they only implement the second mechanism. For DHCPv6,
>>> neighbor discovery and MLD to be as robust as RAs, the DHCPv6
>>> server and the hosts would have to also issue periodically
>>> unsolicited announcements of themselves so that other hosts and
>>> routers don't have to solicit for them, unless they have no
>>> existing knowledge of them.
>>>
>>> (Should we add the ES-IS neighbor discovery model to IPv6 ND to
>>> make it more robust? ES-IS has hosts periodically multicast their
>>> presence to the link's routers, routers periodically multicast
>>> their presence to the hosts, hosts default to sending to their
>>> routers for all destinations, then routers sends a redirects to a
>>> host when the destination host is on the same link.).
>>>
>>>
>>>> for (2): It's great if you can, but I'd like to have protocol
>>>> work in all conditions.
>>>
>>> That sound to me like an assertion that DHCPv6 is going to work
>>> in all conditions. Given that DHCPv6 server discovery is less
>>> reliable than RAs (because of the lack of unsolicited DHCPv6
>>> server advertisements), how is moving RA functions into DHCPv6
>>> going to make DHCPv6 more reliable than RAs?
>>>
>>> broadcasts for ARP and DHCP server discovery. On these links
>>> where IPv4 "looks more robust" than IPv6, are broadcasts provided
>>> more reliable delivery than multicasts, in particular as
>>> broadcasts must be flooded to all hosts, where as multicasts can
>>> have their flooding scope limited using MLD snooping?
>>>
>>>
>>>>
>>>>> One idea I've had for this sort of scenario would be for the
>>>>> link to operate as mostly an IPv6 over NBMA segment. The only
>>>>> multicasts on the  link are RAs, providing the necessary NBMA
>>>>> operation parameters. It of  course would require changes to
>>>>> clients and routers, but then again, so  would using DHCPv6
>>>>> for what RAs are used for today.
>>>>
>>>> Block traffic between the hosts (similar to private vlan),
>>>> advertise prefixes as off-link, send all the traffic via the
>>>> router on the wired side, block all the inbound ND from hosts
>>>> except for the RS and NS sent to solicited node address of the
>>>> router + destined to the router.
>>>>
>>>> I tested this, it works like a charm - at least for the
>>>> strawman browsing scenario.
>>>>
>>>
>>> Right, and doing that would solve the multicast capacity
>>> exhaustion problems that would effect RA multicasts (and DHCPv6,
>>> ND and MLD multicasts), because it is a more extreme case of
>>> constraining where multicasts are sent than MLD snooping.
>>>
>>> wouldn't require both having available and enabling any
>>> link-layer special features to achieve the goal of significantly
>>> reducing multicast traffic.
>>>
>>> (Thinking about it, the recent Efficient ND proposal is perhaps
>>> a special case of operating a BMA link as an NBMA link for the
>>> Neighbor Discovery protocol. I'm starting to wonder if it might
>>> be better to just adopt this complete NBMA model over a BMA link
>>> and eliminate all link-layer multicasts (ND, DHCPv6, MLD), except
>>> RAs to announce the BMA link is operating in NBMA mode. The only
>>> multicasts would be unsolicited RAs, which, for a single router,
>>> could be only once every 30 minutes (15 minutes for two routers).
>>> I'd think that sort of interval would be adequate to address the
>>> concerns of multicasts consuming mobile device battery life.)
>>>
>>>
>>>>>
>>>>> router, multicast solicited RAs might make a significant
>>>>> portion of your traffic - which, due to a difference in
>>>>> modulation, etc.  may eat way more bandwidth than if they
>>>>> were sent unicast."
>>>>>
>>>>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think
>>>>> if a link  can't handle 1 multicast every few seconds, it's
>>>>> also past the point
>>>> of
>>>>> it's capacity (and as above, other multicast/broadcast would
>>>>> also be contributing to exceeding link capacity.)
>>>>
>>>> Modulation. Your multicast packets may take in the most extreme
>>>> case 54x time more airtime than a unicast. This means 54x more
>>>> probability it will be dropped. Also, forget the home wireless
>>>> with one AP. Now imagine 300-500 APs having to send these
>>>> packets. You have 3 frequencies on 2.4Ghz spectrum that you can
>>>> use. So remembering that the whole construct is 3D, you are
>>>> *bound* to have some interference.
>>>>
>>>
>>> Are all of those 300-500 APs in a single broadcast/multicast
>>> domain i.e., one large link? That's convenient, but if
>>> multicasts/broadcasts aren't reliable enough, that suggests the
>>> link capacity is exhausted. Dividing the link up using routers to
>>> reduce multicast/broadcasts is and has been the common solution
>>> since broadcast multiaccess links were invented (which I think
>>> would be since around late 1970s when Ethernet was invented).
>>>
>>> Moving to an NBMA model by effectively modelling the BMA link as
>>> a full mesh of virtual point-to-point links would probably be an
>>> alternative method of overcoming multicast/broadcast capacity
>>> limitations.
>>>
>>>> And again, I want the protocol to be deployable in the most
>>>> extreme cases - especially when legacy IP survives them fine.
>>>>
>>>
>>>> But dismissing those cases just because they do not apply to
>>>> one's environment is incorrect.
>>>>
>>>> And this is to me the whole point of the argument, which I
>>>> would like to get back to, instead of trying to argue about the
>>>> details:
>>>>
>>>> Yes, RA-only operation is *fantastic* for some circumstances. I
>>>> love it myself and do it whenever I can because this allows me
>>>> to avoid doing boring work.
>>>>
>>>> But I may be forced to do DHCPv6. For any of the reasons
>>>> already present in the draft, pick one. And this means I am
>>>> forced to do also RA, which is a pain.
>>>>
>>>
>>> reliable than RAs, given that it too uses multicasts for DHCPv6
>>> server discovery. Adding RA functions into DHCPv6 is described or
>>> asserted to be the panacea to all issues that RAs could suffer
>>> from, yet analysis shows it isn't.
>>>
>>> - I think it would be better to incrementally tune and optimise
>>> the existing designed, standardised, code developed, code
>>> debugged and widely deployed mechanism (RAs) to overcome corner
>>> cases, and/or to adopt past developed methods such as IPv6 over
>>> NBMA, than to spend the next 5 to 10 years waiting for the
>>> design, standardisation, code development, code debugging and
>>> widespread deployment of RA functions to be incorporated into
>>> DHCPv6, and then also have to develop methods of conflict
>>> resolution when RAs and DHCPv6 options disagree (because they
>>> will, unless you don't plan to transition to DHCPv6 only until
>>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions
>>> will have to co-exist on a link for many years if you can't
>>> demand or guarantee DHCPv6 RA functionality from the host
>>> implementations.)
>>>
>>> - Using DHCPv6 for RA functionality won't eliminate one of the
>>> supposed causes of RA unreliability - multicast unreliability.
>>> All of DHCPv6, neighbor discovery and MLD would have to be made
>>> more robust against multicast unreliability to truly solve that
>>> problem.
>>>
>>> - I'm for a single method that works adequately. DHCPv6 with RA
>>> options would probably qualify if we didn't already have a
>>> existing method. Existing methods that work are always better
>>> than non-existent ones that need to be developed, tested and
>>> ubiquitously deployed before they become significantly useful and
>>> can be assumed to be available.
>>>
>>>
>>>> I think the large part of the tussle comes from the people
>>>> wanting to make the functionality of the RA/DHCPv6 more
>>>> symmetric and being told "no".
>>>>
>>>
>>> The thing they need to demonstrate is that the costs of deploying
>>> a new and second mechanism that is near functionally equivalent
>>> to the first is worth the benefits. Given that the costs of
>>> developing and deploying RAs has already been paid, I think the
>>> benefits of using DHCPv6 for RA functions have to be very
>>> significant before the price should be paid. The benefits of
>>> DHCPv6 for RA functions now needs to be compelling. I don't think
>>> they are, otherwise I'd be quite happy to advocate for DHCPv6 for
>>> RA functions.
>>>
>>>
>>>> "fine, I choose no IPv6". And keep stacking on these NATs to
>>>> support devices that "do not support IPv6" in that
>>>> circumstances.
>>>>
>>>
>>> deploying IPv6 at all. I think some people are resisting
>>> deploying IPv6 because it needs to do one or both of two things
>>> for them - solve a foreseeable problem that will effect them, or
>>> provide a tangible benefit. If it won't do either of those
>>> things, then they don't currently see any value from the effort
>>> involved. What are foreseeable problems or tangible benefits is
>>> completely up to the perspective of the decision maker.
>>> Eventually they'll see value in it, and deploy it. In some cases,
>>> some people who could deploy IPv6 may never see any value in
>>> deploying it, so they never will.
>>>
>>> IPv6, no single solution, and things that motivate people to
>>> deploy or not IPv6 may have nothing to do with how IPv6 itself
>>> works.
>>>
>>>
>>>
>>>> of "the best solution" instead of trying to collect the
>>>> properties of the RA and DHCP.
>>>>
>>>> preaching for everyone to adopt the single solution which is
>>>> the best in one scenario and suboptimal in the other, we should
>>>> be engineering a way to be able to apply different solutions in
>>>> different circumstances without the overhead of double work.
>>>>
>>>
>>> A single solution that solves most cases is better than two
>>> different, near functionally equivalent solutions that solve the
>>> same cases. Multiple near-equivalent solutions create more code,
>>> more bugs and then require conflict resolution mechanisms,
>>> creating even more code and more bugs, with very little actual
>>> benefit.
>>>
>>> discovery/host parameter configuration problem (read Radia
>>> Perlman's "Interconnections" book as a starting point, and then
>>> perhaps "Inside Appletalk", and also look into Novell's IPX and
>>> Network Directory Services.). They all have different trade-offs,
>>> but fundamentally the trade-offs aren't significantly different
>>> or compelling. Yet because there are multiple methods to solve
>>> these problems, does that justify implementing all of them
>>> because they each have some minor benefits over the others, that
>>> Regards, Mark. _______________________________________________
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Dec 2013 10:15:13 +0100

Le 07/12/2013 20:56, Andrew Yourtchenko a écrit :
>> discovery. Adding RA functions into DHCPv6 is described or asserted to
>> be the panacea to all issues that RAs could suffer from, yet analysis
>> shows it isn't.
>
>> supposed causes of RA unreliability - multicast unreliability. All of
>> DHCPv6, neighbor discovery and MLD would have to be made more robust
>> against multicast unreliability to truly solve that problem.
>
> Gee, we are stuck on the strawman ureliability - there are *other*
> reasons why one would want to use DHCP, thus being forced to run
> multiple protocols.
>
>>
>> options would probably qualify if we didn't already have a existing
>> method. Existing methods that work are always better than non-existent
>> ones that need to be developed, tested and ubiquitously deployed
>> before they become significantly useful and can be assumed to be
>> available.
>>
>>
>> The thing they need to demonstrate is that the costs of deploying a
>> new and second mechanism that is near functionally equivalent to the
>> first is worth the benefits. Given that the costs of developing and
>> deploying RAs has already been paid, I think the benefits of using
>> DHCPv6 for RA functions have to be very significant before the price
>> should be paid. The benefits of DHCPv6 for RA functions now needs to
>> be compelling. I don't think they are, otherwise I'd be quite happy to
>> advocate for DHCPv6 for RA functions.
>
> For some, the benefit would be significant. For some - it won't be any
> benefit at all.

I agree.  This is a good double point that deserves being mentioned.

Alex

>> deploying IPv6 at all. I think some people are resisting deploying
>> IPv6 because it needs to do one or both of two things for them - solve
>> a foreseeable problem that will effect them, or provide a tangible
>> benefit. If it won't do either of those things, then they don't
>> currently see any value from the effort involved. What are foreseeable
>> problems or tangible benefits is completely up to the perspective of
>> the decision maker. Eventually they'll see value in it, and deploy it.
>> In some cases, some people who could deploy IPv6 may never see any
>> There is no single answer to why people might resist deploying IPv6,
>> no single solution, and things that motivate people to deploy or not
>> IPv6 may have nothing to do with how IPv6 itself works.
>>
>>
>>
>> Multiple near-equivalent solutions create more code, more bugs and
>> then require conflict resolution mechanisms, creating even more code
>> and more bugs, with very little actual benefit.
>>
>> implementing all of them because they each have some minor benefits
>> over the others, that different people might prefer?
>
>>
>> Regards,
>> Mark.
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Dec 2013 10:16:13 +0100

> close to their desired or valid timers.

Or if they are getting close (as in geographical vicinity) to a Router 
that they know it must be there...

Alex

>>> From: Bernie Volz (volz) <[email-masked]> To: Owen DeLong
>>> <[email-masked]> Cc: Mark ZZZ Smith <[email-masked]>;
>>> Andrew Yourtchenko (ayourtch) <[email-masked]>;
>>> "[email-masked]" <[email-masked]> Sent: Saturday, 7 December 2013
>>> 1:25 PM Subject: RE: [v6ops] New Version Notification for
>>> Yes, I am aware of that - unicast RA from the router to the
>>> client is available. Just isn't clear now often it is used.
>>>
>> As a router would have knowledge of the hosts it has sent unicast
>> RAs to via its neighbor cache, for the purposes of NUD, a router
>> could periodically unicast RAs directly to the individual hosts.
>>
>>
>> Regards, Mark.
>>
>>
>>> - Bernie
>>>
>>>
>>>> fewer
>>> problems in some networks because the first hop is typically on
>>> the wired portion of the network (and the destination multicast
>>> address is usually just joined by a few devices (relays and
>>> servers) - not all).
>>>
>>>> distributing the
>>> Clients starting up (and/or a client whose address is close to
>>> its lifetime) send an RS message to a multicast group joined by
>>> only a few. There are no "hops" because this is all link-local
>>> communication.
>>>
>>> DHCPv6 per your comments above, while also providing the
>>> additional robustness you already attributed to
>>> all-hosts-multicast periodic RAs from the routers.
>>>
>>> Owen
>>>
>>>>
>>>> - Bernie
>>>>
>>>> [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
>>>> Sent: Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko
>>>>>> be beneficial - on a crowded large-scale WiFi, without
>>>>>> special
>>> tricks
>>>>>> to  ensure the reliable delivery of multicast packets, you
>>>>>> simply will not  get the SLAAC working because the
>>>>>> multicast RAs will get crunched by the  interference." I'd
>>>>>> think that if multicast is unreliable enough to cause RAs
>>> to
>>>>>> fail  to be delivered often enough, then anything which
>>>>>> relies on multicast  traffic is also likely to fail, which
>>>>>> would include
>>> neighbor discovery.
>>>>>> So regardless of if RAs were replaced with DHCPv6, the link
>>>>>> is not going  to provide reliable IPv6 operation, because
>>>>>> IPv6 addresses cannot be  reliably resolved to layer 2
>>>>>> addresses.
>>>>>>
>>> applications,
>>>>>> even  low bandwidth ones, wouldn't work either, as would
>>>>>> MLD snooping based  layer 2 forwarding optimisation.
>>>>>>
>>> would
>>>>> for (1): RA is probably the only one that does not
>>>>> incorporate a robust retransmit mechanism.
>>>>>
>>>>
>>>> reliability
>>>> AdvDefaultLifetime
>>> or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a
>>> host to lose knowledge of a router it has to miss 3 unsolicited
>>> multicast RAs in a row.
>>>>
>>>> robust, as
>>> they only implement the second mechanism. For DHCPv6, neighbor
>>> discovery and MLD to be as robust as RAs, the DHCPv6 server and
>>> the hosts would have to also issue periodically unsolicited
>>> announcements of themselves so that other hosts and routers don't
>>> have to solicit for them, unless they have no existing knowledge
>>> of them.
>>>>
>>>> make it
>>> more robust? ES-IS has hosts periodically multicast their
>>> work in
>>>> in all
>>> conditions. Given that DHCPv6 server discovery is less reliable
>>> than RAs (because of the lack of unsolicited DHCPv6 server
>>> advertisements), how is moving RA functions into DHCPv6 going to
>>> make DHCPv6 more reliable than RAs?
>>>>
>>> link
>>>>>> on the  link are RAs, providing the necessary NBMA
>>>>>> operation
>>> parameters.
>>>>>> It of  course would require changes to clients and routers,
>>>>>> but
>>> then
>>>>> except for the RS and NS sent to solicited node address of
>>>>> the router + destined to the
>>> router.
>>>>>
>>>> exhaustion
>>> problems that would effect RA multicasts (and DHCPv6, ND and MLD
>>> multicasts), because it is a more extreme case of constraining
>>> where multicasts are sent than MLD snooping.
>>>>
>>>> be better to just adopt this complete NBMA model over a BMA
>>>> link and eliminate all link-layer multicasts (ND, DHCPv6, MLD),
>>>> except RAs to announce the BMA link is operating in NBMA mode.
>>>> The only multicasts would be unsolicited RAs, which, for a
>>>> single router, could be only once every 30 minutes (15 minutes
>>>> for two routers). I'd think that sort of interval would be
>>>> adequate to address the concerns of multicasts consuming mobile
>>>> device battery life.)
>>>>
>>>>
>>>>>>
>>>>>> portion
>>>>>> eat way more bandwidth than if they were sent unicast."
>>>>>>
>>> if a
>>>>>> link  can't handle 1 multicast every few seconds, it's
>>>>>> also
>>> past the
>>>>>> point
>>>>> of
>>> also be
>>>>> Modulation. Your multicast packets may take in the most
>>>>> extreme case 54x time more airtime than a unicast. This means
>>>>> 54x more probability it will be dropped. Also, forget the
>>>>> home wireless with one AP. Now imagine 300-500 APs having to
>>>>> send these packets. You have 3 frequencies on 2.4Ghz spectrum
>>>>> that you can use. So remembering that the whole construct is
>>>>> 3D, you are *bound* to have some interference.
>>>>>
>>>>
>>>> domain i.e.,
>>> one large link? That's convenient, but if multicasts/broadcasts
>>> aren't reliable enough, that suggests the link capacity is
>>> exhausted. Dividing the link up using routers to reduce
>>> multicast/broadcasts is and has been the common solution since
>>> broadcast multiaccess links were invented (which I think would
>>> be since around late 1970s when Ethernet was invented).
>>>>
>>> mesh of virtual point-to-point links would probably be an
>>>>> would like to get back to, instead of trying to argue about
>>>>> the details:
>>>>>
>>>>> Yes, RA-only operation is *fantastic* for some circumstances.
>>>>> I love it myself and do it whenever I can because this allows
>>>>> me to avoid doing boring work.
>>>>>
>>>> supposed
>>> causes of RA unreliability - multicast unreliability. All of
>>> DHCPv6, neighbor discovery and MLD would have to be made more
>>> robust against multicast unreliability to truly solve that
>>> problem.
>>>>
>>>> options
>>> would probably qualify if we didn't already have a existing
>>> method. Existing methods that work are always better than
>>> non-existent ones that need to be developed, tested and
>>> second mechanism that is near functionally equivalent to the
>>> first is worth the benefits. Given that the costs of developing
>>> and deploying RAs has already been paid, I think the benefits of
>>> using DHCPv6 for RA functions have to be very significant before
>>> the price should be paid. The benefits of DHCPv6 for RA functions
>>> now needs to be compelling. I don't think they are, otherwise I'd
>>> be quite happy to advocate for DHCPv6 for RA functions.
>>>>
>>>>
>>> support
>>>> resisting
>>>> IPv6, no
>>> single solution, and things that motivate people to deploy or not
>>>>> I think in this discussion are again getting into the
>>>>> argument of "the best solution" instead of trying to collect
>>>>> the
>>> properties of
>>>>> the RA and DHCP.
>>>>>
>>> preaching
>>>>> for everyone to adopt the single solution which is the best
>>>>> in one scenario and suboptimal in the other, we should be
>>>>> engineering a way to be able to apply different solutions in
>>>> different, near
>>> functionally equivalent solutions that solve the same cases.
>>> Multiple near-equivalent solutions create more code, more bugs
>>> and then require conflict resolution mechanisms, creating even
>>> more code and more bugs, with very little actual benefit.
>>>>
>>>> list [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 9 Dec 2013 02:41:24 -0800 (PST)

>________________________________
> From: Owen DeLong <[email-masked]>
>Cc: Andrew Yourtchenko <[email-masked]>; Bernie Volz (volz) <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, 9 December 2013 4:20 PM

The knobs are still there, they're called static configuration.

>It’s not hard at all. All you have to do is put a router on the network that is connected away from, instead of towards the internet and voila, you have arguably “wrong” RAs.

If I understand your scenario, the RAs are right, it is the route table in the router that is broken (or rather, the upstream network is partitioned). I don't see how putting default router information in DHCPv6 is going to prevent the same problem, or lessen the effects of it. Chances are it might increase the likelihood of issues, because it is one more thing for humans to get wrong when they enter it into their DHCPv6 server.

However, this discussion is only about how hosts learn their default gateway/router information, not whether once the packets make it to the router they can be forwarded by the routing domain to their destination successfully.

>This won’t usually break anything because redirects usually work and even if they don’t, you just put unnecessary load on the network and the router that can’t forward the packets. However, if that…

There are a few ways of resolving this.

Firstly, the routers on the link could be trading routing information using e.g, OSPF via the link the hosts are attached to if that is the only way the two separate upstream networks are interconnected.

Secondly, one of the routers could have a High RA preference (RFC4191), and then that router has static routes towards the prefixes behind the other routers. Having the other routers continue to announce lower preference RAs means that if the High preference router fails, hosts still have a level of reachability to the prefixes behind the remaining routers.

Finally, some level of routing information could be pushed to the hosts so they pick the correct first hop router. RAs support providing this information via the Route Information Option (RFC4191).

There are VRRP options too, however I've limited the above to what can just be done with RAs.

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 9 Dec 2013 06:49:10 -0800

> The knobs are still there, they're called static configuration.

I didn’t mean to imply that the knobs weren’t there. Indeed, RAs have a very large number of knobs for such a lightweight protocol and DHCPv6 has even more.

> If I understand your scenario, the RAs are right, it is the route table in the router that is broken (or rather, the upstream network is partitioned). I don't see how putting default router informa…

No, the route table in the router is not broken, it just doesn’t have a default route to the upstream routers. There are a number of situations where this could even be desirable (for example, the systems on the back-end network behind this third router are not supposed to send/receive from
networks beyond the LAN in question).

I’m not saying that it does. I’m saying that RAs from routers don’t necessarily guarantee that the routers are telling the truth. Not all routers are valid default route candidates.

However, the current IPv6 implementations seem to assume that they are.

The point is that while RA can be easier and more reliably accurate than routing information from DHCPv6 in many scenarios, this is not necessarily always true. Adding the equivalent of RIOs to DHCPv6 would be harmless to those who wish to use only RAs while allowing operators to choose the solution that works best for them.

> However, this discussion is only about how hosts learn their default gateway/router information, not whether once the packets make it to the router they can be forwarded by the routing domain to th…

Yes, but if hosts are learning default routers that aren’t good candidates for that function, one could make the argument that such a scenario is not desirable.

> Firstly, the routers on the link could be trading routing information using e.g, OSPF via the link the hosts are attached to if that is the only way the two separate upstream networks are interconn…

Which results in the redirects and hair pinning described in my paragraph you are claiming this solution resolves.

> Secondly, one of the routers could have a High RA preference (RFC4191), and then that router has static routes towards the prefixes behind the other routers. Having the other routers continue to an…

Which takes you back to fiddling knobs and the potential for human error in the configuration process.

> Finally, some level of routing information could be pushed to the hosts so they pick the correct first hop router. RAs support providing this information via the Route Information Option (RFC4191).

Which also requires fiddling the knobs and re-inserting the potential for human error.

> There are VRRP options too, however I've limited the above to what can just be done with RAs.

I wasn’t trying to put this forward as an insurmountable problem. I was just pointing out that RAs are not a panacea solution to all possible problems associated with routing information from DHCP.

Owen

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Dec 2013 15:59:54 +0000

Hi, all RAs on ISATAP links are unicast and, in spite of my best efforts
to bring it into the specs the operation of DHCPv6 over ISATAP links is
undefined. And, as I said several days ago, unicast RAs can deliver
different information to different clients.

Thanks - Fred

---

From: Ray Hunter <[email-masked]>
Date: Tue, 17 Dec 2013 08:48:08 +0100

Andrew Yourtchenko wrote:
> aims to compare RAs with DHCPv6 which emerged from the discussion on
I think the draft will be useful if

1) it allows an operator to make an informed choice

2) it identifies areas for future work

With that in mind

for 1) As a general remark after reading the comments to the list so
far, there seems to be an underlying assumption that there's only one
way to run a network, and that the infrastructure stack of Hosts/ LAN /
MAN/ WAN/ DHCPv6/ DNS/ IPAM / Printers are all run by a single
authority, and thus integration and change costs are effectively zero.

IMHO "all combinations are possible" as used in an advert by a local
supermarket. These infrastructure elements are usually run on behalf of
a single authority in my experience, but if your LAN routers are not run
by the same people as your IPAM and DNS, you might well want to make
different trade offs with respect to what information is communicated by
RA and what by DHCPv6, and what requests are relayed to a central
instance and what is configured in a distributed manner on the local boxes.

I think the pure technical discussions miss the impact on the management
model mentioned in 2.10.

I'd like to see an addition of some sample management models, where the
infrastructure is run by different parties (this is v6ops after all).
e.g. if you can set up your LAN routers to set up their interfaces using
PD (with all information loaded from IPAM) plus a couple of DHCPv6 relay
commands for the rest (also potentially loaded/learned from IPAM) I
could imagine considerable costs savings in large environments. Whereas
in a highly distributed environment, IPAM may not even make any sense at
all, and local configuration via RA and local config files only might be
extremely useful and cost effective. Provisioning is a major network cost.

However that choice in turn is likely to impact the ease of renumbering
in the future (a major bugbear of IPv4). It will also impact what
protocols a travelling end node will have to support (code bloat).

2) I also think the areas of future work would be filled quicker if we
examine the alternative approaches, and filled in the complete picture.

So I'd suggest we look at the complete end to end picture needed to roll
out and support the following combinations

a) Central model: everything configured centrally as far as possible,
with zero configuration information that is likely to change stored
locally (configure local LAN switch once and forget, plus central IPAM
DNS etc. for changes)
You'll then hit the "How does an end node learn a default route?" and
thus "how does the RA daemon learn it's prefix information?" type questions
Think Meraki cloud controlled devices.

b) Distributed model: everything configured locally on the local LAN
switch or router (no IPAM required)
You'll then hit the "how is DNS updated?" type questions.

c) download model: hosts actively grab an XML file via HTTP for their
"extended" configuration (or use AD).

d) stand alone (disconnected) model: there is no router.
You'll then hit the "How do I elect a DNS server?" and "why not use
zeroconf?" type questions

There is considerable overlap here with Homenet....... although the
focus could be specifically on address assignment and the interactions
between end nodes and routers.

-- 
Regards,
RayH

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 17 Dec 2013 10:45:37 +0000 (WET)

Thanks for the insight!

inline.

> protocols a travelling end node will have to support (code bloat).

I had just removed the entire management section, so this would be for the 
potential future.

I am welcoming the texts describing the operational models that people use 
which I can include as an issue for now, for later, when the "semantics" 
are done.

> zeroconf?" type questions

This looks like two pairs across two independent axis ? (a-b, c-d) ?

Also: if there's no router, there's no communication beyond the link.

> between end nodes and routers.

There were two goals:

1) "what are the inherent protocol properties of RA vs. DHCP"
2) "what to extend for new functionality, RA vs. DHCP ?"

With the assumption the (1) would help to understand (2) better. Maybe.

Now, looking at a-d above, I wonder whether the "new functionality" needs 
to be more tightly bound as a prerequisite to even (1).

If I were writing a new app, I'd certainly try to avoid both RA and
DHCP, in lieu of the download or zeroconf. If I am writing the new 
L3 protocol that needs to be provisioned - this is when I would start to 
consider "RA vs. DHCP".

--a

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 18 Dec 2013 19:18:49 +0000

> I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's pretty trivial if you know enough to tune them properly.

Speaking as a pretty random individual.

First, I don't think that the statement "they never will" holds. They indeed never will while the equation remains the same - IPv6 costs them something and doesn't give them a measurable ROI, or enough of one. The premise of an adoption curve is that the equation indeed changes - the cost of not deploying eventually exceeds the cost of deploying, and as a result people deploy. The question here is not the current state, it's the eventual state. The data tells me that the equation is slowly changing. If we don't believe that, we're all wasting our time.

As to the RA vs DHCP dispute, I think it's largely religious. If you live in, or choose to live in, an RA/SLAAC world, and the information elements in the RA meet your needs, by all means use it. If DHCP does something an RA doesn't, and your network needs it, you're going to use DHCP for at least that purpose. To the extent they are functionally interchangeable  - you can get an address from either, or advertise the address of the DNS server, or etc -  its the cook's choice. 

The primary argument for the RA, from my perspective, is that it identifies a preferred router on a LAN for a prefix that it is advertising, and in the unusual case in which a large number of devices simultaneously join a subnet (such as when the subnet is first turned up or a network is renumbered), or if some other attribute needs to be assigned to every device on a LAN in multicast fashion, it has improved scaling characteristics. The primary argument for DHCP is control - you can say what you mean to an individual system and have that not need to be the same as you say to another, and if you have a requirement to know for sure what system is using what address (for example for Source Address Verification), you own the table.

If it's your network, it will be about the policies your network follows. There is no inherently "right" answer about policy, and as a result there is no inherently "right" answer about the implementation of policy.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Dec 2013 12:46:41 -0800 (PST)

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: Owen DeLong <[email-masked]>; Andrew Yourtchenko (ayourtch) <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Thursday, 19 December 2013 6:18 AM
> First, I don't think that the statement "they never will" holds. 
> They indeed never will while the equation remains the same - IPv6 costs them 
> something and doesn't give them a measurable ROI, or enough of one. The 
> premise of an adoption curve is that the equation indeed changes - the cost of 
> not deploying eventually exceeds the cost of deploying, and as a result people 
> deploy. The question here is not the current state, it's the eventual state. 
> The data tells me that the equation is slowly changing. If we don't believe 
> that, we're all wasting our time.
> 
> As to the RA vs DHCP dispute, I think it's largely religious. If you live 
> in, or choose to live in, an RA/SLAAC world, and the information elements in the 
> RA meet your needs, by all means use it. If DHCP does something an RA 
> doesn't, and your network needs it, you're going to use DHCP for at 
> least that purpose. To the extent they are functionally interchangeable  - you 
> can get an address from either, or advertise the address of the DNS server, or 
> etc -  its the cook's choice. 
> 
> The primary argument for the RA, from my perspective, is that it identifies a 
> preferred router on a LAN for a prefix that it is advertising, and in the 
> unusual case in which a large number of devices simultaneously join a subnet 
> (such as when the subnet is first turned up or a network is renumbered), or if 
> some other attribute needs to be assigned to every device on a LAN in multicast 
> fashion, it has improved scaling characteristics. The primary argument for DHCP 
> is control - you can say what you mean to an individual system and have that not 
> need to be the same as you say to another, and if you have a requirement to know 
> for sure what system is using what address (for example for Source Address 
> Verification), you own the table.
> 
> If it's your network, it will be about the policies your network follows. 
> There is no inherently "right" answer about policy, and as a result 
> there is no inherently "right" answer about the implementation of 
> policy.

I'd suggest the above statement is really "If it's your network and hosts, it will be about the policies your network and hosts follows." I'm sure hosts were implied, however this issue very much depends on host implementations and host feature deployment, so I think it is worth specifically calling the hosts out.  

The trouble is that the rapid rise of the BYOD/"cloud computing"/smartphone/tablet model means that hosts and their IPv6 stack implementation capabilities are rapidly becoming less controlled and less able to be dictated by the people operating the network, in networks where this level of control is currently even  possible. I think we're seeing the split between who operates the hosts and who operates the network significantly and rapidly widen.

So the network operator might want to only use DHCPv6 for everything, but if they need to facilitate connectivity for even just one host that comes along that doesn't support DHCPv6 for everything, they'll need to continue to provide and support RAs too. I think that means RAs will need to exist for at least 5 or perhaps 10 years for those networks where "DHCPv6 for everything" is the goal.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 18 Dec 2013 22:56:40 +0000

On 18/12/2013 19:18, Fred Baker (fred) wrote:
> As to the RA vs DHCP dispute, I think it's largely religious. If you
> live in, or choose to live in, an RA/SLAAC world, and the information
> elements in the RA meet your needs, by all means use it. If DHCP does
> something an RA doesn't, and your network needs it, you're going to use
> DHCP for at least that purpose. To the extent they are functionally
> interchangeable  - you can get an address from either, or advertise the
> address of the DNS server, or etc -  its the cook's choice.

Fred,

The single protocol barrier which stops me in theory from being able to
completely remove RAs from my networks is dhcpv6 default gateway option.

I understand that there are several other things that RA also handles, but
defgw is sine qua non.  I can live with /64 + 1500mtu everywhere, but it's
not possible to have a functional auto-configured network without a default
gateway option.

Several IDs have been put forward to remedy this, but they were shot down
not on any real technical basis but because of opinion.

I understand that some people feel that there should be no gateway option
in DHCPv6, and I respect that.  But conversely, I would ask them to respect
my opinion that on my networks, RAs add nothing except complication.  I do
not want SLAAC anywhere, and if I had a way of turning RAs off, I would do
so tomorrow morning.

But because of the sustained objections of a small number of people, I do
not have this option.

I dearly want to run a simpler network because simplicity is a sound
engineering design goal.  It's incredibly frustrating to have to run an
entire extra protocol on my networks in order to provide a single
auto-configuration option which could just as easily be supplied by dhcp.

How can we fix this?

Nick

---

From: Tore Anderson <[email-masked]>
Date: Thu, 19 Dec 2013 00:10:49 +0100

* Nick Hilliard

> The single protocol barrier which stops me in theory from being able
> to completely remove RAs from my networks is dhcpv6 default gateway
> option.
> 
> I understand that there are several other things that RA also
> handles, but defgw is sine qua non.  I can live with /64 + 1500mtu
> everywhere, but it's not possible to have a functional
> auto-configured network without a default gateway option.

Hi Nick,

If you want (on-link) /64 routes to be signaled by DHCPv6 you need
another (currently nonexistent, ttbomk) option for that as well. IA_NA
leases are single address and do not imply any on-link prefixes. See RFC
5942 section 5.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 18 Dec 2013 23:38:10 +0000

On Dec 18, 2013, at 3:10 PM, Tore Anderson <[email-masked]>
 wrote:

> another (currently nonexistent, ttbomk) option for that as well.

Does that translate to "what is my prefix length" or some variation on that theme?

---

From: Tore Anderson <[email-masked]>
Date: Thu, 19 Dec 2013 00:47:35 +0100

* Fred Baker (fred)

> Does that translate to "what is my prefix length" or some variation on that theme?

Yes. The only way to signal an on-link prefix to hosts is the Prefix
Information Option in RA (with L=1), as far as I know. So if Nick wants
"/64 everywhere", DHCPv6 isn't sufficient, even if it did include the
default gateway option he wanted.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Dec 2013 00:28:48 +0000

> default gateway option he wanted.

and perhaps more to the point, if he wants "/65 in domain X and /63 in domain Z"...

So your argument would be that he needs both a default gateway and a prefix length. Is there anything else he needs?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Dec 2013 00:30:54 +0000

> auto-configuration option which could just as easily be supplied by dhcp.

This time wearing the hat that looks like a chair...

Per charter, we're allowed to file internet drafts and send them (in what any other SDO would call a "liaison") to working groups like 6man or whatever, tell them their stuff is busted, and ask them to fix it. Imagine just for fun we had a draft that said, in essence, "aw cm'on guys, fix this", gave requirements ("we want to operate without the periodic RA and to do that need ..."), listed the drafts that had proposed a fix, and asked the relevant working group to spruce one of them up to spec and adopt it? Imagine, God help us, that it even had implementation experience behind it - "we prototyped the bits and pieces we needed and found that we could in fact live without the RA".

We'd have to have consensus behind the draft, of course. That implies a discussion, potentially in London. Is that anywhere near Ireland?

Do you know anyone that might be willing to write that draft - and then contribute to the work in whatever-working-group that would actually address this?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Dec 2013 10:34:16 +0900

> not on any real technical basis but because of opinion.

Can we stop flogging this dead horse please? This keeps getting proposed,
every time in a different working group, and keeps failing to achieve
consensus. It's a huge waste of time.

I understand that you think that opinion is not a valid reason, but I would
like to point out that yours is also an opinion. Yes, DHCPv6 allows you to
configure more options than RAs, but it's also less flexible in some ways
(e.g., doesn't support load-balancing over multiple routers, doesn't easily
support deprecation, etc.). So I think it's clear that one is not
necessarily better than the other.

I understand the point of view "this is MY network, and in MY network, I
want to use DHCPv6 ONLY", but remember that in many cases, the hosts that
connect to your network are the same hosts that connect to other networks,
and those host implementers probably also only want to reduce the number of
scenarios they support.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 18 Dec 2013 17:50:07 -0800

> First, I don't think that the statement "they never will" holds. They indeed never will while the equation remains the same - IPv6 costs them something and doesn't give them a measurable ROI, or en…

Yep.

> As to the RA vs DHCP dispute, I think it's largely religious. If you live in, or choose to live in, an RA/SLAAC world, and the information elements in the RA meet your needs, by all means use it. I…

I think the idea of “RA vs. DHCP” is absurd, at least without major changes to the current protocol specifications.

The current set of choices is {RA, RA+DHCP, Link-Local-Only, Static}.  As such, railing against RAs makes very little sense to me, but if there is a legitimate argument for a use case where autoconf with DHCP and no RAs, then I’d like to know more about that use case so we might better address it. So far,  the “we want to be able to eliminate RAs from our network” camp hasn’t yet responded with such details.

Owen

---

From: Tore Anderson <[email-masked]>
Date: Thu, 19 Dec 2013 09:37:42 +0100

* Fred Baker (fred)

> and perhaps more to the point, if he wants "/65 in domain X and /63 in domain Z"...

Indeed. Any onlink prefix, regardless of length, can only be signaled by
RA/PIO today.

> So your argument would be that he needs both a default gateway and a prefix length. Is there anything else he needs?

While I can't speak for Nick, it would appear to me that with those two
options available in DHCPv6, one would have the basic functionality
needed to operate a network without RAs. So yes, I think so.

If the host implementations support it, that is. Which might be a very
big "if" indeed.

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Dec 2013 11:09:17 +0100

Le 19/12/2013 09:37, Tore Anderson a écrit :
> Indeed. Any onlink prefix, regardless of length, can only be signaled
> by RA/PIO today.

I agree.  It is not signalled by DHCP, nor by other ICMP messages.  The
prefix length is needed in many cases, such as onlink determination (to
determine whether to send NS to a /128 multicast address prior to
sending the packet, or otherwise send the packet to the default router),
or for DAD which is optional in many cases.

That does not mean one could not live without signalling the prefix
length to the node.

In a simple spartan step signalling the default route would be
sufficient because that will prime over all other entries in the Default
Router List and in the routing table because of its default prefix
length 0 which is special.

That default router would subsequently ICMP Redirect the Host which is
itself a /128 entry in the routing table which would fit longest prefix
match and all other failed.

The subsequent NS/NA for that /128 address does not need any prefix
length in its message fields.

>> So your argument would be that he needs both a default gateway and
>> a prefix length. Is there anything else he needs?
>
> While I can't speak for Nick, it would appear to me that with those
> two options available in DHCPv6, one would have the basic
> functionality needed to operate a network without RAs. So yes, I
> think so.

I would not oppose that combined need.

Alex

>
> If the host implementations support it, that is. Which might be a
> very big "if" indeed.
>
> Tore _______________________________________________ v6ops mailing

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 12:57:02 +0000

> necessarily better than the other.

I'm not claiming that RAs are better than DHCPv6 or the other way around.
If you want to run only SLAAC or benefit from any of the features of
RAs+SLAAC, then that's great and I'm very happy for you.

I'm just stating that for my deployment scenarios, I specifically do not
want the extra stuff that RAs/SLAAC provide like load-balancing over
multiple routers, deprecation of defgws, multiple networks/gateways per l2
domain and all that.

On the other hand, I need to run DHCPv6 because RAs do not provide me with
the technical knobs that I need.  These include address assignment (rather
than slaac), and other dhcp-only knobs.

In this context, RAs serve only to provide defgw and (as Tore kindly
reminded me) prefix assignment, and then hand everything off to DHCPv6.

Leaving aside the operational issues associated with running separate
configuration on separate systems for the same end goal of
autoconfiguration, from a protocol simplicity point of view, this approach
is not very sensible because, we have an entire protocol dedicated to
handling something that with a modest amount of effort could probably be
handled by dhcpv6.

I'm sorry you feel this is a dead horse.  My take is that if we're
designing a protocol which has an expected lifetime of $manyyears, then
protocol simplicity should be high on the list.  Given the amount of recent
noise on this list discussing the interaction between RA+DHCP, it's
abundantly clear that simplicity has been lost in favour of confusion.
Simplicity is a critically important design goal for anything related to
engineering, and the old maxim is true: "everything should be kept as
simple as possible, but no simpler".

If possible, I'd really like if we could have a non-heated discussion about
the technical pros and cons of whether standalone DHCPv6 is viable.

I know that for my use cases, it would be a highly desirable endpoint, but
I understand that other people have different deployment requirements.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Dec 2013 22:40:27 +0900

> simple as possible, but no simpler".

But what you propose is not simple. In fact, far from it. What you propose
requires a DHCPv6 server that's always up and perpetually maintains state,
and it requires that you run VRRP between the routers because DHCPv6. If
you were designing a system from the ground up I'd wager you'd never design
it like that. So why do it like that, then? Because "we already run DHCPv6
for other reasons, so let's just use it"? Isn't that a bit of a sunk cost
fallacy?

> the technical pros and cons of whether standalone DHCPv6 is viable.

Oh, it is viable. We know it works - after all, we do it in IPv4. It works
well, because in IPv4 we have VRRP, things don't change often, and we have
NAT. But many people feel that this time around we can do better than that.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Dec 2013 08:43:58 -0500

On Dec 19, 2013, at 8:40 AM, Lorenzo Colitti <[email-masked]> wrote:
> What you propose requires a DHCPv6 server that's always up and perpetually maintains state, and it requires that you run VRRP between the routers because DHCPv6.

Hm, would VRRP help us with the homenet problem?

;)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Dec 2013 22:47:15 +0900

On Thu, Dec 19, 2013 at 10:43 PM, Ted Lemon <[email-masked]> wrote:

> > What you propose requires a DHCPv6 server that's always up and
> perpetually maintains state, and it requires that you run VRRP between the
> routers because DHCPv6.
>

Sure! That's the DHCP way. Make the configuration procotol completely
static, then realize that failures cause outages, and then be build
redundancy into your services because you've chosen a client communication
protocol that doesn't allow updates. Awesome :-)

I always think that the biggest lie in DHCP is that D at the beginning.
It's not dynamic. It should have been called SHCP. :-)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Dec 2013 09:05:01 -0500

On Dec 19, 2013, at 8:47 AM, Lorenzo Colitti <[email-masked]> wrote:
> Sure! That's the DHCP way. Make the configuration procotol completely static, then realize that failures cause outages, and then be build redundancy into your services because you've chosen a client communication protocol that doesn't allow updates. Awesome :-)

I was being slightly ironic, but also sort of serious, in the sense that the thing you are saying DHCP fails at, that requires additional complexity, is essentially the same problem as needs to be addressed for homenets: how to do routing when there's more than one default router.   Although in a _very limited_ sense this is solved in the single-homed dual-router RA case, the problem as a whole is unsolved.   If it were solved, we would not need VRRP in the dual-router single-home single-failure case.

I'm not saying we should try to solve it here, merely pointing out that the case you are making has wider implications, and that in fact even with RA, your hosts will be happier if you are running VRRP during the outage scenario you describe.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Dec 2013 23:10:48 +0900

On Thu, Dec 19, 2013 at 11:05 PM, Ted Lemon <[email-masked]> wrote:

> I'm not saying we should try to solve it here, merely pointing out that
> the case you are making has wider implications, and that in fact even with
> RA, your hosts will be happier if you are running VRRP during the outage
> scenario you describe.
>

In homenet, what needs to be solved that can't be solved with fast NUD
timers and RAs from multiple routers. You don't need subsecond convergence
in the home, right?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Dec 2013 09:21:24 -0500

On Dec 19, 2013, at 9:10 AM, Lorenzo Colitti <[email-masked]> wrote:
> In homenet, what needs to be solved that can't be solved with fast NUD timers and RAs from multiple routers. You don't need subsecond convergence in the home, right?

If a neighbor goes down, there's up to roughly a 30-second delay before failing over to the other router.   That's pretty slow—not slow enough to kill a TCP connection, but slow enough that I will already have assumed my video stream has failed.

Also, we aren't talking about "in the home" in Nick's case.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 14:34:18 +0000

> Also, we aren't talking about "in the home" in Nick's case.

no, I'm talking about datacentre deployments, although the principals are
also applicable to corporate / campus / enterprise networks where many
operators that I know would frankly prefer not to have client devices make
up their own minds about how to handle the connectivity that's provided to
them.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 14:46:47 +0000

On 19/12/2013 13:40, Lorenzo Colitti wrote:
> and it requires that you run VRRP between the routers because DHCPv6.

Probably I'm not alone in considering dhcp servers to be critical to a
functional DHCP based network.  But as I said, I need DHCPv6 anyway and
things will break if it's not available.

Re: FHRPs, they have very predictable and stable failover characteristics
and in the many years that I've been using them, they've performed
incredibly well.  As I said, if you want to use gateway deprecation on your
networks, I'm happy for you, but I don't want to use this feature because
its technical characteristics are not as consistent as FHRPs, nor as fast
for handling failover.

> If you were designing a system from the ground up I'd wager you'd never
> design it like that. So why do it like that, then?

Can we stick to technical discussion?

> Because "we already
> run DHCPv6 for other reasons, so let's just use it"? Isn't that a bit of
> a sunk cost fallacy?

It's a sunk cost reason, not a sunk cost fallacy, and it's only one reason
out of several I don't want RAs on my network.  Please let's stick to
technical discussion rather than advocacy.

> NAT. But many people feel that this time around we can do better than that.

I have looked at RA/SLAAC and its technical characteristics do not suit my
use cases.  Can you accept this and that I actually understand the
differences between SLAAC, stateful configuration via dhcp and what each
brings to the table, and that I still do not want SLAAC anywhere because it
doesn't work for me?

I'm ok about the fact that it may work very nicely for you.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Dec 2013 01:25:41 +0900

On Thu, Dec 19, 2013 at 11:46 PM, Nick Hilliard <[email-masked]> wrote:

> functional DHCP based network.  But as I said, I need DHCPv6 anyway
> and things will break if it's not available.
>

Fine, but please don't say it's simpler. It's not - it has way more moving
parts.

> Can we stick to technical discussion?

We can, but it won't get us anywhere. You've said that you want to run your
network with DHCPv6 because RAs don't suit your requirements, and I'll say
that I want to run my network with RAs because DHCPv6 doesn't suit my
requirements. We will both have valid reasons, and probably we'll even
concede that in each other's networks the other's solution might be better.

But once we reach that point, we're still stuck. Because the only way
forward from there is to conclude that we need to define two completely
autonomous and competing systems to provision the same protocol on the same
host implementations, and choose one or the other depending on the
deployment scenario. This is a bad outcome, because hosts that want to work
everywhere (and what host doesn't?) need to implement both protocols. The
resulting complexity - which is more than 2x, because in addition to the
two protocols you have to define and implement rules to deal with their
interaction - pushes costs up for everyone, because everyone uses hosts,
including me and you.

That's why I say this is a dead horse - because there *is* no single
technically correct answer. The community has been through this exercise
many times. People who want to put routing in DHCP and people who don't
have had arguments in several working groups, each time with no conclusion,
resulting in a waste of everyone's time. Let's not repeat that, because it
isn't really in anybody's interest.

Instead, what we can do is document the semantic differences and properties
of the two protocols. After that, what we might be able to do is get
consensus on criteria for what should go into RA and into DHCPv6 in the
future. I think those are much mpre useful goals to pursue.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 17:15:18 +0000

> Fine, but please don't say it's simpler. It's not - it has way more moving

No, actually it has a choice of moving parts and creating a priority
mechanism for selecting one over the other is actually simpler than
defining an interaction mechanism between the two.

> concede that in each other's networks the other's solution might be better.

exactly.

> deployment scenario. 

yes, that is the conclusion I have come to too.  And you know what?  It's
actually not a bad solution.

> This is a bad outcome, because hosts that want to work

at the moment we have a mess which seems to work for some people but not
others, and which people have been complaining about loudly since the day
that dhcp became viable.

> technically correct answer.

exactly, which is why I think we need to acknowledge that it would be
better for everyone to come to some conclusion to this mess.  Let the
people who want to use and develop SLAAC do what they want to the protocol
and let the people who want to use and develop DHCPv6 do what they want.
We can put in an arbitration mechanism relatively easily.

I completely agree that these endless arguments are stupid.  But they will
continue until the heat death of the universe, or until we come to a
decision to split off the two protocols - whichever comes sooner.

Nick

---

From: Gert Doering <[email-masked]>
Date: Thu, 19 Dec 2013 19:00:01 +0100

Hi,

On Thu, Dec 19, 2013 at 02:34:18PM +0000, Nick Hilliard wrote:
> no, I'm talking about datacentre deployments, 

I wonder why one would use DHCP in the datacentre?

My servers do not rely on anyone else to tell them their network
config (well, actually they rely on the provisioning system, but that's
"semi-static" and reboot-safe).

For servers, relying on something that might not available after 
something unexpected, like "power outage", but which is otherwise 
completely unnecesarry to fulfill their role seems... surprising.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 18:08:51 +0000

> I wonder why one would use DHCP in the datacentre?

ease of rollout, centralised management, etc.  Tends to help when you have
nontrivial numbers of vms in place.

Nick

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 19 Dec 2013 12:19:15 -0800 (PST)

> From: Lorenzo Colitti <[email-masked]>
>To: Nick Hilliard <[email-masked]> 
>Sent: Friday, 20 December 2013 3:25 AM
>>functional DHCP based network.  But as I said, I need DHCPv6 anyway and things will break if it's not available.
>>
>
>
>Fine, but please don't say it's simpler. It's not - it has way more moving parts.
> 
>We can, but it won't get us anywhere. You've said that you want to run your network with DHCPv6 because RAs don't suit your requirements, and I'll say that I want to run my network with RAs because DHCPv6 doesn't suit my requirements. We will both have valid reasons, and probably we'll even concede that in each other's networks the other's solution might be better.
>
>
>But once we reach that point, we're still stuck. Because the only way forward from there is to conclude that we need to define two completely autonomous and competing systems to provision the same protocol on the same host implementations, and choose one or the other depending on the deployment scenario. This is a bad outcome, because hosts that want to work everywhere (and what host doesn't?) need to implement both protocols. The resulting complexity - which is more than 2x, because in addition to the two protocols you have to define and implement rules to deal with their interaction - pushes costs up for everyone, because everyone uses hosts, including me and you.
>

I agree with this. Removing RAs and replacing them with DHCPv6 from a network might appear to be reducing complexity, but it is only really shifting it and creating more. Host and router implementations become more complex because they'd be expected to support both; during a transition period both methods need to be enabled and supported; network design decisions become more complex because a choice will usually have to be made as to which method to support, perhaps involving a survey of host capabilities; and troubleshooting becomes more complex because there is a chance of disagreement when both RAs and DHCPv6 are run concurrently.

I'd also question the criteria of "one protocol" being a goal. If RAs are to be shifted into DHCPv6 to achieve this goal, why isn't ND and MLD also proposed to be moved into DHCPv6? If the problems are different enough, different protocols are created. If the problems are similar enough, they're solved with a single protocol.

I consider RAs to be solving the problem of link specific layer 3 configuration, and DHCPv6 to be solving the problem of layer 4 and more often higher application oriented configuration. A very good reason (perhaps the primary?) to create two protocols is so that one can be replaced without impacting the other (which is why I think DNS in RAs and IPv6 addressing in DHCPv6 are mistakes). If an alternate application configuration protocol is developed, DHCPv6 can be replaced without disrupting layer 3 configuration. 

>
>That's why I say this is a dead horse - because there *is* no single technically correct answer. The community has been through this exercise many times. People who want to put routing in DHCP and people who don't have had arguments in several working groups, each time with no conclusion, resulting in a waste of everyone's time. Let's not repeat that, because it isn't really in anybody's interest.
>
>
>Instead, what we can do is document the semantic differences and properties of the two protocols. After that, what we might be able to do is get consensus on criteria for what should go into RA and into DHCPv6 in the future. I think those are much mpre useful goals to pursue.
>

I put some text in my "DHCPv6 option transparency" draft which I think would be useful in pursuing that goal. I described why I think the network needs to be application configuration transparent, and therefore why a DHCPv6 client/server in the network model reduces transparency. Further layer 4+ parameters in RAs have the same problem.

"Internet Transparency and Application Configuration"
http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 19 Dec 2013 21:51:01 +0100

* Nick Hilliard

> nontrivial numbers of vms in place.

Indeed. We use DHCP extensively in our data centres. Provisioning OS
onto the servers we do with network boot. This is much more convenient
than physical media or, worse, remote media (which usually depends on
some Java hocus pocus that works correctly only during an eclipse and so
on), and mindlessly clicking through an install wizard N times.

One variant of the above that we've grown more and more fond of in
recent years is to have stateless servers without disks that *always*
boot off the network. They install the OS onto a RAM disk, registers
with Puppet and installs whatever applications they need and are ready
to go within minutes. This is especially nice for running applications
that can automatically scale horizontally onto whatever compute
resources are available. Think for example hypervisors, HPC nodes, and
such. An application needs more capacity? No problem: plug in a dozen
servers, turn them on, and they're all up and running, in production,
within 15 minutes with no human interaction necessary beyond the
physical part. It's a wonderful way to work, tbh, and it all relies 100%
on DHCP.

Unfortunately, it's all DHCP*v4*. Hardly any server manufacturer is
shipping units that can do IPv6 network booting, it's the 3Com PXE ROM
from, what, 2001? they're all shipping still. This is perhaps the
largest impediment to IPv6 deployment I'm dealing with on a day-to-day
basis. Getting improvement here would be way more valuable to IPv6
deployment than continued bickering of whether it is RA or DHCPv6 that
is the dog's bollocks....

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Dec 2013 10:21:13 +1300

On 20/12/2013 05:25, Lorenzo Colitti wrote:
...
> future. I think those are much mpre useful goals to pursue.

This is exactly what we need the document under discussion to do.
No opinions, no judgments - just document the facts. Somebody can draw
the Venn diagram afterwards, and then (and only then) we can tackle
the question of what the Venn diagram *should* be.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Dec 2013 22:03:17 +0000

On 19/12/2013 20:19, Mark ZZZ Smith wrote:
> I agree with this. Removing RAs and replacing them with DHCPv6 from a
> network might appear to be reducing complexity, but it is only really
> shifting it and creating more. Host and router implementations become
> more complex because they'd be expected to support both; during a
> transition period both methods need to be enabled and supported; network
> design decisions become more complex because a choice will usually have
> to be made as to which method to support, perhaps involving a survey of
> host capabilities; and troubleshooting becomes more complex because
> there is a chance of disagreement when both RAs and DHCPv6 are run
> concurrently.

Yes, it shifts some complexity, reduces a pile more in the long term, but
doesn't create a significant quantity of new complexity because it's not
that difficult to create an arbitration mechanism to handle how things
should be handled on the host side.  The state diagram for this is not very
large, tbh.  Have you drawn it out?

> I'd also question the criteria of "one protocol" being a goal. If RAs
> are to be shifted into DHCPv6 to achieve this goal, why isn't ND and MLD
> also proposed to be moved into DHCPv6?

This is a straw man argument and a rather poor one.  ND is concerned with
l3 address to mac layer address mapping and is a separate problem domain.
I don't know why you think that MLD is similar enough in function to DHCP
that you're mentioning them in the same sentence as potential candidates
for functionality merging.

RAs and dhcpv6 are both concerned with host auto-configuration.  We have a
single protocol in ipv4 which provides a superset of the equivalent
functionality of dhcpv6 and enough of the functionality of RAs to reliably
provide network connectivity and many people consider this a good thing.
Also...

> If the problems are different
> enough, different protocols are created. If the problems are similar
> enough, they're solved with a single protocol.

... this is my point: DHCPv6 is exactly two options away from being
independent of RAs to the point that it would be entirely usable in many
situations.  This is because problem domains are substantially the same, as
indicated by the fact that dhcpv4 covers all one, the intersection between
the two and a chunk of what RAs add.

> I consider RAs to be solving the problem of link specific layer 3
> configuration, and DHCPv6 to be solving the problem of layer 4 and more
> often higher application oriented configuration.

And I consider having two protocols to handle the job of one to be poor
quality protocol design, regardless of the best intentions of the people
who designed it like this.

Now we have a deployment / operational mess on our hands which people have
been complaining about for years and will continue to complain about until
it's fixed.  Maybe you don't consider it to be a mess, but I do and a lot
of other people do - people who have complained loudly about it over the
years and whose positions were, well, ignored.  Whether you like it or not,
it is a problem which will not go away by pretending it doesn't exist.

> A very good reason
> (perhaps the primary?) to create two protocols is so that one can be
> replaced without impacting the other (which is why I think DNS in RAs
> and IPv6 addressing in DHCPv6 are mistakes). If an alternate application
> configuration protocol is developed, DHCPv6 can be replaced without
> disrupting layer 3 configuration.

This is actually a complete non-argument.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Thu, 19 Dec 2013 15:28:45 -0800

> handling something that with a modest amount of effort could probably be

First, auto configuration is not really one end goal. There are elements of
auto configuration which are host-specific (system) configuration and
elements which are network topology (routing) configuration. 

Host-specific configuration includes DNS Resolvers, NTP servers, Boot
file servers, boot file names, Host DNS information (DDNS), and more.

Network topology information includes default gateway, other more specific
routes, routing metrics, and more.

Addresses themselves are kind of the merge point of these two aspects of
configuration and that’s one of the reasons that addresses themselves may
be assigned by SLAAC, DHCPv6, or possibly both in some scenarios.

Additionally, RA/RS and SLAAC are not a separate protocol unto themselves.
They are specific messages within the Neighbor Discovery Protocol which
also includes NA/NS messages. Are you also arguing that you want your
DHCP server to provide the IP->MAC address translation table? If not, then
you aren’t able to turn off the entire protocol that RS/RA are part of anyway
and the horse is basically dead.

> abundantly clear that simplicity has been lost in favour of confusion.

I think most of the confusion is not so much because simplicity is lost, but,
because people are arguing about how they think things should be done instead
of listening to each other about how they are actually done.

As I have said, I favor adding the extensions you want to DHCP, but, I do think
it is somewhat fool hearty to use them and I do not advocate making RS/RA
optional parts of the neighbor discovery process. In fact, I think routers should,
by default, emit useful RS/RA messages and it should take configuration effort
to turn them off. On a host, it should also take configuration effort to get the
host not to send RS messages. Further, I’m not sure how you propose for a
host which knows nothing to know that it needs to ask for DHCP information
without first getting an RA that says so. I really don’t favor the complexity of
“Ask for configuration from every possible mechanism and see what sticks”.
That would make things much more complicated than the current scenario.

> simple as possible, but no simpler”.

For the flexibility provided, I believe that the current protocol design actually
provides a high degree of simplicity. However, it definitely needs to be better
documented and much less ambiguously specified. It really would be helpful
if this group would focus on achieving that before trying to make a bunch of
changes to it.

> the technical pros and cons of whether standalone DHCPv6 is viable.

I don’t think my comments have been at all heated and I think Lorenzo’s were
pretty measured as well. However, while I think standalone DHCPv6 could be
made viable, I do not think it would aid in your stated goal of protocol simplicity,
nor do I believe that it would be beneficial in any way.

> I understand that other people have different deployment requirements.

Correct me if I’m wrong, but you have to configure at least one router on every
subnet in your deployment with an IPv6 address and prefix length.

Is it really that hard to add the one line that gives you the M-bit?

After that, everything else goes in DHCPv6 where you want it.

Where’s the unnecessary complexity? The host knows it needs to grab an RA
when it wakes up to find out about what to do next. When it gets the M-bit, it
knows it needs to do DHCP and it does that. The router tells the host about things
that the router knows best and the DHCP server tells the host about the things
the DHCP server knows best. This seems much simpler than having to tell the
DHCP server every time you change the address of a router or replace a router
or…

Owen

---

From: [email-masked]
Date: Fri, 20 Dec 2013 14:42:18 +0100 (CET)

> and the horse is basically dead.

Speaking only for myself - I want the ND part of the protocol to be used
by default. I absolutely do *not* want routers to send RA by default. (I
do not want the DHCP server to deal with the IP->MAC address translation 
table.)

At least one router manufacturer (Juniper) has made the operationally
useful choice (to me, at least) of having ND turned on by default when
an interface is configured with an IPv6 address, while RA must be turned
on by explicit configuration. Thank you Juniper!

And the horse is not dead yet...

Steinar Haug, AS 2116

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Dec 2013 16:29:38 +0000

> Where's the unnecessary complexity? The host knows it needs to grab an RA
> or...

I agree with that, plus the DHCP server may be far away from the link
in some backhaul network where it has more global knowledge while the
router is on the link where it may have only localized knowledge. Let
DHCP servers do what DHCP servers do, and let routers do what routers do.

Fred