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

[Alexandru Petrescu <[e-mail]>]

Le 07/12/2013 22:05, Owen DeLong a écrit :
> 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.

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

Alex

>
> Owen
>
> On Dec 6, 2013, at 19:10 , Mark ZZZ Smith <[e-mail]>
> wrote:
>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Bernie Volz (volz) <[e-mail]> To: Owen DeLong
>>> <[e-mail]> Cc: Mark ZZZ Smith <[e-mail]>;
>>> Andrew Yourtchenko (ayourtch) <[e-mail]>;
>>> "[e-mail]" <[e-mail]> Sent: Saturday, 7 December 2013
>>> 1:25 PM Subject: RE: [v6ops] New Version Notification for
>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>>>
>>> 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.
>>>
>>
>> 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
>>>
>>>
>>> -----Original Message----- From: Owen DeLong
>>> [mailto:[e-mail]] Sent: Friday, December 06, 2013 9:07 PM
>>> To: Bernie Volz (volz) Cc: Mark ZZZ Smith; Andrew Yourtchenko
>>> (ayourtch); [e-mail] Subject: Re: [v6ops] New Version
>>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>>> (fwd)
>>>
>>>
>>> On Dec 6, 2013, at 17:25 , Bernie Volz (volz) <[e-mail]>
>>> wrote:
>>>
>>>> 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).
>>>
>>> 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
>>>
>>>>
>>>> - Bernie
>>>>
>>>> -----Original Message----- From: v6ops
>>>> [mailto:[e-mail]] On Behalf Of Mark ZZZ Smith
>>>> Sent: Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko
>>>> (ayourtch) Cc: [e-mail] Subject: Re: [v6ops] New Version
>>>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>>>> (fwd)
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Andrew Yourtchenko <[e-mail]> To: Mark ZZZ
>>>>> Smith <[e-mail]> Cc: "[e-mail]"
>>>>> <[e-mail]> Sent: Saturday, 7 December 2013 3:34 AM
>>>>> Subject: Re: [v6ops] New Version Notification for
>>>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> Yes.
>>>>
>>>>> 2) Fix your link.
>>>>>
>>>>> 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.
>>>>
>>>> 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.).
>>>>
>>>>
>>>>> 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?
>>>>
>>>>> 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?
>>>>
>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> 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.)
>>>>
>>>>
>>>>>>
>>>>>> "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.)
>>>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> How does it? Legacy IP uses broadcasts.
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>> 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.
>>>>
>>>>
>>>>> 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 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.
>>>>
>>>>
>>>>
>>>>> 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 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. _______________________________________________
>>>> v6ops mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> _______________________________________________ v6ops mailing
>>>> list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>