From nobody Thu Apr 3 02:59:44 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 5A7981A0169 for ; Thu, 3 Apr 2014 02:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8AYN4qGJuTxM for ; Thu, 3 Apr 2014 02:59:37 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03F1A0120 for ; Thu, 3 Apr 2014 02:59:37 -0700 (PDT) Received: from [98.139.212.153] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 09:59:33 -0000 Received: from [98.139.212.235] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 09:59:33 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 09:59:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35427.40212.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 54925 invoked by uid 60001); 3 Apr 2014 09:59:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396519172; bh=Rme90RX86cnkL5Z6M28VvdUWUIRiofBNjOocdxR4cL0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EmTwiNLeoUnpVQz7RU5SPekhHQWKnKO7TOsLDHyLHMNruabQNWPPgwKc9jHWyDQeUiy/Bbu1plhwkgimg//JYoczVciUdZfO6oEhEtDEmqgM2YSJOd0Qz4pLKHsIFWbgajOcbvcUAu74p7/zUVhEjwQOEjHrl7KjOrtawawo3zk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=y4BMFbj6RRCXZLIuAua7qy23ueqs0p34qsHdnmXA7O/a2cfAt3v03vhtb0m6pnK8Zh9OOhi5RCGYR7ThSwaUS0SwbEoRViB7s/he/f8bINOLmTOYpQOpviZ3JrmByKHjzeh2HFoD79F52h2LMOhGZLwcAjUIueIfrRfEof8POUk=; X-YMail-OSG: gbAd.KUVM1nBLeQhkxP0H3.WmoE1VRE.vtQ.zDb_litpYco 5hsvRBETflZai8rBL5xFW5uolfVS59GIvvu3R2M5cw_z8AXiqV9QvJfn7H.v CRZeJlb.uc.RmQHMJlvlYyfhxqqua2pb.M.CAOAnAHPJa6hsiTjL.QPKOx7Z pMu0FfRhZ31qdJX0BtE1x16JGiNdCFy53qddpCAtZzYF77i1toxieEB0mliP nIrMUU8p6k5mPDE7hIaC6fa4nCoifulmJyST4l.ohSAiHoR1m1gmXe.w_rzg LSfg5QJ1A09BrSPBTJAZCSrQ.W8wHf6aySP0oQVfdBEF5yxi3pGOEtFL7Gh5 TnGZnimudXQGplGu7yalaP.SlaRjThkRR_Db7V5tHTLABENa80kx4Fhwpq_o kfGg8WDhq3bIr1s2zEuJNFbZJg4P5GOFLOYdkNu_352NlgneD5eldobK2NG3 mp8PlxjpQFt67FMolk5vuXm_i1XXMBrRTwJBfyOfQz6G4WgnYP1hMthzTQfn 7Ie5MmRWvw.IdAhBxWNo5GX6OqItMRwqVAalaPwvHPLn6sFfaRi4tSWX8C0r b1g9ef2VY6fU66wDYbJ_ft.3uXsP8FCQDnp_UXg6zDCG.YyGRaZhegKRWBUf DHoLdUvgYNwBaYU76TqcOWOsW Received: from [154.72.133.4] by web162005.mail.bf1.yahoo.com via HTTP; Thu, 03 Apr 2014 02:59:32 PDT X-Rocket-MIMEInfo: 002.001, SSB0cmllZCBpdCBpbiBvdXIgVW5pdmVyc2l0eSBsYWIgb24gY2lzY28gcm91dGVycyBhbmQgaXQgd29ya3MuIEkgaG93ZXZlciBmZWFyIGZvciBwcml2YWN5LgpSZWdhcmRzClRhbmRhbmt3YSBTLgoKCk9uIFN1bmRheSwgTWFyY2ggMzAsIDIwMTQgOTo1MyBBTSwgSGlyb2tpIFNhdG8gPGhyc0BGcmVlQlNELm9yZz4gd3JvdGU6CiAKc3RoYXVnQG5ldGhlbHAubm8gd3JvdGUKwqAgaW4gPDIwMTQwMzI4LjE1MjAyMi44NTM3NDc2OC5zdGhhdWdAbmV0aGVscC5ubz46CgpzdD4gPiA.IGl0IGlzIHN1cHBvcnRlZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <35E2D21C-FDD6-49B6-87D2-6261B2933815@employees.org> <53357DE8.8030805@viagenie.ca> <20140328.152022.85374768.sthaug@nethelp.no> <20140330.022403.1289956794479774486.hrs@allbsd.org> Message-ID: <1396519172.81079.YahooMailNeo@web162005.mail.bf1.yahoo.com> Date: Thu, 3 Apr 2014 02:59:32 -0700 (PDT) From: Tandankwa STANLEY Fon Subject: Re: fe80::/128 To: Hiroki Sato , "sthaug@nethelp.no" In-Reply-To: <20140330.022403.1289956794479774486.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1328350513-989962757-1396519172=:81079" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mYV0IQuxcELX7hN4d2Ks4PUvLiI Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Tandankwa STANLEY Fon List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:59:41 -0000 ---1328350513-989962757-1396519172=:81079 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I tried it in our University lab on cisco routers and it works. I however f= ear for privacy.=0ARegards=0ATandankwa S.=0A=0A=0AOn Sunday, March 30, 2014= 9:53 AM, Hiroki Sato wrote:=0A =0Asthaug@nethelp.no wrot= e=0A=A0 in <20140328.152022.85374768.sthaug@nethelp.no>:=0A=0Ast> > > it is= supported for the platform I know best, but require manual configuration a= s far as I remember.=0Ast> >=0Ast> > Adding to the "facts": on KAME/BSD, yo= u need to manually add the=0Ast> > subnet-router anycast address to the int= erface for it to work. So, it=0Ast> > can be "supported" if the administrat= or needs it. Makes total sense IMHO.=0Ast> >=0Ast> > Previous discussion ab= out this here:=0Ast> > http://comments.gmane.org/gmane.ietf.ipv6/18602=0Ast= >=0Ast> So maybe the relevant questions are:=0Ast>=0Ast> 1. Is there any pl= atform which enables the subnet router anycast=0A=0Ast> address by default?= =0Ast>=0Ast> 2. Does anybody use the subnet router anycast address on a reg= ular=0Ast> basis? Presumably then for something more useful than Ole Troan'= s ping=0Ast> example?=0A=0AI sometimes use subnet router anycast adddress a= s the default router=0Aon BSD when RA cannot be used on that link.=A0 First= I used a fixed=0Alink-local address like fe80::1 for this purpose but subn= et router=0Aanycast adddress is useful when there are multiple routers on t= hat=0Alink for fail-over.=0A=0A-- Hiroki=0A=0A=0A--------------------------= ------------------------------------------=0AIETF IPv6 working group mailin= g list=0Aipv6@ietf.org=0AAdministrative Requests: https://www.ietf.org/mail= man/listinfo/ipv6=0A-------------------------------------------------------= ------------- ---1328350513-989962757-1396519172=:81079 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I tried it in our University lab on cisco routers and it work= s. I however fear for privacy.
Regards
Tandankwa S.
On Sunday, = March 30, 2014 9:53 AM, Hiroki Sato <hrs@FreeBSD.org> wrote:
sthaug@nethelp.no<= /a> wrote
  in <
20140328.152022.85374768.sth= aug@nethelp.no>:

st> > &g= t; it is supported for the platform I know best, but require manual configu= ration as far as I remember.
st> >
st> > Adding to the "facts": on KAME/BSD, you need to manually add = the
st> > subnet-router anycast address to the inte= rface for it to work. So, it
st> > can be "supporte= d" if the administrator needs it. Makes total sense IMHO.
st> >
st> > Previous discussion about this h= ere:
st> > http://comments.gmane.= org/gmane.ietf.ipv6/18602
st>
st= > So maybe the relevant questions are:
st>
st> = 1. Is there any platform which enables the subnet router anycast

st> address by d= efault?
st>

st> 2. Does any= body use the subnet router anycast address on a regular
s= t> basis? Presumably then for something more useful than Ole Troan's pin= g
st> example?

I= sometimes use subnet router anycast adddress as the default router
on BSD when RA cannot be used on that link.  First I used = a fixed
link-local address like fe80::1 for this purpose= but subnet router
anycast adddress is useful when there= are multiple routers on that
link for fail-over.

-- Hiroki


--= ------------------------------------------------------------------
IETF IPv6 working group mailing list
ip= v6@ietf.org
Administrative Requests: htt= ps://www.ietf.org/mailman/listinfo/ipv6
-------------= -------------------------------------------------------
<= /div>

---1328350513-989962757-1396519172=:81079-- From nobody Thu Apr 3 12:52:09 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 E87001A010B for ; Thu, 3 Apr 2014 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 owDJxrPQxMmy for ; Thu, 3 Apr 2014 12:52:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id A55E01A0109 for <6man@ietf.org>; Thu, 3 Apr 2014 12:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1396554718; x=1397764318; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=q9GlGdW2xE0wgo50EhAVHle4WD6ceQ0nyJmjdFxI3oA=; b=Kz+xJdIftzhK7xev4vzkdGK4NXuae/EEgZh+vXFgRA5K98SVBTxa2QaY oyd7mO/EzYjzEhnzq+kL8Am7GrkVf7n2I4X6Ecv20doaHMSyI6DwZcRCn wFivmLVwFLQf7JSQ7tfFv/VKd8nyYyx2JpfQEUp+VsmJd0ZYDwrQIIb7G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAPC6PVOtJV2c/2dsb2JhbABYgmUhO1fDfIEgFnSCJwEEOj8SASoUQiAGAQQODQGHcAEMzykXjkAxgyuBFASaD5EKgzCCKw X-IronPort-AV: E=Sophos;i="4.97,789,1389744000"; d="scan'208";a="32687835" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 03 Apr 2014 19:51:58 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s33JpwsK032195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Thu, 3 Apr 2014 19:51:58 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 14:51:58 -0500 From: "Nobo Akiya (nobo)" To: "6man@ietf.org" <6man@ietf.org> Subject: IPv6 Router Alert Option for LSP Ping/Trace Thread-Topic: IPv6 Router Alert Option for LSP Ping/Trace Thread-Index: Ac9PcLCqgVfRefeyS6OVvOhidJGsKA== Date: Thu, 3 Apr 2014 19:51:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] 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/cNt7zQwkjJODuOlD3sYaT-zFly8 Cc: "Kamran Raza \(skraza\)" 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, 03 Apr 2014 19:52:08 -0000 Hi 6MANers, One commonly deployed MPLS OAM tool is LSP Ping/Traceroute (RFC4379). http://datatracker.ietf.org/doc/rfc4379/?include_text=3D1 One of the mandatory requirement from the draft is that Router Alert option= MUST be set in the IP header. For IPv4, value zero(0) is used. https://www.iana.org/assignments/ipv4-routeralert-values/ipv4-routeralert-v= alues.xhtml For IPv6 ... as vendors are starting to implement MPLS on IPv6 control plan= e, we have realized that there is no generic IPv6 Router Alert code point w= hich can be used by LSP Ping/Traceroute. http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-va= lues.xhtml 1. There's no need for a generic code point in IPv6 Router Alert option. 2. There's probably no need for a generic OAM code point in IPv6 Router Ale= rt option. 3. There is, however, a need for a code point for LSP Ping/Traceroute, if t= he tool is to comply with RFC4379. I spoke to authors of RFC4379, and was suggested that (3) is the way to go. But before going ahead to write a small draft for this code point allocatio= n (intended for MPLS WG as it updates RFC4379), I wanted to see if 6MANers = had any comments/questions/concerns with this. Appreciate your time in advance. -Nobo From nobody Thu Apr 3 13:12: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 817801A012F for ; Thu, 3 Apr 2014 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vebLap2XsViL for ; Thu, 3 Apr 2014 13:12:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3B1A011E for ; Thu, 3 Apr 2014 13:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1396555930; x=1397765530; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=q9GlGdW2xE0wgo50EhAVHle4WD6ceQ0nyJmjdFxI3oA=; b=lzrlZ6vkYdqGZkf8QY7F1OAlqH+06wsKtPIuTFFooCnBJF0iTkzPPnC8 WREoCcbPR9pCsE8jEjRznfD9G39NZyBW3BkytrI4J1kcV/zkpJV7v7/gA iUzGCOj2um4g3jHEVK/rt35V5FyZ0XQn9Dv5u1EBIIQxELtzUCzG0SYuM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAAfAPVOtJV2b/2dsb2JhbABYgmUhO1fDfIEgFnSCJwEEOj8SASoUQiAGAQQODQGHcAEMzzcXjkAxgyuBFASaD5EKgzCCKw X-IronPort-AV: E=Sophos;i="4.97,790,1389744000"; d="scan'208";a="32680662" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 03 Apr 2014 20:12:10 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s33KC9nO032382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Apr 2014 20:12:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 15:12:09 -0500 From: "Nobo Akiya (nobo)" To: "ipv6@ietf.org" Subject: IPv6 Router Alert Option for LSP Ping/Trace Thread-Topic: IPv6 Router Alert Option for LSP Ping/Trace Thread-Index: Ac9PePBTho3auB2vTC2RayWi/qmK9Q== Date: Thu, 3 Apr 2014 20:12:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] 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/XgTw5Xo8pB4w6m_MsbVRKFPicvk Cc: "Kamran Raza \(skraza\)" 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, 03 Apr 2014 20:12:44 -0000 Hi 6MANers, One commonly deployed MPLS OAM tool is LSP Ping/Traceroute (RFC4379). http://datatracker.ietf.org/doc/rfc4379/?include_text=3D1 One of the mandatory requirement from the draft is that Router Alert option= MUST be set in the IP header. For IPv4, value zero(0) is used. https://www.iana.org/assignments/ipv4-routeralert-values/ipv4-routeralert-v= alues.xhtml For IPv6 ... as vendors are starting to implement MPLS on IPv6 control plan= e, we have realized that there is no generic IPv6 Router Alert code point w= hich can be used by LSP Ping/Traceroute. http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-va= lues.xhtml 1. There's no need for a generic code point in IPv6 Router Alert option. 2. There's probably no need for a generic OAM code point in IPv6 Router Ale= rt option. 3. There is, however, a need for a code point for LSP Ping/Traceroute, if t= he tool is to comply with RFC4379. I spoke to authors of RFC4379, and was suggested that (3) is the way to go. But before going ahead to write a small draft for this code point allocatio= n (intended for MPLS WG as it updates RFC4379), I wanted to see if 6MANers = had any comments/questions/concerns with this. Appreciate your time in advance. -Nobo From nobody Thu Apr 3 13:29: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 ACA0D1A005F for ; Thu, 3 Apr 2014 13:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 NOmdA0HUUCd9 for ; Thu, 3 Apr 2014 13:29:19 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2C51A0104 for ; Thu, 3 Apr 2014 13:29:18 -0700 (PDT) Received: from [66.196.81.174] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 20:29:13 -0000 Received: from [98.139.212.244] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 20:29:13 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 20:29:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 892564.4350.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 1052 invoked by uid 60001); 3 Apr 2014 20:29:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1396556953; bh=UF7xfbXpAvzmm8u39+mAP7GxZVP9d4WYSgYM/eNF9So=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IaC+W2kiALH1zBT+GWYRJf2sScPfwcGHTBZ0IPs1BFDosP8hquwWm5jNVKdb+4ofwART0A2HmKufCZ3JXhJpsMCpcnWDa4ppz5lldRJY2EqYnBR9Qq8c9xJXgBDSvaKBzusUKZGAqtJZuLNq6VFzWpihbPnCWSOkYqL8s7/Z6y4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qIZHkrF5Vip7kFZMXdAYJ+w1ag/mnRXYwID77Hpozg1zL5XVOTN6CWyJzbjz0VfLgjoCSL9JmfC2L4lJbtkX+QvLJT9rReSfZIS14BJdsYFgkNB5r5byZM3pLA0Eth8mXzekwTi/rlDZsPLfMHWCm81z63YkbJjIE3FIsmUgGKc=; X-YMail-OSG: pAUopZ8VM1mvxPeR9csIRNSj_n8Hd42sH.MsvuFtECDMm3y 5EEY0FX8zzhfLljoitOoD03QoxW1Y0S8Fd47KQgZP7ZskvXLT6pGW.ZowNf_ QQh6T_4ZuZ_UbL5EYT0aB4d8PAv_LKcb5RbGuDYj5Aaj1TM8LTUUEUvEygcm tihJvWDXqonIpEOCJoO3XTL1Nx9i9Dwo8pwoM_JNsmJ0_O_IalbtlmI2pKgg 6fBhTOtACd2yWwiDnAUcieTKOE3C3Bn4OctXSPFVhh9f21w329iPuwdczbb9 dsUT6mhpP95yT7PrRXyuWfZVpThpR1q6iKxV_VIc9neaWdaKC34kOimYICE9 Dec0df1XX.0RI.WTpuaPP3KDdlHtup1wFX8eFT7BMK6H3PHDZs3rdbKTptuO PXctP6sd_hP8KvzRlJ3YMmzz4kri7Jh9cFMwj2Y4h7EJeiSUhDDcYJJdg_2e _5U1PTwSwh4FCUqeWfyGBpd.BHNfiI4G2gvhzXrzKgVyWc5PguWgkR2t4dGH 75PxRoyIEQfTjL.j2b4uFUH0ikVskHDyVCSY6Sc29D.Xn5CyRtft2EEs- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Thu, 03 Apr 2014 13:29:13 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBIaXJva2kgU2F0byA8aHJzQEZyZWVCU0Qub3JnPgo.IFRvOiBzdGhhdWdAbmV0aGVscC5ubwo.IENjOiBpcHY2QGlldGYub3JnCj4gU2VudDogU3VuZGF5LCAzMCBNYXJjaCAyMDE0IDQ6MjQgQU0KPiBTdWJqZWN0OiBSZTogZmU4MDo6LzEyOAo.IAo.IHN0aGF1Z0BuZXRoZWxwLm5vIHdyb3RlCj4gwqAgaW4gPDIwMTQwMzI4LjE1MjAyMi44NTM3NDc2OC5zdGhhdWdAbmV0aGVscC5ubz46Cj4gCjxzbmlwPgoKPiBzdD4KPiBzdD4gU28gbWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <35E2D21C-FDD6-49B6-87D2-6261B2933815@employees.org> <53357DE8.8030805@viagenie.ca> <20140328.152022.85374768.sthaug@nethelp.no> <20140330.022403.1289956794479774486.hrs@allbsd.org> Message-ID: <1396556953.76809.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Thu, 3 Apr 2014 13:29:13 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: fe80::/128 To: Hiroki Sato , "sthaug@nethelp.no" In-Reply-To: <20140330.022403.1289956794479774486.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4jD_lZuABzq6u-TLZLL14hAPWxY Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:29:22 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Hiroki Sato =0A> To: sthaug@nethelp.no=0A> Cc: ipv6@ietf.org=0A> Sent: Sunday, 30 = March 2014 4:24 AM=0A> Subject: Re: fe80::/128=0A> =0A> sthaug@nethelp.no w= rote=0A> =A0 in <20140328.152022.85374768.sthaug@nethelp.no>:=0A> =0A= =0A=0A> st>=0A> st> So maybe the relevant questions are:=0A> st>=0A> st> 1.= Is there any platform which enables the subnet router anycast=0A> =0A> st>= address by default?=0A> st>=0A> st> 2. Does anybody use the subnet router = anycast address on a regular=0A> st> basis? Presumably then for something m= ore useful than Ole Troan's =0A> ping=0A> st> example?=0A> =0A> I sometimes= use subnet router anycast adddress as the default router=0A> on BSD when R= A cannot be used on that link.=A0 First I used a fixed=0A> link-local addre= ss like fe80::1 for this purpose but subnet router=0A> anycast adddress is = useful when there are multiple routers on that=0A> link for fail-over.=0A>= =A0=0A=0AFor networking people, another possible use would be stateless tun= nel end-point redundancy.=0A=0AOne or perhaps both ends of e.g., a stateles= s GRE tunnel could specify a subnet router anycast address as the underlyin= g destination address. When there are multiple routers at the destination, = the outer encapsulation forwarding towards the tunnel endpoint would use th= e shortest path, and if that router failed, the closest of the other remain= ing router(s) providing the same subnet router anycast address would take o= ver.=0A=0A=0AMy guess is that the origins of the idea for an always availab= le subnet router anycast address are Appletalk (pg. 4-7, "Inside Appletalk"= ):=0A=0A"Node ID 0 indicates any router on the network specified by the net= work number part of the=0Anode address. Packets addressed to node ID 0 are = routed through the internet until they reach the=0Afirst router directly co= nnected to a network whose range includes the indicated network number.=0AT= he packet is then delivered to that router. This facility is used by NBP."= =0A=0ANBP is the Name Binding Protocol, and is the inspiration behind Multi= cast DNS and DNS-Service Discovery.=0A=0A"Requirements for a Protocol to Re= place the AppleTalk Name Binding Protocol (NBP)"=0A=0Ahttp://tools.ietf.org= /html/rfc6760=0A=0A=0ASo perhaps people such as the homenet WG, who are int= erested in the sorts of problems Appletalk solved, might also find uses for= it.=0A=0ARegards,=0AMark.=0A From nobody Thu Apr 3 15:49:59 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 BDF511A033B for ; Thu, 3 Apr 2014 15:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aMUNzfXyorLc for ; Thu, 3 Apr 2014 15:49:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 98D101A0337 for <6man@ietf.org>; Thu, 3 Apr 2014 15:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2366; q=dns/txt; s=iport; t=1396565390; x=1397774990; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+1pwIxThDUJyMARbhc9C2+Foz/3BjZS4tDJ0sdu2qHY=; b=E54u6dD5zulGZCX5p9S/GY5mD8Va5AKeaTTzWRwGW7I5yRSJg08ZS7xV TJ+gKuoHLm8kSBTlKM7JpFioEbqLwpb8lUVAKjta2cRlRDmtflHRIJRGV S8bq0t29ImgExrfMtQ8X1TeDQoqkpYX/+so04yOITeHZOPwq9TgVuwxas c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAD/kPVOtJV2a/2dsb2JhbABXgwY7V7xHhzeBHRZ0giUBAQEEAQEBawsMBAIBCBEDAQIvJwsdAwUBAQQBDQUJh3ANz0oXjnEHBoQyBJhbgTSRCoMwgis X-IronPort-AV: E=Sophos;i="4.97,791,1389744000"; d="scan'208";a="314992790" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Apr 2014 22:49:50 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s33MnomO017610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Thu, 3 Apr 2014 22:49:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 17:49:49 -0500 From: "Carlos Pignataro (cpignata)" To: "Nobo Akiya (nobo)" , "6man@ietf.org" <6man@ietf.org> Subject: Re: IPv6 Router Alert Option for LSP Ping/Trace Thread-Topic: IPv6 Router Alert Option for LSP Ping/Trace Thread-Index: Ac9PcLCqgVfRefeyS6OVvOhidJGsKAAJrMiA Date: Thu, 3 Apr 2014 22:49:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.220.170] Content-Type: text/plain; charset="Windows-1252" Content-ID: <59089D495A80F84786B39C0B263E4CFE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5VkESWkkBJBZwimNeAkV9FEQwbc Cc: "Kamran Raza \(skraza\)" 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, 03 Apr 2014 22:49:59 -0000 Hi Nobo, This is a good point that RFC 5350 did not seem to catch or rationalize. To me, option #3 is the way to go. I will note that this specific gap is not captured in http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-05#section-3.4.2 , and should be captured there. Further,=20 http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-05#section-3.4.2 also highlights another issue with using LSP Ping/Trace in IPv6, which is the loopback address to be used (3rd paragraph). Thanks, =8B Carlos. -----Original Message----- From: Nobo Akiya Date: Thursday, April 3, 2014 at 3:51 PM To: "6man@ietf.org" <6man@ietf.org> Cc: "Kamran Raza (skraza)" Subject: IPv6 Router Alert Option for LSP Ping/Trace >Hi 6MANers, > >One commonly deployed MPLS OAM tool is LSP Ping/Traceroute (RFC4379). > >http://datatracker.ietf.org/doc/rfc4379/?include_text=3D1 > >One of the mandatory requirement from the draft is that Router Alert >option MUST be set in the IP header. > >For IPv4, value zero(0) is used. > >https://www.iana.org/assignments/ipv4-routeralert-values/ipv4-routeralert- >values.xhtml > >For IPv6 ... as vendors are starting to implement MPLS on IPv6 control >plane, we have realized that there is no generic IPv6 Router Alert code >point which can be used by LSP Ping/Traceroute. > >http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-v >alues.xhtml > >1. There's no need for a generic code point in IPv6 Router Alert option. >2. There's probably no need for a generic OAM code point in IPv6 Router >Alert option. >3. There is, however, a need for a code point for LSP Ping/Traceroute, if >the tool is to comply with RFC4379. > >I spoke to authors of RFC4379, and was suggested that (3) is the way to >go. > >But before going ahead to write a small draft for this code point >allocation (intended for MPLS WG as it updates RFC4379), I wanted to see >if 6MANers had any comments/questions/concerns with this. > >Appreciate your time in advance. > >-Nobo > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From nobody Tue Apr 8 04:07:55 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 9B4A71A0327 for ; Tue, 8 Apr 2014 04:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LXfOPuLKONRw for ; Tue, 8 Apr 2014 04:07:47 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBB71A0303 for <6man@ietf.org>; Tue, 8 Apr 2014 04:07:47 -0700 (PDT) Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXTsG-0007Mv-Av; Tue, 08 Apr 2014 13:07:28 +0200 Message-ID: <5343D86B.3060502@si6networks.com> Date: Tue, 08 Apr 2014 08:07:23 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: Revision of draft-gont-6man-ipv6-universal-extension-header References: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> In-Reply-To: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0sda1EJ1R0Y0YZjjUcDwagI39ow Cc: draft-gont-6man-ipv6-universal-extension-header@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: Tue, 08 Apr 2014 11:07:52 -0000 Folks, We have published a revision of the aforementioned I-D. It is available at: This version hopefully does a better job about describing the problem, and also, rather than focusing on a single solution, it describes three possible alternative solutions, with pros and cons. We'd like to receive feedback on this document, including feedback on which of the possible solutions is deemed as the most appropriate. Thanks so much! Fernando et al -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-ipv6-universal-extension-header-01.txt Date: Tue, 08 Apr 2014 03:39:07 -0700 From: internet-drafts@ietf.org To: Fernando Gont , "Shucheng LIU (Will)" , "Suresh Krishnan" , Hagen Paul Pfeifer , Will (Shucheng) Liu , "Hagen Paul Pfeifer" , Suresh Krishnan , "Fernando Gont" A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-ipv6-universal-extension-header Revision: 01 Title: IPv6 Universal Extension Header Document date: 2014-04-08 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/ Htmlized: http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-universal-extension-header-01 Abstract: This document analyzes a problem in the Uniform Format for IPv6 Extension Headers specified in RFC 6564, which results in nodes not being able to process an IPv6 Header Chain if it contains an unrecognized IPv6 Extension Header that follows the aforementioned Uniform Format. It analyzes the implications of the aforementioned problem, and discusses a number of possible solutions, including the specification of a new IPv6 Extension Header - the Universal Extension Header - that overcomes the aforementioned issues. 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. The IETF Secretariat From nobody Tue Apr 8 10:27: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 DCF831A03A7 for ; Tue, 8 Apr 2014 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 xyJvJXBFJY-x for ; Tue, 8 Apr 2014 10:26:56 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9C1A045E for <6man@ietf.org>; Tue, 8 Apr 2014 10:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3112; q=dns/txt; s=iport; t=1396978016; x=1398187616; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CvzAlogc+WBfvT4f34Na13k3C0n2UFJFNuSEdpIEvY4=; b=VUclKaKIMCoWqifUgRiEUz2JiuzMW+FwUZvn55kJaHro3pJ9NhzjHHeT OY3rSdfmE7hxtICZ3KtLgj+YsnuLpmmV1mKSiloF4RGNCkRKYzEnIHSkI YlIuTKaxyplq/TguEDQ8wsIhheAEmYeExlDSj9ZE3JdyULv4yV8D04R9Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAH0wRFOtJV2Y/2dsb2JhbABZgmUhO1e8dYc1gSEWdIIlAQEBBAEBATc0CwwEAgEIEQMBAQELFBAnCx0DBQEBBAENBQgBh3MBDMoWF447MQcGgx6BFASaEZEMgzCCKw X-IronPort-AV: E=Sophos;i="4.97,819,1389744000"; d="scan'208";a="34031463" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 08 Apr 2014 17:26:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s38HQusP014129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Tue, 8 Apr 2014 17:26:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 12:26:56 -0500 From: "Nobo Akiya (nobo)" To: "Carlos Pignataro (cpignata)" , "6man@ietf.org" <6man@ietf.org> Subject: RE: IPv6 Router Alert Option for LSP Ping/Trace Thread-Topic: IPv6 Router Alert Option for LSP Ping/Trace Thread-Index: Ac9PcLCqgVfRefeyS6OVvOhidJGsKAAJrMiAAO4AmtA= Date: Tue, 8 Apr 2014 17:26:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] 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/qDsVOd-7zxrT63vxUYNoPkKEMkQ Cc: "Kamran Raza \(skraza\)" 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, 08 Apr 2014 17:27:01 -0000 Thanks for comments Carlos! Considering there are no concerns heard, we will proceed with: > >3. There is, however, a need for a code point for LSP Ping/Traceroute, > >if the tool is to comply with RFC4379. And submit a draft to MPLS WG. Eventually we will also forward this draft t= o 6man WG for review. -Nobo > -----Original Message----- > From: Carlos Pignataro (cpignata) > Sent: Thursday, April 03, 2014 6:50 PM > To: Nobo Akiya (nobo); 6man@ietf.org > Cc: Kamran Raza (skraza) > Subject: Re: IPv6 Router Alert Option for LSP Ping/Trace >=20 > Hi Nobo, >=20 > This is a good point that RFC 5350 did not seem to catch or rationalize. >=20 > To me, option #3 is the way to go. >=20 > I will note that this specific gap is not captured in > http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-05#section- > 3.4.2 > , and should be captured there. >=20 > Further, > http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-05#section- > 3.4.2 > also highlights another issue with using LSP Ping/Trace in IPv6, which i= s the > loopback address to be used (3rd paragraph). >=20 > Thanks, >=20 > < Carlos. >=20 >=20 > -----Original Message----- > From: Nobo Akiya > Date: Thursday, April 3, 2014 at 3:51 PM > To: "6man@ietf.org" <6man@ietf.org> > Cc: "Kamran Raza (skraza)" > Subject: IPv6 Router Alert Option for LSP Ping/Trace >=20 > >Hi 6MANers, > > > >One commonly deployed MPLS OAM tool is LSP Ping/Traceroute (RFC4379). > > > >http://datatracker.ietf.org/doc/rfc4379/?include_text=3D1 > > > >One of the mandatory requirement from the draft is that Router Alert > >option MUST be set in the IP header. > > > >For IPv4, value zero(0) is used. > > > >https://www.iana.org/assignments/ipv4-routeralert-values/ipv4-routerale > >rt- > >values.xhtml > > > >For IPv6 ... as vendors are starting to implement MPLS on IPv6 control > >plane, we have realized that there is no generic IPv6 Router Alert code > >point which can be used by LSP Ping/Traceroute. > > > >http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeraler > >t-v > >alues.xhtml > > > >1. There's no need for a generic code point in IPv6 Router Alert option. > >2. There's probably no need for a generic OAM code point in IPv6 Router > >Alert option. > >3. There is, however, a need for a code point for LSP Ping/Traceroute, > >if the tool is to comply with RFC4379. > > > >I spoke to authors of RFC4379, and was suggested that (3) is the way to > >go. > > > >But before going ahead to write a small draft for this code point > >allocation (intended for MPLS WG as it updates RFC4379), I wanted to > >see if 6MANers had any comments/questions/concerns with this. > > > >Appreciate your time in advance. > > > >-Nobo > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- From nobody Fri Apr 11 07:49: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 ED69C1A06CB; Fri, 11 Apr 2014 07:49:17 -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 BVvKq44WWxzW; Fri, 11 Apr 2014 07:49:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E91F91A001D; Fri, 11 Apr 2014 07:49:16 -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-why64-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411144916.789.13156.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 07:49:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/b2TKp-uCEfb4hsg4gB_8Y6IlKB4 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: Fri, 11 Apr 2014 14:49: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 : Analysis of the 64-bit Boundary in IPv6 Addressing Authors : Brian Carpenter Tim Chown Fernando Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename : draft-ietf-6man-why64-00.txt Pages : 23 Date : 2014-04-10 Abstract: The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the routing prefix. This document describes the advantages of this fixed boundary and analyses the issues that would be involved in treating it as a variable boundary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-why64/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-why64-00 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 Fri Apr 11 12:52: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 516EA1A03BD for ; Fri, 11 Apr 2014 12:52:10 -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 CVg1X_h1VOOp for ; Fri, 11 Apr 2014 12:52:08 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C42011A03A0 for ; Fri, 11 Apr 2014 12:52:08 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so5836133pab.13 for ; Fri, 11 Apr 2014 12:52:07 -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 :subject:content-type:content-transfer-encoding; bh=417sJiNx4DDq8awixWB0/elV/iN1QDXXGXbsf4jClsE=; b=lQqr2pBeURy1FI20oefLf5p025zy58cYvRKll8/wFW5fWIu7oncSjgsCO32UKbbgoi Jh3K89N/H3jYY44KhObfLvHDAhNdGbV3FGZ+MFCgSZmbKAidVDN5vPa6cMz9LSqkVBxY x3WWJcA0at0KMkSEj5H0cworjMDz4ocseGmkI5aemoQfiBxj66fcgjWBZOVKWhPGy1CW vLL3XUfwj7cPm/tnTqOIelarGIM86vpW2XW6Ao2JNBYrTyRCdUVkjSFqd897RYyZpw1T qRmEGQUCK71uywnOt9wYNsKLa8zjbggOT5QpzJaV/GGTAoR5sbMWqC3wdAd2MoKKGG2J GBcg== X-Received: by 10.68.229.106 with SMTP id sp10mr29930177pbc.23.1397245927505; Fri, 11 Apr 2014 12:52:07 -0700 (PDT) Received: from [192.168.178.20] (76.199.69.111.dynamic.snap.net.nz. [111.69.199.76]) by mx.google.com with ESMTPSA id sh5sm17437579pbc.21.2014.04.11.12.52.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 12:52:06 -0700 (PDT) Message-ID: <534847E9.4050208@gmail.com> Date: Sat, 12 Apr 2014 07:52:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fqNCEtVkpkP1YlWnmOF9_U-aCuc 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, 11 Apr 2014 19:52:10 -0000 Hi, This is a substantial update compared to draft-carpenter-6man-why64-01. As requested by the meeting in London, it has been reorganized with a more positive tone (including a proposed consensus statement). There are now three major sections: advantages of the fixed length IID, arguments for shorter lengths, and expected effects of varying the length. There are also quite a few technical clarifications. We hope that all the comments received have been dealt with, but in some cases we've obviously had to make a choice between differing views. Please review and comment further. Regards Brian + co-authors -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-why64-00.txt Date: Fri, 11 Apr 2014 07:49:16 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org 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 : Analysis of the 64-bit Boundary in IPv6 Addressing Authors : Brian Carpenter Tim Chown Fernando Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename : draft-ietf-6man-why64-00.txt Pages : 23 Date : 2014-04-10 Abstract: The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the routing prefix. This document describes the advantages of this fixed boundary and analyses the issues that would be involved in treating it as a variable boundary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-why64/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-why64-00 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/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Sat Apr 12 14:31: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 DB0D91A0243 for ; Sat, 12 Apr 2014 14:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 LXWdh3gkVGmu for ; Sat, 12 Apr 2014 14:31:09 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD01A022E for ; Sat, 12 Apr 2014 14:31:09 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 12 Apr 2014 16:31:00 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f171.google.com [209.85.223.171] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f171.google.com with SMTP id ar20so6839200iec.2 for ; Sat, 12 Apr 2014 14:30:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2mN7wxM/7cDuzT/KHW0oAg0eHIjaa/6iWaHU8vPyp0Y=; b=GcRGciddFlVJX0HHD9M8PmNOIfL0esvoPgfbvAP8RVGT63DrlEAT2366jqgJgk1Y6r vbP8SiF0Uej+0PFNDftp0xUFfPbu4Lz2wPKn1iCfyBT32zEtKWqKl4/O3v+hQU36k3NP 2KxXoaYo4HrfgXpqnNj6XI05xMDoxWXFhhMEsmwRe+rgZsw4pN31a4SUOISUVtKvzkTF kPK4t/Nm5saV4v2LaBpJX4VMdDZvabFUuhdC4Mgbfi8uv6tA3WBYPYDPHY5OJeZzBzXB iYqe7C1SEGLmf3Aqt5haK99M5WXUcrrKBJBR7k3zEXXnnGP5nuREa3ccieHCUXK+eb8G VMTw== X-Gm-Message-State: ALoCoQl1Lw4QvhOQ5WsvrtcX7auSlZqe9cVC3RvqtaoWTcQS22jhXowh7u0WcuejTSpHKtTxgZtn2/OF/NVoMPDIF+m1Cwrjy/DXW0mJANn+zRqc+MCRsJU= X-Received: by 10.43.163.200 with SMTP id mp8mr25935898icc.18.1397338259630; Sat, 12 Apr 2014 14:30:59 -0700 (PDT) X-Received: by 10.43.163.200 with SMTP id mp8mr25935886icc.18.1397338259485; Sat, 12 Apr 2014 14:30:59 -0700 (PDT) Received: from oit201651646.local ([2601:2:5b00:94:e5a3:5010:68cc:8284]) by mx.google.com with ESMTPSA id vk7sm7354454igb.1.2014.04.12.14.30.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 14:30:58 -0700 (PDT) Message-ID: <5349B092.2040306@umn.edu> Date: Sat, 12 Apr 2014 16:30:58 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian E Carpenter , 6man Subject: Re: draft-ietf-6man-why64-00 References: <534847E9.4050208@gmail.com> In-Reply-To: <534847E9.4050208@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SPuLbdS2aB9qjZOCzXj2GQ1PYds X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 21:31:12 -0000 On 4/11/14, 14:52 , Brian E Carpenter wrote: > Hi, > > This is a substantial update compared to draft-carpenter-6man-why64-01. > As requested by the meeting in London, it has been reorganized with > a more positive tone (including a proposed consensus statement). > There are now three major sections: advantages of the fixed length IID, > arguments for shorter lengths, and expected effects of varying the > length. There are also quite a few technical clarifications. > > We hope that all the comments received have been dealt with, but > in some cases we've obviously had to make a choice between differing > views. Please review and comment further. > > Regards > Brian + co-authors I believe my comments have been dealt with and I am satisfied with how the draft balances the issues involved. The draft makes it clear that IID length is a parameter, currently set to 64 by the standards. However, the draft also makes clear, other IID lengths are possible when using DHCPv6 and manual configuration, even though NOT compliant to the overall IPv6 standards defining the IID length as 64. An editorial suggestion; In the second paragraph of section 3.1 the phrase "using either manually configured addressing or DHCPv6" is used and similar language is used in the third paragraph of section 3.4. However, in the second paragraph of section 4.4, the phrase "require either statically configured addresses or DHCPv6" is used. I suggest using the same terminology in all three instances, and would prefer "manually configured" over "statically configured." Finally, I like the addition of section 2, describing the advantages of a fixed IID length, and along with introduction, together these sections provide actual answers to "why 64?" Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Sun Apr 13 15:48: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 97A231A02E2 for ; Sun, 13 Apr 2014 15:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ugr9LhVkOyVR for ; Sun, 13 Apr 2014 15:48:15 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 39E4B1A0241 for ; Sun, 13 Apr 2014 15:48:15 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ld10so7436111pab.26 for ; Sun, 13 Apr 2014 15:48:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gbBKMzn540b89HuXBmaEFvUv5pKSy0+Dx+MzlIzoN9A=; b=VcUC48Tb31gmYmyiOeqWtThVMU3RfnlXA59bMwycaXPQChClcq0eSE92EWWFgPQiTI u1mY7tZVeTbenw/b4UbDMzTywcBz8PD80bDVqD9lRQxbYSUymr9gmCwtvfwWf546Ym4o lFHPbelh4Jlmpzus2lVU+dxBxB3DDXkjarDuhABwS1LT2w9SyR/f4GufTYOWSbt6E3tQ dyRLdpujyk4Sn2StxZ8C1FLfumg7cZVqEu6/msfoCjKUoHLSqeXnu1kgv5IFajOXCeBl dzs18YeICcNH2K+QsQwxx554dN9bz8hj+iGX3NZ9Wn4BfkL+b4LQJrP1mRR2KkV4QQ6N J3Nw== X-Gm-Message-State: ALoCoQl+kyNf4AwnWqzUcwlwUqX1xR0ofYSg8xJXbEVAZHSPOyQ9GWxeZs8rE2Hvih6Ca5I/4JZn MIME-Version: 1.0 X-Received: by 10.69.31.235 with SMTP id kp11mr40842388pbd.33.1397429293005; Sun, 13 Apr 2014 15:48:13 -0700 (PDT) Received: by 10.70.54.230 with HTTP; Sun, 13 Apr 2014 15:48:12 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:6172:f15b:4f15:4ee4] In-Reply-To: <534847E9.4050208@gmail.com> References: <534847E9.4050208@gmail.com> Date: Mon, 14 Apr 2014 08:48:12 +1000 Message-ID: Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1134caaa9bd0b604f6f45cde Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LDoGgzKqN3dqJYDG0umGfM-0_X8 Cc: 6man 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: Sun, 13 Apr 2014 22:48:17 -0000 --001a1134caaa9bd0b604f6f45cde Content-Type: text/plain; charset=ISO-8859-1 I think its a well written document. Overall I think it 'does what it says on the box' which is to both advocate for /64 and explore the issues, and I believe it reflects an honest assessment of the plus and minus considerations. I am somewhat unsure about a circularity which is in effect "because we said so" regarding other standards and prior standards statements regarding /64. I think the cost inside standards process of coping with change is the least technically satisfying reason to exclude a change in standards behaviour: on the same criteria we might as well stick with IPv4 since every standard which mistakenly bound a 32 bit quantity into a field has had to be re-considered. Basically, I think this is a true cost, and a true reason, but the sheer volume of references inside this document rather overloaded the case. Yes: /64 is bound into a lot of places. the 2000::/3 point is good, but I am still left somewhat aghast that an initial world view of "128 will never run out" has now irrevocably (if this document is taken as read) burned 2^64 bits for purely local consideration, on the basis that we're only in 1/512 of the upper space, and 64 will be "enough". -A lot of upper layer richness has indeed gone out of the system with large flat networks being the current architecture. Who is to say that will remain true in 20, 30 years time? Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in computer systems design, we cycle through wheels in networks of hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio bits in future than we thought. So having had my whinge on the other document, and noting nothing much new here commenting on this one, I think its a good, useful document. Thanks for writing it. -George On Sat, Apr 12, 2014 at 5:52 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > This is a substantial update compared to draft-carpenter-6man-why64-01. > As requested by the meeting in London, it has been reorganized with > a more positive tone (including a proposed consensus statement). > There are now three major sections: advantages of the fixed length IID, > arguments for shorter lengths, and expected effects of varying the > length. There are also quite a few technical clarifications. > > We hope that all the comments received have been dealt with, but > in some cases we've obviously had to make a choice between differing > views. Please review and comment further. > > Regards > Brian + co-authors > > -------- Original Message -------- > Subject: I-D Action: draft-ietf-6man-why64-00.txt > Date: Fri, 11 Apr 2014 07:49:16 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipv6@ietf.org > > > 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 : Analysis of the 64-bit Boundary in IPv6 > Addressing > Authors : Brian Carpenter > Tim Chown > Fernando Gont > Sheng Jiang > Alexandru Petrescu > Andrew Yourtchenko > Filename : draft-ietf-6man-why64-00.txt > Pages : 23 > Date : 2014-04-10 > > Abstract: > The IPv6 unicast addressing format includes a separation between the > prefix used to route packets to a subnet and the interface identifier > used to specify a given interface connected to that subnet. > Currently the interface identifier is defined as 64 bits long for > almost every case, leaving 64 bits for the routing prefix. This > document describes the advantages of this fixed boundary and analyses > the issues that would be involved in treating it as a variable > boundary. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-why64/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-why64-00 > > > 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/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1134caaa9bd0b604f6f45cde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think its a well written document. Overall I think it &#= 39;does what it says on the box' which is to both advocate for /64 and = explore the issues, and I believe it reflects an honest assessment of the p= lus and minus considerations.

I am somewhat unsure about a circularity which is in effect = "because we said so" regarding other standards and prior standard= s statements regarding /64. I think the cost inside standards process of co= ping with change is the least technically satisfying reason to exclude a ch= ange in standards behaviour: on the same criteria we might as well stick wi= th IPv4 since every standard which mistakenly bound a 32 bit quantity into = a field has had to be re-considered. Basically, I think this is a true cost= , and a true reason, but the sheer volume of references inside this documen= t rather overloaded the case. Yes: /64 is bound into a lot of places.

the 2000::/3 point is good, but I am still left somewha= t aghast that an initial world view of "128 will never run out" h= as now irrevocably (if this document is taken as read) burned 2^64 bits for= purely local consideration, on the basis that we're only in 1/512 of t= he upper space, and 64 will be "enough". -A lot of upper layer ri= chness has indeed gone out of the system with large flat networks being the= current architecture. Who is to say that will remain true in 20, 30 years = time? Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in comp= uter systems design, we cycle through wheels in networks of hub-and-spoke, = ring and flat-mesh. We may find we need more H/D ratio bits in future than = we thought.

So having had my whinge on the other document, an= d noting nothing much new here commenting on this one, I think its a good, = useful document. Thanks for writing it.

-George


On Sat,= Apr 12, 2014 at 5:52 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
Hi,

This is a substantial update compared to draft-carpenter-6man-why64-01.
As requested by the meeting in London, it has been reorganized with
a more positive tone (including a proposed consensus statement).
There are now three major sections: advantages of the fixed length IID,
arguments for shorter lengths, and expected effects of varying the
length. There are also quite a few technical clarifications.

We hope that all the comments received have been dealt with, but
in some cases we've obviously had to make a choice between differing views. Please review and comment further.

Regards
=A0 =A0Brian + co-authors

-------- Original Message --------
Subject: I-D Action: draft-ietf-6man-why64-00.txt
Date: Fri, 11 Apr 2014 07:49:16 -0700
From: internet-drafts@ietf.org<= /a>
To:
i-d-announce@ietf.org
CC: ipv6@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IPv6 Maintenance Working Group of the I= ETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Analysis of the 64-bit Boundary= in IPv6 Addressing
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Brian Carpenter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Chown
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fernando Gont
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sheng Jiang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alexandru Petrescu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Andrew Yourtchenko
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-6man-why64-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 23
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-04-10

Abstract:
=A0 =A0The IPv6 unicast addressing format includes a separation between the=
=A0 =A0prefix used to route packets to a subnet and the interface identifie= r
=A0 =A0used to specify a given interface connected to that subnet.
=A0 =A0Currently the interface identifier is defined as 64 bits long for =A0 =A0almost every case, leaving 64 bits for the routing prefix. =A0This =A0 =A0document describes the advantages of this fixed boundary and analyse= s
=A0 =A0the issues that would be involved in treating it as a variable
=A0 =A0boundary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-why64-00


Please note that it may take a couple of minutes from the time of submissio= n
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/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--001a1134caaa9bd0b604f6f45cde-- From nobody Tue Apr 15 00:51:49 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 9CB511A0389 for ; Tue, 15 Apr 2014 00:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.341 X-Spam-Level: ** X-Spam-Status: No, score=2.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-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 hBsk_RxJjQrp for ; Tue, 15 Apr 2014 00:51:43 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 520361A0222 for ; Tue, 15 Apr 2014 00:51:43 -0700 (PDT) Received: from 218-182-245-190.fibertel.com.ar ([190.245.182.218] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WZy9Y-0007jI-PR; Tue, 15 Apr 2014 09:51:37 +0200 Message-ID: <534C79D2.9020106@si6networks.com> Date: Mon, 14 Apr 2014 21:14:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Farmer , Brian E Carpenter , 6man Subject: Re: draft-ietf-6man-why64-00 References: <534847E9.4050208@gmail.com> <5349B092.2040306@umn.edu> In-Reply-To: <5349B092.2040306@umn.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/kXLSJHk_0oNxfbNkq27auPwVmG0 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, 15 Apr 2014 07:51:47 -0000 Hi, David, On 04/12/2014 06:30 PM, David Farmer wrote: > On 4/11/14, 14:52 , Brian E Carpenter wrote: > > An editorial suggestion; In the second paragraph of section 3.1 the > phrase "using either manually configured addressing or DHCPv6" is used > and similar language is used in the third paragraph of section 3.4. > However, in the second paragraph of section 4.4, the phrase "require > either statically configured addresses or DHCPv6" is used. I suggest > using the same terminology in all three instances, and would prefer > "manually configured" over "statically configured." +1. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 15 00:51:54 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 08F551A070D for ; Tue, 15 Apr 2014 00:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.341 X-Spam-Level: ** X-Spam-Status: No, score=2.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-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 BdDJE4RaeKDu for ; Tue, 15 Apr 2014 00:51:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7301A0222 for ; Tue, 15 Apr 2014 00:51:47 -0700 (PDT) Received: from 218-182-245-190.fibertel.com.ar ([190.245.182.218] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WZy9e-0007jO-Ub; Tue, 15 Apr 2014 09:51:43 +0200 Message-ID: <534C7B18.5090408@gont.com.ar> Date: Mon, 14 Apr 2014 21:19:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: George Michaelson , Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/K8OeiYCC6_POUE0-1Ic5724zh8I Cc: 6man 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, 15 Apr 2014 07:51:52 -0000 On 04/13/2014 07:48 PM, George Michaelson wrote: > > I am somewhat unsure about a circularity which is in effect "because we > said so" regarding other standards and prior standards statements > regarding /64. I think the cost inside standards process of coping with > change is the least technically satisfying reason to exclude a change in > standards behaviour: on the same criteria we might as well stick with > IPv4 since every standard which mistakenly bound a 32 bit quantity into > a field has had to be re-considered. Basically, I think this is a true > cost, and a true reason, but the sheer volume of references inside this > document rather overloaded the case. FWIW, I agree. Any suggestion to address this? > the 2000::/3 point is good, but I am still left somewhat aghast that an > initial world view of "128 will never run out" has now irrevocably (if > this document is taken as read) burned 2^64 bits for purely local > consideration, on the basis that we're only in 1/512 of the upper space, > and 64 will be "enough". -A lot of upper layer richness has indeed gone > out of the system with large flat networks being the current > architecture. Who is to say that will remain true in 20, 30 years time? > Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in > computer systems design, we cycle through wheels in networks of > hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio > bits in future than we thought. Just as a clarification: Do you mean we might need mre than 64 bits for the subnet, or that we might prefer to have fewer bits for it in the future? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Apr 15 13:08:14 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 304921A01D8 for ; Tue, 15 Apr 2014 13:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 t04Vw_Ev_soQ for ; Tue, 15 Apr 2014 13:08:09 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFFF1A0186 for ; Tue, 15 Apr 2014 13:08:09 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id s3FK86Bc031428 for ; Tue, 15 Apr 2014 13:08:06 -0700 Received: from XCH-PHX-502.sw.nos.boeing.com (xch-phx-502.sw.nos.boeing.com [137.136.239.55]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s3FK84G0031406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 15 Apr 2014 13:08:05 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.6.193]) by XCH-PHX-502.sw.nos.boeing.com ([169.254.7.80]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 13:08:04 -0700 From: "Manfredi, Albert E" To: Fernando Gont Subject: RE: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] Thread-Index: AQHPWH+kErv3ucOAOE2Oxn3ZDWIg35sTGE/w Date: Tue, 15 Apr 2014 20:08:03 +0000 Message-ID: <021E64FECA7E5A4699562F4E66716481189EB241@XCH-PHX-503.sw.nos.boeing.com> References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> In-Reply-To: <534C7B18.5090408@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/sbbb-708uJBmLwwrCnrAqBgw_WM Cc: 6man 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, 15 Apr 2014 20:08:11 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont > On 04/13/2014 07:48 PM, George Michaelson wrote: > > the 2000::/3 point is good, but I am still left somewhat aghast that an > > initial world view of "128 will never run out" has now irrevocably (if > > this document is taken as read) burned 2^64 bits for purely local > > consideration, on the basis that we're only in 1/512 of the upper space= , > > and 64 will be "enough". -A lot of upper layer richness has indeed gone > > out of the system with large flat networks being the current > > architecture. Who is to say that will remain true in 20, 30 years time? > > Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in > > computer systems design, we cycle through wheels in networks of > > hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio > > bits in future than we thought. >=20 > Just as a clarification: Do you mean we might need mre than 64 bits for > the subnet, or that we might prefer to have fewer bits for it in the futu= re? I happen to fully agree with George, as I've indicated in the past, and wha= t he means has to be that prefixes longer than 64 should not be summarily d= ismissed! Here's why HE means that. Quoting: "... but I am still left somewhat aghast that an initial world view of '128= will never run out' has now irrevocably (if this document is taken as read= ) burned 2^64 bits for purely local consideration, ..." I read that to say, we have grabbed a full 64 of 128 bits for use in purely= local subnets. So this "128 bits will never run out" would only be true if= we assume huge individual subnets are actually, realistically, in the card= s. Do we believe the future consists of huge individual subnets? Or do we inst= ead believe that we should dedicate a huge and vastly underused address spa= ce to each local subnet, just so it becomes more difficult to randomly gues= s a real host's address? If the latter (which sounds more plausible), doesn= 't this narrative about how 128-bit addresses "will never run out" start so= unding awfully simplistic and overstated? Bert From nobody Tue Apr 15 15:15:49 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 CE8121A04DC for ; Tue, 15 Apr 2014 15:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 rpjU5v04KRza for ; Tue, 15 Apr 2014 15:15:45 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AC0101A04A1 for ; Tue, 15 Apr 2014 15:15:45 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so10081119pbc.34 for ; Tue, 15 Apr 2014 15:15:42 -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=CpnAYDkV9BfKQv4w/Kz7atFOuWkLrEQ3utyqZa9gT9c=; b=RHlcUEX1/c4veaVjmbgEJJCFbHhe6ozrm57AttDF2VuYLXZTWwQwHpLOplt5O2/ha9 X4kRukI2uNuhX8tF6hbfhAq5Yu2kCEmtKM0eGkoJ2J+tk9P47+ZiVocvNkcb5wIls+Gs xcWCdYGPpk+u+Udq15SFKeTDGzC9S3ZlHZUI1tktNZA2xtzWNpU6MLKl5JPpcrX19Bay f67+E0N6YhOxrt1ip07CFSKDrUYfRTVJWxv/48s0beZyE+FgL1XLkuNg0zFI8FMFQY6e 5rih8MsYTZKXqYs8ChaKC9Tg0a+/NIfaXR94rg5fgzAq/rEKzLBqZF/p/7CWz0KM5DwU B7mg== X-Received: by 10.66.243.131 with SMTP id wy3mr4791440pac.32.1397600142844; Tue, 15 Apr 2014 15:15:42 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id om6sm42547852pbc.43.2014.04.15.15.15.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 15:15:42 -0700 (PDT) Message-ID: <534DAF90.7090405@gmail.com> Date: Wed, 16 Apr 2014 10:15:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> In-Reply-To: <534C7B18.5090408@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hKGpbkD-lBFXOclz0uTeRS1wMOk Cc: 6man 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, 15 Apr 2014 22:15:48 -0000 On 15/04/2014 12:19, Fernando Gont wrote: > On 04/13/2014 07:48 PM, George Michaelson wrote: >> I am somewhat unsure about a circularity which is in effect "because we >> said so" regarding other standards and prior standards statements >> regarding /64. I think the cost inside standards process of coping with >> change is the least technically satisfying reason to exclude a change in >> standards behaviour: on the same criteria we might as well stick with >> IPv4 since every standard which mistakenly bound a 32 bit quantity into >> a field has had to be re-considered. Basically, I think this is a true >> cost, and a true reason, but the sheer volume of references inside this >> document rather overloaded the case. > > FWIW, I agree. Any suggestion to address this? I think it's entirely appropriate that we discuss the affected documents. We should certainly add text pointing out that IETF work is not as expensive as updating all the software in the world. > > >> the 2000::/3 point is good, but I am still left somewhat aghast that an >> initial world view of "128 will never run out" has now irrevocably (if >> this document is taken as read) burned 2^64 bits for purely local >> consideration, on the basis that we're only in 1/512 of the upper space, >> and 64 will be "enough". -A lot of upper layer richness has indeed gone >> out of the system with large flat networks being the current >> architecture. Who is to say that will remain true in 20, 30 years time? >> Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in >> computer systems design, we cycle through wheels in networks of >> hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio >> bits in future than we thought. > > Just as a clarification: Do you mean we might need mre than 64 bits for > the subnet, or that we might prefer to have fewer bits for it in the future? In any case, I don't think it's the job of this document to discuss this in depth. I agree that it is entirely conceivable that when we release a second /3 for unicast allocations (after using up those 35 trillion /48s) we could also decide to change the addressing architecture for that new /3. Brian > > Thanks! > > Best regards, From nobody Tue Apr 15 15:50: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 4279C1A0019 for ; Tue, 15 Apr 2014 15:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 iyfymUGf4Prg for ; Tue, 15 Apr 2014 15:50:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF01A0015 for ; Tue, 15 Apr 2014 15:50:13 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.5.159]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WaCB1-0004Ok-Ta; Wed, 16 Apr 2014 00:50:06 +0200 Message-ID: <534DB553.9010903@gont.com.ar> Date: Tue, 15 Apr 2014 19:40:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> <021E64FECA7E5A4699562F4E66716481189EB241@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E66716481189EB241@XCH-PHX-503.sw.nos.boeing.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/C5w4p7DCB4tFNKCWBVEGE_M2mFI Cc: 6man 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, 15 Apr 2014 22:50:21 -0000 On 04/15/2014 05:08 PM, Manfredi, Albert E wrote: > I read that to say, we have grabbed a full 64 of 128 bits for use in > purely local subnets. So this "128 bits will never run out" would > only be true if we assume huge individual subnets are actually, > realistically, in the cards. > > Do we believe the future consists of huge individual subnets? Or do > we instead believe that we should dedicate a huge and vastly > underused address space to each local subnet, just so it becomes more > difficult to randomly guess a real host's address? If the latter > (which sounds more plausible), doesn't this narrative about how > 128-bit addresses "will never run out" start sounding awfully > simplistic and overstated? I've never done the math myself, although I'm aware that attempts at predicting this sort of stuff ("640K ought to be enough...") have failed. Thinking out loud, I wonder if one could apply the Robustness Principle here, without actually advocating any change on the sending side. (That is, prepare implementations to gracefully handle non-64 prefixes, but, say, still mandate that non-64 prefixes MUST NOT be sent). This would not break anything nowadays, but would lead to more robust implementations that eventually could handle non-64 prefixes if we realize they are of use). Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Apr 15 15:50:44 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 46CB01A001F for ; Tue, 15 Apr 2014 15:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AD17GRYapruF for ; Tue, 15 Apr 2014 15:50:35 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id A80CA1A001D for ; Tue, 15 Apr 2014 15:50:35 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so10107837pad.7 for ; Tue, 15 Apr 2014 15:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tslRWu2uckOm+srA5ILxxH3eosv2ALmUnzDrMQE1d+A=; b=d0p0kaVQ58YSq9dtnVW+UjesDp+vT/B+koKNeffOKDoJ5LmhFCOg49WJG7OCE2n49A ipGb+Y8Dehah9MXhNqRafWYE18X2IkzimsZNd3QlBPyyFtxe0D7JOoQt57Pn2dg4LkGl YHdoU2y5fHGAfkyK6XE0vH12pjo7bvtnuMf6JNPvj1vMLijn0kWiQ67eQCGc77eXb82f muFP4Bg1i/8+QkGEi8fNiUt0tyrVQCNIYGlrvDCnIW2mxN2DDA1T0hLBAfBBa36HoFcY I44HUpvb4sw7e5fOBE5H14pB34CFIyjHVximh6KUfLdjOFLJ2bOa0XiuFsmLservM8/J kd2Q== X-Gm-Message-State: ALoCoQncjx9aiPsNj9J2rAw1PsLhXV3mdxmZ1g3qSVuvrQLkNWVLwi1+EanVaf24J7tXqxWOjxfp MIME-Version: 1.0 X-Received: by 10.66.250.161 with SMTP id zd1mr4820494pac.136.1397602232821; Tue, 15 Apr 2014 15:50:32 -0700 (PDT) Received: by 10.70.54.230 with HTTP; Tue, 15 Apr 2014 15:50:32 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:894b:3b1f:a7c1:caf4] In-Reply-To: <534C7B18.5090408@gont.com.ar> References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> Date: Wed, 16 Apr 2014 08:50:32 +1000 Message-ID: Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] From: George Michaelson To: Fernando Gont Content-Type: multipart/alternative; boundary=047d7b15ac9fa007ff04f71ca099 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lM9_LycpIYSu3jiRLvQFqDliMqU Cc: 6man 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, 15 Apr 2014 22:50:41 -0000 --047d7b15ac9fa007ff04f71ca099 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 15, 2014 at 10:19 AM, Fernando Gont wrote: > Basically, I think this is a true > > cost, and a true reason, but the sheer volume of references inside this > > document rather overloaded the case. > > FWIW, I agree. Any suggestion to address this? > A concordance. I'd start with a draft, collate in tabular or section form the references, and if it gets past an 80:20 point work it through revising the rest in nits time, and then small revisions in future. I think going to registry is overkill. Its a documentation exercise in itself. > > > > We may find we need more H/D ratio > > bits in future than we thought. > > Just as a clarification: Do you mean we might need mre than 64 bits for > the subnet, or that we might prefer to have fewer bits for it in the > future? > More richness in topology bits the address space holder has, fewer bits per local subnet. And of course vice-versa: much larger spaces, which represent as flat topologies on top of ?SDN? and so have huge bitfields for host in the subnet, using weird markers in address bits for stuff I don't think I like but others (DT?) seem to want to explore. I think being proscriptive to 8+8 across the board (outside of INLP) is not right. I think Operations people would ask that the IETF not over state its remit. Yes, a huge amount of silicon is now optimized for /64. A pretty large amount of silicon was optimized for 32 bit computing for a long time too! -G > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > --047d7b15ac9fa007ff04f71ca099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 15, 2014 at 10:19 AM, Fernando Gont &= lt;fernando@gont.= com.ar> wrote:
Basically, I think this is a= true
> cost, and a true reason, but the sheer volume of references inside thi= s
> document rather overloaded the case.

FWIW, I agree. Any suggestion to address this?
<= br>
A concordance. I'd start with a draft, collate in tabular= or section form the references, and if it gets past an 80:20 point work it= through revising the rest in nits time, and then small revisions in future= . I think going to registry is overkill. Its a documentation exercise in it= self.
=C2=A0


>=C2=A0We may find we need more H/D ratio
> bits in future than we thought.

Just as a clarification: Do you mean we might need mre than 64 bits f= or
the subnet, or that we might prefer to have fewer bits for it in the future= ?

More richness in topology bits the ad= dress space holder has, fewer bits per local subnet.

And of course vice-versa: much larger spaces, which represent as flat = topologies on top of ?SDN? and so have huge bitfields for host in the subne= t, using weird markers in address bits for stuff I don't think I like b= ut others (DT?) seem to want to explore.

I think being proscriptive to 8+8 across the board (out= side of INLP) is not right. I think Operations people would ask that the IE= TF not over state its remit. Yes, a huge amount of silicon is now optimized= for /64. A pretty large amount of silicon was optimized for 32 bit computi= ng for a long time too!

-G
=C2=A0

Thanks!

Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar ||= fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--047d7b15ac9fa007ff04f71ca099-- From nobody Tue Apr 15 15:56: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 3688F1A0007 for ; Tue, 15 Apr 2014 15:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FTkgTgc3PGcP for ; Tue, 15 Apr 2014 15:56:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 659941A0004 for ; Tue, 15 Apr 2014 15:56:03 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.5.159]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WaCGl-0004QR-E5; Wed, 16 Apr 2014 00:55:59 +0200 Message-ID: <534DB894.6030105@gont.com.ar> Date: Tue, 15 Apr 2014 19:54:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> <534DAF90.7090405@gmail.com> In-Reply-To: <534DAF90.7090405@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UMS0NO1JsBew-9HtYQ8oglAJlYI Cc: 6man 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, 15 Apr 2014 22:56:05 -0000 On 04/15/2014 07:15 PM, Brian E Carpenter wrote: >>> the 2000::/3 point is good, but I am still left somewhat aghast that an >>> initial world view of "128 will never run out" has now irrevocably (if >>> this document is taken as read) burned 2^64 bits for purely local >>> consideration, on the basis that we're only in 1/512 of the upper space, >>> and 64 will be "enough". -A lot of upper layer richness has indeed gone >>> out of the system with large flat networks being the current >>> architecture. Who is to say that will remain true in 20, 30 years time? >>> Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in >>> computer systems design, we cycle through wheels in networks of >>> hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio >>> bits in future than we thought. >> >> Just as a clarification: Do you mean we might need mre than 64 bits for >> the subnet, or that we might prefer to have fewer bits for it in the future? > > In any case, I don't think it's the job of this document to > discuss this in depth. I agree that it is entirely conceivable > that when we release a second /3 for unicast allocations (after > using up those 35 trillion /48s) we could also decide to change > the addressing architecture for that new /3. FWIW, here I was just asking for help to parse George's response ("English as a second language" thing on my side). Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Apr 15 16:09: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 C58CB1A004C for ; Tue, 15 Apr 2014 16:09: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 MkWC2beTSebZ for ; Tue, 15 Apr 2014 16:08:58 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 241511A0023 for ; Tue, 15 Apr 2014 16:08:58 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so10210847pab.10 for ; Tue, 15 Apr 2014 16:08:55 -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=rW1s+7/k2NVAobYI+7wH0YKnhyG51ZS2bTI3RqL3+Og=; b=lzL0GDz8+hCrKLt5Hs50xulZaqoCHwavvvS5PZaGIDmmDEIpUMQ9z0hX1/+sgvDsh2 tA5Irz8ovDfzaNp32qRCgx06ydjyiEOcvp1q3XeUB22hM6C6aaocFQfnrVDdQXwrIkAE AojWqHaY86hyEfcEdEA4KzgeQLmxzdJ/RBiATAn8bRFh7JYzMIWvm03Gefp58ydGANAY kFq+GCngZ5dqFXgr535gS0vmtRlcisLCWS94UlaO1Pm6stDi1pzHyUxn1nHeIvmMCRN0 eTt+Nci2UejfDmsNNyPSO0AKydnEYpCKO7GYYFAoUYorsmLWuttKxQ6akaQ2oPsG7dPO 7f4A== X-Received: by 10.67.24.1 with SMTP id ie1mr4746928pad.133.1397603335320; Tue, 15 Apr 2014 16:08:55 -0700 (PDT) Received: from [172.24.22.37] (wireless-nat-20.auckland.ac.nz. [130.216.30.131]) by mx.google.com with ESMTPSA id z3sm101721497pas.15.2014.04.15.16.08.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 16:08:54 -0700 (PDT) Message-ID: <534DBC08.4020307@gmail.com> Date: Wed, 16 Apr 2014 11:08:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: George Michaelson Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> <534C7B18.5090408@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-519x4-R_K_9ycplqK_Aa-NDWcU Cc: 6man , Fernando Gont 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, 15 Apr 2014 23:09:03 -0000 On 16/04/2014 10:50, George Michaelson wrote: > On Tue, Apr 15, 2014 at 10:19 AM, Fernando Gont wrote: > >> Basically, I think this is a true >>> cost, and a true reason, but the sheer volume of references inside this >>> document rather overloaded the case. >> FWIW, I agree. Any suggestion to address this? >> > > A concordance. I'd start with a draft, collate in tabular or section form > the references, and if it gets past an 80:20 point work it through revising > the rest in nits time, and then small revisions in future. I think going to > registry is overkill. Its a documentation exercise in itself. You seem to describe more work of an ongoing nature. I think it's necessary *and* sufficient to identify a large enough set of soecifications to show that it would be a big job. If you think it distracts the reader, we could move the detailed list to an appendix. > > >> >>> We may find we need more H/D ratio >>> bits in future than we thought. >> Just as a clarification: Do you mean we might need mre than 64 bits for >> the subnet, or that we might prefer to have fewer bits for it in the >> future? >> > > More richness in topology bits the address space holder has, fewer bits per > local subnet. > > And of course vice-versa: much larger spaces, which represent as flat > topologies on top of ?SDN? and so have huge bitfields for host in the > subnet, using weird markers in address bits for stuff I don't think I like > but others (DT?) seem to want to explore. > > I think being proscriptive to 8+8 across the board (outside of INLP) is not > right. Well, that is a comment on the normative statement in the addressing architecture. The current draft can't address that. If you want to change it, that would need a standards track draft. Brian > I think Operations people would ask that the IETF not over state its > remit. Yes, a huge amount of silicon is now optimized for /64. A pretty > large amount of silicon was optimized for 32 bit computing for a long time > too! > > -G > > >> Thanks! >> >> Best regards, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> > From nobody Wed Apr 16 08:50:48 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 1139C1A01F7 for ; Wed, 16 Apr 2014 08:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 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, GB_SUMOF=1, 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 11iiWyr8DCv9 for ; Wed, 16 Apr 2014 08:50:45 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id AD3EA1A01EC for ; Wed, 16 Apr 2014 08:50:44 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so11165934wes.11 for ; Wed, 16 Apr 2014 08:50:41 -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=4oQbDMwoC4+tWSxWY24IPTAf+9sfzNQIEiIJKESu8TM=; b=dUhnmciPrXFK+5ax0pvaGpmqdHmI16zxcPxqZtcOKkAqCSpTcWCXnDloo0bi5J7CnY Toz801sfHf73qFoCGRDXt0cNM4WBIszbHayThm4gT83l6MdrucKxdMqfvNSgXuJK4Ss0 YE0wMkAOI7vsjXZTnURWcLmoi1G1qPg07wLNcwvB08BIw8lXjabHN/go4fYmayZ9fl8j y1E48kCmyOHsiXO+TWS5HxlYWC3VdWbFIIIbYI3Iwwy4MP2PAqtC0CddbLusGWyfK9wU uK5OZFraQ9rLd/hY1Wr7WVEJdi9lsSBVVwighMv3QeLsQizhl2D4ldO8ICn3XK4wfaKp eY/g== MIME-Version: 1.0 X-Received: by 10.194.57.77 with SMTP id g13mr7639647wjq.42.1397663440979; Wed, 16 Apr 2014 08:50:40 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.3.14 with HTTP; Wed, 16 Apr 2014 08:50:40 -0700 (PDT) In-Reply-To: <534847E9.4050208@gmail.com> References: <534847E9.4050208@gmail.com> Date: Wed, 16 Apr 2014 08:50:40 -0700 X-Google-Sender-Auth: FthbTZE90lXUblcYT1Sts_PE288 Message-ID: Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uGORbFKjLrj6tlQW9TGHj4xZP98 Cc: 6man 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, 16 Apr 2014 15:50:46 -0000 At Sat, 12 Apr 2014 07:52:09 +1200, Brian E Carpenter wrote: > This is a substantial update compared to draft-carpenter-6man-why64-01. [...] > We hope that all the comments received have been dealt with, but > in some cases we've obviously had to make a choice between differing > views. Please review and comment further. A small correction: In Section 4.3.1 it states o the "A" bit in the Prefix Information Options is honored only if the prefix length is 64. At least for the case of a prefix longer than /64, this is consistent with [RFC4862], which defines the case where the sum of the link-local prefix length and the IID length is larger than 128 as an error consition. First off: - s/consition/condition/ - I don't understand why the link-local prefix length is mentioned here. I guess this is just a typo for "advertised (global) prefix". On fixing these trivial points: [RFC4862] defines the case where the sum of the link-local prefix length and the IID length does *not equal* 128 bits, not just *larger than*. The sentence also doesn't make perfect sense since simply because the prefix length > 64 doesn't necessarily mean the sum is larger than 128 (unless we assume a specific value(s) of the size of IIDs, which is not clear from this paragraph). So I suggest revising this sentence as follows: [...] At least for the case where the IID length is defined to be 64 bits in the corresponding link-type-specific document, which is the case for all currently published such documents, this is consistent with [RFC4862], which defines the case where the sum of the advertised prefix length and the IID length does not equal 128 as an error condition. -- JINMEI, Tatuya From nobody Wed Apr 16 13:54:34 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 000811A02FC for ; Wed, 16 Apr 2014 13:54:31 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, 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 HdCbP2m0B3py for ; Wed, 16 Apr 2014 13:54:31 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2B21A02E8 for ; Wed, 16 Apr 2014 13:54:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bj1so11359039pad.31 for ; Wed, 16 Apr 2014 13:54:27 -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=tTPYfEAZYtuV2NX/tKLX67SxO1FsfgNKxwRyps4j7f0=; b=teFoOjWlcw7j76vCTPL0W6DO6RZUkHtmW5K7mMfp+Z/iMoCB9SMPjgqqzewcxjVBbf nl6dZrXw6IzIeYMZqq1JBQ7J5vUJmVUgZfyNeRdfRfF34/dMjdnlqmuLVzjeHzfhScBR Ho3DXPM4Mw/I2QVrQS6I8TrWcLLGKdLvjUeTgkd1/ZbB7kW61T/2pRPAiQPVmVcjPIcd vggpPYkRdKV4hCKVSJZQUaFNvdCM9Iv1ShZB0yN0Ogi7E70Jhqpy1tAiNfdZAlG3WCbQ 7dKtWyoPJCaRmVoGC2lQdY5KaV1HtmhFJ/7XOfk/oyAoRNdJpYhwxWiGOAP3FtLQ98Uh Ouqw== X-Received: by 10.66.142.170 with SMTP id rx10mr10952946pab.117.1397681667864; Wed, 16 Apr 2014 13:54:27 -0700 (PDT) Received: from [192.168.178.20] (198.197.69.111.dynamic.snap.net.nz. [111.69.197.198]) by mx.google.com with ESMTPSA id av2sm48972809pbc.16.2014.04.16.13.54.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 13:54:27 -0700 (PDT) Message-ID: <534EEE07.5000102@gmail.com> Date: Thu, 17 Apr 2014 08:54:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt] References: <534847E9.4050208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hBQzo-PuKZ2UONSI8NraSUc0CBA Cc: 6man 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, 16 Apr 2014 20:54:32 -0000 Hi, Thanks for the careful reading. On 17/04/2014 03:50, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Sat, 12 Apr 2014 07:52:09 +1200, > Brian E Carpenter wrote: >=20 >> This is a substantial update compared to draft-carpenter-6man-why64-01= =2E > [...] >> We hope that all the comments received have been dealt with, but >> in some cases we've obviously had to make a choice between differing >> views. Please review and comment further. >=20 > A small correction: In Section 4.3.1 it states >=20 > o the "A" bit in the Prefix Information Options is honored only if > the prefix length is 64. At least for the case of a prefix longe= r > than /64, this is consistent with [RFC4862], which defines the > case where the sum of the link-local prefix length and the IID > length is larger than 128 as an error consition. >=20 > First off: > - s/consition/condition/ OK > - I don't understand why the link-local prefix length is mentioned > here. I guess this is just a typo for "advertised (global) prefix". Direct quote from 4862 section 5.3.: If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required. Direct quote from 4862 section 5.5.3: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. I think the current text mixes these two cases. >=20 > On fixing these trivial points: [RFC4862] defines the case where the > sum of the link-local prefix length and the IID length does *not > equal* 128 bits, not just *larger than*. The sentence also doesn't > make perfect sense since simply because the prefix length > 64 doesn't > necessarily mean the sum is larger than 128 (unless we assume a > specific value(s) of the size of IIDs, which is not clear from this > paragraph). >=20 > So I suggest revising this sentence as follows: >=20 > [...] At least for the case where the IID length is defined to > be 64 bits in the corresponding link-type-specific document, > which is the case for all currently published such documents, > this is consistent with [RFC4862], which defines the case where > the sum of the advertised prefix length and the IID length does > not equal 128 as an error condition. That's fine. Thanks Brian >=20 > -- > JINMEI, Tatuya >=20 From nobody Thu Apr 17 07:27:39 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 5F6AA1A0109; Thu, 17 Apr 2014 07:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 CArxQJZQKJjn; Thu, 17 Apr 2014 07:27:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6F1A00A3; Thu, 17 Apr 2014 07:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26668; q=dns/txt; s=iport; t=1397744850; x=1398954450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MBd3FwT2RWr3j4hcCoBmh7PnIbLHJsuTuG2e1vyih1Y=; b=bojLW+nOY3uS6yL1qEidM2VBv3Dy49wz27rWy15e4Sq88PRpIUo+OGyt osnqzna0vwgplea7PioT+I54+EwPpA57d2U35P3g/XwAAd8YPijr8V/oK f24tuXG3ICQ7Q+0v4xSUa552VQolc4PUu6+iruLyVbYuFHEyzKR5plqjg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FAM/jT1OtJA2B/2dsb2JhbABZgkJEO1eDFKkejjWBP4ZmUhmBDBZ0giUBAQEEAQEBIAocJQsQAgEZBAEBCx0DAgICHwYLEwEJCAIEDgUIh2ADEQ2nepwHDYZbF4xJgTEXAQEBHRYXBAYBCYJmNYEUBJcABoMfiUKCBIVQgXKBP4FyOQ X-IronPort-AV: E=Sophos; i="4.97,879,1389744000"; d="scan'208,217"; a="36636944" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 17 Apr 2014 14:27:29 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3HERTuk029254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 14:27:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 09:27:29 -0500 From: "Pascal Thubert (pthubert)" To: "6man@ietf.org" <6man@ietf.org> Subject: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets Thread-Topic: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets Thread-Index: AQHPWhL++1GeHuUHZ0GcdgYXmHZiqZsV2/DA Date: Thu, 17 Apr 2014 14:27:29 +0000 Deferred-Delivery: Thu, 17 Apr 2014 14:27:00 +0000 Message-ID: References: <534D4F7A.3040605@cox.net> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.48] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842605A64xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Epzznk9z4weVIrl_wnz5AmunLjE Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Ines Robles , roll 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, 17 Apr 2014 14:27:38 -0000 --_000_E045AECD98228444A58C61C200AE1BD842605A64xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGw7DQoNCkNvbnNpZGVyaW5nIHRoZSBzdXBwb3J0IHdlIGhhdmUgYXQgNlRpU0NIIGFu ZCBST0xMIGZvciB0aGUgd29yaywgSSBwdWJsaXNoZWQgZHJhZnQtdGh1YmVydC02bWFuLWZsb3ct bGFiZWwtZm9yLXJwbC0wMC50eHQgdG8gdGhlIDZNQU4gV0cuDQpUaGUgbWFpbiBkaXNjdXNzaW9u IGlzIHByb2JhYmx5IHRvIGNvbmZpcm0gd2hldGhlciBvdXIgcHJvcG9zZWQgdXNlIG9mIHRoZSBm bG93IGxhYmVsIGluc2lkZSB0aGUgUlBMIGRvbWFpbiBpcyBjb21wYXRpYmxlIHdpdGggdGhlIGdv YWxzIHRoYXQgYXJlIGFjaGlldmVkIGJ5IFJGQzY0MzcuIExldCB1cyBjb250aW51ZSB0aGUgZGlz Y3Vzc2lvbiB0aGVyZSBmcm9tIG5vdyBvbi4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJvbTog eHZpbGFqb3NhbmFAZ21haWwuY29tIFttYWlsdG86eHZpbGFqb3NhbmFAZ21haWwuY29tXSBPbiBC ZWhhbGYgT2YgWGF2aWVyIFZpbGFqb3NhbmENClNlbnQ6IGpldWRpIDE3IGF2cmlsIDIwMTQgMTA6 MDANClRvOiBJbmVzIFJvYmxlcw0KQ2M6IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7IDZ0aXNj aEBpZXRmLm9yZzsgcm9sbA0KU3ViamVjdDogUmU6IFs2dGlzY2hdIFtSb2xsXSBTdXBwb3J0IG9m IGZsb3cgbGFiZWwgdG8gY2FycnkgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiBkYXRhIHBhY2tldHMN Cg0KKzEgSSB0aGluayB0aGlzIGlzIG1vcmUgdGhhbiBuZWVkZWQuIEluIGFkZGl0aW9uIFJGQyA2 MjgyIGRlZmluZXMgaG93IGhlYWRlciBjb21wcmVzc2lvbiBuZWVkcyB0byBiZSBoYW5kbGVkIHRv Z2V0aGVyIHdpdGggZXh0ZW5zaW9uIGhlYWRlcnMuIEkgdGhpbmsgdGhpcyBpcyBub3QgY2xlYXIg YW5kIGxlYWRzIHRvIGNvbmZ1c2lvbnMgKGFmZWN0aW5nIGFscmVhZHkgc29tZSB3aXJlc2hhcmsg ZGlzc2VjdG9ycykuIFRoZSB1c2Ugb2YgZmxvdyBsYWJlbCB3aWxsIHNvbHZlIHNldmVyYWwgcHJv YmxlbXMgYXQgb25jZS4NCg0KWC4NCg0KDQoNCjIwMTQtMDQtMTYgMjI6NDQgR01UKzAyOjAwIElu ZXMgUm9ibGVzIDxtYXJpYWluZXNyb2JsZXNAZ29vZ2xlbWFpbC5jb208bWFpbHRvOm1hcmlhaW5l c3JvYmxlc0Bnb29nbGVtYWlsLmNvbT4+Og0KKzENCg0KSW5lcw0KDQoyMDE0LTA0LTE1IDIxOjE5 IEdNVC0wMzowMCBRaW4gV2FuZyA8cWlud2FuZzZ0b3BAeWFob28uY29tPG1haWx0bzpxaW53YW5n NnRvcEB5YWhvby5jb20+PjoNCisxDQoNClFpbg0KT24gV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAx NCAxOjQ3IEFNLCBQcm9mLiBEaWVnbyBEdWpvdm5lIDxkaWVnby5kdWpvdm5lQG1haWwudWRwLmNs PG1haWx0bzpkaWVnby5kdWpvdm5lQG1haWwudWRwLmNsPj4gd3JvdGU6DQorMSAhDQoNCjIwMTQt MDQtMTUgMTI6MjUgR01ULTAzOjAwIFRvbSBQaGlubmV5IDx0b20ucGhpbm5leUBjb3gubmV0PG1h aWx0bzp0b20ucGhpbm5leUBjb3gubmV0Pj46DQorMSBmb3Igc3VyZS4gVGhlIGZsb3cgbGFiZWwg aGFzIGFsd2F5cyBiZWVuIHRoZSBwcmVmZXJhYmxlIG1ldGhvZCBmb3IgbWUsIGFuZCBJIHN1c3Bl Y3QgZm9yIG90aGVycyB3aXRoIGtub3dsZWRnZSBvZiBob3cgaXQgaXMgdXNlZCBpbiBJU0ExMDAu MTFhLg0KPT09DQoNCk9uIDIwMTQuMDQuMTUgMDc8dGVsOjIwMTQuMDQuMTUlMjAwNz46MjUsIFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQpEZWFyIGFsbDoNCg0KQXMgc29tZSBvZiB5 b3UgcmVtZW1iZXIsIHRoZSBSUEwgc3BlY2lmaWNhdGlvbiBoYXMgY2hhbmdlZCBvdmVyIHRpbWUg V1JUIHRvIHRoZSBsb2NhdGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCBSUEwgcGxhY2VzIGlu IHRoZSBkYXRhIHBhY2tldHMuIFdlIHN0YXJ0ZWQgd2l0aCB0aGUgZmxvdyBsYWJlbCBidXQgdGhl c2Ugd2VyZSB0aGUgZGF5cyB3aGVuIHdoYXQgYmVjYW1lIFJGQyA2NDM3IHdhcyBiZWluZyBkZWZp bmVkIGF0IDZNQU4sIHNvIHdlIHNoaWVkIGF3YXkgYW5kIGRlZmluZWQgdGhlIEhiSCB0ZWNobmlx dWUgdGhhdCBpcyBub3cgc3BlY2lmaWVkIGFzIFJGQyA2NTUzLg0KDQpXZeKAmWxsIG5vdGUgdGhh dCB0aGUgUlBMIG9wdGlvbiBkZWZpbmVkIGluIFJGQyA2NTUzIHRha2VzIDYgb2N0ZXRzLCBhbmQg d2l0aCB0aGUgSGJIIGhkciB3ZSBlbmQgdXAgd2l0aCA4IGV4dHJhIG9jdGV0cy4gQW4gZXh0cmEg SVAtaW4tSVAgZW5jYXBzdWxhdGlvbiBpcyByZXF1aXJlZCBvbiB0b3Agb2YgdGhhdCB1bmxlc3Mg Ym90aCBlbmRwb2ludHMgYXJlIGluIHRoZSBzYW1lIFJQTCBkb21haW4uIEFsbCB0aGlzIG92ZXJo ZWFkIG1heSBiZSBhY2NlcHRhYmxlIHdoZW4gcG93ZXIgaXMgYXZhaWxhYmxlIGFuZCB0aGUgUEhZ IGFsbG93cyBmb3IgbGFyZ2VyIGZyYW1lcywgYnV0IGluIHRyYWRpdGlvbmFsIGJhdHRlcnktb3Bl cmF0ZWQgMTUuNCB3aXRoIH4gODAgYnl0ZXMgdXNhYmxlIHBlciBmcmFtZSwgbXkgZXhwZXJpZW5j ZSBmcm9tIGludGVncmF0aW5nIDZMb1dQQU4gSEMgd2l0aCBJU0ExMDAuMTFhIHNheXMgdGhhdCBh bGwgdGhlc2UgZXh0cmEgYnl0ZXMgd2lsbCBiZSBvbiB0aGUgd2F5IG9mIHRoZSA2VGlTQ0ggYWRv cHRpb24uDQoNClN0aWxsLCBib3RoIFJGQyA2NTUwIGFuZCBSRkMgNjU1MiBhcmUgZGVzaWduZWQg dG8gYWxsb3cgZm9yIGFuIGFsdGVybmF0ZSB0ZWNobmlxdWUgYW5kIGluIHBhcnRpY3VsYXIgZm9y IHRoZSB1c2Ugb2YgdGhlIGZsb3cgbGFiZWwsIGFzIGlzIGVsYWJvcmF0ZWQgaW4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC1yb2xsLWZsb3ctbGFiZWwtMDIgLiBVc2lu ZyB0aGUgZmxvdyBsYWJlbCByZWR1Y2VzIHRoZSBjb3N0IG9mIHRoZSBSUEwgaW5mb3JtYXRpb24g ZHJhbWF0aWNhbGx5LCBkb3duIHRvIGEgbGV2ZWwgdGhhdCBpcyBwcm9iYWJseSBhY2NlcHRhYmxl IGZvciB0aGUgdGFyZ2V0IFNET3MuDQoNClNvIG15IHBsYW4gZm9yIG5vdyBpcyB0byBtb3ZlIHRo ZSBmbG93IGxhYmVsIGRyYWZ0IHRvIDZNQU4gYW5kIHByZXBhcmUgZm9yIGEgaG90IHNlYXNvbiwg YW5kIEnigJltIGxvb2tpbmcgZm9yIHN1cHBvcnQgZnJvbSBib3RoIDZUaVNDSCBhbmQgUk9MTCB0 byBiYWNrIG1lIHVwIGZyb20gdGhlIHN0YXJ0LiAgWWVzLCB5b3UgY2FuIGhlbHAhDQoNClBsZWFz ZSArMSBpZiB5b3UgYWdyZWUgd2UgbmVlZCB0aGlzIHdvcmsgdG8gaGFwcGVuLCBhbmQvb3IgcHJv dmlkZSBhbnkgc3VnZ2VzdGlvbi4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo2dGlzY2ggbWFpbGluZyBs aXN0DQoNCjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaA0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2 dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCg0KDQotLQ0KRElFR08gRFVKT1ZORQ0KQWNh ZMOpbWljbyBFc2N1ZWxhIGRlIEluZ2VuaWVyw61hIGVuIEluZm9ybcOhdGljYSB5IFRlbGVjb211 bmljYWNpb25lcw0KRmFjdWx0YWQgZGUgSW5nZW5pZXLDrWEgVURQDQp3d3cuaW5nZW5pZXJpYS51 ZHAuY2w8aHR0cDovL3d3dy5pbmdlbmllcmlhLnVkcC5jbC8+DQooNTYgMikgNjc2IDgxMjU8dGVs OiUyODU2JTIwMiUyOSUyMDY3NiUyMDgxMjU+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2dGlzY2hAaWV0Zi5v cmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vNnRpc2NoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xs QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZ0aXNj aCBtYWlsaW5nIGxpc3QNCjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gNCg0K --_000_E045AECD98228444A58C61C200AE1BD842605A64xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIg YWxsOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXJpbmcgdGhlIHN1cHBvcnQgd2UgaGF2ZSBhdCA2VGlTQ0gg YW5kIFJPTEwgZm9yIHRoZSB3b3JrLCBJIHB1Ymxpc2hlZCBkcmFmdC10aHViZXJ0LTZtYW4tZmxv dy1sYWJlbC1mb3ItcnBsLTAwLnR4dCB0byB0aGUgNk1BTiBXRy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIG1haW4gZGlzY3Vzc2lvbiBpcyBwcm9iYWJseSB0byBjb25maXJtIHdo ZXRoZXIgb3VyIHByb3Bvc2VkIHVzZSBvZiB0aGUgZmxvdyBsYWJlbCBpbnNpZGUgdGhlIFJQTCBk b21haW4gaXMgY29tcGF0aWJsZSB3aXRoIHRoZSBnb2FscyB0aGF0IGFyZSBhY2hpZXZlZCBieQ0K IFJGQzY0MzcuIExldCB1cyBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiB0aGVyZSBmcm9tIG5vdyBv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB4 dmlsYWpvc2FuYUBnbWFpbC5jb20gW21haWx0bzp4dmlsYWpvc2FuYUBnbWFpbC5jb21dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlhhdmllciBWaWxham9zYW5hPGJyPg0KPGI+U2VudDo8L2I+IGpldWRp IDE3IGF2cmlsIDIwMTQgMTA6MDA8YnI+DQo8Yj5Ubzo8L2I+IEluZXMgUm9ibGVzPGJyPg0KPGI+ Q2M6PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyA2dGlzY2hAaWV0Zi5vcmc7IHJvbGw8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFs2dGlzY2hdIFtSb2xsXSBTdXBwb3J0IG9mIGZsb3cg bGFiZWwgdG8gY2FycnkgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiBkYXRhIHBhY2tldHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIEkg dGhpbmsgdGhpcyBpcyBtb3JlIHRoYW4gbmVlZGVkLiBJbiBhZGRpdGlvbiBSRkMgNjI4MiBkZWZp bmVzIGhvdyBoZWFkZXIgY29tcHJlc3Npb24gbmVlZHMgdG8gYmUgaGFuZGxlZCB0b2dldGhlciB3 aXRoIGV4dGVuc2lvbiBoZWFkZXJzLiBJIHRoaW5rIHRoaXMgaXMgbm90IGNsZWFyIGFuZCBsZWFk cyB0byBjb25mdXNpb25zIChhZmVjdGluZyBhbHJlYWR5IHNvbWUgd2lyZXNoYXJrIGRpc3NlY3Rv cnMpLg0KIFRoZSB1c2Ugb2YgZmxvdyBsYWJlbCB3aWxsIHNvbHZlIHNldmVyYWwgcHJvYmxlbXMg YXQgb25jZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlgu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDQtMTYgMjI6NDQgR01UJiM0Mzsw MjowMCBJbmVzIFJvYmxlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmlhaW5lc3JvYmxlc0Bnb29n bGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNv bTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYj NDM7MTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5lczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wNC0xNSAy MToxOSBHTVQtMDM6MDAgUWluIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpxaW53YW5nNnRvcEB5 YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5xaW53YW5nNnRvcEB5YWhvby5jb208L2E+Jmd0Ozo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojODg4ODg4Ij5RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQg MTo0NyBBTSwgUHJvZi4gRGllZ28gRHVqb3ZuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpZWdvLmR1 am92bmVAbWFpbC51ZHAuY2wiIHRhcmdldD0iX2JsYW5rIj5kaWVnby5kdWpvdm5lQG1haWwudWRw LmNsPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mIzQzOzEgITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE0LTA0LTE1IDEyOjI1IEdNVC0wMzow MCBUb20gUGhpbm5leSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbS5waGlubmV5QGNveC5uZXQiIHRh cmdldD0iX2JsYW5rIj50b20ucGhpbm5leUBjb3gubmV0PC9hPiZndDs6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiYjNDM7MSBmb3Igc3VyZS4gVGhlIGZsb3cgbGFiZWwgaGFzIGFsd2F5cyBiZWVuIHRoZSBwcmVm ZXJhYmxlIG1ldGhvZCBmb3IgbWUsIGFuZCBJIHN1c3BlY3QgZm9yIG90aGVycyB3aXRoIGtub3ds ZWRnZSBvZiBob3cgaXQgaXMgdXNlZCBpbiBJU0ExMDAuMTFhLjxicj4NCj09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPk9uIDxhIGhyZWY9InRlbDoyMDE0LjA0LjE1JTIwMDciIHRhcmdldD0iX2Js YW5rIj4NCjIwMTQuMDQuMTUgMDc8L2E+OjI1LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGVhciBhbGw6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFzIHNvbWUgb2YgeW91IHJlbWVt YmVyLCB0aGUgUlBMIHNwZWNpZmljYXRpb24gaGFzIGNoYW5nZWQgb3ZlciB0aW1lIFdSVCB0byB0 aGUgbG9jYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgUlBMIHBsYWNlcyBpbiB0aGUgZGF0 YSBwYWNrZXRzLiBXZSBzdGFydGVkIHdpdGggdGhlIGZsb3cgbGFiZWwgYnV0IHRoZXNlDQogd2Vy ZSB0aGUgZGF5cyB3aGVuIHdoYXQgYmVjYW1lIFJGQyA2NDM3IHdhcyBiZWluZyBkZWZpbmVkIGF0 IDZNQU4sIHNvIHdlIHNoaWVkIGF3YXkgYW5kIGRlZmluZWQgdGhlIEhiSCB0ZWNobmlxdWUgdGhh dCBpcyBub3cgc3BlY2lmaWVkIGFzIFJGQyA2NTUzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPldl4oCZbGwgbm90ZSB0aGF0IHRoZSBSUEwgb3B0aW9uIGRlZmluZWQg aW4gUkZDIDY1NTMgdGFrZXMgNiBvY3RldHMsIGFuZCB3aXRoIHRoZSBIYkggaGRyIHdlIGVuZCB1 cCB3aXRoIDggZXh0cmEgb2N0ZXRzLiBBbiBleHRyYSBJUC1pbi1JUCBlbmNhcHN1bGF0aW9uIGlz IHJlcXVpcmVkIG9uIHRvcCBvZiB0aGF0IHVubGVzcw0KIGJvdGggZW5kcG9pbnRzIGFyZSBpbiB0 aGUgc2FtZSBSUEwgZG9tYWluLiBBbGwgdGhpcyBvdmVyaGVhZCBtYXkgYmUgYWNjZXB0YWJsZSB3 aGVuIHBvd2VyIGlzIGF2YWlsYWJsZSBhbmQgdGhlIFBIWSBhbGxvd3MgZm9yIGxhcmdlciBmcmFt ZXMsIGJ1dCBpbiB0cmFkaXRpb25hbCBiYXR0ZXJ5LW9wZXJhdGVkIDE1LjQgd2l0aCB+IDgwIGJ5 dGVzIHVzYWJsZSBwZXIgZnJhbWUsIG15IGV4cGVyaWVuY2UgZnJvbSBpbnRlZ3JhdGluZyA2TG9X UEFOIEhDDQogd2l0aCBJU0ExMDAuMTFhIHNheXMgdGhhdCBhbGwgdGhlc2UgZXh0cmEgYnl0ZXMg d2lsbCBiZSBvbiB0aGUgd2F5IG9mIHRoZSA2VGlTQ0ggYWRvcHRpb24uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdGlsbCwgYm90aCBSRkMgNjU1MCBh bmQgUkZDIDY1NTIgYXJlIGRlc2lnbmVkIHRvIGFsbG93IGZvciBhbiBhbHRlcm5hdGUgdGVjaG5p cXVlIGFuZCBpbiBwYXJ0aWN1bGFyIGZvciB0aGUgdXNlIG9mIHRoZSBmbG93IGxhYmVsLCBhcyBp cyBlbGFib3JhdGVkIGluDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC10aHViZXJ0LXJvbGwtZmxvdy1sYWJlbC0wMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC1yb2xsLWZsb3ctbGFiZWwtMDI8L2E+IC4g VXNpbmcgdGhlIGZsb3cgbGFiZWwgcmVkdWNlcyB0aGUgY29zdCBvZiB0aGUgUlBMIGluZm9ybWF0 aW9uIGRyYW1hdGljYWxseSwgZG93biB0byBhIGxldmVsIHRoYXQgaXMgcHJvYmFibHkgYWNjZXB0 YWJsZSBmb3IgdGhlIHRhcmdldCBTRE9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TbyBteSBwbGFuIGZvciBub3cgaXMgdG8gbW92ZSB0aGUgZmxvdyBsYWJlbCBkcmFm dCB0byA2TUFOIGFuZCBwcmVwYXJlIGZvciBhIGhvdCBzZWFzb24sIGFuZCBJ4oCZbSBsb29raW5n IGZvciBzdXBwb3J0IGZyb20gYm90aCA2VGlTQ0ggYW5kIFJPTEwgdG8gYmFjayBtZSB1cCBmcm9t IHRoZSBzdGFydC4gJm5ic3A7WWVzLCB5b3UgY2FuDQogaGVscCEgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QbGVhc2UgJiM0MzsxIGlmIHlvdSBhZ3JlZSB3 ZSBuZWVkIHRoaXMgd29yayB0byBoYXBwZW4sIGFuZC9vciBwcm92aWRlIGFueSBzdWdnZXN0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNoZWVycyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGFzY2FsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3ByZT4NCjxwcmU+NnRpc2NoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2giIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaDwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KNnRpc2NoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2giIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPGJyPg0KRElFR08gRFVKT1ZO RTxicj4NCkFjYWTDqW1pY28gRXNjdWVsYSBkZSBJbmdlbmllcsOtYSBlbiBJbmZvcm3DoXRpY2Eg eSBUZWxlY29tdW5pY2FjaW9uZXM8YnI+DQpGYWN1bHRhZCBkZSBJbmdlbmllcsOtYSBVRFA8YnI+ DQo8YSBocmVmPSJodHRwOi8vd3d3LmluZ2VuaWVyaWEudWRwLmNsLyIgdGFyZ2V0PSJfYmxhbmsi Pnd3dy5pbmdlbmllcmlhLnVkcC5jbDwvYT48YnI+DQo8YSBocmVmPSJ0ZWw6JTI4NTYlMjAyJTI5 JTIwNjc2JTIwODEyNSIgdGFyZ2V0PSJfYmxhbmsiPig1NiAyKSA2NzYgODEyNTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KNnRpc2NoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42dGlzY2hAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82dGlzY2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvLzZ0aXNjaDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+Um9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo2dGlz Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOjZ0aXNjaEBpZXRmLm9yZyI+NnRp c2NoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vNnRpc2NoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby82dGlzY2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E045AECD98228444A58C61C200AE1BD842605A64xmbrcdx01ciscoc_-- From nobody Thu Apr 17 07:50: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 5594B1A0204; Thu, 17 Apr 2014 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y3BnC2UAAqC5; Thu, 17 Apr 2014 07:49:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A151A01EA; Thu, 17 Apr 2014 07:49:53 -0700 (PDT) Received: from [2001:5c0:1000:a::bc1] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WandJ-0004WM-4F; Thu, 17 Apr 2014 16:49:45 +0200 Message-ID: <534FE9F4.9060700@gont.com.ar> Date: Thu, 17 Apr 2014 11:49:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets References: <534D4F7A.3040605@cox.net> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/sVrJecVQM3lHdKynsNpkuUXErf4 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Ines Robles , roll 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, 17 Apr 2014 14:49:59 -0000 Hi, Pascal, On 04/17/2014 11:27 AM, Pascal Thubert (pthubert) wrote: > > Considering the support we have at 6TiSCH and ROLL for the work, I > published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG. > > The main discussion is probably to confirm whether our proposed use of > the flow label inside the RPL domain is compatible with the goals that > are achieved by RFC6437. Let us continue the discussion there from now on. I just skimmed through the I-D. Two quick questions: 1) Does your document propose/require that the Flow Label be rewritten by some border router? -- I ask because, at the time, there was strong opposition to this. 2) Does the algorithm/scheme with which you'll rewrite the Flow-Label lead to predictable sequences? And/or, would the resulting values have a uniform distribution? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Thu Apr 17 10:08:16 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 5F72B1A0298; Thu, 17 Apr 2014 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 sNvbzTbint2q; Thu, 17 Apr 2014 10:08:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6CD1A0292; Thu, 17 Apr 2014 10:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2948; q=dns/txt; s=iport; t=1397754484; x=1398964084; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s0Ju5AtxnBeyzfcFeZXR+y8EUz1edKRQp+Tonyti9gQ=; b=HGeO+zQvgbho7nCHwbFdGtz3UyNITlJoKc7uGdZhsX7n7fEUXU2EfYSu Q0Qpg71te9491kWBHoItDJcC0AhGrralXfzKxqZWoPs0taRRUH9Hdcffa 41YwzOZ/IJuUDs8iShu7BwiLxPEeYEalhFGkqzZ/l4Ga7nH9T6r1H0VrF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMMJUFOtJV2c/2dsb2JhbABZgwaBEsNggSUWdIIlAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIh3TLLReOMTEHBoMegRQEo2eHVIFygT+CKw X-IronPort-AV: E=Sophos;i="4.97,880,1389744000"; d="scan'208";a="36677912" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 17 Apr 2014 17:08:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3HH83S5031900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 17:08:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 12:08:03 -0500 From: "Pascal Thubert (pthubert)" To: Fernando Gont , "6man@ietf.org" <6man@ietf.org> Subject: RE: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets Thread-Topic: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets Thread-Index: AQHPWkxLZufVJd4IcEWCVYj/JQlplpsWB1zg Date: Thu, 17 Apr 2014 17:08:02 +0000 Deferred-Delivery: Thu, 17 Apr 2014 17:08:00 +0000 Message-ID: References: <534D4F7A.3040605@cox.net> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> <534FE9F4.9060700@gont.com.ar> In-Reply-To: <534FE9F4.9060700@gont.com.ar> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.48] 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/b0GUtZJNlBSQfA_4wcjgVLRRKgE Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Ines Robles , roll 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, 17 Apr 2014 17:08:12 -0000 Hello Fernando Thanks for your review, and we can certainly use some piece of advice from = you here: 1) Yes, the idea is that leaves of a RPL network do not use the flow label.= Inside the RPL domain it is used to support RPL operations.=20 At the border router, which is a RPL root, it is finally set to the value t= hat is visible in the Internet. I can expect some knee jerk about this prop= osal but before rejecting in on some principle we must consider the benefit= s in IoT applications, and whether the interests that the flow label serves= in the core can still be enabled with this proposal. 2) The draft did not finalize the way the Flow Label is computed in the Int= ernet side. If we agree on the principle then we can work out the details. To give you an idea, my mind is to compute classically a hash for a given f= low. The root is expected to have a policy that indicates whether the original s= ource address is relevant or not in the identification of a flow (it is not= for a compound flow that we do not want to see separated in the Internet).= The instance ID that is in the original flow label is certainly relevant a= nd is used in the hash computation. A random computed by the root at boot w= ould be useful as well. We expect few flows to emerge from a given RPL root, and even fewer from a = given constrained device. The random and the hash are really there to enable load balancing between f= lows out of different backbone routers. Cheers, Pascal > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > Sent: jeudi 17 avril 2014 16:49 > To: Pascal Thubert (pthubert); 6man@ietf.org > Cc: 6tisch@ietf.org; Ines Robles; roll > Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL infor= mation > in data packets >=20 > Hi, Pascal, >=20 > On 04/17/2014 11:27 AM, Pascal Thubert (pthubert) wrote: > > > > Considering the support we have at 6TiSCH and ROLL for the work, I > > published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG. > > > > The main discussion is probably to confirm whether our proposed use of > > the flow label inside the RPL domain is compatible with the goals that > > are achieved by RFC6437. Let us continue the discussion there from now > on. >=20 > I just skimmed through the I-D. Two quick questions: >=20 > 1) Does your document propose/require that the Flow Label be rewritten by > some border router? -- I ask because, at the time, there was strong > opposition to this. >=20 > 2) Does the algorithm/scheme with which you'll rewrite the Flow-Label lea= d > to predictable sequences? And/or, would the resulting values have a > uniform distribution? >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 From nobody Thu Apr 17 13:31: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 80AB91A012D; Thu, 17 Apr 2014 13:31:29 -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 ATdeFvvETFiE; Thu, 17 Apr 2014 13:31:28 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E17B1A012A; Thu, 17 Apr 2014 13:31:28 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lj1so750449pab.20 for ; Thu, 17 Apr 2014 13:31:24 -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=Rrg6unD6qPNPpZMUNWq5N3u8HT/Ee8oX49BfXRKzy8A=; b=QnJ6OlHfOXQViIW88bLemMqXx1pGMuydXgEitiRhrVMzwPuKI3p1lW8yVBnXTpHXK4 DjINXsqFNFKiq4fcWG0KP7v/RZ1efJryd12jzWX/7qObliN/WNtn889tSaD5xPpc5mv0 EoU1sP3ECaUU0iJ0c5Lo8m3UslThIDQkm75b0qxKMNE5FO+V2wrbhKRyNRsb1ybqirhp Zo32ttfRsIxMSZR0QoBOdWOXeGU/iaUNRn3HQQP6rKEUS2KvFX+c0ghLVkAyzD+iqlYu h/ckujv0bAfMsYbEqKAPRJVtVWLYpGZAyKAp3EeELJly8rkmBu8scj97hf1uWzxJzXit vR5A== X-Received: by 10.68.240.68 with SMTP id vy4mr17618873pbc.127.1397766684714; Thu, 17 Apr 2014 13:31:24 -0700 (PDT) Received: from [192.168.178.20] (34.199.69.111.dynamic.snap.net.nz. [111.69.199.34]) by mx.google.com with ESMTPSA id yv5sm55405343pbb.49.2014.04.17.13.31.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 13:31:24 -0700 (PDT) Message-ID: <53503A22.2090600@gmail.com> Date: Fri, 18 Apr 2014 08:31:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets References: <534D4F7A.3040605@cox.net> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> <534FE9F4.9060700@gont.com.ar> In-Reply-To: <534FE9F4.9060700@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fN7A198HTdhpUyQek2icN30dZ3Q Cc: "Pascal Thubert \(pthubert\)" , "6man@ietf.org" <6man@ietf.org>, roll , "6tisch@ietf.org" <6tisch@ietf.org>, Ines Robles 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, 17 Apr 2014 20:31:29 -0000 Fernando, On 18/04/2014 02:49, Fernando Gont wrote: > Hi, Pascal, > > On 04/17/2014 11:27 AM, Pascal Thubert (pthubert) wrote: >> Considering the support we have at 6TiSCH and ROLL for the work, I >> published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG. >> >> The main discussion is probably to confirm whether our proposed use of >> the flow label inside the RPL domain is compatible with the goals that >> are achieved by RFC6437. Let us continue the discussion there from now on. > > I just skimmed through the I-D. Two quick questions: > > 1) Does your document propose/require that the Flow Label be rewritten > by some border router? -- I ask because, at the time, there was strong > opposition to this. It was of course contested, but we have to remember that the flow label is an unauthenticated field, so our interpretation of it has to be robust against altered values. RFC 6437 indeed covers the case where a forwarding node sets the flow label. > 2) Does the algorithm/scheme with which you'll rewrite the Flow-Label > lead to predictable sequences? And/or, would the resulting values have a > uniform distribution? The same part of RFC 6437 does RECOMMEND a uniform distribution. Also, the very first paragraph of RFC 6437 states that "a flow is not necessarily 1:1 mapped to a transport connection", so there is reasonable flexibility. Brian > > Thanks! > > Best regards, From nobody Thu Apr 17 15:54: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 F1A011A01E6; Thu, 17 Apr 2014 15:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BSGkO2ACmROB; Thu, 17 Apr 2014 15:54:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA61A0110; Thu, 17 Apr 2014 15:54:06 -0700 (PDT) Received: from [2001:5c0:1000:a::bc1] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WavBh-000776-5t; Fri, 18 Apr 2014 00:53:45 +0200 Message-ID: <53505920.4000204@si6networks.com> Date: Thu, 17 Apr 2014 19:43:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets References: <534D4F7A.3040605@cox.net> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> <534FE9F4.9060700@gont.com.ar> <53503A22.2090600@gmail.com> In-Reply-To: <53503A22.2090600@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/pb3L8554sWS2-nA4RULVBu8SeK8 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Pascal Thubert \(pthubert\)" , "6man@ietf.org" <6man@ietf.org>, roll , Ines Robles 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, 17 Apr 2014 22:54:12 -0000 Hi, Brian, On 04/17/2014 05:31 PM, Brian E Carpenter wrote: >> >> On 04/17/2014 11:27 AM, Pascal Thubert (pthubert) wrote: >>> Considering the support we have at 6TiSCH and ROLL for the work, I >>> published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG. >>> >>> The main discussion is probably to confirm whether our proposed use of >>> the flow label inside the RPL domain is compatible with the goals that >>> are achieved by RFC6437. Let us continue the discussion there from now on. >> >> I just skimmed through the I-D. Two quick questions: >> >> 1) Does your document propose/require that the Flow Label be rewritten >> by some border router? -- I ask because, at the time, there was strong >> opposition to this. > > It was of course contested, but we have to remember that the flow label > is an unauthenticated field, so our interpretation of it has to be > robust against altered values. RFC 6437 indeed covers the case where a > forwarding node sets the flow label. FWIW, I was just asking to get an overall/quick understanding of where they wanted to go, and contrast that where 6man seemed to want to go at the time. Just that. IHMO, if the point/use case is valid, we should "evaluate" their proposal (i.e., by no means I was meaning "6man doesn't like that, forget it".) >> 2) Does the algorithm/scheme with which you'll rewrite the Flow-Label >> lead to predictable sequences? And/or, would the resulting values have a >> uniform distribution? > > The same part of RFC 6437 does RECOMMEND a uniform distribution. Agreed. Again, I was checking the extent to which they might be deviating from that was set here. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Apr 19 09:51: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 874DE1A0033 for ; Sat, 19 Apr 2014 09:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 nvS-HHUu6Bas for ; Sat, 19 Apr 2014 09:51:15 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762131A0032 for <6man@ietf.org>; Sat, 19 Apr 2014 09:51:15 -0700 (PDT) Received: (qmail 23667 invoked from network); 19 Apr 2014 09:51:10 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Apr 2014 09:51:10 -0700 Date: Sat, 19 Apr 2014 09:51:10 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Fernando Gont Subject: Re: Revision of draft-gont-6man-ipv6-universal-extension-header In-Reply-To: <5343D86B.3060502@si6networks.com> Message-ID: References: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> <5343D86B.3060502@si6networks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/g0n01PX1UDwO-haiJFFAfh61RCE 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: Sat, 19 Apr 2014 16:51:19 -0000 Greetings Fernando, My thanks to you and your co-authors for continuing with this initiative. In response to your request for feedback, I would like first to discuss a quasi-editorial issues, and then provide my view of the preferred solution. In Section 4, Implications, you state: Since there is no way for a node to process IPv6 extension headers that employ unknown next header values, an IPv6 host that receives a packet that employs a new IPv6 extension header will not be able to parse the IPv6 header chain past that unknown extension header, and hence it will drop the aforementioned packet. It seems to me that this is not really a problem, since RFC 2460 Section 4 already mandates that a host discard packets with extension headers that it does not recognize: If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. The paragraph above does use the word "node" rather than "host" but in the context of RFC 2460 it does refer specifically to an end system ("the node [...] identified in the Destination Address field of the IPv6 header"). As far as I am aware, there have been no updates to the IPv6 specifications requiring or even suggesting that end systems should ever try to skip over extension headers that they do not recognize. The problem exists only for middleboxes that examine and act on extension headers, so I recommend that this draft drop all discussion of end systems. Furthermore, I don't see how the extension header problem discussed in this draft impedes deployment of transport protocols. To be sure, here are problems with middleboxes filtering out transport protocols that they don't know, but that is an issue even without extension headers. I therefore suggest the following replacement for Section 4 of your draft: The current impossibility to parse an IPv6 header chain that includes unknown Next Header values results in concrete implications for the extensibility of the IPv6 protocol, and the deployability of IPv6 extension headers. Specifically, a middlebox that needs to process the transport-protocol header will be faced with the dilemma of what to do with packets that employ unknown Next Header values. Since it will not be able to parse the IPv6 header chain past the unknown Next Header, it is very likely that it will drop such packets. We believe that the current situation has implications that are generally overlooked, and that, whatever the outcome, it should be the result of an explicit decision by our community, rather than simply "omission". BTW, I strongly agree with that last paragraph (which I did not change). Now to solution space. A couple of months ago, in this message http://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html I acted on Brian Carpenter's suggestion to examine whether any of the existing extension headers could not have been equally well implemented by one of the following: - hop-by-hop option - destination option - upper-layer header My conclusion -- subject to provisos that the Destination Options header be allowed to appear more than twice and that constraints be allowed regarding the order in which destination options could appear -- was that the only extension headers that had really good reasons for being extension headers rather than one of the above were the Fragment Header and the Authentication Header, and AH was so classified only because it is shared with IPv4, which has no analog to the Destination Options header. Based on that, I would be perfectly comfortable with the solution proposed in Section 5.3, i.e., prohibiting new extension headers. That would largely(*) obsolete RFC 6564. As for the other alternatives, I can't see any technical reason why the Destination Options header (subject to the provisos stated above) could not be used under any circumstance when the UEH (Section 5.1) would be wanted. And given the previous history "Yes we wanted to do this as well, but the WG didn't want to waste a protocol number for something that may never be used" when RFC 6564 was being developed (see Suresh Krishnan's message http://www.ietf.org/mail-archive/web/ipv6/current/msg20168.html), it would require a remarkable turnaround to get consensus for the range of values alternative (Section 5.2). That being said, I can live with any of the alternatives suggested in the draft. If we are unable to come to consensus on any of those alternatives (which IMHO would be an unfortunate outcome), I think we should at least publish advice to implementors of middleboxes that any unrecognized Next Header value SHOULD be treated as if it indicates the presence of an unknown upper-layer header, and that they MUST have a configuration option to pass packets containing such values (as specified in RFC 7045). Accompanying that should be an admonition to protocol designers to plan for such behavior. See also Brian Carpenter's message http://www.ietf.org/mail-archive/web/ipv6/current/msg20285.html for more discussion of this issue. Thanks and regards, Mike Heard (*) As far as I can tell, the one part of RFC 6564 that would not be obsoleted by such a move is this: New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible. Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential in the document proposing the new option with hop-by-hop behavior. On Tue, 8 Apr 2014, Fernando Gont wrote: > Folks, > > We have published a revision of the aforementioned I-D. It is available > at: > > > This version hopefully does a better job about describing the problem, > and also, rather than focusing on a single solution, it describes three > possible alternative solutions, with pros and cons. > > We'd like to receive feedback on this document, including feedback on > which of the possible solutions is deemed as the most appropriate. > > Thanks so much! > Fernando et al > > > > > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-6man-ipv6-universal-extension-header-01.txt > Date: Tue, 08 Apr 2014 03:39:07 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , "Shucheng LIU (Will)" > , "Suresh Krishnan" > , Hagen Paul Pfeifer > , Will (Shucheng) Liu > , "Hagen Paul Pfeifer" > , Suresh Krishnan > , "Fernando Gont" > > > A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-ipv6-universal-extension-header > Revision: 01 > Title: IPv6 Universal Extension Header > Document date: 2014-04-08 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/ > Htmlized: > http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-universal-extension-header-01 > > Abstract: > This document analyzes a problem in the Uniform Format for IPv6 > Extension Headers specified in RFC 6564, which results in nodes not > being able to process an IPv6 Header Chain if it contains an > unrecognized IPv6 Extension Header that follows the aforementioned > Uniform Format. It analyzes the implications of the aforementioned > problem, and discusses a number of possible solutions, including the > specification of a new IPv6 Extension Header - the Universal > Extension Header - that overcomes the aforementioned issues. > > > > > > 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. > > The IETF Secretariat > > > > > From nobody Mon Apr 21 16:34:06 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 EFA791A031D; Mon, 21 Apr 2014 16:33:59 -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 I1ia6LIYgOKS; Mon, 21 Apr 2014 16:33:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B15431A02BE; Mon, 21 Apr 2014 16:33:58 -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-resilient-rs-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421233358.25573.65946.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 16:33:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xmEx65xj46CpShx7btjfp_F5Hu0 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: Mon, 21 Apr 2014 23:34:00 -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 : Packet loss resiliency for Router Solicitations Authors : Suresh Krishnan Dmitry Anipko Dave Thaler Filename : draft-ietf-6man-resilient-rs-03.txt Pages : 7 Date : 2014-04-21 Abstract: When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-resilient-rs-03 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 Mon Apr 21 18:20: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 68BCF1A033B for ; Mon, 21 Apr 2014 18:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YZm625H5nQr5 for ; Mon, 21 Apr 2014 18:20:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C71A033E for <6man@ietf.org>; Mon, 21 Apr 2014 18:20:40 -0700 (PDT) Received: from [186.134.14.172] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WcPNt-0001zF-6d; Tue, 22 Apr 2014 03:20:32 +0200 Message-ID: <5355B58F.1090908@gont.com.ar> Date: Mon, 21 Apr 2014 21:19:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "C. M. Heard" , Fernando Gont Subject: Re: Revision of draft-gont-6man-ipv6-universal-extension-header References: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> <5343D86B.3060502@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/P6dXZOnUzdqpCeWsr0Ke9WRFjBM 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: Tue, 22 Apr 2014 01:20:45 -0000 Hi, Mike, Thanks so much for your feedback! Please find my comments in-line.... On 04/19/2014 01:51 PM, C. M. Heard wrote: > In Section 4, Implications, you state: > > Since there is no way for a node to process IPv6 extension > headers that employ unknown next header values, an IPv6 host that > receives a packet that employs a new IPv6 extension header will > not be able to parse the IPv6 header chain past that unknown > extension header, and hence it will drop the aforementioned > packet. > > It seems to me that this is not really a problem, since RFC 2460 > Section 4 already mandates that a host discard packets with > extension headers that it does not recognize: > > If, as a result of processing a header, a node is required to > proceed to the next header but the Next Header value in the > current header is unrecognized by the node, it should discard the > packet and send an ICMP Parameter Problem message to the source > of the packet, with an ICMP Code value of 1 ("unrecognized Next > Header type encountered") and the ICMP Pointer field containing > the offset of the unrecognized value within the original packet. > The same action should be taken if a node encounters a Next > Header value of zero in any header other than an IPv6 header. Good grief. I guess one would just conclude that "it is impossible to incrementally deploy new EHs". That said, there's a different assumption that is very widespread in that one can parse an IPv6 header chain even it it contains new EHs. At the very least, it would seem that this should be clarified. > The paragraph above does use the word "node" rather than "host" but > in the context of RFC 2460 it does refer specifically to an end > system ("the node [...] identified in the Destination Address field > of the IPv6 header"). Not really. It could be a router, if the packet used a Routing Header. > As far as I am aware, there have been no updates to the IPv6 > specifications requiring or even suggesting that end systems should > ever try to skip over extension headers that they do not recognize. > The problem exists only for middleboxes that examine and act on > extension headers, so I recommend that this draft drop all > discussion of end systems. I understand your point. Me, I think it would be worthwhile to note that you cannot really "incrementally deploy" new EHs... at least without an Universal Extension Header. > Furthermore, I don't see how the extension header problem discussed > in this draft impedes deployment of transport protocols. To be > sure, here are problems with middleboxes filtering out transport > protocols that they don't know, but that is an issue even without > extension headers. Right now, there's the misleading assumption (confusion?) that you *can* parse past unknown EHs. I wouldn't be surprised if a middlebox that receives a packet with a new transport protocol assumes that the corresponding header is really an EH, and tries to parse it according to RFC6564, and hence discard th packet. > I therefore suggest the following replacement for Section 4 of your > draft: > > The current impossibility to parse an IPv6 header chain that > includes unknown Next Header values results in concrete > implications for the extensibility of the IPv6 protocol, and the > deployability of IPv6 extension headers. Specifically, a > middlebox that needs to process the transport-protocol header > will be faced with the dilemma of what to do with packets that > employ unknown Next Header values. Since it will not be able to > parse the IPv6 header chain past the unknown Next Header, it is > very likely that it will drop such packets. > > We believe that the current situation has implications that are > generally overlooked, and that, whatever the outcome, it should be > the result of an explicit decision by our community, rather than > simply "omission". > > BTW, I strongly agree with that last paragraph (which I did not > change). Ok. I'll wait for your response to my comments above -- but will keep this text in mind for incorporation. > Now to solution space. A couple of months ago, in this message > > http://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html > > I acted on Brian Carpenter's suggestion to examine whether any of > the existing extension headers could not have been equally well > implemented by one of the following: > > - hop-by-hop option > - destination option > - upper-layer header > > My conclusion -- subject to provisos that the Destination Options > header be allowed to appear more than twice and that constraints be > allowed regarding the order in which destination options could > appear -- was that the only extension headers that had really good > reasons for being extension headers rather than one of the above > were the Fragment Header and the Authentication Header, and AH was > so classified only because it is shared with IPv4, which has no > analog to the Destination Options header. Based on that, I would be > perfectly comfortable with the solution proposed in Section 5.3, > i.e., prohibiting new extension headers. That would largely(*) > obsolete RFC 6564. Point taken. > As for the other alternatives, I can't see any technical reason why > the Destination Options header (subject to the provisos stated > above) could not be used under any circumstance when the UEH > (Section 5.1) would be wanted. I guess the argument in favor of UEH would be "to leave the door open for future uses that might need a new EH, but that we cannot think of today". > And given the previous history > > "Yes we wanted to do this as well, but the WG didn't want to waste > a protocol number for something that may never be used" > > when RFC 6564 was being developed (see Suresh Krishnan's message > http://www.ietf.org/mail-archive/web/ipv6/current/msg20168.html), it > would require a remarkable turnaround to get consensus for the range > of values alternative (Section 5.2). Me, I fully agree. > That being said, I can live with any of the alternatives suggested > in the draft. > > If we are unable to come to consensus on any of those alternatives > (which IMHO would be an unfortunate outcome), I think we should at > least publish advice to implementors of middleboxes that any > unrecognized Next Header value SHOULD be treated as if it indicates > the presence of an unknown upper-layer header, and that they MUST > have a configuration option to pass packets containing such values > (as specified in RFC 7045). Accompanying that should be an > admonition to protocol designers to plan for such behavior. Agreed. > (*) As far as I can tell, the one part of RFC 6564 that would not be > obsoleted by such a move is this: > > New options for the existing Hop-by-Hop Header SHOULD NOT be > created or specified unless no alternative solution is feasible. > Any proposal to create a new option for the existing Hop-by-Hop > Header MUST include a detailed explanation of why the hop-by-hop > behavior is absolutely essential in the document proposing the > new option with hop-by-hop behavior. Agreed. Although some folks have argued that, in such case, we better incorporate that para into oour document, and obsolete RFC6564. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Apr 21 22:51:51 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 9C7C81A003A for ; Mon, 21 Apr 2014 22:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 apXHN5vCsoeZ for ; Mon, 21 Apr 2014 22:51:49 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511E51A0084 for <6man@ietf.org>; Mon, 21 Apr 2014 22:51:42 -0700 (PDT) Received: (qmail 11772 invoked from network); 21 Apr 2014 22:51:35 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Apr 2014 22:51:35 -0700 Date: Mon, 21 Apr 2014 22:51:35 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Fernando Gont Subject: Re: Revision of draft-gont-6man-ipv6-universal-extension-header In-Reply-To: <5355B58F.1090908@gont.com.ar> Message-ID: References: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> <5343D86B.3060502@si6networks.com> <5355B58F.1090908@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DbQ4Z6a7Dsq5CUsvGtPVquW1dBI 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: Tue, 22 Apr 2014 05:51:50 -0000 On Mon, 21 Apr 2014, Fernando Gont wrote: > > The paragraph above does use the word "node" rather than "host" but > > in the context of RFC 2460 it does refer specifically to an end > > system ("the node [...] identified in the Destination Address field > > of the IPv6 header"). > > Not really. It could be a router, if the packet used a Routing Header. True, but that does not change my main point: end systems are required by 2460 to discard any extension header they don't understand, so a UEH does not help them work better. The problem it solves is that of middleboxes being unable to find the upper-layer header. > > As far as I am aware, there have been no updates to the IPv6 > > specifications requiring or even suggesting that end systems should > > ever try to skip over extension headers that they do not recognize. > > The problem exists only for middleboxes that examine and act on > > extension headers, so I recommend that this draft drop all > > discussion of end systems. > > I understand your point. Me, I think it would be worthwhile to note that > you cannot really "incrementally deploy" new EHs... at least without an > Universal Extension Header. Yes, that's true, since the barrier to incremental deployment is that middleboxes can't presently parse past them. > > Furthermore, I don't see how the extension header problem discussed > > in this draft impedes deployment of transport protocols. To be > > sure, here are problems with middleboxes filtering out transport > > protocols that they don't know, but that is an issue even without > > extension headers. > > Right now, there's the misleading assumption (confusion?) that you *can* > parse past unknown EHs. I wouldn't be surprised if a middlebox that > receives a packet with a new transport protocol assumes that the > corresponding header is really an EH, and tries to parse it according to > RFC6564, and hence discard th packet. Point taken. //cmh From nobody Tue Apr 22 02:04:56 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 8CE841A017D for ; Tue, 22 Apr 2014 02:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 AoHm51jhE1wk for ; Tue, 22 Apr 2014 02:04:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD591A017E for <6man@ietf.org>; Tue, 22 Apr 2014 02:04:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 74CCA9C; Tue, 22 Apr 2014 11:04:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6D0569A for <6man@ietf.org>; Tue, 22 Apr 2014 11:04:41 +0200 (CEST) Date: Tue, 22 Apr 2014 11:04:41 +0200 (CEST) From: Mikael Abrahamsson To: 6man@ietf.org Subject: IPv6 multicast GLOP space Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/XdbPHjQOPlpblGT8QSxN2YOMguU 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, 22 Apr 2014 09:04:54 -0000 Hi, I can't find any active multicast working group (apart from PIM), so I thought 6man would be next stop. I can't find any multicast GLOP space for IPv6. I believe there is a need for 32bit ASN based allocated space for multicast addresses. This has most likely been talked about before, anyone care to give history lesson? In what WG should this be handled? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 22 02:12:36 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 C77B81A0197 for ; Tue, 22 Apr 2014 02:12:34 -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] 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 Mm_sRlaXLwDi for ; Tue, 22 Apr 2014 02:12:30 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 227CC1A017D for <6man@ietf.org>; Tue, 22 Apr 2014 02:12:30 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 82CED10037C7B; Tue, 22 Apr 2014 09:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1398157972; bh=MRs6IP+u1m5zQgeDMjYBJQOQoj3Dq52MvW4imrwkzxw=; h=Date:From:To:Subject:References:In-Reply-To; b=gjiq3jHtapqxEDMnoQeV8W6NwSU3TEdPBeI8xU2/PdDHganIe224aX/H99ocGATs3 yLp2yiW0H5Dgni/LZj4lHRuUB9kWoJmIFQZJJh0VSJrOFTpWZ5f7OCn9MY6zsRpP5O OlZj1p6ckz/nGN45KUun0PX07wys7u8S8ueFFpqsGUWL9EP3qo2DfUzoFbHF1q2EYk YxsjzTqV/Z5lxmy0yK8AJ0agUI3zDBgwG9W9Ws1IraLEyHVSfCrIhYOeTMFxFLizu1 pfd72zARcHhlDlEenK7xQYq1KYnjc5DMYpxJSIkCEIYQlSNE/Kyfky2z00RZEHWnSL UXjAu3Js0pmEA== Message-ID: <53563273.8070405@massar.ch> Date: Tue, 22 Apr 2014 11:12:19 +0200 From: Jeroen Massar Organization: Massar Networking User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mikael Abrahamsson , 6man@ietf.org Subject: Re: IPv6 multicast GLOP space References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/w6xFOyC2n5cU7xhOErcLI8NeQh0 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, 22 Apr 2014 09:12:34 -0000 On 2014-04-22 11:04 , Mikael Abrahamsson wrote: > > Hi, > > I can't find any active multicast working group (apart from PIM), so I > thought 6man would be next stop. > > I can't find any multicast GLOP space for IPv6. I believe there is a > need for 32bit ASN based allocated space for multicast addresses. You can base your multicast-address space off of your IPv6 prefix, hence no need to do it off an ASN. Eg if you have 2001:db8:1234:5678::/64 then your prefix is: FF3x:0030:2001:db8:1234:5678::/96 See RFC3306 / RFC3956 for the details. Greets, Jeroen From nobody Tue Apr 22 13:33: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 BB9701A025B for ; Tue, 22 Apr 2014 13:33:21 -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 7HktwUsjnBoS for ; Tue, 22 Apr 2014 13:33:20 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A86E91A0258 for <6man@ietf.org>; Tue, 22 Apr 2014 13:33:20 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rq2so2482pbb.11 for <6man@ietf.org>; Tue, 22 Apr 2014 13:33:15 -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=kkkReqIh0hONbXhWF52nTVXBI8kFun/2iZXFBp51K54=; b=ahWEX/z13WVjhQTDGGj0BrdVqF9ibhqgVqFyfxmMCYAFKUOS3DFPN2FVVQjZrzCI0g lg8sdNK3/evIVP0Ah9bOq9Y8ekP2T+HKqT8hZ7Emh2ywm8K8Ju5gN35DiABSjF6VK4jJ FyLgxPGgC0HW3vdOo00C/bQrXZy4oL+yt279+By1edTm/za/bLdCCBCtlJiOIKFPuAVY P6qWf9kwEhytuEKHU5g1lAtb29LO5MIeFLQ+nTz/I8AgaWjFy5yLQPy7pH6S0fbfJADs MX+fTUS30Zsu29zuFUlDcMDXSUfq1mUhnlJxQtsckDANa0cyZ+sa4u8/HME6/gpxB7yp 5WAg== X-Received: by 10.68.102.34 with SMTP id fl2mr46962749pbb.2.1398198795355; Tue, 22 Apr 2014 13:33:15 -0700 (PDT) Received: from [192.168.178.20] (42.200.69.111.dynamic.snap.net.nz. [111.69.200.42]) by mx.google.com with ESMTPSA id ph1sm206644154pac.14.2014.04.22.13.33.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 13:33:14 -0700 (PDT) Message-ID: <5356D20C.7040606@gmail.com> Date: Wed, 23 Apr 2014 08:33:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: Revision of draft-gont-6man-ipv6-universal-extension-header References: <20140408103907.23507.7047.idtracker@ietfa.amsl.com> <5343D86B.3060502@si6networks.com> <5355B58F.1090908@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/OhsMRqQ7kz_JLM0kIsnl4mL_v9M Cc: Fernando Gont , 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: Tue, 22 Apr 2014 20:33:21 -0000 On 22/04/2014 17:51, C. M. Heard wrote: ... >> Right now, there's the misleading assumption (confusion?) that you *can* >> parse past unknown EHs. I wouldn't be surprised if a middlebox that >> receives a packet with a new transport protocol assumes that the >> corresponding header is really an EH, and tries to parse it according to >> RFC6564, and hence discard th packet. > > Point taken. But operationally, it doesn't matter. The destination doesn't receive the packet, and whether the middlebox discarded it because it thought it was a suspicious extension header or a suspicious transport payload is of no importance. I would expect firewalls to have a whitelist of extension headers and a whitelist of transport protocols, and an unknown extension header or an unknown transport protocol will be in neither list, so will be discarded. Please don't forget that RFC 7045 "updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future." A universal extension header format makes RFC 7045 easier to implement, but doesn't change the principle. I don't believe any other changes to RFC 2460 are needed in this area. Brian From nobody Tue Apr 22 21:39:10 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 4C44A1A02B3; Tue, 22 Apr 2014 21:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 jySnvlF-RU1t; Tue, 22 Apr 2014 21:39:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B71A003B; Tue, 22 Apr 2014 21:38:37 -0700 (PDT) Received: from DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) by DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 23 Apr 2014 04:38:31 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) by DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) with mapi id 15.00.0918.000; Wed, 23 Apr 2014 04:38:31 +0000 From: Dave Thaler To: Jeroen Massar , Mikael Abrahamsson , "6man@ietf.org" <6man@ietf.org> Subject: RE: IPv6 multicast GLOP space Thread-Topic: IPv6 multicast GLOP space Thread-Index: AQHPXgn0oFDp+XlYDEe2oW8//pWUppsdWdiAgAFFJuA= Date: Wed, 23 Apr 2014 04:38:31 +0000 Message-ID: <8f395211d1934aa498269ef996161124@DM2PR03MB414.namprd03.prod.outlook.com> References: <53563273.8070405@massar.ch> In-Reply-To: <53563273.8070405@massar.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(377454003)(199002)(189002)(377424004)(51704005)(13464003)(24454002)(81542001)(77096999)(76176999)(54356999)(99396002)(92566001)(80022001)(87936001)(77982001)(19580395003)(80976001)(46102001)(66066001)(20776003)(79102001)(50986999)(99286001)(15975445006)(76576001)(76482001)(2656002)(86612001)(85852003)(83322001)(19580405001)(83072002)(4396001)(33646001)(86362001)(74502001)(81342001)(31966008)(74662001)(74316001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB414; H:DM2PR03MB414.namprd03.prod.outlook.com; FPR:ECE4C9AE.ADF657E2.74DD7FA3.886A9359.20211; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gsy0w80HWzyVeUAoaOPdngVHM98 Cc: "mboned@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, 23 Apr 2014 04:39:08 -0000 Jeroen is correct. IPv6 is already more flexible than GLOP is. GLOP was a workaround for the inability of IPv4 to be as flexible as IPv6 is. -Dave (co-author of RFC 3306) P.S. MBoneD is the relevant multicast working group here.=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Tuesday, April 22, 2014 2:12 AM > To: Mikael Abrahamsson; 6man@ietf.org > Subject: Re: IPv6 multicast GLOP space >=20 > On 2014-04-22 11:04 , Mikael Abrahamsson wrote: > > > > Hi, > > > > I can't find any active multicast working group (apart from PIM), so I > > thought 6man would be next stop. > > > > I can't find any multicast GLOP space for IPv6. I believe there is a > > need for 32bit ASN based allocated space for multicast addresses. >=20 > You can base your multicast-address space off of your IPv6 prefix, hence = no > need to do it off an ASN. >=20 > Eg if you have 2001:db8:1234:5678::/64 then your prefix is: >=20 > FF3x:0030:2001:db8:1234:5678::/96 >=20 > See RFC3306 / RFC3956 for the details. >=20 > Greets, > Jeroen >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Apr 29 23:54:02 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 D29EE1A6EE5; Tue, 29 Apr 2014 23:54:00 -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 PfZqaayJ-zJV; Tue, 29 Apr 2014 23:53:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D871A6EE8; Tue, 29 Apr 2014 23:53:59 -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-predictable-fragment-id-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430065359.31690.30174.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 23:53:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6Ut0RecrxyRA-N7pIn1SJ2H2pHs 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, 30 Apr 2014 06:54:01 -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 : Security Implications of Predictable Fragment Identification Values Author : Fernando Gont Filename : draft-ietf-6man-predictable-fragment-id-01.txt Pages : 16 Date : 2014-04-29 Abstract: IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that employed for any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations use simple a global counter for setting the Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-predictable-fragment-id/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-predictable-fragment-id-01 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 Apr 30 14:06:09 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 A4A321A0948; Wed, 30 Apr 2014 14:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ObmUA4MepWOv; Wed, 30 Apr 2014 14:06:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id DC3861A0957; Wed, 30 Apr 2014 14:05:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0D4318000D; Wed, 30 Apr 2014 14:05:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7217 on A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140430210539.E0D4318000D@rfc-editor.org> Date: Wed, 30 Apr 2014 14:05:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZSAWOlY4l-bWuAYt4PzbkoDg3g8 Cc: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.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, 30 Apr 2014 21:06:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7217 Title: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) Author: F. Gont Status: Standards Track Stream: IETF Date: April 2014 Mailbox: fgont@si6networks.com Pages: 19 Characters: 48497 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-stable-privacy-addresses-17.txt URL: http://www.rfc-editor.org/rfc/rfc7217.txt This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses). This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Apr 30 23:09: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 CE4DF1A09F8; Wed, 30 Apr 2014 23:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ClyiU_4L0904; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 300011A0A03; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1398924532; x=1400134132; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Vte9Knz0JjhgdbAJ1kp3eKKp3ToonmUBVOihCQgxQ+g=; b=IsqidTfcc30ArMFreNaKt0c6brNj2SKNlCN8ZCo1pAluHEJaWd+Ci9Oe XWlAzAJ92+OiEYY0iziK1OkPdt2jkt/LH503Sr7tai186awJa1AOCPn9i 9ujEe2LHkSUyJrB21kstU1jSwuunyg8Syqu0L7Wg/CzzIL3EkwcN8lYNk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAB3kYVOtJA2L/2dsb2JhbABZgwZPV8RYgRgWdIIsOj8SAT5CJwQBDYhGDcoGF45RhEAEmSqBPJEwgzOCKw X-IronPort-AV: E=Sophos;i="4.97,963,1389744000"; d="scan'208";a="40196646" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 01 May 2014 06:08:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4168qRh016918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 06:08:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 1 May 2014 01:08:52 -0500 From: "Rajiv Asati (rajiva)" To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Subject: Q about IPv4-mapped IPv6 address & MPLS Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpHw== Date: Thu, 1 May 2014 06:08:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.218.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <63CAFEE989E18C4398F9ABD33C077125@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5bTw2KvFiv9pDFcsWqkAKwDn3hA Cc: "mpls@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, 01 May 2014 06:08:58 -0000 We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 of [RFC4291]).=20 1. Should/Would they appear in IPv6 routing table? 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or treated as a loopback packet, if ever received? The answer to Q#1 will help MPLS WG to decide the proper handling of v4-mapped v6 addresses in LDPv6 draft section 7 1st para. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * The answer to Q2 will help us assess the efficacy of RFC4379. Thanks.=20 --=20 Cheers, Rajiv=20 * // An LSR MUST treat the IPv4-mapped IPv6 address, defined in section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and not mix it with the 'corresponding' IPv4 address. // From nobody Wed Apr 30 23:40:09 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 452411A0A1D; Wed, 30 Apr 2014 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 Xlf-HPyfvtsC; Wed, 30 Apr 2014 23:40:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0948D1A0A17; Wed, 30 Apr 2014 23:40:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41647A6; Thu, 1 May 2014 08:40:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398926401; bh=IUHzY9P5Tzupc+oTZ9Cw00jAZ0R12KITCQd0JZw7mT8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=v9iSrtsKIY6SlqfOHArroPqa2T7ik1NVdcSEWIWkldg0RNfVZmbMtfF+BrgcpmuZq 3VRaVh/8zy+n1Z2s+Ol4Lgn/L/sKA+JWtQVmdhC7S4UYkIh8kOMz91uRIwm2x5ywAo k5asWe7ioeDjuKaX1yw1Y7fZCMl438Vn0IVEWQd4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D8FAA5; Thu, 1 May 2014 08:40:01 +0200 (CEST) Date: Thu, 1 May 2014 08:40:01 +0200 (CEST) From: Mikael Abrahamsson To: "Rajiv Asati (rajiva)" Subject: Re: Q about IPv4-mapped IPv6 address & MPLS In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/51NpYc8RkToX25rT-I_m21ZPQqA Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "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: Thu, 01 May 2014 06:40:07 -0000 On Thu, 1 May 2014, Rajiv Asati (rajiva) wrote: > > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]). > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * > > The answer to Q2 will help us assess the efficacy of RFC4379. http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 I realise this draft seems to have died, but I would never expect to see packets with these addresses on the wire or in the routing table and if they're there, I would want hosts/routers to drop them. Not doing this seems to me it would open to all kinds of unwanted consequences when it comes to filtering etc. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 30 23:44:51 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 BDD8A1A0A17; Wed, 30 Apr 2014 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vTFzjQ12N6O9; Wed, 30 Apr 2014 23:44:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32F1A0A15; Wed, 30 Apr 2014 23:44:37 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB423.namprd03.prod.outlook.com (10.141.78.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 06:44:29 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0929.001; Thu, 1 May 2014 06:44:29 +0000 From: Christian Huitema To: "Rajiv Asati (rajiva)" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Subject: RE: Q about IPv4-mapped IPv6 address & MPLS Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQ Date: Thu, 1 May 2014 06:44:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.156.113] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(77096999)(87936001)(33646001)(2201001)(19580395003)(85852003)(20776003)(76576001)(15202345003)(46102001)(79102001)(83072002)(101416001)(81342001)(77982001)(92566001)(54356999)(86362001)(50986999)(99396002)(83322001)(80022001)(99286001)(81542001)(74502001)(86612001)(4396001)(80976001)(2656002)(66066001)(31966008)(15975445006)(76176999)(76482001)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB423; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BCA2C0F5.3EFE1DC9.9D11349.C68AE311.201EE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fCt9pHllqohZaQbyiSIE2ut2e78 Cc: "mpls@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, 01 May 2014 06:44:41 -0000 > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]).=20 > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped o= r > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * You may want to check RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. R= FC 6052 updates RFC4291, and lets translators construct domain specific add= resses that can actually be used in the routing tables. It also includes an= answer to your loopback packet question: The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets. -- Christian Huitema From nobody Wed Apr 30 23:46:52 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 AE1E61A0A15 for ; Wed, 30 Apr 2014 23:46:50 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 kq1bHcZQlETl for ; Wed, 30 Apr 2014 23:46:49 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id A47C61A0A27 for <6man@ietf.org>; Wed, 30 Apr 2014 23:46:46 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1WfklV-0006Ph-Va; Thu, 01 May 2014 16:46:42 +1000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 01 May 2014 16:46:33 +1000 Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS From: Hesham Soliman To: Mikael Abrahamsson , "Rajiv Asati (rajiva)" Message-ID: Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1XzpUgOimojyJ-J9uZTsovfeAMA Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "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: Thu, 01 May 2014 06:46:51 -0000 >> >>We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >> of [RFC4291]). >> >> 1. Should/Would they appear in IPv6 routing table? >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped >>or >> treated as a loopback packet, if ever received? >> >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >> >> The answer to Q2 will help us assess the efficacy of RFC4379. > >http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 > >I realise this draft seems to have died, but I would never expect to see >packets with these addresses on the wire =3D> I recall an information RFC but don=B9t remember the number. I agree they will most likely not appear on the wire. > or in the routing table =3D> That=B9s a different story. I don=B9t think there is anything banning this, not least due to the fact that it is an implementation issue. If that entry points to an IPv4 tunnel it should be fine. So it is possible to implement a tunnel that way inside the host/router and nothing to stop someone from doing unless I missed an RFC. > and if=20 >they're there, I would want hosts/routers to drop them. =3D> Is that behaviour documented somewhere? Also, you=B9re mixing them appearing on the wire with an internal implementation issue. Hesham >Not doing this=20 >seems to me it would open to all kinds of unwanted consequences when it >comes to filtering etc. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 30 23:59:36 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 472AD1A0A27; Wed, 30 Apr 2014 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 k07gSmZUr0tY; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA51A0A17; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B4FCA6; Thu, 1 May 2014 08:59:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398927562; bh=8xqZPIWyBXZqp6CTGwV0Pcox1VFGEELHcpcDyoP4C6o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=y0mdbxSSvD+nRQBAoYSpkaZ6yRxzHjDS5vmaEe/Mhw4WWxMKaBn43953IW2wzLa6h jL1kokdz7ISR24CwYn1LEx3puCia6sYgb8PzLCy0I1MQHa+1hIcyv8WKVxwvwjzDai AsEaanXlo9009qbDj0kfNDEJ+xJgta+lxRRHEucU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7DB4CA5; Thu, 1 May 2014 08:59:22 +0200 (CEST) Date: Thu, 1 May 2014 08:59:22 +0200 (CEST) From: Mikael Abrahamsson To: Hesham Soliman Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-478116969-1398927562=:29282" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/NxzA5giR8SFyaMp_PZKWPyGB7Ps Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "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: Thu, 01 May 2014 06:59:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-478116969-1398927562=:29282 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 1 May 2014, Hesham Soliman wrote: >> or in the routing table > > => Thatıs a different story. I donıt think there is anything banning this, > not least due to the fact that it is an implementation issue. If that > entry points to an IPv4 tunnel it should be fine. So it is possible to > implement a tunnel that way inside the host/router and nothing to stop > someone from doing unless I missed an RFC. Let me qualify my statement that I don't want to see it outside the box, ie in routes it's sending to anyone else. If it's in the internal RIB I have no problem with it, if it starts being announced in IGP and BGP then I think it's a bigger issue. >> and if >> they're there, I would want hosts/routers to drop them. > > => Is that behaviour documented somewhere? Also, youıre mixing them > appearing on the wire with an internal implementation issue. If this is documented somewhere, I am not aware, but I am definitely not the right person to ask about what might be in what RFC. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-478116969-1398927562=:29282--