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

[Alexandru Petrescu <[e-mail]>]

Le 05/12/2013 15:40, Andrew Yourtchenko a écrit :
> Thanks a lot for the comments!
>
> inline...
>
> On Thu, 5 Dec 2013, Alexandru Petrescu wrote:
>
>> 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),
>
> What about Rapid Commit ? I was under impression there you can do the
> 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.

>> whereas a DAD-less operation would be a single RA
>> message (forgetting the initial MLD 'join').
>
> 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.

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.

> (I
>
>>
>>> 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).
>>
>
> 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).

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

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

I agree.

>>> 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
>
> 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 think the PD RFC defines a Delegating Router to be a DHCP Server, and 
then only talks DR.

> I will try to reflect this somehow, created the
> https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks!
>
>>
>>> 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.
>
> Yes, it is almost un-edited copy-paste from the emails, with ultra-light
> editing for the first pass.
>
>>
>> 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).
>
> 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.

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

>
> I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6.
>
> --a
>
>>
>> Alex
>>
>> Le 27/11/2013 14:06, Andrew Yourtchenko a écrit :
>>> 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: [e-mail] To: Andrew Yourtchenko
>>> <[e-mail]> 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 [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>
>>