Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

[Alexandru Petrescu <[e-mail]>]

Le 25/03/2012 20:31, Erik Kline a écrit :
>>> Motivation and uses cases are now significant part of this draft
>>>  itself. If the group believes that it would be cleaner, it may
>>> be split into separate draft. But please, don't use this
>>> possibility as a way to delay this work. There are many networks
>>> that want this option deployed asap.
>
> With respect to motivations...I think we need to weed out all the
> specious ones first, to what's really left and worthy of interest.
> IMHO, most, if not all, are specious.  (And I suspect that Suresh's
> Line-ID may be useful to address whatever else is left.)
>
> [3.1-1]
>
> "and the Service Provide would like to avoid routing on the CPE,
> there is a need to provision static route entries on RGs/CPEs"
>
> I read this as "we don't want to do routing so here's how we're going
> to do routing".  If it's dynamic versus static, then saying that
> might be more clear.
>
> [3.1-2]
>
> Is there an external source for this claim?  It is not at all the
> case for the two large IPv6 deployments with which I've been directly
> involved. Furthermore, the current deployments to O(millions) of
> existing IPv6 users make it seem like this isn't actually an issue.
>
> [3.1-4]
>
> Perhaps this has been discussed elsewhere, and I'm out of my depth,
> but I thought DHCPv6 wasn't really spec'd until R10, and even then
> only DHCPv6-PD.
>
> It looks to me like the 3GPP link goes to a draft for R11.
> Additionally, this 3GPP draft seems to reference this MIF draft. This
> makes it look like the references are circular (you can't cite IDs),
> which is a bad justification.
>
> [3.1-6]
>
> The thing about these walled-garden arguments is that they seem to
> imply that deployments don't want to give a route to a walled-garden
>  network to non-customers.  But surely the existence of a route is
> not alone sufficient for valid access?
>
> IOW, is there harm if a non-customer has a route a walled-garden
> network of which they are not a customer?  Unless the walled-garden
> is advertising a default route, I wonder what the real harm is.

Allow me to take advantage of this conversation to mention that this
brings up another issue.

When setting up routes one would like to make sure they're right and
they lead somewhere at least most of the time.  At the smart end node
and dumb network, there should always exist a fallback and that fallback
is typically the default route ("when everything else fails").

In this sense, if the end node sets up its routes with DHCP, it would
like to be sure they're right most of the time, otherwise use the
default route.

But when the default route _and_ the other more specific routes are
provided by DHCP, and if failing, then there is a risk of misconfiguration.

Something that could be done about this is the use of different Types in
DHCP (ORO) for specific routes and a different Type for default routes.
  This would mean not only that the config file owuld have different
sections for default routes vs specific routes (thus guide  the Server's
administrator to double check the default part) but also the DHCP Client
implementation to have separate software sections for specific routes vs
default routes.  Some lighter DHCP Clients may choose to implement
_only_ the default route option part (and not the specific route part).

With respect to this there was also a question about compliance with
specs - if a stack doesn implement eg ICMP Redirect then it's not
compliant.  Do we want to ensure the same level of strength in
compliance with DHCP?   Even for low end devices?

Alex

>
> But a potentially more important consideration is why walled garden
> arguments appear anywhere within a Motivation section.  Quoting from
>  the IAB in 2000, section 4.2.1 of RFC3002
> (http://tools.ietf.org/html/rfc3002#section-4.2):
>
> """ It was strongly recommended that independent of the ubiquity of
> the "walled garden" deployment scenario that protocols and
> architectural decisions should not target this model.  To continue
> the success of Internet protocols at operating across a highly
> diverse and heterogeneous environment the IETF must continue to
> foster the adoption of an "open model".  IETF protocol design must
> address seamless, secure, and scalable access. """
>
> In the spirit of the above, I would like to see all discussion
> pertaining to walled gardens unequivocally removed. This removes at
> least use cases 1, 6, and 8.
>
> [3.1-7]
>
> Do you have any metrics on the support situation WRT 4191?  Both
> DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434),
> and both are pretty old by now (from 2005?).
>
> [3.1-10]
>
> s/home network with/home networks/, I think
>
> I think the "solve the rogue RA problem" is not a valid argument.
> You're just trading a rogue RA problem for a rogue DHCPv6 server
> problem.  You can claim some security association with the DHCPv6
> server, but you can equally claim some security association with the
>  router(s) (e.g., SEND).
>
> Also, I think this is specious:
>
> "forced to run two protocols increasing complexity and
> troubleshooting, where we have proof of concept in IPv4 that only one
> protocol (DHCP) should be needed."
>
> In networks where you want run reliable IPv4, you still need 2
> protocols: DHCPv4 and VRRP.  Just because they're operated by two
> different groups doesn't mean you don't need them both.
>
> [3.1-11]
>
> If this is a use case that is not "investigated further" then I would
> question why it's needed at all in what is fundamentally a
> "Motivation" discussion.  It also seems circular to propose as a
> motivation that the option be used to break a tie when the option is
>  coexisting with RAs.
>
> [3.1-12]
>
> I'm not sure that a "different failure mode" is much of a
> motivation.
>
> I would take exception with a claim like a "rogue DHCP server will
> cause no immediate harm".  If someone gives me different DNS servers
>  they can still hijack all my traffic.  Only in this case I think
> it's even worse: I am aware of no provision in DHCP for the real
> server to send out messages that can nullify the bad information.
> Once a host is misconfigured that's pretty much it until the lease
> lifetime is up or a network change event happens.
>
> [3.1-concluding paragraphs]
>
> I disagree with the assertion "It is better to have a generic option
>  then [sic] a bunch of competing vendor options".  *IF* the decision
> of the IETF is that this constitutes a "You're Doing It Wrong (TM)"
> situation, then NO, a standardized option is not better; it would in
>  fact send the opposite message.  Also, like Microsoft's RADIUS
> extension for DNS servers, I don't think you would see multiple
> competing definitionsーthe first to publish would become the de facto
>  standard.
>
> Fundamentally, I think the core issue to be decided is whether there
>  should be a standardized way for hosts on the same network to learn
>  different routes from their neighbors.  I would think this
> constitutes a fundamental architectural change, and therefore ought
> to be considered in 6man (regardless of history and charters).
>