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

[Alexandru Petrescu <[e-mail]>]

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