Re: Lack of responses on WG Last Calls
JP Vasseur <jpv@cisco.com> Thu, 17 March 2011 18:07 UTC
Return-Path: <jpv@cisco.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A2E3A6ADD for <ipv6@core3.amsl.com>; Thu, 17 Mar 2011 11:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.511
X-Spam-Level:
X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rZ8pY6GHaV9 for <ipv6@core3.amsl.com>; Thu, 17 Mar 2011 11:07:08 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B6FD33A6A04 for <ipv6@ietf.org>; Thu, 17 Mar 2011 11:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=9761; q=dns/txt; s=iport; t=1300385317; x=1301594917; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=wMkCkT+u2D6rI5ZPCp32TRgSMcHkoBjFsH/0JlW1GnQ=; b=MY1Iv3ftRdvv/XuWywW1UbSQpwaPgPRCDSlGKcEIJr6A6OSJH0cdxqd6 TI67ZVZ6u9g5a6Z4S4CKbrp93yzbsStETY5cGLqZ7I6RIUOfORsf3SWU/ 7p2W1sT8Sg60juEwcfvsmBzZ4vCYSqGNlELngEH9hQBWFB9prEyPrL3O1 Y=;
X-IronPort-AV: E=Sophos; i="4.63,200,1299456000"; d="scan'208,217"; a="415495150"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2011 18:08:35 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HI88Gb014367; Thu, 17 Mar 2011 18:08:35 GMT
Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 11:08:33 -0700
Received: from [10.2.59.95] ([10.21.76.250]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Mar 2011 11:08:32 -0700
Subject: Re: Lack of responses on WG Last Calls
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-134--44434350"
From: JP Vasseur <jpv@cisco.com>
In-Reply-To: <80CC860A-8625-4B27-89F8-3C5DB1FAF538@cisco.com>
Date: Thu, 17 Mar 2011 11:08:32 -0700
Message-Id: <93C139AA-66C1-437A-A5D0-1B7EAAA686BB@cisco.com>
References: <4D0AA2CE.8000604@gmail.com> <80CC860A-8625-4B27-89F8-3C5DB1FAF538@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1082)
X-OriginalArrivalTime: 17 Mar 2011 18:08:32.0839 (UTC) FILETIME=[53AC5570:01CBE4CE]
Cc: Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2011 18:07:10 -0000
Dear Brian, Many thanks for your review. We addressed your comment in the new revision, just posted. Kind Regards. JP. > > From: Brian E Carpenter <brian.e.carpenter@gmail.com> > > Date: December 16, 2010 3:37:50 PM PST > > To: Brian Haberman <brian@innovationslab.net> > > Cc: IPv6 WG Mailing List <ipv6@ietf.org> > > Subject: Re: Lack of responses on WG Last Calls > > > > For my sins, I was the Gen-ART reviewer for the main RPL spec, > > so I was able to have a quick glance at these without being > > completely mystified. > > > > On 2010-12-17 02:53, Brian Haberman wrote: > >> All, > >> Working group last calls ended 10 days ago for the two RPL-related > >> drafts (draft-ietf-6man-rpl-option > > > > This looks basically OK to me. However: > > > >> 9. IANA Considerations > >> > >> The RPL option requires an IPv6 Option Number. > > > > Shouldn't we have a "TBD" here, as used in the main text? > > And an instruction to the RFC Editor to resolve the TBD > > after IANA performs the assignment. > > > >> > >> HEX act chg rest > >> --- --- --- ----- > >> 1 01 1 01011 > >> > >> > >> The first two bits indicate that the IPv6 node MUST discard the > >> packet if it doesn't recognize the option type, and the third bit > >> indicates that the Option Data may change en-route. > >> > >> This document also creates a new IANA registry for the sub-TLVs. No > >> sub-TLVs are defined in this specification. The policy for this > >> registry [RFC5226] is IETF Review. > > > > I think the IANA will ask for a bit more guidance about the format > > and name of this registry. > > > > and > >> draft-ietf-6man-rpl-routing-header). > > > > This defines a new routing header called RH4 (subject to > > IANA confirming the "4"). One question that comes to mind > > is whether this is going to cause more or fewer operational > > difficulties than an instantiation of draft-ietf-6man-exthdr > > would. Will legacy nodes treat RH4 as they should (discard the > > packet), treat it like RH0 due to sloppy coding (which > > amounts to the same thing under RFC5095) or what? Anyway, > > it seems clear that RH4 will not successfully cross any > > non-RPL-aware routers. > > > > Now this may be deemed irrelevant because RH4 is "for use > > strictly within a RPL domain." But it seems highly likely that > > in practice, the odd non-RPL router will see one of these > > headers. So at the least, I think the draft should discuss > > what will happen in that case, even if only to point out that > > the rules of RFC 2460 mean that the packet (not just the header) > > will be dropped unless Segments Left is zero. > > > > Then: > > > >> 6.1. Source Routing Attacks > >> > >> [RFC5095] deprecates the Type 0 Routing header due to a number of > >> significant attacks that are referenced in that document. Such > >> attacks include network discovery, bypassing filtering devices, > >> denial-of-service, and defeating anycast. > >> > >> Because this document specifies that Type 4 Routing headers are only > >> for use within a RPL domain, such attacks cannot be mounted from > >> outside the RPL domain. As described in Section 5, RPL Border > >> Routers MUST drop datagrams entering or exiting the RPL domain that > >> contain a Type 4 Routing header in the IPv6 Extension headers. > > > > OK, but that implies that such attacks can still be mounted inside the > > RPL domain. How is that OK, given that ROLL may be deployed in highly > > dynamic scenarios where roaming nodes drop into a network at will? > > > > Brian > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >
- Lack of responses on WG Last Calls Brian Haberman
- RE: Lack of responses on WG Last Calls Don Sturek
- Re: Lack of responses on WG Last Calls Brian E Carpenter
- Re: Lack of responses on WG Last Calls Fred Baker
- RE: Lack of responses on WG Last Calls Don Sturek
- Re: Lack of responses on WG Last Calls Fred Baker
- Re: Lack of responses on WG Last Calls Thomas Narten
- Re: Lack of responses on WG Last Calls Fred Baker
- Re: Lack of responses on WG Last Calls Thomas Narten
- Re: Lack of responses on WG Last Calls Bob Hinden
- Re: Lack of responses on WG Last Calls Bob Hinden
- Re: Lack of responses on WG Last Calls Don Sturek
- RE: Lack of responses on WG Last Calls Don Sturek
- Re: Lack of responses on WG Last Calls JP Vasseur