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 >
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- [mif] I-D Action: draft-ietf-mif-dhcpv6-route-opt… internet-drafts
- [mif] draft-ietf-mif-dhcpv6-route-option-04 publi… Tomek Mrugalski
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Brian E Carpenter
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Ted Lemon
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Ted Lemon
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Erik Kline
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Tao Sun
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Erik Kline
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Marc Blanchet
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Marc Blanchet
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Lorenzo Colitti
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Ted Lemon
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Alexandru Petrescu
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Ted Lemon
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Brian E Carpenter
- Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 p… Paul Ebersman