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

[Alexandru Petrescu <[e-mail]>]

Le 05/12/2013 17:24, Andrew Yourtchenko a écrit :
[...]
>> 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).

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.


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

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

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

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

Anyways, your draft is right.

Alex

>
>>
>>> (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.
>>
>
> 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.
>
>>>> 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.
>
> Ah, ok I missed that. So, indeed there *are* cases that "router==dhcp
> server".
>
>>
>>> I will try to reflect this somehow, created the
>>> https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks!
>>>
>
> [snip]
>
>>>> 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
>
> Thanks!
>
>>>    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      |
>>  -------------------+-------------+-------------+
>>
>
> Makes sense. I've added this into the "issue" and will XMLify / add
> reference later.
>
> Thanks a lot!
>
> --a
>
>
>> 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
>>>>>
>>>>>
>>>>
>>>>
>>
>>