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

Tao Sun <hisuntao@gmail.com> Mon, 26 March 2012 12:22 UTC

Return-Path: <hisuntao@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83F921F8715 for <mif@ietfa.amsl.com>; Mon, 26 Mar 2012 05:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN1ypX0fxqj1 for <mif@ietfa.amsl.com>; Mon, 26 Mar 2012 05:22:57 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 485EF21F8724 for <mif@ietf.org>; Mon, 26 Mar 2012 05:22:57 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2990918vbb.31 for <mif@ietf.org>; Mon, 26 Mar 2012 05:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ndPdrzrkzhgGzlGQTPWaeXDuE7ih6N21cikbDb3lIU=; b=BEzsGO5Q2Y7Qm0M6hS11tlBiY1IVPvP/rPNcoTS/j9Qltt2GSWLkRlj41n3TUDWi6q rAm2yj0MnHq56uoz4Wm44Fzyrsg0D9KFP/aC8Ff80/yFkb9bSMhZdYN+FCrod9HPCoyU nUYgMdr154olSuaiOG6f+wAkWTHsaBYO6XYRHpxLjoPm9awumpjkJLRds+sMJmeUvUv1 QPmJhP2lLGW6uTPy7JrpWSiQWsi0P/deKkHHmJAhMd+uBMlEGtxPSsY7Kchg5o+nhPAg LLC9U+oTV73d4OKnIq4P1SANbjgKFKu9eEYyy0siyDoPByQ6v1UUdKTOhGn3d62DwYbN FYPA==
MIME-Version: 1.0
Received: by 10.52.93.138 with SMTP id cu10mr8373354vdb.86.1332764576745; Mon, 26 Mar 2012 05:22:56 -0700 (PDT)
Received: by 10.220.183.3 with HTTP; Mon, 26 Mar 2012 05:22:56 -0700 (PDT)
In-Reply-To: <CAAedzxqSPqPp1f34Z1Fm1h87mOB0aESfivZQMZmYAh7DNLv1ZQ@mail.gmail.com>
References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <CAAedzxqSPqPp1f34Z1Fm1h87mOB0aESfivZQMZmYAh7DNLv1ZQ@mail.gmail.com>
Date: Mon, 26 Mar 2012 20:22:56 +0800
Message-ID: <CA+H2C9aNoRhTXNU5o1kQF663e0eqW_PuVrpDTgssyORi1auq6w@mail.gmail.com>
From: Tao Sun <hisuntao@gmail.com>
To: Erik Kline <ek@google.com>
Content-Type: multipart/alternative; boundary="20cf307cfeaa2a87a304bc246fbb"
Cc: mif@ietf.org
Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 12:22:58 -0000

Hi Erik,



Thanks for the review. I would like to clarify for your comments on [3.1-4].

The link to 3GPP TR23.853 is a technical report for a R11 work item. The
work item is not finished due to time limits of R11 in 3GPP.

You may see that there are 3 scenarios agreed and documented in the TR.
This draft refers the TR for the *Scenario* justification. On the *solution
mechanism*, the TR listed some related work which includes this draft.

The references are not circular since they are from different aspects.



Regards,



Tao


On Mon, Mar 26, 2012 at 2:31 AM, Erik Kline <ek@google.com> wrote:

> >> 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.
>
> 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).
>  _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>