Complementary angles

This event will feature the following complementary a= ngles:

= Interoperation
Demonstration

Tools

Focus 1: Interoperation

Dow= nload the interoperation guidelines:

- TBD for Toronto - interoperation guidelines, version 1 (Lon= don)

The= focus during this event is open to demonstrating 6lo, ROLL or 6TiSCH draft= s implementations, including but not limited to: e.g. - 6TiSCH minimal draf= t:=C2=A0http://tools.ietf.org/html/draft-ietf-6tisch-minimal-00. = - TBD

Par= ticipants are encouraged to bring devices which implement parts or all of t= he listed drafts.

Lev= els of interoperation are proposed:

Level 1, star topology.= A single BBR devices acts as the time source neighbor for all other nodes.= Nodes need to demonstrate frame-based and acknowledgement-based synchroniz= ation. The static TSCH schedule, as well as all slot timings are taken from= draft-ietf-6tisch-minimal-00.
Level 2, multi-hop topo= logy. This level builds upon level 1. The goal of this level is full compli= ance to draft-ietf-6tisch-minimal-00, including multi-hop routing (RPL).
Level 3, on-the-fly sch= eduling. [optional] Preliminary implementations of=C2=A0http://to= ols.ietf.org/html/draft-dujovne-6tisch-on-the-fly=C2=A0can be shown.
Level 4, drafts from RO= LL, such as: draft-ietf-roll-mpl-parameter-configuration, draft-ko-roll-mix= -network-pathology, Opportunistic routing, selective DIS, and others that p= articipants want to show
Level 5, drafts from 6l= o, such as: draft-ietf-6lo-btle, draft-ietf-6lo-ghc,draft-ietf-6lo-lowpanz,= and others that participants want to show.
Level 6=C2=A0Other drafts, such as draft-thubert-6man-flow= -label-for-rpl, etc.

Focus 2: Demonstration

Participants are encouraged to bring devices and te= chnology based on 6TiSCH, 6lo and ROLL which they believe can be of interes= t for the other participants. These devices may or may not participate in t= he interoperation event. Demonstration of more complete systems are encoura= ged, for example systems which show the interconnection of a 6TiSCH based m= esh to traditional networks.

Focus= 3: Tools

Participants are encouraged to bring and present different tools developed = around 6TiSCH/6lo/ROLL networks. Possible tools include, but are not limite= d to:

acquisition devices (i.e. "sniffers= ")
packet analysis tools (e.g. = Wireshark)
simulation/emulation plat= forms

= Important Dates

The preparation of this event will be held during a portion of the bi-weekl= y 6TiSCH call (To Be Decided how and when!!!). In particul= ar:

06/02/2014=C2=A0Announc= ement of the plugfest event to the WG/ML related with constrained devices, = such as: 6tisch, 6lo, roll, core, lwig, dtls-iot, coman, ace, etc.
06/06/2014=C2=A0Adoption of the plugfest call by the WGs, = and call for participants at each group.
06/02/2014-06/13/2014=C2=A0Participants have contacte= d the plugfest chairs (Xavier or Ines) with a tentative description of what= they wish to participate in.
06/20/2014=C2=A0Synchro= nization point 1. Participants can share the state of advancement of the im= plementation and raise blocking points.
07/11/2014=C2=A0Synchronization point 2. Participants can = share the state of advancement of the implementation and raise blocking poi= nts.
07/20/2014. Plugfest at= IETF90.

Tentative Agenda from 9:00 to 13:00

[09.00]=C2=A0Welcome and I= nitial Instructions
[09.05]=C2=A0Participants Pitch= (5 min per Participant)
[09.45]= =C2=A0Participants Pitch Tools (5 min per Participant)
[10.15]=C2=A0Interoperation (Islands)
[11.50]=C2=A0Feedback and open discussion.
[12.40]=C2=A0Acknowledgements and Plugf= est End

For M= ore Information

Contact: Xavi Vilajosan= a=C2=A0xvilajosana@eecs.berkel= ey.edu=C2=A0- Ines Robles=C2=A0mariainesrobles@gmail.com

= Note Well

This event is organized as part of the IETF90 standardization meeting. You = need to register to the IETF90 conference to be able to participate. Daily = passes are available. The IETF Note Well applies to this plugfest, see=C2= =A0http:/= /www.ietf.org/about/note-well.html.

About=

http://datatracker.ietf.org/wg/6tisch/charter/, which also = contains links to the mailing list and the Internet-Drafts published by the= group. 6TiSCH holds weekly phone calls on Friday 8am PST. Participation is= open, and is subject to the IETF Note Well.

The= IETF 6lo working group focuses on the work that facilitates IPv6 connectiv= ity over constrained node networks with the characteristics of: limited pow= er, memory and processing resources;. You can access the charter at=C2=A0https:/= /datatracker.ietf.org/wg/6lo/charter/, which also contains links to the= mailing list and the I-D published by the group.

The= IETF ROLL working group is focused on routing issues for LLN (Low Power an= d Lossy Networks), in IPv6 routing architectural framework for the industri= al, connected home, building and urban sensor networks application scenario= s. You can access the charter at=C2=A0https://datatracker.ietf.org/wg/roll/char= ter/, which also contains links to the mailing list and the I-D publish= ed by the group.

On F= ri, Jun 13, 2014 at 1:39 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:

Link-state and distance-vector routing protocols are both based=

on graph theory algorithms that *assume* perfect knowledge of
the topology. That is a bit strange, since initially routers have
almost zero knowledge of the topology, but the reality is that by
the time one of these routing protocols converges, the distributed
algorithm has discovered the topology in order to execute itself.
So Lorenzo's god box is distributed across all the nodes participating<= br> in the routing protocol.

Right, and tha= t's fine.

I have no issues with an entity= that has limited topological knowledge presenting that limited knowledge t= o the hosts as authoritative. For example: a router sending a host a route = announcement for a prefix it knows it can reach, and potentially annotating= said route announcement with "you must use this source prefix to reac= h this prefix through me" information, if it has it (e.g., if it got a= PD for the source prefix).

I have no issues with an entity that has "fu= ll" topological knowledge (for some value of "full") present= ing that knowledge to the hosts as authoritative. For example: router parti= cipating in homenet giving information on the homenet - if homenet runs a d= istributed routing protocol, once the protocol has converged, then all node= s have "full" knowledge.

I strongly oppose having an entity with limited topolog= ical knowledge telling the hosts things it does not have knowledge about. F= or example, the homenet router in the previous paragraph making assertions = about the a 4G network the host might be connected to, or a 4G network maki= ng assertions about a wifi network the host might be connected to.

Logically, the whole problem does solve its= elf if all multi-addressed
hosts also run the routing protocol. I'm beginning to wonder if
that isn't actually a lower cost solution than the alternatives.

It will be a long time before we get there.

What sort of problem are we trying to solve? If it&= #39;s just a question of "this route is not likely to work from this s= ource address", the host doesn't need a routing protocol. It just = needs a way to have that hint communicated to it in a timely manner.=C2=A0<= /div>

--001a1134cb1206125804fbb09377-- From nobody Fri Jun 13 03:00:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01CE1B27A2 for ; Fri, 13 Jun 2014 03:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9ojHyiIhKvA for ; Fri, 13 Jun 2014 03:00:16 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F951A023B for <6man@ietf.org>; Fri, 13 Jun 2014 03:00:16 -0700 (PDT) Received: from [172.20.10.2] (77.16.6.178.tmi.telenormobil.no [77.16.6.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 77D4F6296; Fri, 13 Jun 2014 03:00:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_188424C6-D5F2-4DE7-816D-661DD9EB0F75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt From: Ole Troan In-Reply-To: <539A8087.5010606@gmail.com> Date: Fri, 13 Jun 2014 12:00:03 +0200 Message-Id: <61F9C47E-AAA2-4AB0-8539-E1123F70CEF1@employees.org> References:

<53963D6F.9040503@gmail.com> <5397D80B.4060807@gmail.com> <53990EB8.6080608@gmail.com> <539915EB.7030707@gmail.com> <539A0900.9040101@globis.net> <539A8087.5010606@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Clyr4yGBCD-95KfQmBjyekN8lwY Cc: =?iso-8859-1?Q?Dan_L=FCdtke?= , Ray Hunter , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:00:18 -0000 --Apple-Mail=_188424C6-D5F2-4DE7-816D-661DD9EB0F75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, > Logically, the whole problem does solve itself if all multi-addressed > hosts also run the routing protocol. I'm beginning to wonder if > that isn't actually a lower cost solution than the alternatives. Topology #1: CER A CER B | | -------------- | host Topology #2: CER A CER B | | -------------- | router | host Topology #3: CER A ----| |---- host ---- CER B CER B ----| what do you mean by the "whole problem"? I assume we are talking about multi-prefix multihoming, in my mind that = is where a host has a single interface with multiple addresses (from = different /64s). each address is essentially connected to different exit = circuits, and it is the responsibility of the host to "multi-home".=20 topology #1 and #2 (which can be an arbitrary topology) is MHMP. = Topology #1 is solved by rule 5.5 in RFC6724 (prefer the next-hop router = that I learnt the source address from). Topology #2 is solved by SADR in = the network. all of them put quite a lot of requirements on the host/application: - probing for working SA/DA pairs on connection - load sharing across circuits - failover to different SA/DA pair on failure - take local host policy into consideration, e.g. prefer WIFI over 4G = for cost reasons, rather than purely using the link with best latency / bandwidth - take connected network policy into consideration, e.g. only use = source addresses from ISP A, when ISP B fails (cause that's my=20 expensive backup link.) would any of this be easier if the host had full routing information = available? a full BGP feed from each ISP on each interface? I just can't = see that, I need sub-second failover, BGP provides sub hour convergence. = even participating in SADR doesn't really give the host very much, SADR = only helps reaching the right exits in the local network. the routers do = that for the host already. and yes in an arbitrary topology routers must = use a routing protocol for that. topology #3 which is what in my reading this draft focuses on. it = appears to proposed that a multi-homed host (that is, with multiple = interfaces) should trust a message from a router on one interface to = install a route to a different router on another interface. that seems = like a big departure from how routing generally works. and it makes a = big assumption about how the host is connected to the network. it also = seems like quite a far fetched use case. I'll connect to a WIFI link, to = receive a default route that should point out the 4G interface? as far as I'm concerned the problem of MHMP is solved, with SADR in the = network and rule 5.5 in the host directly connected to do independent = CERs. and while the local network can give some indication on failure, = the network is largely unaware of the end to end connection, and I don't = see any other option than that the host probes. isn't that what = essentially shim6 does to? the use of MP-TCP would of course help a lot. = what problem do you see as unsolved here? what is lacking though, is how hosts / applications deal with = multi-homing. I run MPMH at home and I have still not found any IP stack = / application that handles that well. name based sockets seemed quite = promising, anyone continuing work on that? cheers, Ole --Apple-Mail=_188424C6-D5F2-4DE7-816D-661DD9EB0F75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTmsujAAoJEFuJXizso86gUE4IAKxONSDrxHVIaYul3hbLktJz a695w7LZTBBKO2Y6DkxT9Ko2hI3fhEYs9sYdmawEGBRzoI2SLLV6tCph8UKKjWdM Hi/AF1M/h759RFeD8I3Yw4UGKWXFHQFLGnqKZ8ivqMbmiqwYiz0CHKEpLIyEJ1LW G629vy3UMTt54Cc63L9Jyaq+kIRFpxI2dH2PXzyK+moNmBjkK/8zdGrTjZ+zTqJK JAtRFNZaPiYpoECidRgC7JoqJUdvOU4DN9v/a1YbfRQ64QlwaTdHaBnyqngblTsh aeGsDp9ENYXVQa4YccW/CQsDiT38dEaAC0wvdXVMRVT3byazGwYzAeLZNzFVyzs= =vyMh -----END PGP SIGNATURE----- --Apple-Mail=_188424C6-D5F2-4DE7-816D-661DD9EB0F75-- From nobody Fri Jun 13 12:04:47 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543351A01FF; Fri, 13 Jun 2014 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10lgOl62M3Lm; Fri, 13 Jun 2014 12:04:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A932B1B2A00; Fri, 13 Jun 2014 12:04:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'IPv6 Multicast Address Scopes' to Proposed Standard (draft-ietf-6man-multicast-scopes-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613190442.9691.14736.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 12:04:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EwEnhKkgWv_2zHKyr3qtx2-mB4A Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:04:45 -0000 The IESG has approved the following document: - 'IPv6 Multicast Address Scopes' (draft-ietf-6man-multicast-scopes-07.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-multicast-scopes/ Technical Summary This document updates the definitions of IPv6 multicast scopes. As defined in RFC4291 (RFC4007) Working Group Summary Nothing to note. Document Quality The ZigBee-IP spec uses multicast with scope 0x03 in a couple of ways and there are several independent interoperating implementations of ZigBee-IP. The 6man working group appoints reviewers for all documents being advanced to the IESG. This document has been reviewed in detail by Jouni Korhonen. In addition to the chair's and shepherd's review. Personnel Document Shepherd: Ole Troan Responsible Area Director: Brian Haberman From nobody Fri Jun 13 13:29:07 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5861B2A35 for ; Fri, 13 Jun 2014 13:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.152 X-Spam-Level: X-Spam-Status: No, score=-17.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-77rV3d5fGu for ; Fri, 13 Jun 2014 13:29:03 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2101B2A48 for <6man@ietf.org>; Fri, 13 Jun 2014 13:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15443; q=dns/txt; s=iport; t=1402691343; x=1403900943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pz6VuBY2RkHYx79I0WsDIl0SN7VomTgarVZMELgchHg=; b=Y+ME+rtJg7dzPIJWHsrpqRMgP3jvfQ7XHA6BjAC+RTq9ld4EFcTKH1lO a2X8a2JtpFSi+pO65hGKC4qkPh9jr8UX5kL0qLbM0j+zb6ka+E5fAzNd6 IYyUprqLQ6xOb5qTQ/JzM5L4wnZD8ndDyZvbAaGqMlajdkxa10iZOSdo5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQHAGRem1OtJA2F/2dsb2JhbABagw1SWaleAQEBAQEBBQGRZYc9AYEFFnWEAwEBAQQBAQE3NAkCDAQCAQgRBAEBAQoUCQchBgsUCQgCBA4FCAGIJQMRDct/DYYGF4Vdhl+BUgEBHgYrBwaDJYEWBJVlRoITgzyMFYV/gz5sgQs5 X-IronPort-AV: E=Sophos;i="5.01,473,1400025600"; d="scan'208";a="52939153" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 13 Jun 2014 20:29:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5DKT2t2008802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 20:29:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 15:29:01 -0500 From: "Panos Kampanakis (pkampana)" To: "C. M. Heard" Subject: RE: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt Thread-Topic: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt Thread-Index: AQHPfoXbanO4VBqswUyRiGWCNwM2qZtmsSAPgAdflqyAAP6OMA== Date: Fri, 13 Jun 2014 20:29:01 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7513BB7602@xmb-rcd-x10.cisco.com> References: <20140602170733.22309.62074.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A7513BA2B0E@xmb-rcd-x10.cisco.com> <5393EEC6.5030403@gmail.com> <1C9F17D1873AFA47A969C4DD98F98A7513BAFF7D@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jCmhaYIz3ymx8unqsYI4IC2ehto Cc: 6man <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:29:06 -0000 Thank you Mike for the detailed response. Very valuable feedback.=20 I will make sure to address it in the next iteration if the document become= s an WG item. Panos -----Original Message----- From: C. M. Heard [mailto:heard@pobox.com]=20 Sent: Thursday, June 12, 2014 5:33 PM To: Panos Kampanakis (pkampana) Cc: Brian E Carpenter; 6man Subject: RE: New Version Notification for draft-kampanakis-6man-ipv6-eh-par= sing-00.txt Greetings, Here are some things that I perceive as issues with this draft, along with = suggestions for how to fix them. First: not all devices that process IPv6 header header chains to enforce po= licies match (or even care about) the content of IPv6 extension headers; al= l they want to to is to traverse the header chain to find the upper-layer h= eader. Examples are RA-Guard (http://tools.ietf.org/html/rfc7113) and DHCPv6-Shield (http://tools.ietf.= org/html/draft-ietf-opsec-dhcpv6-shield). For those functions extension he= aders do not matter so long as the transport header can be found and inspec= ted; the implementation advice for the RA-Guard and DHCPv6-Shield filters i= s to pass everything that can be positively identified as NOT being a forbi= dden RA message or DHCPv6 message. For that reason, I would recommend the following global changes: intermediate devices that enforce policies by matching on IPv6 EHs (ACLs, s= tateful inspection and firewalling) intermediate devices that process IPv6 header chains in order to enforce po= licies an intermediate device that enforces policies by matching on IPv6 EHs (ACLs= , stateful inspection and firewalling) an intermediate device that processed IPv6 header chains in order to enforc= e policies Now for some specific issues. Guideline 4: According to Section 4.1 of [RFC2460], when a end-host processes a IPv6 packet with multiple DestOpt EHs, o if there is no RH EH in the packet, then only the final destination host SHOULD process only the last DestOpt EH. o if there is a RH in the packet * if the node is the final destination, then it SHOULD process all the DestOpt EHs in the packet. * if the node is one of the destinations in the RH, it SHOULD only process the DestOpt EHs in the chain that are before the RH EH. It would seem that these rules should apply to end systems or to intermedia= te systems that do not enforce policies, but that's not quite what is said.= Also, I think that the first bullet is simply wrong. =20 The relevant note in RFC 2460 says: note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. so the final destination end system should process ALL of the DestOPt EHs i= n the packet. Here is proposed replacement text: Guideline 4: As specified in Section 4.1 of [RFC2460], when a end-host or an intermediate system that does not inspect IPv6 header chains in order to enforce policies processes an IPv6 packet with multiple DestOpt EHs, o if there is no RH EH in the packet, then the final destination host alone SHOULD process all the DestOpt EHs in the packet. o if there is a RH in the packet * if the node is the final destination, then it SHOULD process all the DestOpt EHs in the packet. * if the node is one of the destinations in the RH, it SHOULD only process the DestOpt EHs in the chain that are before the RH EH. Given the impossibility of distinguishing between an unknown extension head= er and an unknown upper-layer protocol, I believe that the following text i= s problematic: 5. Other guidelines Guideline 7: Unknown Eh o As defined in Section 4 of [RFC2460], end-hosts should discard packets with unknown EH types and send an ICMP Parameter Problem message to the source of the packet. o Intermediate devices that enforce policies (ACLs, stateful inspection and firewalling) by matching on IPv6 EHs MUST only drop unknown EH as part of configuration policy (Section 2.1 of [RFC7045]). Here is the proposed replacement, which would require adding a reference to= RFC 6564: 5. Other guidelines Since IPv6 Extension Headers and upper-layer protocols share the same namespace (the "Assigned Internet Protocol Numbers" registry/namespace), it is impossible to tell whether an unrecognized Next Header value refe= rs to an IPv6 Extension Header to to an unrecognized upper-layer protocol, [RFC6564] notwithstanding. Thus, when parsing an IPv6 header chain: Guideline 7: Unecognized Next Header values o As specified in Section 4 of [RFC2460], end-hosts should discard pack= ets with unrecognized Next Header values and send an ICMP Parameter Probl= em message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer fi= eld containing the offset of the unrecognized value within the original p= acket. o Intermediate devices that process IPv6 header chains in order to enfo= rce policies MUST NOT attempt to continue parsing an IPv6 header chain af= ter encountering an unrecognized Next Header value. Per Section 2.1 of [= RFC7045], such systems MUST be configurable to allow such packets, but the defa= ult configuration MAY drop such packets. And finally I recommend changing Guideline 8: Intermediate or end-hosts MUST process a RH in an IPv6 packet only when the host's address is the same as the packet's IPv6 Destination Address. (Section 4.4 of [RFC2460]) to Guideline 8: End-hosts or intermediate systems that do not process IPv6 header chains in order to enforce policies MUST process an RH in an IPv6 packet only when the node's address is the same as the packet's IPv6 Destination Address. (Section 4.4 of [RFC2460]) I agree with Brian Carpenter that the implementation advice in this draft i= s needed. I would like to believe that with the changes proposed above (or= something similar to them) it could subsume implementation guide aspects o= f Fernando Gont's recent draft http://tools.ietf.org/html/draft-gont-6man-i= pv6-universal-extension-header, and I freely confess to stealing some of Fernando's excellent text. Thanks and regards, Mike Heard On Mon, 9 Jun 2014, Panos Kampanakis (pkampana) wrote: > Thank you Brian. >=20 > I will certainly address all these along with your previous MUST NOT=20 > comment in the next iteration. >=20 > As for BCP, I think it could be either Informational or BCP. I don't=20 > feel strongly about it. I will defer to the chairs and the rest of the=20 > group, if this doc ends up being adopted and a WG item. We can=20 > certainly change it. >=20 > Panos >=20 >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Sunday, June 08, 2014 1:04 AM > To: Panos Kampanakis (pkampana) > Cc: 6man@ietf.org > Subject: Re: New Version Notification for=20 > draft-kampanakis-6man-ipv6-eh-parsing-00.txt >=20 > Panos, >=20 > I think this draft fills a gap. In fact I wonder whether it shouldn't=20 > be a BCP, so that it gets anough attention. >=20 > I do have a few comments, and I hope that some real implementors can=20 > have a look too. >=20 > > 1. Introduction > ... > > [RFC2460] > > describes some IPv6 EH recommendations of the order and allowed > > occurrences of headers, but it does not provide other guidance on ho= w > > EHs should be parsed.=20 >=20 > I apologise for plugging my own RFC, but I think it's important to=20 > insert something like this: >=20 > [RFC7045] updates RFC 2460 by specifying the required behavior of =20 > middleboxes when handing an EH chain, but it does not go into detail =20 > about the parsing process. >=20 > (The reason is that we really need all those middlebox implementors to=20 > look at the IETF's latest thinking on this. There is a lot of code out=20 > there based on careless reading of RFC 2460.) >=20 > > Guideline 2: From Section 5 of [RFC7112], when parsing an EH chain, >=20 > That reads as if you are quoting RFC 7112, but you are not. Is this=20 > what you mean?: >=20 > Guideline 2: As a consequence of Section 5 of [RFC7112], when parsing=20 > an EH chain, >=20 > Then you have this phrase twice: >=20 > > field is not an Upper Layer (UL) protocol (i.e. TCP) >=20 > I hope you mean "(e.g. TCP)" because this would apply to any protocol,=20 > not just TCP. >=20 > Also, you could add a note that the current list of defined EH values=20 > is maintained by IANA in the "IPv6 Extension Header Types" registry=20 > created by RFC 7045. This registry is intended precisely as a=20 > convenient reference for implementors. >=20 > > Guideline 3: Thus, when parsing an EH chain, > ... > > o an intermediate device that enforces policies (ACLs, stateful > > inspection and firewalling) by matching on IPv6 EHs MUST discard > > packets that have an HbH EH that is not first in the chain > > (Section 2.2 of [RFC7045]). If the device is not parsing the EH > > chain, it MAY NOT discard the packets. >=20 > I've already mentioned in private mail that this needs to be MUST NOT. > However, a picky implementor will want to know how a device that is=20 > not parsing the header chain will even know that there is a HbH EH=20 > that is not first. >=20 > > 4. Parsing malformed EHs > ... > > If the data of the last EH or the UL > > Header plus its data does not align with the original IPv6 Header > > Payload Length the packet MUST be dropped unless another policy step > > already discarded it. >=20 > I think this is inconsistent with a statement in RFC 2460: >=20 > > 4.7 No Next Header > >=20 > > The value 59 in the Next Header field of an IPv6 header or any > > extension header indicates that there is nothing following that > > header. If the Payload Length field of the IPv6 header indicates th= e > > presence of octets past the end of a header whose Next Header field > > contains 59, those octets must be ignored, and passed on unchanged i= f > > the packet is forwarded. >=20 > Unless I have misunderstood something, your guideline 5 needs an=20 > exception for the No Next Header case. >=20 > (Or we could decide that the case described in RFC 2460 is an=20 > invitation to buffer overflow attacks, and change the rule.) >=20 > Regards > Brian >=20 > On 03/06/2014 05:36, Panos Kampanakis (pkampana) wrote: > > Hello, > >=20 > > I just submitted an Informational draft that provides guidelines for IP= v6 implementers on how to parse IPv6 extension headers. > >=20 > > There are multiple RFCs like RFC2460, RFC7112, RFC7045, RFC5722 and RFC= 6946 already that provide some rules on IPv6 packet processing. These addre= ss separate issues and is tough for an implementer to track all rules in ea= ch RFC. Additionally, there are some gaps in parsing malformed EHs and how = EH chains should be parsed. To my knowledge, there is no document that and = implementer could use as a single source of truth that would tell him how I= Pv6 EH should be parsed. That has led to different implementations that are= inconsistent. For example malformed packets are in some cases processed an= d others dropped based on vendor implementation. > >=20 > > As more and more smart devices are starting to participate in the netwo= rk, there is a need for a document that will ensure there is consistency on= how IPv6 EHs are processed to prevent inconsistencies and potential securi= ty implications from incorrectly parsing headers. This document is trying t= o address that need. > >=20 > > Name: draft-kampanakis-6man-ipv6-eh-parsing > > Revision: 00 > > Title: Implementation Guidelines for parsing IPv6 Extension Headers > > Document date: 2014-06-02 > > Group: Individual Submission > > Pages: 8 > > URL: http://www.ietf.org/internet-drafts/draft-kampanakis-6m= an-ipv6-eh-parsing-00.txt=20 > > Status: https://datatracker.ietf.org/doc/draft-kampanakis-6man-= ipv6-eh-parsing=20 > > Htmlized: http://tools.ietf.org/html/draft-kampanakis-6man-ipv6-e= h-parsing-00=20 > >=20 > >=20 > > Thoughts on the doc being adopted as WG item and other feedback is welc= ome. > >=20 > > Panos > > Cisco Systems > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, June 02, 2014 1:08 PM > > To: Panos Kampanakis (pkampana); Panos Kampanakis (pkampana) > > Subject: New Version Notification for=20 > > draft-kampanakis-6man-ipv6-eh-parsing-00.txt > >=20 > >=20 > > A new version of I-D, draft-kampanakis-6man-ipv6-eh-parsing-00.txt > > has been successfully submitted by Panos Kampanakis and posted to the I= ETF repository. > >=20 > > Name: draft-kampanakis-6man-ipv6-eh-parsing > > Revision: 00 > > Title: Implementation Guidelines for parsing IPv6 Extension Headers > > Document date: 2014-06-02 > > Group: Individual Submission > > Pages: 8 > > URL: http://www.ietf.org/internet-drafts/draft-kampanakis-6m= an-ipv6-eh-parsing-00.txt > > Status: https://datatracker.ietf.org/doc/draft-kampanakis-6man-= ipv6-eh-parsing/ > > Htmlized: http://tools.ietf.org/html/draft-kampanakis-6man-ipv6-e= h-parsing-00 > >=20 > >=20 > > Abstract: > > IPv6 is widely used on the internet today and is expected to be > > deployed more as more devices (i.e. home automation) get inter- > > connected. The IPv6 header format allows for the use of Extension > > Headers (EH). EHs could be chained together with very few existing > > guidelines by the IPv6 protocol on how devices should parse them, > > which open room for security concerns and inconsistencies. This > > document presents guidelines for parsing IPv6 EHs with a goal of > > providing a common and consistent parsing methodology for IPv6 > > implementers among the industry. > >=20 > > = =20 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. > >=20 > > The IETF Secretariat > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 From nobody Fri Jun 13 15:06:47 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692BA1B2A59 for ; Fri, 13 Jun 2014 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EGijvhxVWB8 for ; Fri, 13 Jun 2014 15:06:40 -0700 (PDT) Received: from nm3-vm2.bullet.mail.ne1.yahoo.com (nm3-vm2.bullet.mail.ne1.yahoo.com [98.138.91.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE341B2A25 for ; Fri, 13 Jun 2014 15:06:40 -0700 (PDT) Received: from [98.138.226.178] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2014 22:06:39 -0000 Received: from [98.138.226.62] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2014 22:06:39 -0000 Received: from [127.0.0.1] by smtp213.mail.ne1.yahoo.com with NNFMP; 13 Jun 2014 22:06:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402697199; bh=bwCobGLIlIBr4vQkWuRe5X0gGZFGwlpAuZPWd1XpG6k=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=ZwgdbyeJiaBtDfvrjdwvEOZOMuiR6ZDUr94EaYHwEk5pyhYKj9g8gJf4HaajBiUMENAe2Pm6ObeNOCccQhTtX0PnbcnpKCmOmlk/N7fvxDje+7fxRf7UipCB2GlCmmUsHZvVqNwtsCmNOXpxZebDmgUv0K7onX3P+fVRQ8opsnk= X-Yahoo-Newman-Id: 357724.21201.bm@smtp213.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b70jBEEVM1n8SHId6bTAbTfqOsK7Wx7dF_fcZQi7SP6F97U S8YSLBv1tuzBM_LF.MDcyzmisI9S0L2ERFjZp8JBJTFRDp8bxQuIzBpa6kDy Rp_7n_pHKF0lP8AawbAm6y.470HqMV3UCuaClfm56IBQ4s2y3DOglOGmlxH. 7k4aBZ_TJiMlcjR9SKTN53CNgoLpWLO7g47z6aMXML.hrgr5Mrz0hjPHdNIV RLlSbFnApfWcZRFKHPCVMOi9YsoRAYAWO0A5z9Ae5EjK3CdHqHYebNng.VHe oU1fbgg4fOmpIkIJuTmuDakMBpl6OL3lnzvQ397fiSzcnMYBzY7.Yup8VASq mS20LSVsGf7u5Z46Zi4uI.ykEYKcnG2qYHO6pVtD0bMP63nULK8ZA0Ej6avV iLtsyUw0dbHiwisr0ue9NDRyxLiV7rLVXyEiBt9VcrXNIAzJd1Jo0xvfFXW7 3jEklJcb7ctZoJg2iwyVrSHgFjABaXHgSSc8MzZoCQs.kxSsxVElSrgz4ITt zRUvx8awsZbdmDWKgwBdXgGVR9Kg- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- X-Rocket-Received: from [192.168.1.2] (osmankh@101.174.197.235 with xymcookie [98.138.86.130]) by smtp213.mail.ne1.yahoo.com with SMTP; 13 Jun 2014 22:06:39 +0000 UTC Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt From: Usman Latif Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D201) Message-Id: <88FDADC4-3905-4CC6-9096-8FFD5F1EFA0F@yahoo.com> Date: Sat, 14 Jun 2014 08:06:35 +1000 To: "ipv6@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EkpiZcpnc5YASyeaHfdPxQpej9w X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 22:06:42 -0000 Hi, My comment/query may not be directly related to this subject but what is our= current position with regards to portable IPv6 subnets that are permitted f= or IPv6 Internet? There was one RFC recommending minimum /48 If that is the case, then we have accepted potentially 2.8 x 10^14 prefixes f= or the Internet? There was also an RFC (LISP) which provided a solution for mobility and mult= ihoming/portability but doesn't look to be progressing much in terms of oper= ators implementing ITR/ETRs in their network ... So is there any additional document/draft that is looking into multihoming/p= ortability and prefix scaling issue if all /48s eventually made it to the IP= v6 Internet (similar to how we have almost all /24s appearing in IPv4 Intern= et table) From nobody Fri Jun 13 18:31:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2931B2AE4 for ; Fri, 13 Jun 2014 18:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdzt1g_-dZSO for ; Fri, 13 Jun 2014 18:31:11 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE891B2AE0 for <6man@ietf.org>; Fri, 13 Jun 2014 18:31:10 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id md12so1806812pbc.33 for <6man@ietf.org>; Fri, 13 Jun 2014 18:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0jcIkgBcL8PjpZAFxJK2B3cnh59PWbnWSP8o/M3PlLM=; b=G3YAONdPqm+KfpeId9fy48A7dGaERKtS265Lhp59dwUDyy5DQ/o7wj7d/M92k2vsmN pGUCTJh7zhN9vK66MZDuRx5rJWdhUGQlfDUePfnyoMUEX0VmxW2KkSQb4825AoofL9SU xv9qUZxgaCA5fwA666xStL9em3K6GbixrPfYVHxT5iG0zS83ZDGcaUUZa1T4xbESCK9E K+nNHnhTm34KTNbhwO98vHU9u92iM9H7TNru+WTHl7HfgNS1Fe+GxxggjcTXkb7EPA5A ovdMG3dlrsnO21F+BHQL58RVZnAAHvt4WyAqqvQJnQS5aI4A9uaP4hsMQC8wOWimtfc9 V1vg== X-Received: by 10.68.237.67 with SMTP id va3mr7442210pbc.19.1402709470433; Fri, 13 Jun 2014 18:31:10 -0700 (PDT) Received: from [192.168.178.23] (115.199.69.111.dynamic.snap.net.nz. [111.69.199.115]) by mx.google.com with ESMTPSA id qf10sm5884201pbc.23.2014.06.13.18.31.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 18:31:09 -0700 (PDT) Message-ID: <539BA5E7.3050809@gmail.com> Date: Sat, 14 Jun 2014 13:31:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt References:

<53963D6F.9040503@gmail.com> <5397D80B.4060807@gmail.com> <53990EB8.6080608@gmail.com> <539915EB.7030707@gmail.com> <539A0900.9040101@globis.net> <539A8087.5010606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5TopA2TRWZSkm0JJJXcyqg078z4 Cc: =?UTF-8?B?RGFuIEzDvGR0a2U=?= , Ray Hunter , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 01:33:44 -0000 On 13/06/2014 17:01, Lorenzo Colitti wrote: ... > What sort of problem are we trying to solve? If it's just a question of > "this route is not likely to work from this source address", the host > doesn't need a routing protocol. It just needs a way to have that hint > communicated to it in a timely manner. If your application runs over TCP, MPTCP resolves this. Brian From nobody Mon Jun 16 09:05:18 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25B81A00E2 for ; Mon, 16 Jun 2014 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u61mb6Bibht for ; Mon, 16 Jun 2014 09:05:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD881A00DE for ; Mon, 16 Jun 2014 09:05:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5GG57iK004909; Mon, 16 Jun 2014 18:05:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1526520621A; Mon, 16 Jun 2014 18:06:52 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 03DBD20620D; Mon, 16 Jun 2014 18:06:52 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5GG4paP003445; Mon, 16 Jun 2014 18:05:07 +0200 Message-ID: <539F15A2.2030603@gmail.com> Date: Mon, 16 Jun 2014 18:04:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ipv Subject: New version of draft-petrescu-ipv6-over-80211p-02 References: <20140616155846.13134.16461.idtracker@ietfa.amsl.com> In-Reply-To: <20140616155846.13134.16461.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140616155846.13134.16461.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/474smX6uX9Iore-0o5IBhl97brs Cc: t.leinmueller@denso-auto.de, Pierre PFISTER X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:05:17 -0000 Hello participants to 6MAN WG, We have just submitted version -02 of the IPv6-over-802.11p draft: http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-02 The changelog from -01 is: o updated authorship. o added explanation about FCC not prohibiting IP on channels, and comments about engineering advice and reliability of IP messages. o added possibility to use 6lowpan adaptation layer when in OCB mode. o added appendix about the distribution of certificates to vehicles by using IPv6-over-802.11p single-hop communications. o refined the explanation of 'half-rate' mode. o added the privacy concerns and necessity of and potential effects of dynamically changing MAC addresses. Comments welcome, thanks. Alex, with co-authors. -------- Message original -------- Sujet: I-D Action: draft-petrescu-ipv6-over-80211p-02.txt Date : Mon, 16 Jun 2014 08:58:46 -0700 De : R�pondre � : Pour : A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IEEE 802.11p Networks Authors : Alexandru Petrescu Pierre Pfister Nabil Benamar Tim Leinmueller Filename : draft-petrescu-ipv6-over-80211p-02.txt Pages : 30 Date : 2014-06-16 Abstract: In order to transmit IPv6 packets on IEEE 802.11p networks there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, the header format preceding the IPv6 base header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11p networks; it portrays the layering of IPv6 on 802.11p similarly to other known 802.11 and Ethernet layers, by using an existing Ethernet Adaptation Layer. In addition, the document attempts to list what is different in 802.11p compared to more 'traditional' 802.11a/b/g/n layers, layers over which IPv6 protocols run ok. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. An example of an IPv6 packet captured while transmitted over an IEEE 802.11p link is given. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-petrescu-ipv6-over-80211p/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-petrescu-ipv6-over-80211p-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 16 10:21:08 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0846B1A0119 for ; Mon, 16 Jun 2014 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqvq7bTcKHrl for ; Mon, 16 Jun 2014 10:21:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AEA1A00C9 for ; Mon, 16 Jun 2014 10:21:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B1FC9880AE; Mon, 16 Jun 2014 10:21:05 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6312671C0002; Mon, 16 Jun 2014 10:21:05 -0700 (PDT) Message-ID: <539F2781.60000@innovationslab.net> Date: Mon, 16 Jun 2014 13:21:05 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org, 6man WG Subject: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Mwid3HlEg9r8HtNaoWwIm10HKtE14t8uM" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/3o1Aqj2QjNS0_si6rRpffZS762M X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:21:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mwid3HlEg9r8HtNaoWwIm10HKtE14t8uM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I have completed my AD Evaluation of draft-ietf-6man-multicast-addr-arch-update as a part of the publication process. Please review these comments, discuss as necessary, and resolve them. Once a revision is available that addresses these comments, the document can proceed to the next phase of the publication process (IETF Last Call). * Re-word the Abstract to remove explicit reference to the reserved bits location. Something like "...by re-defining the reserved bits as generic..." * Section 1 - This document updates the IPv6 addressing architecture (not the multicast addressing architecture) to change the reserved bits to flag bits. * Sections 1 & 2 - If the text contains the actual offset of the bits being changed, the document needs to indicate what reference point is being used. For example, RFC 4291 refers to "high-order bits" to indicate the point of reference. * Section 2 1. What is the rationale for the use of the term "so-called" in reference to Embedded-RP? 2. I would suggest specifying that ff1 directly maps to flgs in 4291 & 39= 56. * There is quite a bit of redundancy between sections 2 & 4, but not information is contained in 2. I would suggest re-structuring these sections so that one contains the rationale for this change and the other contains the complete list of updates being made to the affected documents. * This may be nit-picky, but I would like to see the names listed in the Acknowledgements be completely spelled out. * idnits indicates issues that need to be addressed. Regards, Brian --Mwid3HlEg9r8HtNaoWwIm10HKtE14t8uM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTnyeIAAoJEBOZRqCi7goqYgUIALtW4sCb9PAwBYcuUo4NKYaD s3Ilz/Ofg5URWrwMonkpSeihbi6XKOAtVUBw7eEHFyHSd8DGQdd/niPKzlx7ZwIb Zpc02bHW05O/HDjmGm04Uh8xdEFisathuUIfAm52Tw08f2Bnx2LlkB1CO976UB2E w/qPPk5mseXLSji6zHh3iwlktOrXuTQk0YI0x6CbPkUSLgLlD1Khk3zZi4LbuyIt iU+xXeZSj7aNOcV7C8q/95WHfKV6O1mSXrWYg7PFrDDhKx1rUtMe/brRkHOBULJz ec7qC5hNE00DHzOxeJtoUE/QyL4d3edycRcGR2Qklp7496aXBin+JYsBa3DC/Mw= =Af/1 -----END PGP SIGNATURE----- --Mwid3HlEg9r8HtNaoWwIm10HKtE14t8uM-- From nobody Tue Jun 17 04:39:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D611A0350 for ; Tue, 17 Jun 2014 04:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JygymaOcJ8Pf for ; Tue, 17 Jun 2014 04:39:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6271A034D for ; Tue, 17 Jun 2014 04:39:07 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2906032426A; Tue, 17 Jun 2014 13:39:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 012E14C072; Tue, 17 Jun 2014 13:39:05 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 13:39:04 +0200 From: To: Brian Haberman , "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" , 6man WG Subject: RE: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update Thread-Topic: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update Thread-Index: AQHPiYdkikjiHka2y0iRmzGZkoiRcZt1LKuA Date: Tue, 17 Jun 2014 11:39:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933001838D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539F2781.60000@innovationslab.net> In-Reply-To: <539F2781.60000@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.17.110330 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2bF-6CzHBSK8MT2HMSKk9swRp6E X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 11:39:12 -0000 Hi Brian, Thank you for the review.=20 The editorial comments will be fixed in -05. We fixed idnits issues except these two ones (that we don't think are issue= s): * Lack of a disclaimer for pre-RFC5378 work: When we specify the explicit changes we quote text from documents older than 2008, and the new next is largely the same as the old one. We don't think we want to contact all authors about BCP78 rights. * Missing Reference: 'ADDRARCH': This is not a missing reference. It is only here because we quote some text from a document which has this reference. The new version will be available online soon. Cheers, Med=20 >-----Message d'origine----- >De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Brian Haberman >Envoy=E9=A0: lundi 16 juin 2014 19:21 >=C0=A0: draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; 6ma= n WG >Objet=A0: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update > >All, > I have completed my AD Evaluation of >draft-ietf-6man-multicast-addr-arch-update as a part of the publication >process. Please review these comments, discuss as necessary, and >resolve them. Once a revision is available that addresses these >comments, the document can proceed to the next phase of the publication >process (IETF Last Call). > > >* Re-word the Abstract to remove explicit reference to the reserved bits >location. Something like "...by re-defining the reserved bits as >generic..." > >* Section 1 - This document updates the IPv6 addressing architecture >(not the multicast addressing architecture) to change the reserved bits >to flag bits. > >* Sections 1 & 2 - If the text contains the actual offset of the bits >being changed, the document needs to indicate what reference point is >being used. For example, RFC 4291 refers to "high-order bits" to >indicate the point of reference. > >* Section 2 > >1. What is the rationale for the use of the term "so-called" in >reference to Embedded-RP? > >2. I would suggest specifying that ff1 directly maps to flgs in 4291 & >3956. > >* There is quite a bit of redundancy between sections 2 & 4, but not >information is contained in 2. I would suggest re-structuring these >sections so that one contains the rationale for this change and the >other contains the complete list of updates being made to the affected >documents. > >* This may be nit-picky, but I would like to see the names listed in the >Acknowledgements be completely spelled out. > >* idnits indicates issues that need to be addressed. > > >Regards, >Brian From nobody Tue Jun 17 13:11:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA61A0168 for ; Tue, 17 Jun 2014 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxAfi1ymSqAD for ; Tue, 17 Jun 2014 13:10:59 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FB31A0166 for <6man@ietf.org>; Tue, 17 Jun 2014 13:10:59 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so5896644yho.25 for <6man@ietf.org>; Tue, 17 Jun 2014 13:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=CXSFAbjubUswA8jiFHbBxdX3vtyCxiNOrClid6twwTY=; b=bmvkNiM/ZgKoKAQlaktzcGujpbOj0Zt80M7aXK2Swji6eKVpJu1FLf4Ekiaw5ERh4r Ku7mM0RLFsqvduwmsZVTc01upIFtKDWOo3V8u+0NCCAHPnDJaShOYk04Sj7fXpxPEkW7 Ca0p8Grd/UzuZqzyqJufTtVUdMa7gJqfH0wTDcwutrt3Yat3Kwq1CDRBlloR4E9YXKCc OSR0dtccX0cknacS0oWI9iRUVvYhYc+MeMTE2anNUVPFTWyFs5TKBx+btU2mdgNJIkcv fZ2J/PIufxGYejJSmk+jiB8JHGpeLuM2Bcb54jLOogJpGQ1Q2oU9BCGXSICtGlYiM+iE 1qDw== MIME-Version: 1.0 X-Received: by 10.236.191.132 with SMTP id g4mr47921489yhn.32.1403035858633; Tue, 17 Jun 2014 13:10:58 -0700 (PDT) Received: by 10.170.156.130 with HTTP; Tue, 17 Jun 2014 13:10:58 -0700 (PDT) In-Reply-To: <61F9C47E-AAA2-4AB0-8539-E1123F70CEF1@employees.org> References:

<53963D6F.9040503@gmail.com> <5397D80B.4060807@gmail.com> <53990EB8.6080608@gmail.com> <539915EB.7030707@gmail.com> <539A0900.9040101@globis.net> <539A8087.5010606@gmail.com> <61F9C47E-AAA2-4AB0-8539-E1123F70CEF1@employees.org> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1V7t4TMvt8HT3twFoUX354Lr_v0 Cc: =?iso-8859-1?Q?Dan_L=FCdtke?= , Ray Hunter , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:21:29 -0000 --Apple-Mail=_0F63C19B-8152-4223-A2C0-B1A93CCD3956 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > What is CER in your topologies? I did not see them used in RFC 7157? Customer Edge Router. See RFC6204, or the homenet-arch document. cheers, Ole --Apple-Mail=_0F63C19B-8152-4223-A2C0-B1A93CCD3956 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJToKM0AAoJEFuJXizso86gppcIALt235v/BJ2XVF9eituO6f0L CwqvH06sTgXSX/WUjFkl2r3oiBkjE1GdU9Dv0YE4msa+jYCZcTIHGidYpyZF+xfm 9u3GP/whj0UhVAb9j0wZ7xpSxK1xdkluTVA3YvBUIycnX2BsJZHQ1DIkfaNT0qhP 8YjXh88NPoMKJN2phTxWAHfpBYMzifm82uG4WNwTLN/gwORoszi9Jk+7o5TRm5z8 lv/4Pg4Us4dUmZUe8vTEcAySFo7krSSfmgJ9/2aPC4LW2op0JBxwZWY50ozybM2o DRPDFRaSU3RrgbakVPxrqhOLOnbdNb5T7mFLAjVWoXDNYBoxIqfPtPoDqFzm32Y= =fVqa -----END PGP SIGNATURE----- --Apple-Mail=_0F63C19B-8152-4223-A2C0-B1A93CCD3956-- From nobody Tue Jun 17 13:28:04 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A571A010C for ; Tue, 17 Jun 2014 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTf028kVrWXi for ; Tue, 17 Jun 2014 13:28:02 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254791A007E for ; Tue, 17 Jun 2014 13:28:02 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id md12so5250825pbc.3 for ; Tue, 17 Jun 2014 13:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0lk0MEAbhVuyou3emeKGjZZpoOzO9r5mM1lYC5sP074=; b=UZB1NjaD9tCGNVTrBno1q2op37iRDjJjmLjrb8r21g8QxXVERlfafIbYNVyNajRocc LvB+dMZwUR7HFfvTSlzbg+RvK+sLiO567Ih647aYN57n7fleXdBeZm6xXl6rFMfYEUAZ dZe5Kag3leMmhVzy8vIGJcV6wFlbbstvlA32t9EBzq4W4O2LPV1gfaPcxv6Xdhog3sW8 WKBtaCsx5YenIVjTeX5pMH32zKikbuPeox8Z/mG7I7/n89KWqhpqXoqyu1QdQt3bD4aY IpRorGAzqts0uubuHXzrA0qk904aplSbkp6QKbJf3G3/v/P3DmW4xtjfhXb7Y0ai8Rwf kd5g== X-Received: by 10.67.14.231 with SMTP id fj7mr35075932pad.115.1403036880760; Tue, 17 Jun 2014 13:28:00 -0700 (PDT) Received: from [192.168.178.23] (171.198.69.111.dynamic.snap.net.nz. [111.69.198.171]) by mx.google.com with ESMTPSA id bg15sm2319703pac.1.2014.06.17.13.27.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 13:28:00 -0700 (PDT) Message-ID: <53A0A4D0.5010800@gmail.com> Date: Wed, 18 Jun 2014 08:28:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Usman Latif Subject: "portable" IPv6 subnets [was New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt] References: <88FDADC4-3905-4CC6-9096-8FFD5F1EFA0F@yahoo.com> In-Reply-To: <88FDADC4-3905-4CC6-9096-8FFD5F1EFA0F@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ubnxwaElVLmoIQ0XHG9s_17hIz4 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:28:03 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 14/06/2014 10:06, Usman Latif wrote: > Hi, My comment/query may not be directly related to this > subject No > but what is our current position with regards to > portable IPv6 subnets that are permitted for IPv6 Internet? I don't like the word "portable". After all, IPv6 prefixes are loaned not given. > There was one RFC recommending minimum /48 You may be thinking of obsolete RFC 3177. Please read RFC 6177, which is a bit more up to date. > If that is the > case, then we have accepted potentially 2.8 x 10^14 prefixes > for the Internet? As a theoretical possibility, there are many more than that, but the actual number is of course vastly less and is climbing at a modest rate (see Geoff Huston's work for the facts). > There was also an RFC (LISP) which provided > a solution for mobility and multihoming/portability LISP has several RFCs and its own WG, but what it actually offers is a solution for BGP-4 scaling. > but > doesn't look to be progressing much in terms of operators > implementing ITR/ETRs in their network ... So is there any > additional document/draft that is looking into > multihoming/portability and prefix scaling issue if all /48s > eventually made it to the IPv6 Internet I'm on record as suggesting that the real-world concern is a maximum of something like 10 million prefixes wanting to be announced in BGP-4. I'll stick to that, but this isn't really the place for that discussion. (similar to how we > have almost all /24s appearing in IPv4 Internet table) No we don't. Brian From nobody Tue Jun 17 14:27:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB2D1A017C for ; Tue, 17 Jun 2014 14:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuQ7a7Bq_b9g for ; Tue, 17 Jun 2014 14:27:26 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E35B1A017B for <6man@ietf.org>; Tue, 17 Jun 2014 14:27:26 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so5966882yha.8 for <6man@ietf.org>; Tue, 17 Jun 2014 14:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jg/tETi0LQjgf7SvkdDwk3Vd+/R7ZLh1abNrDmnLxbA=; b=lZIPy8pG0dbArAyGk9jmE52oRKdd7zbgVumRpIWaJvgdmux/7gTA26RsmMoAgIjzq/ yOcFBoicARWYXo1o/dOCtLZFnl519dNeSxnkXlnLtr6rbqWQOxfn5PIHaJZTqkhXPLU+ a00bNlxhiCvrFeEXV649/D5rJ7dmxZBhkYH2c2J0hZoRtLL/jbZpY6oB1pdPAKyNG+nm QQFKc3Cr5IUaa71fZdDj2sNl7xjjFT+RRk6LW5Fw3/9ar5xS8nvKHmBVh0wLfP9oWKzf 32ac3kS22+KMQS4I3gfeglS7o/tO/zs9Aawwx76T9Z3/kGZKZrUJOR3+cJf0kWznIoZA CxMw== MIME-Version: 1.0 X-Received: by 10.236.84.202 with SMTP id s50mr47703816yhe.77.1403040445720; Tue, 17 Jun 2014 14:27:25 -0700 (PDT) Received: by 10.170.156.130 with HTTP; Tue, 17 Jun 2014 14:27:25 -0700 (PDT) In-Reply-To: <535BD60E-4EE2-4152-A6EB-6CA7D1502F76@employees.org> References:

<53963D6F.9040503@gmail.com> <5397D80B.4060807@gmail.com> <53990EB8.6080608@gmail.com> <539915EB.7030707@gmail.com> <539A0900.9040101@globis.net> <539A8087.5010606@gmail.com> <61F9C47E-AAA2-4AB0-8539-E1123F70CEF1@employees.org> <535BD60E-4EE2-4152-A6EB-6CA7D1502F76@employees.org> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SAB18VsJPuEEARl3mzTi7JgUVBE Cc: =?iso-8859-1?Q?Dan_L=FCdtke?= , Ray Hunter , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:34:27 -0000 --Apple-Mail=_DAB37775-6A98-4F9E-8152-22FA051187DC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > Then I don't understand your Topology #2, it is not in homenet-arch? > Where is it, what is it? what don't you understand? Two ISPs, two CERs, internal router on shared subnet cheers, Ole --Apple-Mail=_DAB37775-6A98-4F9E-8152-22FA051187DC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJToLRbAAoJEFuJXizso86ggwEH/0gySt/Wa3+AuRrlicMZM+mW q7iyqddO5yVe8q4NqxnZjlnwSMjo3Jb1qgMzaXGcUkH8ail1LsEBzXTA151PfN1H K6Hf+y3DVFHJNUQaSnjQLZ6WVHUEksOYkGKsmi2VDcfxfQ2hsW5n+7jDUcM+BbF5 JZa0RUWTDBD+BWbbHkeu0tJYkCE7qE68NFkyc+cI41qKS1W4sgq9uhR0tyYzX3eO 6fTu1GDjttgIK5XpNhgXK97ezP2WA4TCb/dXTjaD6uhi1igOdwrd5Al9pXRQpEeo OlnPiKsLMpa3L34PQbuo+yqT1HuB6OOMZF2V3oESSnaOO/m7YQAPLf9DBKqGv44= =n7+I -----END PGP SIGNATURE----- --Apple-Mail=_DAB37775-6A98-4F9E-8152-22FA051187DC-- From nobody Tue Jun 17 17:32:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19E11A014E for ; Tue, 17 Jun 2014 17:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmBMfvbGldtg for ; Tue, 17 Jun 2014 17:32:18 -0700 (PDT) Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (nm5-vm2.bullet.mail.ne1.yahoo.com [98.138.90.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59881A00ED for ; Tue, 17 Jun 2014 17:32:17 -0700 (PDT) Received: from [98.138.101.132] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 00:32:17 -0000 Received: from [98.138.226.31] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 00:32:17 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 00:32:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403051536; bh=sZVyrXGckZzwDk0jJaSwbvUUFz/rVJ7ljQCVugAyIrs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Q9nXavF7NjB49KpG1XrAhQdS6+bkXsCqwR3DAq6X81UAByE+U6gZ0WRVXMi+BjfQ7+dgglYTNCQvz+By7gRergf/wsnNy9FvvRqRUXyGDiDQ6RYacIB1sFhn45NP1fLx8VPpAa/NSMoAPsgTZIlTVGk7xQN6/PRT25MdW2UMsRo= X-Yahoo-Newman-Id: 990564.46680.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RKKmJoQVM1kOEjwlNxs.DjWp9mptryPZZgDsfZSyqDYAVIA u12MjOno68qAwIyzj3WYqejUBNWhE0hAn_EzCK7f7suIKFFKnhiPRW2xyowP glPQI_W6f7bVBXsXpPKCBDdkAhOLF7wPzLvTm_BU6p1HB0kxeqqURotl_inP qQNHMIC.tq0m2vz7Wt3va.BGVRkFIaBWWFJfaeUG4j2px4JiBpIk6V.SqeVs 2BngrseIDKrYvxHm7SH95DqjYqQrJWAll.61txmoBnJL.f9i08pQ3fxoUaSp jxypCFr3f7xzpdc05gvkT0EwUf8TeC7tjAVn1JNM8wzWVwYVE5rrWV43G478 pdxwEVbgejn0m6Tw6BgffPh2M3CwZ9P2joLGfgKYg8ThY2.LG2ukBbwlrNpE rQWHh7GwJl3Sudkx5uK_bFpQvjyzc7bq8mIuwJL28LLEzcEferYbTL0zGdEo .tuz6mN5F_urc7iyWpLzwm76PTD9P4AGfBGgCp0ksqDrx91lwAEJwDAjtWEz jafP1CoJxoBjDoqrpjtEQkmZcAnGvpnXuW5akLLGFIolQ34UwIKR88Dp8TdE fHaXb3KfSzTY4i8AR76jcKrswmY2.CDfu_0nZBl4luA-- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- X-Rocket-Received: from [10.181.72.50] (osmankh@1.150.115.30 with xymcookie [216.39.61.254]) by smtp202.mail.ne1.yahoo.com with SMTP; 17 Jun 2014 17:32:16 -0700 PDT References: <88FDADC4-3905-4CC6-9096-8FFD5F1EFA0F@yahoo.com> <53A0A4D0.5010800@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53A0A4D0.5010800@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3C0444C6-F468-4329-B9FC-685E417A1C99@yahoo.com> X-Mailer: iPhone Mail (11D201) From: Usman Latif Subject: Re: "portable" IPv6 subnets [was New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt] Date: Wed, 18 Jun 2014 10:32:09 +1000 To: Brian E Carpenter Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/77MXiYGgvMp52AiXxzdd8b_bVg0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 00:32:20 -0000 Thanks Brian for your comments, =46rom both 3177 and 6177 and seeing what is happening in practice, it seems= /48 has been accepted as a commonly agreed prefix length (for now) which is= accepted between ISPs boundaries today. My query was mainly to find out: whether we have accepted the fact that the D= FZ would be open to however many /48s that are advertised to it or is there w= ork happening (or already happened and I am unaware of) in IETF to devise a p= rotocol that could reduce these advertisements while still allowing end-to-e= nd reachability?=20 (route aggregation never seems to be implemented too well in practice and we= saw this in IPv4 already) Regards, Usman > On 18 Jun 2014, at 6:28 am, Brian E Carpenter wrote: >=20 >=20 > Regards > Brian Carpenter > http://orcid.org/0000-0001-7924-6182 >=20 >=20 >=20 >=20 >> On 14/06/2014 10:06, Usman Latif wrote: >> Hi, My comment/query may not be directly related to this >> subject >=20 > No >=20 >> but what is our current position with regards to >> portable IPv6 subnets that are permitted for IPv6 Internet? >=20 > I don't like the word "portable". After all, IPv6 prefixes are > loaned not given. >=20 >> There was one RFC recommending minimum /48 >=20 > You may be thinking of obsolete RFC 3177. Please read RFC 6177, > which is a bit more up to date. >=20 >> If that is the >> case, then we have accepted potentially 2.8 x 10^14 prefixes >> for the Internet? >=20 > As a theoretical possibility, there are many more than that, but > the actual number is of course vastly less and is climbing at a > modest rate (see Geoff Huston's work for the facts). >=20 >> There was also an RFC (LISP) which provided >> a solution for mobility and multihoming/portability >=20 > LISP has several RFCs and its own WG, but what it actually > offers is a solution for BGP-4 scaling. >=20 >> but >> doesn't look to be progressing much in terms of operators >> implementing ITR/ETRs in their network ... So is there any >> additional document/draft that is looking into >> multihoming/portability and prefix scaling issue if all /48s >> eventually made it to the IPv6 Internet >=20 > I'm on record as suggesting that the real-world concern is a > maximum of something like 10 million prefixes wanting to be > announced in BGP-4. I'll stick to that, but this isn't really > the place for that discussion. >=20 > (similar to how we >> have almost all /24s appearing in IPv4 Internet table) >=20 > No we don't. >=20 > Brian From nobody Wed Jun 18 00:58:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4A81A00A9; Wed, 18 Jun 2014 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCKDJ8aLCYdr; Wed, 18 Jun 2014 00:58:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D771A002E; Wed, 18 Jun 2014 00:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-addr-arch-update-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618075817.308.54785.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 00:58:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xd3sttf6dRB3wFuy5NaQDVtsYbE Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 07:58:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Updates to the IPv6 Multicast Addressing Architecture Authors : Mohamed Boucadair Stig Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-05.txt Pages : 9 Date : 2014-06-18 Abstract: This document updates the IPv6 multicast addressing architecture by re-defining the reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 18 01:32:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F18B1A00A6 for ; Wed, 18 Jun 2014 01:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNYF159YA_zT for ; Wed, 18 Jun 2014 01:31:58 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A5C1A008C for ; Wed, 18 Jun 2014 01:31:58 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-135.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 778B36698; Wed, 18 Jun 2014 01:29:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_74B5D6E7-9FC4-4C6D-A679-A9684787FAA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: 6MAN WGLC: draft-ietf-6man-enhanced-dad From: Ole Troan In-Reply-To: <9EFFDD58-67F3-4DA0-8265-698D0641E2C5@employees.org> Date: Wed, 18 Jun 2014 10:29:16 +0200 Message-Id: <7B47E6BC-FB08-4521-8259-C30DBB8C475A@employees.org> References: <9EFFDD58-67F3-4DA0-8265-698D0641E2C5@employees.org> To: 6man WG X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/etd9gR--nUBtLFHd-EByYuKHr4U Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:31:59 -0000 --Apple-Mail=_74B5D6E7-9FC4-4C6D-A679-A9684787FAA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 All, This WGLC has not received a single comment.=20 We will keep this last call open until we get some review of the = document. We also need a volunteer to do a detailed review. Best regards, Ole On 03 Jun 2014, at 17:09 , Ole Troan wrote: > All, >=20 > This message starts a two week 6MAN Working Group Last Call on = draft-ietf-6man-enhanced-dad >=20 > Title : Enhanced Duplicate Address Detection > Author(s) : R. Asati, H. Singh, W. Beebee, E. Dart, W. George, = C. Pignataro > Filename : draft-ietf-6man-enhanced-dad-05 > Pages : 11 > Date : 2014-05-02 > http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad >=20 > as a Proposed Standards document. Substantive comments and statements = of support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on June 17, 2014. >=20 > We need volunteers to do a detailed review of the document. We would = also encourage volunteers to act as document shepherds. Please contact = the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_74B5D6E7-9FC4-4C6D-A679-A9684787FAA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJToU3dAAoJEFuJXizso86g464H/jjR8qbuWoJ1WJ8KIsC28GKt 4TG0pOevgsYwfOYbcju66j1BkMKV6jzCJIND4qjf6ROvPyCLcfpunOVUdHZPqWiy 9+JaL82+GgKZggtQEDj0nr+WHuKsjXc8jSPPR0CPFp/hKW0KUi37SVpN2fyMXxA/ DhFqJdKBUJnBs2zEubVDRZH+VxpzeygkDa5gUE8T4frFlLmJc7HOm4x50fZteuek xCdcKVp2ZrUxJ4Jk+H11r7F+jtcdFR5Ii/usa02Rum6k1CGHEiW2v9/g5c6UwpIv jKK12QkiYDr2u+bNodlyY0z9LWk3RBqbIXk2zK+JxO+xNIDx/ncHsma0yyHHD1o= =t0HJ -----END PGP SIGNATURE----- --Apple-Mail=_74B5D6E7-9FC4-4C6D-A679-A9684787FAA3-- From nobody Wed Jun 18 08:26:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3A1A0269 for ; Wed, 18 Jun 2014 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeA4jSiqz1Mx for ; Wed, 18 Jun 2014 08:26:25 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6971A005B for ; Wed, 18 Jun 2014 08:26:24 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1354486wib.13 for ; Wed, 18 Jun 2014 08:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=S9IFSYdUZt7w7CMknF34QhpJ5dNwhhPVkhRcCqqeW80=; b=J1vF0GJ+CTeL93QWFvYO2OaHb5jClOXDwgGFAd8Bb2AfJFxN2GYApqGwExgiMzC8r0 TMbe4z9mWvfkp1WuMpGvOrUBmon4Ot47mWQP7bfe+CBV6nzzZX5ubaydW1O3pz8v0uK6 kXViamesvIooCUfUhK1NPknqtJWMkGbk9aZAjNUE/0gaDnqyAfyzuxvCbjUBMsf/wAxW LBrzO5ZUoTtCEjrI9nSYpLuy4+BxJGa00mArXLh957T9NSQi4ZcIJGtjqBwwbG6pJbUT 5tpXwdcScTOunqp2JVRJGa+0W/J7waQ6pxq2clEsMTWEdr568CF5uMCCTvupmGqAOugJ JAjQ== MIME-Version: 1.0 X-Received: by 10.180.14.65 with SMTP id n1mr6077342wic.4.1403105183170; Wed, 18 Jun 2014 08:26:23 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Wed, 18 Jun 2014 08:26:23 -0700 (PDT) In-Reply-To: <7B47E6BC-FB08-4521-8259-C30DBB8C475A@employees.org> References: <9EFFDD58-67F3-4DA0-8265-698D0641E2C5@employees.org> <7B47E6BC-FB08-4521-8259-C30DBB8C475A@employees.org> Date: Wed, 18 Jun 2014 08:26:23 -0700 X-Google-Sender-Auth: 1zfN0Im-KsRpD32U9iyFKtEFSD8 Message-ID: Subject: Re: 6MAN WGLC: draft-ietf-6man-enhanced-dad From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cLelGsvZxmbUVL2mwQHUZIja0uA Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 15:26:25 -0000 At Wed, 18 Jun 2014 10:29:16 +0200, Ole Troan wrote: > This WGLC has not received a single comment. > We will keep this last call open until we get some review of the document. We also need a volunteer to do a detailed review. I've read the draft on the LC, but didn't find anything obviously wrong or any useful comments that could improve it. I didn't explicitly respond to the LC since I generally don't like to respond with a one-liner like "no objection":-). I also didn't volunteer for a detailed review as I didn't seem to be able to provide any non-trivial feedback. But if there's no other (and better) volunteer I'll give another, a bit closer read, and see if I can say something more meaningful. -- JINMEI, Tatuya From nobody Wed Jun 18 11:45:11 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2121A02C2; Wed, 18 Jun 2014 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrJYJmSa_HPX; Wed, 18 Jun 2014 11:45:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569BE1A0016; Wed, 18 Jun 2014 11:45:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Updates to the IPv6 Multicast Addressing Architecture) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140618184506.791.21973.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 11:45:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/bGAsthGejoJEkYDe1rhThErPqM4 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:45:07 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Updates to the IPv6 Multicast Addressing Architecture' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the IPv6 multicast addressing architecture by re-defining the reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 19 05:08:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7C1A0382 for ; Thu, 19 Jun 2014 05:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1_sK7nMgi18 for ; Thu, 19 Jun 2014 05:08:10 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545521A037F for ; Thu, 19 Jun 2014 05:08:10 -0700 (PDT) Received: from dhcp-10-54-73-46.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 64E3C661B; Thu, 19 Jun 2014 05:08:07 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_DEAA2D6C-BB02-4893-8E5E-8D61527F8A75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: draft-ietf-6man-resilient-rs update Date: Thu, 19 Jun 2014 14:08:05 +0200 Message-Id: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> To: 6man WG , draft-ietf-6man-resilient-rs@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/wMHM3QZuIALTXfItmLbffmuxYk8 Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:08:22 -0000 --Apple-Mail=_DEAA2D6C-BB02-4893-8E5E-8D61527F8A75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii all, we have had this document in a WGLC for quite a while. there has been = one outstanding issue. the document as currently written states: Abstract: Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intended to work even in such scenarios. Introduction: b. Access networks/links that turn off periodic RAs and only send RAs in response to RSs. In this case, if the link between the Access Point (AP) and the host comes up before the link between the AP and the Controller/Router, the host will never be able to connect. This technique of turning off periodic RAs is commonly used in several wireless LAN and datacenter networks to reduce the amount of multicast traffic. in the specification part of the document it states: On multicast-capable links, the hosts following this specification SHOULD stop retransmitting the RSs when Router Discovery is successful (i.e. an RA with a non-zero Router Lifetime that results in a default route is received). as written a host connected to a link with the properties described in = b, would lose its default router after the initial RA lifetime, and = would not recover. there are two solutions to this: 1) remove the text in the abstract and introduction implying that this = is a solution to links with multicast RA turned off 2) modify the algorithm to restart router solicitations when required after discussing this issue with the authors, there appears to be = agreement to we resolve this issue by focusing the document on initial = connection to the link only (1). unless this is contentious, the authors will publish an updated revision = with these changes, that we'll run a short WGLC on, and then we will = advance the document to the IESG. Best regards, Ole --Apple-Mail=_DEAA2D6C-BB02-4893-8E5E-8D61527F8A75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTotKlAAoJEFuJXizso86gRwoIAIYedmDaNlWc3quQwnGk02hs 07KwYCPN65Qz4Amsb/cIwfgWPQMHnuvnMEucqYFUdLeEnykBLmo6U4uc3oAMPsLz gfXOvCnoSW2g3h3cEq5oiXizdQl1j+5DLwXBOe2odhvGYebvRCx5enA0vSLCYfSF UWIXvAr+UY0cTFtjzA4+cefuNmaZrSZP2wvMYlpTUlggOWu6MM0ZeerRywwm4WgL GaNsKXhbN8Szj7XI2OGwstoD5BEHjWyv14Qk1HUp8jPyW/DbND/PeC/Jbu/hN1Tf wDWbmMCXK1Ngqf/UWnpnFnCGtuqim+x30HWWiq3g5oALWrZBM1ppwDNnjezlUsM= =nySq -----END PGP SIGNATURE----- --Apple-Mail=_DEAA2D6C-BB02-4893-8E5E-8D61527F8A75-- From nobody Thu Jun 19 07:27:20 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811021A0213 for ; Thu, 19 Jun 2014 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6621AzKZHod for ; Thu, 19 Jun 2014 07:27:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4931A03BD for ; Thu, 19 Jun 2014 07:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3164; q=dns/txt; s=iport; t=1403188037; x=1404397637; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Dq3F+2Vu+K+ZtpdubEbM1TUuOBrvgEBxQWeoaVVonDM=; b=I3Na6DDiFytNLFnZ1FziA6Dsu2l13MmyJj8DM+qJ64evFTMEESozxRnK V9MVISIgoCN1ptZSyHohtaJva2oQIGc7inP8ymxyMlqSE2Gq6/QeEOuAL qkgAoPEbLLktvwMm0LyXSTG8oQK5gqeyZvVnAB9CFomHoHcYd/JuRDFN6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAMLyolOtJA2N/2dsb2JhbABZgw1SWqoVAQEBAQEBBQGZJwGBBhZ1hAQBAQRuCxACAQgOODIlAgQBDQWIQg3OKheFYokUB4RDBIoFkD6BQ5IVg0KCMA X-IronPort-AV: E=Sophos;i="5.01,507,1400025600"; d="scan'208";a="54416813" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 19 Jun 2014 14:27:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5JERFqA003751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 14:27:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 09:27:15 -0500 From: "Eric Vyncke (evyncke)" To: Ole Troan , 6man WG Subject: Re: 6MAN WGLC: draft-ietf-6man-enhanced-dad Thread-Topic: 6MAN WGLC: draft-ietf-6man-enhanced-dad Thread-Index: AQHPfz3QMBF72mdTi0upuWFrHdfmTpt5C/yA Date: Thu, 19 Jun 2014 14:27:14 +0000 Message-ID: References: <9EFFDD58-67F3-4DA0-8265-698D0641E2C5@employees.org> In-Reply-To: <9EFFDD58-67F3-4DA0-8265-698D0641E2C5@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <647098C4DED18F4D8CDC0876782A8D63@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xWvM4a7nUz8LYnWCJ2pyaAR6cVE Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:27:19 -0000 So let's go for it... Minor comment, why is Carlos not in the same block of Cisco authors? I would prefer to have section 1 (terminology) after section 2 (introduction). Section 1: - first bullet s/Note even Optimistic/Note: even Optimistic/ - loopback does not always loop between the same physical interface... Think about a layer-3 switch with two different layer-2 interface for the same layer-3 interface, looping the layer-2 interfaces will also introduce a loop - NS(DAD) should we add the destination at layer-2 and layer-3 being a mcast? Section 2 should be a real introduction, i.e., more the 'problem description' in a new section ;-) - "The interface issues a NS for the IPv6 link-local address DAD" why restricting to LLA only? GUA/ULA have the same problem - the last paragraph would benefit if rewritten, not really easy to understand and ASCII art would help, also state that the cable-modem are in bridge mode - s/one layer 3 interface/one layer-3 interface/ - s/100 thousand/hundred thousands/ Section 3.1 - this I-D would benefit of a better punctuation, such as s/simplest the mitigation/simplest; the mitigation/ - not sure whether a core router 'SHOULD' support disabling DAD... Consequences could be catastrophic for a core router Section 3.2: - s/layer 2 protocols/layer-2 protocols/ (to be applied multiple times) - add using the source MAC address as differentiator example? Section 4: - should we add 'mitigation 'to the section title to be similar to section 3? - s/sufficiently large for nonce collisions/sufficiently large for avoiding nonce collisions/ Section 4.2: - split the paragraph in two pieces: one for the sheer sending and one for repeating the sending of the probes - not sure why enhanced DAD should be optional... Why not making it mandatory? Section 4.3: - s/compares the nonce, if any, is included in the message/compares the nonce included in the message, if any,/ - not sure why the last sentence is there as it is relevant to section 4.2 Section 6: - should we add that the nonce does not protect against the DoS caused by a rogue node replying by fake NA to all DAD probes? Hope this helps -=E9ric On 3/06/14 17:09, "Ole Troan" wrote: >All, > >This message starts a two week 6MAN Working Group Last Call on >draft-ietf-6man-enhanced-dad > > Title : Enhanced Duplicate Address Detection > Author(s) : R. Asati, H. Singh, W. Beebee, E. Dart, W. George, C. >Pignataro > Filename : draft-ietf-6man-enhanced-dad-05 > Pages : 11 > Date : 2014-05-02 > http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad > >as a Proposed Standards document. Substantive comments and statements of >support for advancing this document should be directed to the mailing >list. Editorial suggestions can be sent to the authors. This last call >will end on June 17, 2014. > >We need volunteers to do a detailed review of the document. We would also >encourage volunteers to act as document shepherds. Please contact the >chairs directly. > >Regards, > >Bob Hinden & Ole Tr=F8an From nobody Thu Jun 19 09:17:00 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F641A03F9 for ; Thu, 19 Jun 2014 09:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjOt4GjMXM2o for ; Thu, 19 Jun 2014 09:16:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709B41A03EC for ; Thu, 19 Jun 2014 09:16:49 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 19 Jun 2014 16:16:47 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.155]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.155]) with mapi id 15.00.0954.000; Thu, 19 Jun 2014 16:16:47 +0000 From: Dmitry Anipko To: Ole Troan , 6man WG , "draft-ietf-6man-resilient-rs@tools.ietf.org" Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40y Date: Thu, 19 Jun 2014 16:16:46 +0000 Message-ID: <1403194605449.87135@microsoft.com> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> In-Reply-To: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(189002)(199002)(92566001)(92726001)(99396002)(85306003)(80022001)(20776003)(77096002)(74502001)(31966008)(74662001)(21056001)(79102001)(86362001)(101416001)(64706001)(106116001)(83072002)(81542001)(86612001)(85852003)(81342001)(19580395003)(54356999)(76176999)(95666004)(2656002)(50986999)(46102001)(36756003)(87936001)(77982001)(105586002)(76482001)(83322001)(99286002)(19580405001)(4396001)(22906005)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hbgAoPFEUOUjN75Ixt631DMhBO8 Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:16:59 -0000 My impression from the discussion in London that the consensus was closer t= o (2) than (1) - that on such links the hosts should be allowed to restart = transmissions in a reasonable / rate-limited manner, when connectivity para= meters expire. And that we should add MAY text for that.=0A= =0A= The minutes seem to be consistent with my impression:=0A= =0A= =0A= Andrew: I agree with both Erik and Lorenzo. We should not explicitly=0A= prohibit hosts from 1.b.=0A= =0A= Suresh: If we keep 1.b., we would need to address it.=0A= =0A= Andrew: Don't prohibit it, so that it may be addressed in another=0A= document.=0A= ...=0A= =0A= Dave Thaler: Keep scenario 1.b. Do constraints on rate-limiting. We have=0A= cases where ND varies by a specific ling-layer. Indeed, the mecha= nisms=0A= in this document comes from one of those documents. I think I'm i= n=0A= agreement with what I think is the consensus.=0A= =0A= =0A= ________________________________________=0A= From: Ole Troan =0A= Sent: Thursday, June 19, 2014 5:08 AM=0A= To: 6man WG; draft-ietf-6man-resilient-rs@tools.ietf.org=0A= Cc: <6man-chairs@tools.ietf.org>=0A= Subject: draft-ietf-6man-resilient-rs update=0A= =0A= all,=0A= =0A= we have had this document in a WGLC for quite a while. there has been one o= utstanding issue.=0A= the document as currently written states:=0A= =0A= Abstract:=0A= Furthermore, on some links, unsolicited multicast=0A= Router Advertisements are never sent and the mechanism in this=0A= document is intended to work even in such scenarios.=0A= =0A= Introduction:=0A= b. Access networks/links that turn off periodic RAs and only send=0A= RAs in response to RSs. In this case, if the link between the=0A= Access Point (AP) and the host comes up before the link between=0A= the AP and the Controller/Router, the host will never be able to=0A= connect. This technique of turning off periodic RAs is commonly=0A= used in several wireless LAN and datacenter networks to reduce=0A= the amount of multicast traffic.=0A= =0A= in the specification part of the document it states:=0A= On multicast-capable links, the hosts following this specification=0A= SHOULD stop retransmitting the RSs when Router Discovery is=0A= successful (i.e. an RA with a non-zero Router Lifetime that results=0A= in a default route is received).=0A= =0A= as written a host connected to a link with the properties described in b, w= ould lose its default router after the initial RA lifetime, and would not r= ecover.=0A= =0A= there are two solutions to this:=0A= 1) remove the text in the abstract and introduction implying that this is a= solution to links with multicast RA turned off=0A= 2) modify the algorithm to restart router solicitations when required=0A= =0A= after discussing this issue with the authors, there appears to be agreement= to we resolve this issue by focusing the document on initial connection to= the link only (1).=0A= =0A= unless this is contentious, the authors will publish an updated revision wi= th these changes, that we'll run a short WGLC on, and then we will advance = the document to the IESG.=0A= =0A= Best regards,=0A= Ole=0A= =0A= From nobody Thu Jun 19 12:38:58 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D691A0308 for ; Thu, 19 Jun 2014 12:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0_1Gv97DxFi for ; Thu, 19 Jun 2014 12:38:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7CD1A019A for ; Thu, 19 Jun 2014 12:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6432; q=dns/txt; s=iport; t=1403206734; x=1404416334; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=pKOG0FZ7LF8RGSt4dgLY5DubD1AqUZV3+KMofJiZQsw=; b=QFHQ8kqOwu2lpbhURI934Anw814Er90kAhsUHJu7psXwIF4O7x2qWu94 DJEQkDeQpM2XoijEY+5h4dMZUmvr/eXKMOVxhc/LcaG6OA6syrn+AWAr0 0tLADZCgojIEVLzyuSBlBNmYd8bVs1jVyC6booidufLqGPMGA7599tw+c 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAP06o1OtJA2D/2dsb2JhbABZgw1SWrwKhz8BgQ8WdYQDAQEBAgIBAQFrCwwGAQgRBAEBCx0uCxQJCQEEAQ0FCAESiCcNzQMXjhMhETENgyeBFgSFXoQnkgGSFYNCbIEEQA X-IronPort-AV: E=Sophos;i="5.01,508,1400025600"; d="scan'208";a="54488937" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 19 Jun 2014 19:38:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5JJcrrn001732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 19:38:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 14:38:53 -0500 From: "Hemant Singh (shemant)" To: "Eric Vyncke (evyncke)" , Ole Troan , 6man WG Subject: RE: 6MAN WGLC: draft-ietf-6man-enhanced-dad Thread-Topic: 6MAN WGLC: draft-ietf-6man-enhanced-dad Thread-Index: Ac+L9hHdEXhTQbNlRhuL8hAjps15hQ== Date: Thu, 19 Jun 2014 19:38:52 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8915545904@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/bwWXiDM9mg1vr2Tmqla3YSRWFUo Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive:

Low Power and Lossy Networks plugfest at IETF90

Goals=

Complementary angles

Focus 1: Interoperation

Focus 2: Demonstration

Focus= 3: Tools

= Important Dates

Tentative Agenda from 9:00 to 13:00

For M= ore Information

= Note Well

About=

Low Power and Lossy Networks plugfest at IETF90

Goals=

Complementary angles

Focus 1: Interoperation

Focus 2: Demonstration

Focus= 3: Tools

= Important Dates

Tentative Agenda from 9:00 to 13:00

For M= ore Information

= Note Well

About=