From swmike@swm.pp.se Wed Aug 1 03:08:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA221F86F0 for ; Wed, 1 Aug 2012 03:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JusqznalKaV for ; Wed, 1 Aug 2012 03:08:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D64C721F86F1 for ; Wed, 1 Aug 2012 03:08:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 783029C; Wed, 1 Aug 2012 12:08:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 739989A; Wed, 1 Aug 2012 12:08:45 +0200 (CEST) Date: Wed, 1 Aug 2012 12:08:45 +0200 (CEST) From: Mikael Abrahamsson To: Daniel Roesen In-Reply-To: <20120730211819.GA1177@srv03.cluenet.de> Message-ID: References: <20120730211819.GA1177@srv03.cluenet.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 10:08:47 -0000 On Mon, 30 Jul 2012, Daniel Roesen wrote: > I was considering using an EDNS0 option to request DNS64 service, kinda > "DNS64 desired" similar to "recursion desired". Single-stack IPv6 > clients would set this flag. I think this sounds like a good idea, then our regular resolvers would only give DNS64 responses to clients who ask for it, and if we know some devices need only DNS64 responses (older clients without this functionality and ones we know will be behind NAT44 anyway), then we give them special DNS64-only resolvers. Would such an option be something only newer implementations used, so it's not "always before set to 0" (older clients without this implemented), because then modern clients (with this option implemented) could indicate to the DNS64 resolvers that they did *not* want DNS64 responses as well. -- Mikael Abrahamsson email: swmike@swm.pp.se From dr@cluenet.de Wed Aug 1 03:26:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72A21F85FC for ; Wed, 1 Aug 2012 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFGF-k08b5df for ; Wed, 1 Aug 2012 03:26:55 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27021F85D6 for ; Wed, 1 Aug 2012 03:26:55 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 293A01086DB; Wed, 1 Aug 2012 12:26:54 +0200 (CEST) Date: Wed, 1 Aug 2012 12:26:54 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120801102654.GA18894@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20120730211819.GA1177@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 10:26:56 -0000 On Wed, Aug 01, 2012 at 12:08:45PM +0200, Mikael Abrahamsson wrote: >> I was considering using an EDNS0 option to request DNS64 service, kinda >> "DNS64 desired" similar to "recursion desired". Single-stack IPv6 clients >> would set this flag. > > I think this sounds like a good idea, then our regular resolvers would only > give DNS64 responses to clients who ask for it, and if we know some devices > need only DNS64 responses (older clients without this functionality and > ones we know will be behind NAT44 anyway), then we give them special > DNS64-only resolvers. Personally, I wouldn't complicate it that much but just provide a single set of resolvers which are capable of DNS64 if requested by the endpoint. But that depends on some considerations specific to the outfit's user base and access technology. > Would such an option be something only newer implementations used, so it's > not "always before set to 0" (older clients without this implemented), > because then modern clients (with this option implemented) could indicate > to the DNS64 resolvers that they did *not* want DNS64 responses as well. EDNS0 is defined in RFC2671. EDNS0 sports querying for a pseudo RR "OPT" which contains a 16-bit flag field. Currently, there is only one of those defined (http://www.iana.org/assignments/dns-parameters/): ============================================================== Registry Name: EDNS Header Flags (16 bits) Reference: [RFC2671] Registration Procedures: RFC Required Registry: Bit Flag Description Reference --------- ---- --------------------- ------------------ Bit 0 DO DNSSEC answer OK [RFC4035][RFC3225] Bit 1-15 Reserved ============================================================== The EDNS0 spec calls for the 16-bit field to be set to zero unless usage is defined, so one can expect the undefined bits to be zero. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From swmike@swm.pp.se Wed Aug 1 03:57:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7320F21F86A0 for ; Wed, 1 Aug 2012 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q454dz9XYXNy for ; Wed, 1 Aug 2012 03:57:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id ED9CA21F869F for ; Wed, 1 Aug 2012 03:57:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A73839C; Wed, 1 Aug 2012 12:57:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A17A59A; Wed, 1 Aug 2012 12:57:44 +0200 (CEST) Date: Wed, 1 Aug 2012 12:57:44 +0200 (CEST) From: Mikael Abrahamsson To: Daniel Roesen In-Reply-To: <20120801102654.GA18894@srv03.cluenet.de> Message-ID: References: <20120730211819.GA1177@srv03.cluenet.de> <20120801102654.GA18894@srv03.cluenet.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 10:57:46 -0000 On Wed, 1 Aug 2012, Daniel Roesen wrote: > The EDNS0 spec calls for the 16-bit field to be set to zero unless usage > is defined, so one can expect the undefined bits to be zero. Oki, well, then either we need two bits (one for DNS64 desired and one for DNS64 not desired) or just ignore one of the use-cases I described and go with a single bit (DNS64 desired). -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Wed Aug 1 06:47:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746E711E80FD for ; Wed, 1 Aug 2012 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF4ZELDMBG8o for ; Wed, 1 Aug 2012 06:47:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A24DC11E8100 for ; Wed, 1 Aug 2012 06:47:38 -0700 (PDT) Received: by lagv3 with SMTP id v3so4897386lag.31 for ; Wed, 01 Aug 2012 06:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YYSAfExB44LwVq21qiWlERxZdXFXJoqrWYCnvcOuMrA=; b=ZKJa6JL3E0P4tq+QFC1ECLCouX5CPgIJre9DfkgOxw8+ownng90Kn3e7umf3OFFsM2 FTjyGCGcxCFEc3bBkAiyc5uKawiMip+IyfSNNxqgaQpddxipi8h7p9omKR6jbSE2RGsH l7pVKJeYLmnxVV1fdVXnzIvytm0sf0eMPgALU7OeZdn6pbibX7YIJoDmqQ/1Jmu7bH8K vSvtFH1yWXS6kKDPe3QT3dhZIOaUEsQdlSzDxLlG10iHxpae0KE2xUU9aQQzq0pmDZSF 25d4glMjjNcj4K3wMJlEEmnkDSDPsDBCsYD+XMR2Tnr8D5rcVACnPp/VG/VqS2xXLiXN zgFg== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr18029878lab.51.1343828851766; Wed, 01 Aug 2012 06:47:31 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Wed, 1 Aug 2012 06:47:31 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Wed, 1 Aug 2012 06:47:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 06:47:31 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=e89a8f22bfb159362604c6348956 Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:47:40 -0000 --e89a8f22bfb159362604c6348956 Content-Type: text/plain; charset=ISO-8859-1 On Jul 31, 2012 10:30 PM, "Mikael Abrahamsson" wrote: > > On Wed, 1 Aug 2012, jouni korhonen wrote: > >>> Let's say we have a network where clients can connect, some will be dual stack, some will be IPv6 only (3GPP for instance, also wifi). In case the client is IPv6 only (single stack), I would like them to have access to DNS64/NAT64 infrastructure. >> >> >> For 3GPP networks this can be achieved using AAA to provision DNS servers >> for your APN.. obviously you need some additional logic then in your AAA >> server to hand out different DNS servers depending on the PDP-Type that got >> established. > > > I don't believe this solves my problem. If I hand out DNS64 for everybody who connects using IPv6, I might cause problems to clients who establish a second PDP context, this time IPv4 only (dual bearer). > > I read the 464xlat discussion from february, and I can only chime in with Cameron that getting v4v6 dual stack PDP context actually working in a 2G/3G/4G environement, is non-trivial. There are a lot of components that need to support it and it seems whenever I get one of them fixed, there is something else we didn't think of. > > Also handsets seem to be very slow to adopt this (the only time I've been able to successfully able to enable a dual stack single bearer is on LTE, which then fails miserably when handing over to (or trying to establish in) 2G/3G), but handsets also do not seem to go the way of supporting 2 single stack bearers either (at least not Android). My Galaxy Nexus with 4.1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (and I don't really know if it's the phone or the network (or both) that fails). > > I would at least like to thank Google for IPv6-enabling their phones so we have something to test with (we have USB dongles for computer connectivity as well, but that doesn't test the App ecosystem). I have been trying to reach someone at Apple to try to understand where they're headed, but so far no luck on that (which doesn't greatly surprise me considering their usual secrecy), but if someone from Apple reads this, it would greatly help if you would at least say for instance "it looks like we're going to support single v4v6 PDP context, single v4, or single v6 in the not too distant future", so we have something to plan for. > > Right now I have a really hard time internally trying to get something done because I can't say what we should be headed for, what will the handsets support in 1-2 years time. Installed base is also of great importance, if tens of percent doesn't support something (or will support it in the not too distant future) it's really hard to get anyone to spend time on implementing anything network side. > > So the only thing I can say for sure right now is that v6 only seems to work on a few android phones, and getting networking code into android would be easier (at least I imagine so) than to get baseband changes done to support new PDP context types. But this is just speculation on my part... > A bit off topic from the subject line, but i 100% agree with your rant about mobile challenges with dual stack. < plug> And, that is why 464XLAT is appealing. We took the matter into our own hands by leveraging the ability to contribute code into the android base (still in code review at Android, but builds for nexus s and galaxy nexus freely available as well as source code) so that the feature is avalable down stream to all Android OEMs and builds on the what we know commonly works (ipv6-only + nat64/dns64). This has the advantage of that it works today using existing generally available components and it does not carry the dual stack bagage (no ipv4 left for DS, happy eyeballs issues, ....) FYI. The T-Mobile USA Samsung SG2, SG3, Note, Nesus S and GNex all support ipv6-only with nat64/dns64. So, there is progress to build on. CB > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --e89a8f22bfb159362604c6348956 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 31, 2012 10:30 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Wed, 1 Aug 2012, jouni korhonen wrote:
>
>>> Let's say we have a network where clients can connect, som= e will be dual stack, some will be IPv6 only (3GPP for instance, also wifi)= . In case the client is IPv6 only (single stack), I would like them to have= access to DNS64/NAT64 infrastructure.
>>
>>
>> For 3GPP networks this can be achieved using AAA to provision DNS = servers
>> for your APN.. obviously you need some additional logic then in yo= ur AAA
>> server to hand out different DNS servers depending on the PDP-Type= that got
>> established.
>
>
> I don't believe this solves my problem. If I hand out DNS64 for ev= erybody who connects using IPv6, I might cause problems to clients who esta= blish a second PDP context, this time IPv4 only (dual bearer).
>
> I read the 464xlat discussion from february, and I can only chime in w= ith Cameron that getting v4v6 dual stack PDP context actually working in a = 2G/3G/4G environement, is non-trivial. There are a lot of components that n= eed to support it and it seems whenever I get one of them fixed, there is s= omething else we didn't think of.
>
> Also handsets seem to be very slow to adopt this (the only time I'= ve been able to successfully able to enable a dual stack single bearer is o= n LTE, which then fails miserably when handing over to (or trying to establ= ish in) 2G/3G), but handsets also do not seem to go the way of supporting 2= single stack bearers either (at least not Android). My Galaxy Nexus with 4= .1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (= and I don't really know if it's the phone or the network (or both) = that fails).
>
> I would at least like to thank Google for IPv6-enabling their phones s= o we have something to test with (we have USB dongles for computer connecti= vity as well, but that doesn't test the App ecosystem). I have been try= ing to reach someone at Apple to try to understand where they're headed= , but so far no luck on that (which doesn't greatly surprise me conside= ring their usual secrecy), but if someone from Apple reads this, it would g= reatly help if you would at least say for instance "it looks like we&#= 39;re going to support single v4v6 PDP context, single v4, or single v6 in = the not too distant future", so we have something to plan for.
>
> Right now I have a really hard time internally trying to get something= done because I can't say what we should be headed for, what will the h= andsets support in 1-2 years time. Installed base is also of great importan= ce, if tens of percent doesn't support something (or will support it in= the not too distant future) it's really hard to get anyone to spend ti= me on implementing anything network side.
>
> So the only thing I can say for sure right now is that v6 only seems t= o work on a few android phones, and getting networking code into android wo= uld be easier (at least I imagine so) than to get baseband changes done to = support new PDP context types. But this is just speculation on my part... >

A bit off topic from the subject line, but i 100% agree with your rant a= bout mobile challenges with dual stack.

< plug>

And, that is why 464XLAT is appealing. We took the matter into our own h= ands by leveraging the ability to contribute code into the android base (st= ill in code review at Android, but builds for nexus s and galaxy nexus free= ly available as well as source code) so that the feature is avalable down s= tream to all Android OEMs and builds on the what we know commonly works (ip= v6-only + nat64/dns64).

This has the advantage of that it works today using existing generally a= vailable components and it does not carry the dual stack bagage (no ipv4 le= ft for DS, happy eyeballs issues, ....)

FYI. The T-Mobile USA Samsung SG2, SG3, Note, Nesus S and GNex all suppo= rt ipv6-only with nat64/dns64. So, there is progress to build on.

</plug>

CB

>
> --
> Mikael Abrahamsson =A0 =A0email: s= wmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--e89a8f22bfb159362604c6348956-- From swmike@swm.pp.se Wed Aug 1 09:16:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AAD11E814C for ; Wed, 1 Aug 2012 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zp++7L-GZvg for ; Wed, 1 Aug 2012 09:16:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3711E8118 for ; Wed, 1 Aug 2012 09:16:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8D8909C; Wed, 1 Aug 2012 18:16:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8A3359A; Wed, 1 Aug 2012 18:16:15 +0200 (CEST) Date: Wed, 1 Aug 2012 18:16:15 +0200 (CEST) From: Mikael Abrahamsson To: Cameron Byrne In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:16:19 -0000 On Wed, 1 Aug 2012, Cameron Byrne wrote: > And, that is why 464XLAT is appealing. We took the matter into our own > hands by leveraging the ability to contribute code into the android base > (still in code review at Android, but builds for nexus s and galaxy nexus > freely available as well as source code) so that the feature is avalable > down stream to all Android OEMs and builds on the what we know commonly > works (ipv6-only + nat64/dns64). > > This has the advantage of that it works today using existing generally > available components and it does not carry the dual stack bagage (no ipv4 > left for DS, happy eyeballs issues, ....) > > FYI. The T-Mobile USA Samsung SG2, SG3, Note, Nesus S and GNex all support > ipv6-only with nat64/dns64. So, there is progress to build on. I wholeheartedly applaud your initiative here, and I think for instance 464XLAT to enable NAT64 to work for apps that have not been designed for IPv6 only use, is a key feature that is going to be needed in the next few years in order to get v6 only access off the ground. Developers of apps and PC programs generally do not test their software in an v6 environment (not even dual stack), and users want to use this software on their devices, so before there is a working solution we cannot deploy as that would cause customer outrage (my own very limited tests show for instance that Waze, Spotify and Skype doesn't work). Your list of apps on android that needs 464XLAT to work is excellent, please keep up the good work. Does 464XLAT make "portable hotspot" work as well? Currently with v6 only access it seems at least a Galaxy Nexus with 4.1.1 does "nothing". I would be very interested in testing 464XLAT on Windows 7 as well if it was available. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Wed Aug 1 12:05:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED2211E840F for ; Wed, 1 Aug 2012 12:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVKAlbLvdU3h for ; Wed, 1 Aug 2012 12:05:08 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE05C11E810B for ; Wed, 1 Aug 2012 12:05:06 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so578921lbb.31 for ; Wed, 01 Aug 2012 12:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5qdCtGfu5HBPx1NghMOg5VC6IbYo3hrs3hD77pUuaN8=; b=ugmICKNQlEKfzl+M3SHNLWCiiOInIB9p+AA/4ygO4COti3Sx0YnYjGKgAV1F6PlvbD j+SpT2oj3UFqfGoNpS9O1ttIpM+TkFRfNtnA613nNC2j/iZiPWRVOMiHA9c3VjYTK4Ce bnDy2mzMyqZKcZOocxV3fi1U1v11BlVLhk5Lc1sAKjOIA9eKj4JhqEuu3eXcet0X/qZ+ 1dpraPKWaRwjSlqQjF3zAqXxQ4Fmy186WayL1uoRn6Rc1MVKLHzUrIcPfpvoxpKPVwUl GT1FcnXGuR4DEIQ0izJC6c0pjrcX7CbbvSn0zeROZMx6Ut7WPjo3kfwXMFQtv3xgCeZ5 IrrA== MIME-Version: 1.0 Received: by 10.112.101.169 with SMTP id fh9mr8812321lbb.18.1343847905802; Wed, 01 Aug 2012 12:05:05 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Wed, 1 Aug 2012 12:05:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 12:05:05 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:05:09 -0000 On Wed, Aug 1, 2012 at 9:16 AM, Mikael Abrahamsson wrote: > On Wed, 1 Aug 2012, Cameron Byrne wrote: > >> And, that is why 464XLAT is appealing. We took the matter into our own >> hands by leveraging the ability to contribute code into the android base >> (still in code review at Android, but builds for nexus s and galaxy nexus >> freely available as well as source code) so that the feature is avalable >> down stream to all Android OEMs and builds on the what we know commonly >> works (ipv6-only + nat64/dns64). >> >> This has the advantage of that it works today using existing generally >> available components and it does not carry the dual stack bagage (no ipv4 >> left for DS, happy eyeballs issues, ....) >> >> FYI. The T-Mobile USA Samsung SG2, SG3, Note, Nesus S and GNex all support >> ipv6-only with nat64/dns64. So, there is progress to build on. > > > I wholeheartedly applaud your initiative here, and I think for instance > 464XLAT to enable NAT64 to work for apps that have not been designed for > IPv6 only use, is a key feature that is going to be needed in the next few > years in order to get v6 only access off the ground. > Thank you, i deflect all credit to the folks that coded the solution (Dan Drown for Android and the folks at NEC) and the folks the specified the comment parts in RFC 6145 and RFC 6146 > Developers of apps and PC programs generally do not test their software in > an v6 environment (not even dual stack), and users want to use this software > on their devices, so before there is a working solution we cannot deploy as > that would cause customer outrage (my own very limited tests show for > instance that Waze, Spotify and Skype doesn't work). Your list of apps on > android that needs 464XLAT to work is excellent, please keep up the good > work. Does 464XLAT make "portable hotspot" work as well? Currently with v6 > only access it seems at least a Galaxy Nexus with 4.1.1 does "nothing". > Yes, 464XLAT I-D as well as open source Android code supports the dual-stack WLAN extended from an IPv6-only GSM/UMTS/LTE UE and network. Meaning, you can present a DS WLAN to a PC via an IPv6-only network (3GPP for Android , FTTH for NEC ...) Running code matters. To that end, here is a reminder set of links on where this can be found http://dan.drown.org/android/clat/ (source and Nexus S image) http://dl.dropbox.com/u/6628080/update-cm-9-20120514-SNAPSHOT-maguro-signed.zip (Galaxy Nexus image) > I would be very interested in testing 464XLAT on Windows 7 as well if it was > available. > > Like most things, 464XLAT evolves in Open Source and I-D documents. Once there is a viable market for the solution and the solution is proven at scale, others (Microsoft, Apple, ...) may pick it up too. CB > -- > Mikael Abrahamsson email: swmike@swm.pp.se From rajiva@cisco.com Wed Aug 1 13:02:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7EC11E810A for ; Wed, 1 Aug 2012 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NfNKG7qMU0y for ; Wed, 1 Aug 2012 13:02:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 716AE11E8193 for ; Wed, 1 Aug 2012 13:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4345; q=dns/txt; s=iport; t=1343851326; x=1345060926; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4MiCuzzqfc10S7GrwjkflML9UTOh78cJbX3md2QcvUo=; b=Mkq9Ob38gpu3QenpQh3ltx2G/9h7NRi9HucSIIZJALpr1fhUQIFVa4oi /ZKUajfwKSr1HXRek40pO3MvBH3B+3ObTWJbZ1e6ml9yA50AboRjOVU1X yLRkaGv89Blm8Vd71A7y1TvKmYPNC6iHbiKd9N6EoemN6dlm0C7mjMS/E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ+KGVCtJXG8/2dsb2JhbABFuRCBB4IgAQEBAwEBAQEPASc0EAcEAgEIDgMEAQEBChQJBycLFAkIAgQBEggahW+BdgYLnGmgSgSLSYYpYAOjboFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="107588440" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2012 20:02:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71K21Iu018873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 20:02:01 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.184]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 15:02:00 -0500 From: "Rajiv Asati (rajiva)" To: Mikael Abrahamsson , "v6ops@ietf.org" Thread-Topic: [v6ops] Different DNS servers depending on dual stack or single stack usage Thread-Index: AQHNb6bP6U2joAsdLEW3jzG6+LbH85dFWL0A Date: Wed, 1 Aug 2012 20:02:00 +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: [64.102.38.108] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--74.427900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:02:08 -0000 Hi Mikael, > who connects using IPv6, I might cause problems to clients who establish = a > second PDP context, this time IPv4 only (dual bearer). Hmmm....not sure if I follow. Assuming we meant to say 2nd primary PDP cont= ext (and not secondary PDP contexts, since secondary PDP contexts must use= the same IP address as that of the associated primary PDP context), could= n't HSS force SGSN/MME to override the requested PDN type (=3DIPv4, say) wi= th PDN type=3DIPv6 at the time of PDP creation, or simply reject it? In other words, Jouni's suggestion of using AAA to assign different DNS ser= ver addresses to different PDN-types should solve your problem. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: Wednesday, August 01, 2012 1:30 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] Different DNS servers depending on dual stack or sin= gle > stack usage >=20 > On Wed, 1 Aug 2012, jouni korhonen wrote: >=20 > >> Let's say we have a network where clients can connect, some will be > >> dual stack, some will be IPv6 only (3GPP for instance, also wifi). In > >> case the client is IPv6 only (single stack), I would like them to > >> have access to DNS64/NAT64 infrastructure. > > > > For 3GPP networks this can be achieved using AAA to provision DNS > > servers for your APN.. obviously you need some additional logic then > > in your AAA server to hand out different DNS servers depending on the > > PDP-Type that got established. >=20 > I don't believe this solves my problem. If I hand out DNS64 for everybody > who connects using IPv6, I might cause problems to clients who establish = a > second PDP context, this time IPv4 only (dual bearer). >=20 > I read the 464xlat discussion from february, and I can only chime in with > Cameron that getting v4v6 dual stack PDP context actually working in a > 2G/3G/4G environement, is non-trivial. There are a lot of components that > need to support it and it seems whenever I get one of them fixed, there i= s > something else we didn't think of. >=20 > Also handsets seem to be very slow to adopt this (the only time I've been > able to successfully able to enable a dual stack single bearer is on LTE,= which > then fails miserably when handing over to (or trying to establish > in) 2G/3G), but handsets also do not seem to go the way of supporting 2 > single stack bearers either (at least not Android). My Galaxy Nexus with > 4.1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (a= nd I > don't really know if it's the phone or the network (or both) that fails). >=20 > I would at least like to thank Google for IPv6-enabling their phones so w= e > have something to test with (we have USB dongles for computer > connectivity as well, but that doesn't test the App ecosystem). I have be= en > trying to reach someone at Apple to try to understand where they're > headed, but so far no luck on that (which doesn't greatly surprise me > considering their usual secrecy), but if someone from Apple reads this, i= t > would greatly help if you would at least say for instance "it looks like = we're > going to support single v4v6 PDP context, single v4, or single v6 in the = not > too distant future", so we have something to plan for. >=20 > Right now I have a really hard time internally trying to get something do= ne > because I can't say what we should be headed for, what will the handsets > support in 1-2 years time. Installed base is also of great importance, if= tens > of percent doesn't support something (or will support it in the not too > distant future) it's really hard to get anyone to spend time on implement= ing > anything network side. >=20 > So the only thing I can say for sure right now is that v6 only seems to w= ork > on a few android phones, and getting networking code into android would > be easier (at least I imagine so) than to get baseband changes done to > support new PDP context types. But this is just speculation on my part... >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Wed Aug 1 13:05:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC511E8237 for ; Wed, 1 Aug 2012 13:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iacuNHzkX9K5 for ; Wed, 1 Aug 2012 13:05:20 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C880D11E8235 for ; Wed, 1 Aug 2012 13:05:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8335481ghb.31 for ; Wed, 01 Aug 2012 13:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=f8x3W/eTvbF/hNekG0/ZUXfEhpSMWUxbSB7eD864rSQ=; b=lbA/03Y5T42f+JgKCi1m37rLHZFAXvIny0x3fawU2Y0eI4hsnd3kNt8IJSWxBpRd8R SojhesSpEPK9zJLjvleYHdbiEnXJz6DIxRjZ9w2HOcReaImTCB/ghAhexVtYC6XOfPdM Z8m8fXwUsfv8jvw/WH/IbGNu7dRTqMifgM6QS8LcyM1NTNZfo3p7fJaD/xCjz9OhsJ/v zDcrobdKmM7xSQ0S+0qO71JqKaCZ0IganekV5p8+H8OgN/Kc+bcFiJmivQo88F2E179N j3MxxtM7mIIXOqvvTiVwkc7eRRwlLBRlhP429+W3gWP/l/fZMZLJ7c4zBDvpqaUHY++v onPg== Received: by 10.66.76.130 with SMTP id k2mr42318717paw.19.1343851518969; Wed, 01 Aug 2012 13:05:18 -0700 (PDT) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id of4sm3184082pbb.51.2012.08.01.13.05.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 13:05:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 1 Aug 2012 23:05:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <493F80C3-0E1B-4DF0-9D67-C89F20B99D9C@gmail.com> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:05:21 -0000 Mikael, On Aug 1, 2012, at 8:30 AM, Mikael Abrahamsson wrote: > On Wed, 1 Aug 2012, jouni korhonen wrote: >=20 >>> Let's say we have a network where clients can connect, some will be = dual stack, some will be IPv6 only (3GPP for instance, also wifi). In = case the client is IPv6 only (single stack), I would like them to have = access to DNS64/NAT64 infrastructure. >>=20 >> For 3GPP networks this can be achieved using AAA to provision DNS = servers >> for your APN.. obviously you need some additional logic then in your = AAA >> server to hand out different DNS servers depending on the PDP-Type = that got >> established. >=20 > I don't believe this solves my problem. If I hand out DNS64 for = everybody who connects using IPv6, I might cause problems to clients who = establish a second PDP context, this time IPv4 only (dual bearer). So then don't let your subscribers establish a "dualstack" with two = contexts for those APNs you care about this.. with a limitation then that IPv4 would = only be=20 possible with real dualstack context. Without modifying the end host and = the current tools in 3GPP specs there is a limited amount things you can do. For the rest below, yes, painful points many of us is very aware of :( - Jouni > I read the 464xlat discussion from february, and I can only chime in = with Cameron that getting v4v6 dual stack PDP context actually working = in a 2G/3G/4G environement, is non-trivial. There are a lot of = components that need to support it and it seems whenever I get one of = them fixed, there is something else we didn't think of. >=20 > Also handsets seem to be very slow to adopt this (the only time I've = been able to successfully able to enable a dual stack single bearer is = on LTE, which then fails miserably when handing over to (or trying to = establish in) 2G/3G), but handsets also do not seem to go the way of = supporting 2 single stack bearers either (at least not Android). My = Galaxy Nexus with 4.1.1 at least has the v4v6 PDP type I can choose, but = it doesn't work (and I don't really know if it's the phone or the = network (or both) that fails). >=20 > I would at least like to thank Google for IPv6-enabling their phones = so we have something to test with (we have USB dongles for computer = connectivity as well, but that doesn't test the App ecosystem). I have = been trying to reach someone at Apple to try to understand where they're = headed, but so far no luck on that (which doesn't greatly surprise me = considering their usual secrecy), but if someone from Apple reads this, = it would greatly help if you would at least say for instance "it looks = like we're going to support single v4v6 PDP context, single v4, or = single v6 in the not too distant future", so we have something to plan = for. >=20 > Right now I have a really hard time internally trying to get something = done because I can't say what we should be headed for, what will the = handsets support in 1-2 years time. Installed base is also of great = importance, if tens of percent doesn't support something (or will = support it in the not too distant future) it's really hard to get anyone = to spend time on implementing anything network side. >=20 > So the only thing I can say for sure right now is that v6 only seems = to work on a few android phones, and getting networking code into = android would be easier (at least I imagine so) than to get baseband = changes done to support new PDP context types. But this is just = speculation on my part... >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Wed Aug 1 13:34:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C911E8212 for ; Wed, 1 Aug 2012 13:34:15 -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=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D+8Agboox4G for ; Wed, 1 Aug 2012 13:34:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCCC11E820D for ; Wed, 1 Aug 2012 13:34:13 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1657790pbb.31 for ; Wed, 01 Aug 2012 13:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=spMYJhVDuBH8FjoANLlLOj6oEIrVM68O3m+hFi3QMAI=; b=vYW2VtRAelidHI9blEYMZiga4qaw8oYb/6CfZ9/xJVWc0lzRUS5qrOS7Z+D2DxB8e1 XWbz2ZUdikn3tu26GsaEzk1aftc3GW9qhp7Gtycn90BT0jDApCDzFppo6pYpbQM7Ngar x7CdN81wOSu5I7I4opLaoYlaFTcC+NsWs2w8oGfBh6FqB3p58hAjXBpDO52cGejoLiwx 13v0P6nFGl5PAysF4F/6DLbv2fyWLzGVgSBqebDtkRUIQZhE1OKLmkb1lZv3oPzBuD3L frgXob9sUwGtJbuihyepkPb6Hc19pya2cQKoqT/EhGjqeR//0VJk3n4ysuUTKFhmig4p WVyQ== Received: by 10.68.227.201 with SMTP id sc9mr54278839pbc.163.1343853253364; Wed, 01 Aug 2012 13:34:13 -0700 (PDT) Received: from [130.129.19.190] (dhcp-13be.meeting.ietf.org. [130.129.19.190]) by mx.google.com with ESMTPS id nu5sm3223040pbb.53.2012.08.01.13.34.08 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 13:34:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 01 Aug 2012 13:34:04 -0700 From: Victor Kuarsingh To: Philip Matthews , v6ops Message-ID: Thread-Topic: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-00.txt In-Reply-To: <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3426672848_17077012" Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:34:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3426672848_17077012 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Philip, In general, I like the concept of this document and it appears to be quite objective. Not to try and bloat the size/subject areas of the document, but should we add a section which discusses the basics of operating IPv6 in BGP/MPLS IP VPNs? There are some things to be aware of - such as with 6VPE, Multi Protocol BGP etc. One may also still need to consider 6PE. Additionally, I saw some comments noting OSPFv3 and IS-IS. Would a document like this try and provide a contrast between these two protocols or just talk to each of the without specific guidelines as to when each may or may not be useful? (some network operators may want to consider first which to use, then how to use the respective protocol). Again, I am not saying you should put this contrast/compare in, as wondering if you had planned to. My opinion on this is that we may not need to since exposing the reader to both, they can then compare/contrast them on their own. Regards, Victor K Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 29, 2012 9:46:43 EDT > To: philip_matthews@magma.ca > Subject: New Version Notification for > draft-matthews-v6ops-design-guidelines-00.txt > > > A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt > has been successfully submitted by Philip Matthews and posted to the > IETF repository. > > Filename: draft-matthews-v6ops-design-guidelines > Revision: 00 > Title: Design Guidelines for IPv6 Networks > Creation date: 2012-06-29 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines-00. > txt > Status: > http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines > Htmlized: > http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 > > > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. > > > > > The IETF Secretariat > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3426672848_17077012 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Philip,

=
In general, I like the concept of this document and it appears to be qu= ite objective.  

Not to try and bloat the size= /subject areas of the document, but should we add a section which discusses = the basics of operating IPv6 in BGP/MPLS IP VPNs?

T= here are some things to be aware of - such as with 6VPE, Multi Protocol BGP = etc.  One may also still need to consider 6PE.

Additionally, I saw some comments noting OSPFv3 and IS-IS.  Would a do= cument like this try and provide a contrast between these two protocols or j= ust talk to each of the without specific guidelines as to when each may or m= ay not be useful? (some network operators may want to consider first which t= o use, then how to use the respective protocol).  Again, I am not sayin= g you should put this contrast/compare in, as wondering if you had planned t= o.

My opinion on this is that we may not need to si= nce exposing the reader to both, they can then compare/contrast them on thei= r own.

Regards,

Victor K



Begin forwarded message:

Da= te: June= 29, 2012 9:46:43 EDT
= Subject: New Version Notification for draft-matthews-v6ops-design-guideli= nes-00.txt


A new version of I-D, draft-matt= hews-v6ops-design-guidelines-00.txt
has been successfully submitted by Ph= ilip Matthews and posted to the
IETF repository.

Filename: draft-matthews-v6ops-d= esign-guidelines
Revision: 00
Title: De= sign Guidelines for IPv6 Networks
Creation date: 2012-06-29
WG ID: Individual Submission
Number of pages: 10
= URL:             = ;http://www.ietf.org/internet-drafts/draft-matthews-v6ops-de= sign-guidelines-00.txt
Status:       &n= bsp;  http://datatracker.ietf.org/doc/draft-matthews-v6ops-de= sign-guidelines
Htmlized:        <= a href=3D"http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00= ">http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00

Abstract:
  This document presents advice on the des= ign choices that arise when
  designing IPv6 networks (both du= al-stack and IPv6-only).  The
  intended audience is some= one designing an IPv6 network who is
  knowledgeable about bes= t current practices around IPv4 network
  design, and wishes t= o learn the corresponding practices for IPv6.




The IETF Se= cretariat



_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3426672848_17077012-- From joelja@bogus.com Wed Aug 1 16:09:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935E11E8235 for ; Wed, 1 Aug 2012 16:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMxoor5xoOBh for ; Wed, 1 Aug 2012 16:09:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0B611E8225 for ; Wed, 1 Aug 2012 16:09:28 -0700 (PDT) Received: from dhcp-6624.meeting.ietf.org (dhcp-6624.meeting.ietf.org [130.129.102.36]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q71N9Hj7041448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 1 Aug 2012 23:09:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5019B71E.3050200@bogus.com> Date: Wed, 01 Aug 2012 16:09:18 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 01 Aug 2012 23:09:17 +0000 (UTC) Subject: [v6ops] Not enough slides. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:09:29 -0000 I show 6 slide decks in the materials: *V6OPS* Agenda No minutes received Enterprise Incremental IPv6 - K. Chittimaneni A Reference Framework for DC Migra4on to IPv6 - Diego R. Lopez NAT64 Operational Experiences - Cameron Byrne IPv6 over ATM Interworking Function - Jiexin Zhang Semantic IPv6 Prefix - Sheng Jiang 464XLAT - Cameron Byrne The agenda shows 9 discussions. If you don't see your materials already up there, we need your slides. Thanks joel From joelja@bogus.com Wed Aug 1 16:16:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1A11E83A0 for ; Wed, 1 Aug 2012 16:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7MROr953J2D for ; Wed, 1 Aug 2012 16:16:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F2CEC11E8391 for ; Wed, 1 Aug 2012 16:16:38 -0700 (PDT) Received: from dhcp-6624.meeting.ietf.org (dhcp-6624.meeting.ietf.org [130.129.102.36]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q71NGcTX041513 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 1 Aug 2012 23:16:38 GMT (envelope-from joelja@bogus.com) Message-ID: <5019B8D8.6010500@bogus.com> Date: Wed, 01 Aug 2012 16:16:40 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 01 Aug 2012 23:16:38 +0000 (UTC) Subject: [v6ops] 464xlate, to be discussed friday in v6ops... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:16:39 -0000 FYI, http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05 Will be discussed in v6ops on friday. This draft was dicussed prior to IETF84 as possibly being appropriate for sunset4, and was presented there. We belive in consultation with our ADs that v6ops remains the most appropriate location for it given the evolving nature of the sunset4 charter. thanks joel From swmike@swm.pp.se Wed Aug 1 21:01:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD411E8169 for ; Wed, 1 Aug 2012 21:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztx+neYMDGrO for ; Wed, 1 Aug 2012 21:01:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA4311E8136 for ; Wed, 1 Aug 2012 21:01:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8874A9C; Thu, 2 Aug 2012 06:01:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8146D9A; Thu, 2 Aug 2012 06:01:17 +0200 (CEST) Date: Thu, 2 Aug 2012 06:01:17 +0200 (CEST) From: Mikael Abrahamsson To: "Rajiv Asati (rajiva)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:01:31 -0000 On Wed, 1 Aug 2012, Rajiv Asati (rajiva) wrote: > Hmmm....not sure if I follow. Assuming we meant to say 2nd primary PDP > context (and not secondary PDP contexts, since secondary PDP contexts > must use the same IP address as that of the associated primary PDP > context), couldn't HSS force SGSN/MME to override the requested PDN type > (=IPv4, say) with PDN type=IPv6 at the time of PDP creation, or simply > reject it? Yes, but if the goal for the client is to end up being dual stacked, then your suggestion doesn't help anything. And yes, I am talking about 2nd primary PDP context, as in "client will have two primary PDP contexts, one v4 and one v6". The problem this solves is that the network is not ready for v4v6 dual stack PDP context and neither is the UE. Otoh I have not heard from mobile phone vendors that they're interested in supporting two simultaneous PDP contexts, but we have this working with test firmware in LTE USB dongles. > In other words, Jouni's suggestion of using AAA to assign different DNS > server addresses to different PDN-types should solve your problem. I don't see how it does. -- Mikael Abrahamsson email: swmike@swm.pp.se From xuxiaohu@huawei.com Thu Aug 2 10:12:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696E321E8090 for ; Thu, 2 Aug 2012 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.828 X-Spam-Level: X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[AWL=1.771, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pquodWoWf-0 for ; Thu, 2 Aug 2012 10:12:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9F66F21E803F for ; Thu, 2 Aug 2012 10:12:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ19340; Thu, 02 Aug 2012 09:12:27 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 10:11:12 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 10:11:10 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 01:11:05 +0800 From: Xuxiaohu To: "v6ops@ietf.org" Thread-Topic: draft-matthews-v6ops-design-guidelines Thread-Index: Ac1wzY01yvdWzv3KRP2pc9E4J8HzCA== Date: Thu, 2 Aug 2012 17:11:03 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753E19F@szxeml525-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:12:34 -0000 Hi author, It said in your presentation slides that "My sense is that most operators d= o (b). "=20 My question is what's the major reason for most operators to prefer GUA to = LLA when configuring a static route. The major reason I can think of is it'= s easy to type the CLI (i.e., easy to remember for human) by using GUA. =20 If the major reason as the above, it seems that the work we should do is to= offer more tutorials about how to use the LLA more conveniently (e.g., con= figure a local mapping of name to LLA and use the corresponding name instea= d of the LLA itself if appropriate), rather than updating RFC4861 immediate= ly just due to this unimportant reason, IMHO. Best regards, Xiaohu= From alexandru.petrescu@gmail.com Thu Aug 2 10:31:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1D21E80ED for ; Thu, 2 Aug 2012 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc+yy4ScMJi6 for ; Thu, 2 Aug 2012 10:31:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2721E8037 for ; Thu, 2 Aug 2012 10:31:51 -0700 (PDT) Received: by qcac10 with SMTP id c10so6053309qca.31 for ; Thu, 02 Aug 2012 10:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=1ZzOKanYdlpBpzohinFnHj5uvs4W4BQB8MZ7IIG2oMc=; b=QajWyvUXk1dLZN8f4u3cy64f8DuZxzokxIbvFwOpFBcxYPmfSpl4B8YdSfuP9B7iYw Y35uNiA1r4FDgrW2Pwrfut9pvUn7lFzGjCZdpLhwAbJbr2MsO6ojFaiYQTnXKNLN8RIV Oph5+yJVzo92geGfEHEO+DDRSbl7F4GzNZuBJFx/Qa32McjCl/urOjW8WA/6ELU7HGHo czVF09Nz6NBdAk4NuNE1PtIxlQ6DsWAfGmaiDjihK0gFI+nrJhFsPjoslh6Qk8SMidvC cLl+0mt6l2ldOpR7qugG4bwzRxApRhlMCFGBu9l/Tinyo38B8y54Gghp2o3AzvEwh9vU yFEQ== Received: by 10.60.2.193 with SMTP id 1mr39283482oew.29.1343928710627; Thu, 02 Aug 2012 10:31:50 -0700 (PDT) Received: from [130.129.19.61] (dhcp-133d.meeting.ietf.org. [130.129.19.61]) by mx.google.com with ESMTPS id 6sm5032311oef.6.2012.08.02.10.31.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 10:31:50 -0700 (PDT) Message-ID: <501AB97A.7060202@gmail.com> Date: Thu, 02 Aug 2012 10:31:38 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:31:52 -0000 About LLAs pros/cons static routing, On slide 4 of http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf about draft-matthews-v6ops-design-guidelines There was an aspect that I dont think I heard during the discussion. When considering the next hop of a static route to be a LLA or a global/ula, one also wonders whether that address is self-configured (fe80, MAC) or autoconfigured with help from outside like SLAAC/DHCP. And knowing that a router would typically not SLAAC for its address then... A preference would be to avoid autoconfigured addresses and use LLAs as nexthop of static permanent routes. Just some thoughts. Alex From jouni.nospam@gmail.com Thu Aug 2 11:04:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119811E818A for ; Thu, 2 Aug 2012 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlAKlfPUUYMW for ; Thu, 2 Aug 2012 11:04:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 073BA11E80F5 for ; Thu, 2 Aug 2012 11:03:59 -0700 (PDT) Received: by yenq13 with SMTP id q13so9763007yen.31 for ; Thu, 02 Aug 2012 11:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4TS4eFqctkXUsFFm44DMDR9rnJYNlt963JU4mphjFJA=; b=gNmVMEA0bt299VaKG9psc3sfu1BhSsVaTLSYqLdY37km4wRZJ9pZ90uka25O6mWEKy sLhfO3al2abeX9eMcEVc8Ionzx8LTtFxcFxIkonssXeqqQy7CJSKVQFPN06ubZEaxG+1 b6vF7BK4x3L/E+NSvlQSoD0y0h/Go/qKSmi8cFJbe9f+L/TTjBGPTYMwV9lhO01hWrX9 +yeEYh4IjnzelGuFmiw4Yjbw1J2Ftdr5XoaHDh9CSjfo+y7qntK1uxz28Mm2sSmI0Cee hSd8FXfEohU2PO36gBgq7XxHEhkx6qIVHZlHvrTbUw4iQmRYtLeJS4VekuV32cF2GlQC Vxdw== Received: by 10.50.149.199 with SMTP id uc7mr5212119igb.12.1343930639161; Thu, 02 Aug 2012 11:03:59 -0700 (PDT) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id pp4sm14850995igb.5.2012.08.02.11.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 11:03:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 2 Aug 2012 21:03:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson , "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:04:00 -0000 On Aug 2, 2012, at 7:01 AM, Mikael Abrahamsson wrote: > On Wed, 1 Aug 2012, Rajiv Asati (rajiva) wrote: >=20 >> Hmmm....not sure if I follow. Assuming we meant to say 2nd primary = PDP context (and not secondary PDP contexts, since secondary PDP = contexts must use the same IP address as that of the associated primary = PDP context), couldn't HSS force SGSN/MME to override the requested PDN = type (=3DIPv4, say) with PDN type=3DIPv6 at the time of PDP creation, or = simply reject it? >=20 > Yes, but if the goal for the client is to end up being dual stacked, = then your suggestion doesn't help anything. And yes, I am talking about = 2nd primary PDP context, as in "client will have two primary PDP = contexts, one v4 and one v6". The problem this solves is that the = network is not ready for v4v6 dual stack PDP context and neither is the = UE. Otoh I have not heard from mobile phone vendors that they're = interested in supporting two simultaneous PDP contexts, but we have this = working with test firmware in LTE USB dongles. Afair some (Android based) tablets to do that. Also some 3G USB dongles = did two PDPs. >> In other words, Jouni's suggestion of using AAA to assign different = DNS server addresses to different PDN-types should solve your problem. >=20 > I don't see how it does. Mikael is right regarding the case where two PDP context would be used = (or allowed) for the "dualstack". There we have no means to figure out = in advance whether we need to assign a DNS64 to the IPv6 PDP Context or = not, since we do not know whether IPv4 PDP gets ever established. - Jouni > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wwwrun@rfc-editor.org Thu Aug 2 12:01:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9DA11E80EA; Thu, 2 Aug 2012 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pj0GmurJt7j; Thu, 2 Aug 2012 12:01:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 07E7611E81CF; Thu, 2 Aug 2012 12:01:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1249F72E009; Thu, 2 Aug 2012 12:00:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120802190049.1249F72E009@rfc-editor.org> Date: Thu, 2 Aug 2012 12:00:46 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6666 on A Discard Prefix for IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 19:01:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6666 Title: A Discard Prefix for IPv6 Author: N. Hilliard, D. Freedman Status: Informational Stream: IETF Date: August 2012 Mailbox: nick@inex.ie, david.freedman@uk.clara.net Pages: 6 Characters: 10658 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-discard-prefix-05.txt URL: http://www.rfc-editor.org/rfc/rfc6666.txt Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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/rfcsearch.html. 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 philip_matthews@magma.ca Thu Aug 2 13:40:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8111E80ED for ; Thu, 2 Aug 2012 13:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grIX7mRGJhpz for ; Thu, 2 Aug 2012 13:40:56 -0700 (PDT) Received: from mail-02.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1111E80E5 for ; Thu, 2 Aug 2012 13:40:56 -0700 (PDT) Received: from dhcp-1483.meeting.ietf.org ([130.129.20.131]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sx2CV-000643-00; Thu, 02 Aug 2012 16:40:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35-560632683 From: Philip Matthews In-Reply-To: Date: Thu, 2 Aug 2012 13:40:52 -0700 Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1483.meeting.ietf.org [130.129.20.131] Cc: v6ops Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:40:57 -0000 --Apple-Mail-35-560632683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Victor: As we discussed face-to-face ... Yes, I think that 6PE, 6VPE, and iBGP would all fall within what I see = as the scope of the draft. I also think a discussion of what IGP to use = for IPv6 would also fall within the scope of the draft. However, I have = not yet figured out what to say in these areas. I would like to keep the = draft to crisply-worded questions with a solid list of pros and cons, = and I haven't yet quite figured out what these would be for the areas = you mentioned. - Philip On 2012-08-01, at 13:34 , Victor Kuarsingh wrote: > Philip, >=20 > In general, I like the concept of this document and it appears to be = quite objective. =20 >=20 > Not to try and bloat the size/subject areas of the document, but = should we add a section which discusses the basics of operating IPv6 in = BGP/MPLS IP VPNs? >=20 > There are some things to be aware of - such as with 6VPE, Multi = Protocol BGP etc. One may also still need to consider 6PE. >=20 > Additionally, I saw some comments noting OSPFv3 and IS-IS. Would a = document like this try and provide a contrast between these two = protocols or just talk to each of the without specific guidelines as to = when each may or may not be useful? (some network operators may want to = consider first which to use, then how to use the respective protocol). = Again, I am not saying you should put this contrast/compare in, as = wondering if you had planned to. >=20 > My opinion on this is that we may not need to since exposing the = reader to both, they can then compare/contrast them on their own. >=20 > Regards, >=20 > Victor K >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: June 29, 2012 9:46:43 EDT >> To: philip_matthews@magma.ca >> Subject: New Version Notification for = draft-matthews-v6ops-design-guidelines-00.txt >>=20 >>=20 >> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt >> has been successfully submitted by Philip Matthews and posted to the >> IETF repository. >>=20 >> Filename: draft-matthews-v6ops-design-guidelines >> Revision: 00 >> Title: Design Guidelines for IPv6 Networks >> Creation date: 2012-06-29 >> WG ID: Individual Submission >> Number of pages: 10 >> URL: = http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines= -00.txt >> Status: = http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines >> Htmlized: = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 >>=20 >>=20 >> Abstract: >> This document presents advice on the design choices that arise when >> designing IPv6 networks (both dual-stack and IPv6-only). The >> intended audience is someone designing an IPv6 network who is >> knowledgeable about best current practices around IPv4 network >> design, and wishes to learn the corresponding practices for IPv6. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 >=20 > _______________________________________________ v6ops mailing list = v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-35-560632683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Begin = forwarded message:

Date: June 29, 2012 9:46:43 EDT
Subject: New Version Notification for = draft-matthews-v6ops-design-guidelines-00.txt


A new version of I-D, = draft-matthews-v6ops-design-guidelines-00.txt
has been successfully = submitted by Philip Matthews and posted to the
IETF = repository.

Filename: = draft-matthews-v6ops-design-guidelines
Revision: = 00
Title: = = Design Guidelines for IPv6 Networks
Creation date: = 2012-06-29
WG ID: Individual Submission
Number = of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-matthews-v6ops-= design-guidelines-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelin= es
Htmlized:        http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00


Abstract:
  This document presents advice on = the design choices that arise when
  designing IPv6 = networks (both dual-stack and IPv6-only).  The
=   intended audience is someone designing an IPv6 network who = is
  knowledgeable about best current practices around = IPv4 network
  design, and wishes to learn the = corresponding practices for IPv6.




The IETF = Secretariat


_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops _______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-35-560632683-- From philip_matthews@magma.ca Thu Aug 2 13:51:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E582B11E80FD for ; Thu, 2 Aug 2012 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVi1HWhMvW-d for ; Thu, 2 Aug 2012 13:51:18 -0700 (PDT) Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 464C511E80E5 for ; Thu, 2 Aug 2012 13:51:18 -0700 (PDT) Received: from dhcp-1483.meeting.ietf.org ([130.129.20.131]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sx2MX-000116-26; Thu, 02 Aug 2012 16:51:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753E19F@szxeml525-mbx.china.huawei.com> Date: Thu, 2 Aug 2012 13:51:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753E19F@szxeml525-mbx.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1483.meeting.ietf.org [130.129.20.131] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:51:19 -0000 If you were present in the V6OPS meeting today, then you heard the = discussion of this question.=20 Other points mentioned, in addition to what the current draft says, = include: - Next-hop doesn't change if line-card changes - Issue with redistributing a static route with a LLA next-hop into = another protocol I plan to carefully listen to the audio recording, then capture the = points made in the document. - Philip On 2012-08-02, at 10:11 , Xuxiaohu wrote: > Hi author, >=20 > It said in your presentation slides that "My sense is that most = operators do (b). "=20 >=20 > My question is what's the major reason for most operators to prefer = GUA to LLA when configuring a static route. The major reason I can think = of is it's easy to type the CLI (i.e., easy to remember for human) by = using GUA. =20 >=20 > If the major reason as the above, it seems that the work we should do = is to offer more tutorials about how to use the LLA more conveniently = (e.g., configure a local mapping of name to LLA and use the = corresponding name instead of the LLA itself if appropriate), rather = than updating RFC4861 immediately just due to this unimportant reason, = IMHO. >=20 >=20 > Best regards, > Xiaohu > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From philip_matthews@magma.ca Thu Aug 2 13:58:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206BE11E815A for ; Thu, 2 Aug 2012 13:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvxHn5uvFW8I for ; Thu, 2 Aug 2012 13:58:18 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97C11E8140 for ; Thu, 2 Aug 2012 13:58:18 -0700 (PDT) Received: from dhcp-1483.meeting.ietf.org ([130.129.20.131]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sx2TJ-0005lA-36; Thu, 02 Aug 2012 16:58:18 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <501AB97A.7060202@gmail.com> Date: Thu, 2 Aug 2012 13:58:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> References: <501AB97A.7060202@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1483.meeting.ietf.org [130.129.20.131] Cc: v6ops@ietf.org Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:58:19 -0000 I agree on your point about manually-configured vs auto-configured = addresses for interface addresses on routers. I will add a discussion of = this to the document. However, I don't see how this plays into the choice of LLA vs GUA/ULA = for the next-hop of a static route. - Philip On 2012-08-02, at 10:31 , Alexandru Petrescu wrote: > About LLAs pros/cons static routing, >=20 > On slide 4 of > http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf > about draft-matthews-v6ops-design-guidelines >=20 > There was an aspect that I dont think I heard during the discussion. >=20 > When considering the next hop of a static route to be a LLA or a > global/ula, one also wonders whether that address is self-configured > (fe80, MAC) or autoconfigured with help from outside like SLAAC/DHCP. > And knowing that a router would typically not SLAAC for its address = then... >=20 > A preference would be to avoid autoconfigured addresses and use LLAs = as > nexthop of static permanent routes. >=20 > Just some thoughts. >=20 > Alex > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From alexandru.petrescu@gmail.com Thu Aug 2 14:05:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062F21E80A5 for ; Thu, 2 Aug 2012 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMSIP4w7JEtR for ; Thu, 2 Aug 2012 14:05:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9721E80A1 for ; Thu, 2 Aug 2012 14:05:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so16316450obb.31 for ; Thu, 02 Aug 2012 14:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zHEXqA9gaCz+7pL4Ky19hIK9/U8aq+toiCV4btEAKBw=; b=ASIQ0G2uRnmA5sudNHjOEkq0o52cpTXU5ijdy0WgsI2la5Kbj7/8irkRNfty2hHnlH 0JO0i8+NCVSh73YrenE8wpe3ZePLJd0Gkbh4SPQSYwckytPt5MG1zOLIikDbl4fb2OmV T03SGb1Jd3TPrSvnXy6uHHryaRB3y1ZomAC09viSKKbe9wvikSLJhTxCb2MyKU9bPIK3 vyBmBWZePkOVtT0aCFFLm+0PvWQ3VjGqRbFW/IEMxWya4Yz5Gh/5XbuZsqQJLD4Y+V7A wjFceHC561+MORfJjzFnbrZCJ9oQyvE1GXm+AI16fIL25skb9GlYzE9zT/y1tCPf89ew rSgA== Received: by 10.182.46.41 with SMTP id s9mr40203785obm.57.1343941523423; Thu, 02 Aug 2012 14:05:23 -0700 (PDT) Received: from [130.129.19.61] (dhcp-133d.meeting.ietf.org. [130.129.19.61]) by mx.google.com with ESMTPS id l9sm5577600oeg.3.2012.08.02.14.05.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:05:22 -0700 (PDT) Message-ID: <501AEB86.5080808@gmail.com> Date: Thu, 02 Aug 2012 14:05:10 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Philip Matthews References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> In-Reply-To: <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:05:41 -0000 Sorry, one preference goes like this: _always_ use ll addresses as next hop of each static route. Whereas this has the risk of needing to change when an interface is replaced it may have more chances to stay stable than when the prefix of that link changes (router renumbering) or when the sysadmin configures another global or ULA on that interface, or when the DHCP server gives it another address. Some people may prefer to maintain a dhcpd.conf in a single server which may happen to be the place from where the routes are distributed as well (the ospf conf files). I think overall the preference of using or not using LL address as next hop of static routes depends a lot on how the addresses are (auto)configured on these interfaces. Alex Le 02/08/2012 13:58, Philip Matthews a écrit : > I agree on your point about manually-configured vs auto-configured > addresses for interface addresses on routers. I will add a > discussion of this to the document. > > However, I don't see how this plays into the choice of LLA vs > GUA/ULA for the next-hop of a static route. > > - Philip > > On 2012-08-02, at 10:31 , Alexandru Petrescu wrote: > >> About LLAs pros/cons static routing, >> >> On slide 4 of >> http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf about >> draft-matthews-v6ops-design-guidelines >> >> There was an aspect that I dont think I heard during the >> discussion. >> >> When considering the next hop of a static route to be a LLA or a >> global/ula, one also wonders whether that address is >> self-configured (fe80, MAC) or autoconfigured with help from >> outside like SLAAC/DHCP. And knowing that a router would typically >> not SLAAC for its address then... >> >> A preference would be to avoid autoconfigured addresses and use >> LLAs as nexthop of static permanent routes. >> >> Just some thoughts. >> >> Alex _______________________________________________ v6ops mailing >> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > From victor.kuarsingh@gmail.com Thu Aug 2 14:05:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB87721E80B5 for ; Thu, 2 Aug 2012 14:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDs5EWEGkcIu for ; Thu, 2 Aug 2012 14:05:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C25FC21E80B4 for ; Thu, 2 Aug 2012 14:05:46 -0700 (PDT) Received: by yhq56 with SMTP id 56so9976148yhq.31 for ; Thu, 02 Aug 2012 14:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=l7Av9e5WUE/XHFUjHXJ4I/F65qaAi41CVRczunAwgNY=; b=LANzswYeAosdisBMvReoaDzPa9XEkgXIAO/gGoVcGasbf5ZaUCSRPaPxkRsCSWSIwl /DOCjFqekEz/sUuyV/dqf+ZbFEEt09zGSUrpoKZg0NDkrU6/FaYuKLMrEb11yvR9anz1 yZha9b5u/MlOJLwppobsHlsQZ7ck19qaTcqZv+M9Vau4bpbfjmuTtGF0j9nJDoqKq/k9 eE+zI79wNBZcoW+0sFCaGvXIioI06Ieeg/qv35fcS8LTDbUsHPClzd5OUGxzjjlgqgXW OR9M2JBBlYbZI63qZ7594WB10W2F2vAdu0G6+LEby3x/nEcLdGraaL43mGQ1Bda7GaoN dKqg== Received: by 10.60.22.5 with SMTP id z5mr40003191oee.2.1343941546255; Thu, 02 Aug 2012 14:05:46 -0700 (PDT) Received: from [130.129.19.190] (dhcp-13be.meeting.ietf.org. [130.129.19.190]) by mx.google.com with ESMTPS id m7sm5579159oef.1.2012.08.02.14.05.40 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:05:44 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 02 Aug 2012 14:05:36 -0700 From: Victor Kuarsingh To: Philip Matthews , Xuxiaohu Message-ID: Thread-Topic: [v6ops] draft-matthews-v6ops-design-guidelines In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:05:48 -0000 Philip, Additional items to consider. - if a router is on a public peering exchange, its common to use an IP from the exchange prefix (which will be GUA) - will using the LLA work if I am using an eBGP session over multiple links by managing session on the Loopback? (it's common to use router loopback on these cases which does not rely on IP of interface). - How do people (that use LLA for peering) plan to deal with DNS records? Would they generate records which resolve to LLAs? (operators may want to have DNS names for IPs which the use for key functions) As noted in our post WG meeting conversation, using LLAs seem to be workable in some cases, but not all cases. (perhaps someone can prove me wrong). Regards, Victor K On 12-08-02 1:51 PM, "Philip Matthews" wrote: >If you were present in the V6OPS meeting today, then you heard the >discussion of this question. >Other points mentioned, in addition to what the current draft says, >include: >- Next-hop doesn't change if line-card changes >- Issue with redistributing a static route with a LLA next-hop into >another protocol >I plan to carefully listen to the audio recording, then capture the >points made in the document. >- Philip > >On 2012-08-02, at 10:11 , Xuxiaohu wrote: > >> Hi author, >> >> It said in your presentation slides that "My sense is that most >>operators do (b). " >> >> My question is what's the major reason for most operators to prefer GUA >>to LLA when configuring a static route. The major reason I can think of >>is it's easy to type the CLI (i.e., easy to remember for human) by using >>GUA. >> >> If the major reason as the above, it seems that the work we should do >>is to offer more tutorials about how to use the LLA more conveniently >>(e.g., configure a local mapping of name to LLA and use the >>corresponding name instead of the LLA itself if appropriate), rather >>than updating RFC4861 immediately just due to this unimportant reason, >>IMHO. >> >> >> Best regards, >> Xiaohu >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From xuxiaohu@huawei.com Thu Aug 2 15:04:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1521E80C2 for ; Thu, 2 Aug 2012 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZnAET6JJm2H for ; Thu, 2 Aug 2012 15:04:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70E11E8102 for ; Thu, 2 Aug 2012 15:04:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ35810; Thu, 02 Aug 2012 14:04:02 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 15:01:50 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 15:01:56 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 06:01:53 +0800 From: Xuxiaohu To: Philip Matthews Thread-Topic: [v6ops] draft-matthews-v6ops-design-guidelines Thread-Index: Ac1wzY01yvdWzv3KRP2pc9E4J8HzCP//v+cAgACXv8E= Date: Thu, 2 Aug 2012 22:01:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753E2D0@szxeml525-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753E19F@szxeml525-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.70] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:04:03 -0000 WWVzLCBJIGhhZCBldmVyIGVuY291bnRlcmVkIHRoZSBmaXJzdCBpc3N1ZSAoaS5lLiwgTmV4dC1o b3AgaGFzIHRvIGJlIGNoYW5nZWQgd2hlbiB0aGUgbGluZS1jYXJkIGNoYW5nZXMpLiBBcyBmb3Ig dGhlIHNlY29uZCBpc3N1ZSwgd2hlbiB0aGUgcmVkaXN0cmlidXRlZCByb3V0ZSBpcyBhZHZlcnRp c2VkIHRvIGEgcmVtb3RlIHBlZXIgd2hpY2ggaXMgbm90IHdpdGhpbiB0aGUgc2FtZSBMQU4gYXMg dGhlIG5leHQtaG9wIHJvdXRlciwgdGhlIG5leHQtaG9wIHNob3VsZCBiZSBjaGFuZ2VkIGFjY29y ZGluZ2x5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBQaGlsaXAgTWF0dGhld3MgW3BoaWxpcF9tYXR0 aGV3c0BtYWdtYS5jYV0NCreiy83KsbzkOiAyMDEyxOo41MIzyNUgNDo1MQ0Ktb06IFh1eGlhb2h1 DQpDYzogdjZvcHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbdjZvcHNdIGRyYWZ0LW1hdHRoZXdzLXY2 b3BzLWRlc2lnbi1ndWlkZWxpbmVzDQoNCklmIHlvdSB3ZXJlIHByZXNlbnQgaW4gdGhlIFY2T1BT IG1lZXRpbmcgdG9kYXksIHRoZW4geW91IGhlYXJkIHRoZSBkaXNjdXNzaW9uIG9mIHRoaXMgcXVl c3Rpb24uDQpPdGhlciBwb2ludHMgbWVudGlvbmVkLCBpbiBhZGRpdGlvbiB0byB3aGF0IHRoZSBj dXJyZW50IGRyYWZ0IHNheXMsIGluY2x1ZGU6DQotIE5leHQtaG9wIGRvZXNuJ3QgY2hhbmdlIGlm IGxpbmUtY2FyZCBjaGFuZ2VzDQotIElzc3VlIHdpdGggcmVkaXN0cmlidXRpbmcgYSBzdGF0aWMg cm91dGUgd2l0aCBhIExMQSBuZXh0LWhvcCBpbnRvIGFub3RoZXIgcHJvdG9jb2wNCkkgcGxhbiB0 byBjYXJlZnVsbHkgbGlzdGVuIHRvIHRoZSBhdWRpbyByZWNvcmRpbmcsIHRoZW4gY2FwdHVyZSB0 aGUgcG9pbnRzIG1hZGUgaW4gdGhlIGRvY3VtZW50Lg0KLSBQaGlsaXANCg0KT24gMjAxMi0wOC0w MiwgYXQgMTA6MTEgLCBYdXhpYW9odSB3cm90ZToNCg0KPiBIaSBhdXRob3IsDQo+DQo+IEl0IHNh aWQgaW4geW91ciBwcmVzZW50YXRpb24gc2xpZGVzIHRoYXQgIk15IHNlbnNlIGlzIHRoYXQgbW9z dCBvcGVyYXRvcnMgZG8gKGIpLiAiDQo+DQo+IE15IHF1ZXN0aW9uIGlzIHdoYXQncyB0aGUgbWFq b3IgcmVhc29uIGZvciBtb3N0IG9wZXJhdG9ycyB0byBwcmVmZXIgR1VBIHRvIExMQSB3aGVuIGNv bmZpZ3VyaW5nIGEgc3RhdGljIHJvdXRlLiBUaGUgbWFqb3IgcmVhc29uIEkgY2FuIHRoaW5rIG9m IGlzIGl0J3MgZWFzeSB0byB0eXBlIHRoZSBDTEkgKGkuZS4sIGVhc3kgdG8gcmVtZW1iZXIgZm9y IGh1bWFuKSBieSB1c2luZyBHVUEuDQo+DQo+IElmIHRoZSBtYWpvciByZWFzb24gYXMgdGhlIGFi b3ZlLCBpdCBzZWVtcyB0aGF0IHRoZSB3b3JrIHdlIHNob3VsZCBkbyBpcyB0byBvZmZlciBtb3Jl IHR1dG9yaWFscyBhYm91dCBob3cgdG8gdXNlIHRoZSBMTEEgbW9yZSBjb252ZW5pZW50bHkgKGUu Zy4sIGNvbmZpZ3VyZSBhIGxvY2FsIG1hcHBpbmcgb2YgbmFtZSB0byBMTEEgYW5kIHVzZSB0aGUg Y29ycmVzcG9uZGluZyBuYW1lIGluc3RlYWQgb2YgdGhlIExMQSBpdHNlbGYgaWYgYXBwcm9wcmlh dGUpLCByYXRoZXIgdGhhbiB1cGRhdGluZyBSRkM0ODYxIGltbWVkaWF0ZWx5IGp1c3QgZHVlIHRv IHRoaXMgdW5pbXBvcnRhbnQgcmVhc29uLCBJTUhPLg0KPg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFhpYW9odQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPg== From dr@cluenet.de Thu Aug 2 17:37:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C111E8111 for ; Thu, 2 Aug 2012 17:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaB0gfkmH5TJ for ; Thu, 2 Aug 2012 17:37:43 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2930111E80D1 for ; Thu, 2 Aug 2012 17:37:42 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id D47131086D2; Fri, 3 Aug 2012 02:37:40 +0200 (CEST) Date: Fri, 3 Aug 2012 02:37:40 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120803003740.GB18460@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:37:43 -0000 On Thu, Aug 02, 2012 at 09:03:46PM +0300, jouni korhonen wrote: > Mikael is right regarding the case where two PDP context would be used > (or allowed) for the "dualstack". There we have no means to figure out > in advance whether we need to assign a DNS64 to the IPv6 PDP Context > or not, since we do not know whether IPv4 PDP gets ever established. The same issue is present with any host in a dualstacked LAN as well. You'll never know wether that device is IPv6-only or dualstack capable. We need something "inband" in DNS to signal wether DNS64 is required (alias "IPv6 only") or not. Because only the endpoint knows. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From swmike@swm.pp.se Thu Aug 2 22:56:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D995221F8CA8 for ; Thu, 2 Aug 2012 22:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AXFxxBFwqD4 for ; Thu, 2 Aug 2012 22:56:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5222F21F8C9D for ; Thu, 2 Aug 2012 22:56:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6E3AE9C; Fri, 3 Aug 2012 07:56:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 69D639A; Fri, 3 Aug 2012 07:56:15 +0200 (CEST) Date: Fri, 3 Aug 2012 07:56:15 +0200 (CEST) From: Mikael Abrahamsson To: joel jaeggli In-Reply-To: <5019B8D8.6010500@bogus.com> Message-ID: References: <5019B8D8.6010500@bogus.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] 464xlate, to be discussed friday in v6ops... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:56:17 -0000 On Wed, 1 Aug 2012, joel jaeggli wrote: > Will be discussed in v6ops on friday. This draft was dicussed prior to > IETF84 as possibly being appropriate for sunset4, and was presented > there. We belive in consultation with our ADs that v6ops remains the > most appropriate location for it given the evolving nature of the > sunset4 charter. I believe 464XLATE is an important piece in the puzzle to get ipv6 adopted, not only for sunsetting IPv4 so I agree with the above text. I'm in the process of testing the 464XLATE enabled image for Galaxy Nexus that Cameron Byrne posted about because NAT64/DNS64 alone will not work give a good user experience on v6 only access (too many apps won't work), and 464XLATE seems to be one way to greatly improve the customer experience. -- Mikael Abrahamsson email: swmike@swm.pp.se From gert@space.net Fri Aug 3 06:52:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81C21F8CCF for ; Fri, 3 Aug 2012 06:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I+hh2iF9FRb for ; Fri, 3 Aug 2012 06:52:45 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id BC28B21F87B3 for ; Fri, 3 Aug 2012 06:52:44 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7827BF8D2A for ; Fri, 3 Aug 2012 15:52:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5A9E4F8D19 for ; Fri, 3 Aug 2012 15:52:43 +0200 (CEST) Received: (qmail 52302 invoked by uid 1007); 3 Aug 2012 15:52:43 +0200 Date: Fri, 3 Aug 2012 15:52:43 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20120803135243.GU38127@Space.Net> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501AEB86.5080808@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:52:46 -0000 Hi, On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu wrote: > Sorry, one preference goes like this: _always_ use ll addresses as next > hop of each static route. Well, that is *one* preference. Our preference is "always use GUA addresses as next-hop". People differ, and so do preferences. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From cb.list6@gmail.com Fri Aug 3 07:05:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F221F8D52 for ; Fri, 3 Aug 2012 07:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8weqci6lmFlU for ; Fri, 3 Aug 2012 07:05:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9221F8463 for ; Fri, 3 Aug 2012 07:05:02 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1741216lbb.31 for ; Fri, 03 Aug 2012 07:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l1jwwKr3gwk1BE+dRTo9XeirOmO6Gd0jJyot7HQwnnw=; b=bcN3I/L9j7iT+v5HWe17jxdffbic+MMWHop/icVIsYRwB78WtDcLIPWAraPk36L5uC EfUBvtu0wxMripRtaLZ3uIct7QnD6T9C534YRtZjqxAEdmH8Nr48pKbzDNMj+hwuqpm5 lzM8UuDKplEBbnk+8DcESdCxP1c/hZDvAVnDiqjc+ax4OemXWrJKNPEY5chM4fBLSiz+ eXnn3agjG1+gMRgq4Ak18GKclHjtKqc3R/FVVIfcTqCQLfPDrZchGWBfhtg5fIc3kb9l rJn7KzBaZ05vL1LyUwueKHUtGT6aiTK2tkNp3LItnhvJKlKwI0xdJLUlY28qTIlSAkqO I4fg== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr1662333lab.51.1344002701671; Fri, 03 Aug 2012 07:05:01 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Fri, 3 Aug 2012 07:05:01 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Fri, 3 Aug 2012 07:05:01 -0700 (PDT) In-Reply-To: <20120803135243.GU38127@Space.Net> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> Date: Fri, 3 Aug 2012 07:05:01 -0700 Message-ID: From: Cameron Byrne To: Gert Doering Content-Type: multipart/alternative; boundary=e89a8f22bfb19c3cc204c65d039a Cc: v6ops@ietf.org, Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:05:04 -0000 --e89a8f22bfb19c3cc204c65d039a Content-Type: text/plain; charset=ISO-8859-1 On Aug 3, 2012 6:52 AM, "Gert Doering" wrote: > > Hi, > > On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu wrote: > > Sorry, one preference goes like this: _always_ use ll addresses as next > > hop of each static route. > > Well, that is *one* preference. > > Our preference is "always use GUA addresses as next-hop". > > People differ, and so do preferences. > +1 We use ULA or GUA as next hop and never LLA CB > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --e89a8f22bfb19c3cc204c65d039a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 3, 2012 6:52 AM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu wrote: > > Sorry, one preference goes like this: _always_ use ll addresses a= s next
> > hop of each static route.
>
> Well, that is *one* preference.
>
> Our preference is "always use GUA addresses as next-hop". >
> People differ, and so do preferences.
>
+1

We use ULA or GUA as=A0 next hop and never LLA

CB

> Gert Doering
> =A0 =A0 =A0 =A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: S= ebastian v. Bomhard
> Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Gr= undner-Culemann
> D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG M= uenchen)
> Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279<= br> > _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--e89a8f22bfb19c3cc204c65d039a-- From marka@isc.org Fri Aug 3 09:41:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7821F8E35 for ; Fri, 3 Aug 2012 09:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFOHj1EqdVzw for ; Fri, 3 Aug 2012 09:41:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAC521F8E31 for ; Fri, 3 Aug 2012 09:41:20 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 79C655F997B for ; Fri, 3 Aug 2012 16:41:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:bdb7:33d6:f762:3d2f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 98D32216C36 for ; Fri, 3 Aug 2012 16:41:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C618323445AD for ; Sat, 4 Aug 2012 02:40:58 +1000 (EST) To: v6ops@ietf.org From: Mark Andrews References: <20120803003740.GB18460@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org In-reply-to: Your message of "Fri, 03 Aug 2012 02:37:40 +0200." <20120803003740.GB18460@srv03.cluenet.de> Date: Sat, 04 Aug 2012 02:40:58 +1000 Message-Id: <20120803164058.C618323445AD@drugs.dv.isc.org> Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:41:21 -0000 In message <20120803003740.GB18460@srv03.cluenet.de>, Daniel Roesen writes: > On Thu, Aug 02, 2012 at 09:03:46PM +0300, jouni korhonen wrote: > > Mikael is right regarding the case where two PDP context would be used > > (or allowed) for the "dualstack". There we have no means to figure out > > in advance whether we need to assign a DNS64 to the IPv6 PDP Context > > or not, since we do not know whether IPv4 PDP gets ever established. > > The same issue is present with any host in a dualstacked LAN as well. > You'll never know wether that device is IPv6-only or dualstack capable. > > We need something "inband" in DNS to signal wether DNS64 is required > (alias "IPv6 only") or not. Because only the endpoint knows. > > Best regards, > Daniel And recursive servers need to get *both* styles of answers at once. EDNS provides a way for a client to signal that it is DNS64 aware and if it is DNS64 aware the server can return *both* the regular answer and the addresses it would have sent if it was synthesised. EDNS could also be used by the client to lookup the mapping of IPv4 literal over DNS with QCOUNT=0. Request: []* Response: []+ Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pkern@spike.0x539.de Sat Aug 4 10:57:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EA921F863F for ; Sat, 4 Aug 2012 10:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGY5+JiUw8Uk for ; Sat, 4 Aug 2012 10:57:22 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF021F8609 for ; Sat, 4 Aug 2012 10:57:22 -0700 (PDT) Received: from spike.mobile.philkern.de ([2001:6f8:12a7:0:224:d7ff:fe9d:1198] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Sxiaz-0003k5-SD for v6ops@ietf.org; Sat, 04 Aug 2012 19:57:01 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1SxibH-0000kw-5S for v6ops@ietf.org; Sat, 04 Aug 2012 19:57:19 +0200 Date: Sat, 4 Aug 2012 19:57:19 +0200 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20120804175719.GA2757@spike.0x539.de> References: <20120803003740.GB18460@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20120803003740.GB18460@srv03.cluenet.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 17:57:23 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 03, 2012 at 02:37:40AM +0200, Daniel Roesen wrote: > We need something "inband" in DNS to signal wether DNS64 is required > (alias "IPv6 only") or not. Because only the endpoint knows. Or we need something that signals a NAT64 range through e.g. DHCPv6 and enables the client to map IPv4 transparently into it if Dual Stack is not available. Kind regards Philipp Kern --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlAdYn8ACgkQ7Ro5M7LPzdj0tQCgyu0+MVA6z2BKqUlkgBleVqft 8GUAoM/CX99zx19vOU1+uDdW7t8hYokriQEcBAEBCAAGBQJQHWJ/AAoJEERuJUU1 0FbsT1cIALX488lh2xAl+M8y4DxYt1cN6lqtKsa75pz8o5BtP1NfGHQel8iA2Pw0 u6R/zldxinFq6ReNmIh/BAyaQcOBwcP5MrpuyC7DGk5eDCgLxrkCg5G+82kz6c+g cttt4sB9igFX6qhrHaCgbjES4kFKXGMFpgmWrvfm3xyivMM4SqVEGoJO0DJy3zr8 76iw1zIiLNP0nee+JGQk0kQ39di//kxN+rWOEINziGuvsNkBZsOLUhf3zb3tZojL 1rqA/gIuNMxs3h4LbqEVlSCNiLBU67U1uYjmfSFvxAy2Wp7bIdmcF3+4ZHyOJdkJ IE5XVusN3ClrHFChSLO0o6McNsCvVb0= =vaHo -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From cb.list6@gmail.com Sat Aug 4 11:29:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33BD21F87D5 for ; Sat, 4 Aug 2012 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH-DluZUTawf for ; Sat, 4 Aug 2012 11:29:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B587921F87D4 for ; Sat, 4 Aug 2012 11:29:10 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2276050lbb.31 for ; Sat, 04 Aug 2012 11:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4bux8LDhWmyM+txn+/nkTKirOmO60ELhZLf4HDTHhIQ=; b=I8J2y2/PTW+Vx2MNGnzeNW7wdCG1LrTKy0HuaEKExWiNW/Cnf/hGxLPNixqCXAE8iV BU6aJfhjHcgNjwUVwvhsD2xPgez5e7krTD+0suuTxZf3tA8a2irxUM7/3JJNkuEmN4yV VuoNlJmW5ZzjRGjPGi4FyRdsvcKfxxRP6SwH4gzxUoMPlAaF/29ivB5u66mwLNGk+h6+ 3/iCxbrbf1IbaRd0ee/kSpyCYcqxLeiW+a/YvXHG052LLoh2z8RSNZ0sNMkR5eR3NLLa uMdB9bVD7wncsAcieJ02MCLmW7ON+4ywhkQp3r5H943Z7tZvzS5KLctvYJYbILumeQFF P/9Q== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr5421038lab.48.1344104949488; Sat, 04 Aug 2012 11:29:09 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sat, 4 Aug 2012 11:29:09 -0700 (PDT) In-Reply-To: <20120804175719.GA2757@spike.0x539.de> References: <20120803003740.GB18460@srv03.cluenet.de> <20120804175719.GA2757@spike.0x539.de> Date: Sat, 4 Aug 2012 11:29:09 -0700 Message-ID: From: Cameron Byrne To: Philipp Kern Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 18:29:12 -0000 On Sat, Aug 4, 2012 at 10:57 AM, Philipp Kern wrote: > On Fri, Aug 03, 2012 at 02:37:40AM +0200, Daniel Roesen wrote: >> We need something "inband" in DNS to signal wether DNS64 is required >> (alias "IPv6 only") or not. Because only the endpoint knows. > > Or we need something that signals a NAT64 range through e.g. DHCPv6 and > enables the client to map IPv4 transparently into it if Dual Stack is not > available. > You may find this interesting for a host to discover that a DNS64 is available http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-11 From marka@isc.org Sun Aug 5 10:57:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8021F854D for ; Sun, 5 Aug 2012 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYvLi+9gmepk for ; Sun, 5 Aug 2012 10:57:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3223B21F854A for ; Sun, 5 Aug 2012 10:57:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3F866C951C; Sun, 5 Aug 2012 17:57:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:8717:1:d020:a051:bc82:f1cc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2D1CD216C33; Sun, 5 Aug 2012 17:57:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4B027234E39B; Mon, 6 Aug 2012 03:56:56 +1000 (EST) To: Cameron Byrne From: Mark Andrews References: <20120803003740.GB18460@srv03.cluenet.de> <20120804175719.GA2757@spike.0x539.de> In-reply-to: Your message of "Sat, 04 Aug 2012 11:29:09 MST." Date: Mon, 06 Aug 2012 03:56:56 +1000 Message-Id: <20120805175656.4B027234E39B@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 17:57:16 -0000 In message , Cameron Byrne writes: > On Sat, Aug 4, 2012 at 10:57 AM, Philipp Kern wrote: > > On Fri, Aug 03, 2012 at 02:37:40AM +0200, Daniel Roesen wrote: > >> We need something "inband" in DNS to signal wether DNS64 is required > >> (alias "IPv6 only") or not. Because only the endpoint knows. > > > > Or we need something that signals a NAT64 range through e.g. DHCPv6 and > > enables the client to map IPv4 transparently into it if Dual Stack is not > > available. > > > > You may find this interesting for a host to discover that a DNS64 is > available http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuri > stic-11 Which doesn't handle all the nuances of DNS64. Requires every app that handles IPv4 literals (i.e. just about all network apps) to be updated. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fred@cisco.com Sun Aug 5 22:30:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79021F8474 for ; Sun, 5 Aug 2012 22:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V13vMYatKZMi for ; Sun, 5 Aug 2012 22:30:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 470F521F841E for ; Sun, 5 Aug 2012 22:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=424; q=dns/txt; s=iport; t=1344231030; x=1345440630; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wNCDp8OqTXNy7Xw1ZKfleW9dKmEUgPO42Ykq7k31M7o=; b=OpP+QsavueFWhRV6IQvFvTvbfefMEFdzILNapjGjhxfWX/vW+uH1qQmb m+/BuZrcbQmgBKdg9wjEbcZcA+788sKFp1T1qOtuH94cDJTZcGYRdL35P SEIYFffqNONS8rtp813knDAyv2ivFVkaWi+bQZjdBqt++Z9m/hslatGXv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFADpWH1CtJV2a/2dsb2JhbABFhTS0B4EHgicSASc/EgE+QicEDieHawubPZ8hkW5gA5VJgRSNEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,717,1336348800"; d="scan'208";a="108660588" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 06 Aug 2012 05:30:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q765Twer014292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 05:29:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 00:29:57 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNc5SEZaOo7GeIYE+zCAtJF8/cLA== Date: Mon, 6 Aug 2012 05:29:57 +0000 Message-ID: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.004 x-tm-as-result: No--24.387200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9C572D228B3F3B41AD1A511D1A5329E5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: V6ops Chairs , Ron Bonica Subject: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 05:30:32 -0000 This is to open a two week Working Group last Call on=20 http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6 Guidance for Internet Content and Application Service Providers", Brian Carpenter, Sheng Jiang, 10-Jul-12 Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulness t= o its target audience.= From gvandeve@cisco.com Mon Aug 6 01:42:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B048D21F8523; Mon, 6 Aug 2012 01:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sqCtkXSmUOr; Mon, 6 Aug 2012 01:42:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 01ACA21F8609; Mon, 6 Aug 2012 01:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6814; q=dns/txt; s=iport; t=1344242575; x=1345452175; h=from:to:subject:date:message-id:mime-version; bh=eO37779sF36BTfCRA2QiLQLFQFifebyNn/OOgYCtYnk=; b=D2+E6ulHtInjY+/Zo5im6LuKmWmvP8MQjRyLvCXyllYWjXMhUAHYP5ZN uCyfh4sHxY234oCmr9kEDrffNgy61/f8eB5LEe2zmEdMhji52uHaSFZ1c yF3lFO15gvp4i9AV+VLKoWV6XQnhU3ditIu8usUXiOrh3Su7IEVPrM/PG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAeDH1CtJV2Y/2dsb2JhbAA7CoJKtnSBB4IiAQQSARpeASpWJgEEARoMDodrm0SfU4tahhRgA6NvgWaCXw X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208,217";a="105728263" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 06 Aug 2012 08:42:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q768gs0R019543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 08:42:54 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 03:42:54 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" , "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71Apg== Date: Mon, 6 Aug 2012 08:42:53 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--36.409000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240674C2xmbalnx12ciscocom_" MIME-Version: 1.0 Subject: [v6ops] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 08:42:55 -0000 --_000_67832B1175062E48926BF3CB27C49B240674C2xmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Can I request the WG members for 3 volunteers to read the draft draft-gont-= opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list? This will help the OPSEC chairs to identify if the work is ready for WG ado= ption or not. The work targets are within charter of the WG, and seems to b= e interesting work for the community. Questions we are looking answers for: 1) Should it be targeted BCP or Informational? 2) Is the work quality ok to be accepted as WG document? 3) Is the topic inline with the OPSEC charter? 4) Any missing or over-described points? Many thanks in advance, Kind Regards, OPSEC Chairs, (G/, KK, Warren) --_000_67832B1175062E48926BF3CB27C49B240674C2xmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Can I request the WG members for 3 volunteers to rea= d the draft draft-gont-opsec-ipv6-implications-on-ipv4-nets and provide fee= dback to the list?

 

This will help the OPSEC chairs to identify if the w= ork is ready for WG adoption or not. The work targets are within charter of= the WG, and seems to be interesting work for the community.

 

Questions we are looking answers for:

 

1)      Should it be targeted BCP or Informational?

2)      Is the work quality ok to be accepted as WG documen= t?

3)      Is the topic inline with the OPSEC charter?

4)      Any missing or over-described points?

 

Many thanks in advance,

 

Kind Regards,

OPSEC Chairs,

(G/, KK, Warren)

--_000_67832B1175062E48926BF3CB27C49B240674C2xmbalnx12ciscocom_-- From gvandeve@cisco.com Mon Aug 6 01:51:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D621F858A; Mon, 6 Aug 2012 01:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.396 X-Spam-Level: X-Spam-Status: No, score=-10.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZeBuqC5-C1C; Mon, 6 Aug 2012 01:51:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E490E21F8541; Mon, 6 Aug 2012 01:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=6187; q=dns/txt; s=iport; t=1344243070; x=1345452670; h=from:to:cc:subject:date:message-id:mime-version; bh=pv+9GhIfX8hWTTwol2z/EDfFD58lKfdRTSuh8P28L8A=; b=kq+CetO9F7KWtqbFPR3Uhb20SbRNx9sXz0nxCnc3H86T8uBVrwYYHwIW 8clNyv/jc08csYJoXNbSUHn4cGx2IyibH9LVjt9GtS8M+koDU9JT+OV/c T3h4hBr7BWa2Sx+p0BczJnPpVbjWqaPLyiyipLO607roUNjIaXit16Az9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAOyEH1CtJXHA/2dsb2JhbABFgkqmFIgPAYhQgQeCIgEEEgEKEEwSASpWJgEEDg0ah2sLmzqfVJFuYAOWXY0SgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208,217";a="108719066" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 06 Aug 2012 08:51:09 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q768p96I010708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 08:51:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 03:51:09 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IPv6 OPSEC drafts need review Thread-Index: Ac1zr7XviImO0VW9ShaYOQMMM67U3A== Date: Mon, 6 Aug 2012 08:51:08 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240674DA@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.004 x-tm-as-result: No--32.390100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240674DAxmbalnx12ciscocom_" MIME-Version: 1.0 Cc: "draft-vyncke-opsec-v6@tools.ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "draft-jdurant-bgp-security-01@tools.ietf.org" Subject: [v6ops] IPv6 OPSEC drafts need review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 08:51:10 -0000 --_000_67832B1175062E48926BF3CB27C49B240674DAxmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, As mentioned during the OPSEC WG meeting, the following 2 drafts will in 3 = weeks be considered for WG documents, after a call for feedback on the emai= l list. During the WG meeting it became clear that not that many people rea= d the documents until now. Please read drafts: 1) http://datatracker.ietf.org/doc/draft-vyncke-opsec-v6/ 2) http://tools.ietf.org/html/draft-jdurand-bgp-security-01 On Monday 27th the chairs of OPSEC WG will ask the WG during a period of 7 = days for feedback on these drafts to support or deny acceptance as WG docum= ents. Kind Regards, G/, KK & Warren --_000_67832B1175062E48926BF3CB27C49B240674DAxmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

As mentioned during the OPSEC WG meeting, the follow= ing 2 drafts will in 3 weeks be considered for WG documents, after a call f= or feedback on the email list. During the WG meeting it became clear that n= ot that many people read the documents until now.

 

Please read drafts:

 

1)      http://datatracker.ietf.org/doc/draft-vyncke-opsec-v6/<= o:p>

2)      http://tools.ietf.org/html/draft-jdurand-bgp-security-01<= /a>

 

On Monday 27th the chairs of OPSEC WG wil= l ask the WG during a period of 7 days for feedback on these drafts to supp= ort or deny acceptance as WG documents.

 

Kind Regards,

G/, KK & Warren

--_000_67832B1175062E48926BF3CB27C49B240674DAxmbalnx12ciscocom_-- From gvandeve@cisco.com Mon Aug 6 02:03:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C718421F84F6; Mon, 6 Aug 2012 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.397 X-Spam-Level: X-Spam-Status: No, score=-10.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBSdSt036r8g; Mon, 6 Aug 2012 02:03:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5621F84E4; Mon, 6 Aug 2012 02:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3394; q=dns/txt; s=iport; t=1344243788; x=1345453388; h=from:to:cc:subject:date:message-id:mime-version; bh=HBGuloKUT9SIOhAnizh6QHJPYGVtxoSt702ID6UnXGk=; b=J/7LhM0x8qIHNWnS9aFwkOsseYPvIM6qILTJC82CVgX3tVVbX2qgHSuT dohDkwyIgSSbQN71ESifFZP6o9IoOCT1bOIwH90oLxUaHRAUsi6HIkp4K vFhSE0APFIp/A5OjCTsWKozCYGvgE3ynyAPvFNxJ+/dhx7q55fEpi9VTA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAFWHH1CtJV2d/2dsb2JhbABFgkqCaqs5AYhQgQeCIgEEEgEaTBIBDB5WJgEEDg0ah2sLmz+fV5FuYAOWXY0SgWaCXw X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208,217";a="108720193" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2012 09:03:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q76938h2030052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 09:03:08 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 04:03:07 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7Q== Date: Mon, 6 Aug 2012 09:03:06 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--28.972000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B24068549xmbalnx12ciscocom_" MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" , "opsec-chairs@ietf.org" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:03:10 -0000 --_000_67832B1175062E48926BF3CB27C49B24068549xmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (distributed to OPSEC WG and in cc v6ops) Dear all, During the OPSEC WG meeting last Wednesday there was consensus to adopt the= draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working gr= oup document with Informational status. Please read the draft, and if there is no violent objection on the list, th= e document will be requested to be submitted as WG document in 7 days. Ciao, G/, KK & Warren --_000_67832B1175062E48926BF3CB27C49B24068549xmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(distributed to OPSEC WG and in cc v6ops)=

 

Dear all,

 

During the OPSEC WG meeting last Wednesday there was= consensus to adopt the draft http://t= ools.ietf.org/html/draft-behringer-lla-only-01 as working group documen= t with Informational status.

 

Please read the draft, and if there is no violent ob= jection on the list, the document will be requested to be submitted as WG d= ocument in 7 days.

 

Ciao,

G/, KK & Warren

--_000_67832B1175062E48926BF3CB27C49B24068549xmbalnx12ciscocom_-- From brian.e.carpenter@gmail.com Mon Aug 6 02:24:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31921F84F6; Mon, 6 Aug 2012 02:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.174 X-Spam-Level: X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgAooLVCf3Di; Mon, 6 Aug 2012 02:24:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F01521F85FC; Mon, 6 Aug 2012 02:24:52 -0700 (PDT) Received: by eekb45 with SMTP id b45so676373eek.31 for ; Mon, 06 Aug 2012 02:24:51 -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=LFnCaHZ+L8Wxy4qp6VWlcXQumJVNZ6p0hyWaTVI1NjQ=; b=uxe9vpEs8cK6m22aScM5f+v3PH1zzUFSSmD/2HxqRLKXZrV/nfI8iT2Ci1n1RqaYaD 3vIXe/lBJyH6YL7bR5o9dbkjtHh5SXp48hIISo7ydRU2NBnmN6Jxu/6VIXNtqiVEuvf/ fx0oj8KBZcTziSaGJZ4FxGyPBbL2l3J1uhjZgZe1ZLm2Tp9mfglU3Dee0j5VL4tFxiBx 1apWzOj5UfF16m0MMYhnDYfKmfgPbER+Bh81uWfuh/qSvJBMpBB9/C2CqcCLzjNe3E0j UPS0pKOx9VYVHNhgD0zBzDHHxURrogiQaC3wVtgVH7lmdWD9oqJ2ybWp082Hc/BBzzi+ JCHg== Received: by 10.14.210.197 with SMTP id u45mr12174953eeo.42.1344245091552; Mon, 06 Aug 2012 02:24:51 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-73.as13285.net. [2.102.216.73]) by mx.google.com with ESMTPS id o47sm45916015eem.0.2012.08.06.02.24.49 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 02:24:50 -0700 (PDT) Message-ID: <501F8D5F.5000805@gmail.com> Date: Mon, 06 Aug 2012 10:24:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:24:53 -0000 Hi, > o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo > request ... can be addressed to loopback addresses of routers with > a global scope address. Router management can also be done over > out-of-band channels. > > o ICMP error message can also be sourced from the global scope > loopback address. These statements seem too weak. Using GUAs for ICMP in particular needs to have a normative MUST somewhere (preferably in a BCP). In the context of this Informational draft, the language needs to state a requirement ("must" not "can") even if you don't use RFC 2119 terminology. This matters because packets with a LL source address MUST NOT be forwarded, so a router that is misconfigured to send ICMP replies with a LL source address breaks both ping and traceroute. I think the rule is that any packet that is *not* sent to a LL address must have a GUA as the source address. That takes care of ICMP, and everything else as well. Furthermore, that GUA needs to be associated with a prefix that belongs to the organisation operating the router in question. Otherwise the traceroute results can be very confusing. We discussed that on v6ops back in March. Regards Brian Carpenter On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: > (distributed to OPSEC WG and in cc v6ops) > > Dear all, > > During the OPSEC WG meeting last Wednesday there was consensus to adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working group document with Informational status. > > Please read the draft, and if there is no violent objection on the list, the document will be requested to be submitted as WG document in 7 days. > > Ciao, > G/, KK & Warren > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Aug 6 02:36:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46221F8617; Mon, 6 Aug 2012 02:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBDutU9hycz7; Mon, 6 Aug 2012 02:36:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9C921F8616; Mon, 6 Aug 2012 02:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=4172; q=dns/txt; s=iport; t=1344245780; x=1345455380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HfICAQuLFJnRHlPLt0ENIRtDz42BUu17PEyrzbeVoPw=; b=Pr0EdVY5v3amqMtfSbXBiYittmWLuNNAkfLvXvzLLWiNT7PQFh6VY1F0 gmOud5L/ouQkxfm8C1O4go4KsKOOa02j4Blwz019lBXJyXpmjfMI1iATu BLxeicQeuainrAB1uWsQDMyAFMK1LMR6I8Y5/Rt/cjdBNhwiYU7JqcEud 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF2PH1CtJV2d/2dsb2JhbABFhXuyTXaBB4IgAQEBAwEBAQEPARAROgsFBwQCAQgRBAEBAQICBh0DAgICHwYLFAEICAEBBA4FCBqHXAMGBgubSI0ZiGgNiU6BIYlCZ4VyMmADk3aCZ4l1gx2BZoJf X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208";a="108731552" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2012 09:36:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q769aJag027302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 09:36:19 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 04:36:19 -0500 From: "Gunter Van de Velde (gvandeve)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAApGAYA= Date: Mon, 6 Aug 2012 09:36:18 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> In-Reply-To: <501F8D5F.5000805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--44.211700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:36:21 -0000 QW5zd2VyIGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IuDQoNCkZyZWQgQi4gYW5kIG15c2VsZiBk aWQgYSBkcmFmdCB0byBleGFjdGx5IGFkZHJlc3MgdGhlIHRyYWNlYWJpbGl0eSBvZiBpbnRlcmZh Y2VzIHdpdGhvdXQgDQppbmNyZWFzaW5nIHRoZSBhdHRhY2sgdmVjdG9yIG9uIGludGVyZmFjZXM6 IFBhc3NpdmUgSVB2NiBhZGRyZXNzZXMNCg0KTm8gbmV3IGNsYXNzIG9mIGFkZHJlc3NlcyBhdCBh bGwuLi4gbm8gbmV3IElBTkEgYWxsb2NhdGlvbi4uLiBqdXN0IGJlaGF2aW91ciBvZiB0aGUgYWRk cmVzczoNCg0KMSkgaXQgaXMgY29uZmlndXJlZCBhcyBhIG5vcm1hbCBhZGRyZXNzDQoyKSBqdXN0 IGFuIGV4dHJhIGtleXdvcmQgYXR0YWNoZWQgdG8gdGhlIGFkZHJlc3MgaWRlbnRpZnlpbmcgaXRz IGJlaGF2aW9yDQozKSBJdCBjYW4gb25seSBiZSB1c2VkIGFzIGEgJ3NvdXJjZScgYWRkcmVzcw0K NCkgaWYgaXQgaXMgdXNlZCBhcyBkZXN0aW5hdGlvbiBhZGRyZXNzLCB0aGVuIHdoZW4gcmVhY2hp bmcgdGhlIHJvdXRlciBpdCB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZSBOdWxsMCBpbnRlcmZhY2UN Cg0KVGhpcyB3aWxsIGhlbHAgdmlzaWJpbGl0eSBvZiB0aGUgdHJhY2Utcm91dGUgaW4gY2FzZXMg b2YgTEwtb25seS4uLg0KDQpHLw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0g DQpTZW50OiAwNiBBdWd1c3QgMjAxMiAxMToyNQ0KVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2 YW5kZXZlKQ0KQ2M6IG9wc2VjQGlldGYub3JnOyB2Nm9wcyB2Nm9wcyBXRyAodjZvcHNAaWV0Zi5v cmcpOyBvcHNlYy1jaGFpcnNAaWV0Zi5vcmc7ICdkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9v bHMuaWV0Zi5vcmcnIChkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9vbHMuaWV0Zi5vcmcpDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2IExMLW9ubHkgYXMgV0cgZG9jdW1lbnQgLSBmZWVkYmFj ayByZXF1ZXN0ZWQNCg0KSGksDQoNCj4gICAgbyAgTWFuYWdlbWVudCBwbGFuZSB0cmFmZmljLCBz dWNoIGFzIFNTSCwgVGVsbmV0LCBTTk1QLCBJQ01QIGVjaG8NCj4gICAgICAgcmVxdWVzdCAuLi4g Y2FuIGJlIGFkZHJlc3NlZCB0byBsb29wYmFjayBhZGRyZXNzZXMgb2Ygcm91dGVycyB3aXRoDQo+ ICAgICAgIGEgZ2xvYmFsIHNjb3BlIGFkZHJlc3MuICBSb3V0ZXIgbWFuYWdlbWVudCBjYW4gYWxz byBiZSBkb25lIG92ZXINCj4gICAgICAgb3V0LW9mLWJhbmQgY2hhbm5lbHMuDQo+IA0KPiAgICBv ICBJQ01QIGVycm9yIG1lc3NhZ2UgY2FuIGFsc28gYmUgc291cmNlZCBmcm9tIHRoZSBnbG9iYWwg c2NvcGUNCj4gICAgICAgbG9vcGJhY2sgYWRkcmVzcy4NCg0KVGhlc2Ugc3RhdGVtZW50cyBzZWVt IHRvbyB3ZWFrLiBVc2luZyBHVUFzIGZvciBJQ01QIGluIHBhcnRpY3VsYXIgbmVlZHMgdG8gaGF2 ZSBhIG5vcm1hdGl2ZSBNVVNUIHNvbWV3aGVyZSAocHJlZmVyYWJseSBpbiBhIEJDUCkuIEluIHRo ZSBjb250ZXh0IG9mIHRoaXMgSW5mb3JtYXRpb25hbCBkcmFmdCwgdGhlIGxhbmd1YWdlIG5lZWRz IHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQgKCJtdXN0IiBub3QgImNhbiIpIGV2ZW4gaWYgeW91IGRv bid0IHVzZSBSRkMgMjExOSB0ZXJtaW5vbG9neS4NCg0KVGhpcyBtYXR0ZXJzIGJlY2F1c2UgcGFj a2V0cyB3aXRoIGEgTEwgc291cmNlIGFkZHJlc3MgTVVTVCBOT1QgYmUgZm9yd2FyZGVkLCBzbyBh IHJvdXRlciB0aGF0IGlzIG1pc2NvbmZpZ3VyZWQgdG8gc2VuZCBJQ01QIHJlcGxpZXMgd2l0aCBh IExMIHNvdXJjZSBhZGRyZXNzIGJyZWFrcyBib3RoIHBpbmcgYW5kIHRyYWNlcm91dGUuDQoNCkkg dGhpbmsgdGhlIHJ1bGUgaXMgdGhhdCBhbnkgcGFja2V0IHRoYXQgaXMgKm5vdCogc2VudCB0byBh IExMIGFkZHJlc3MgbXVzdCBoYXZlIGEgR1VBIGFzIHRoZSBzb3VyY2UgYWRkcmVzcy4gVGhhdCB0 YWtlcyBjYXJlIG9mIElDTVAsIGFuZCBldmVyeXRoaW5nIGVsc2UgYXMgd2VsbC4NCg0KRnVydGhl cm1vcmUsIHRoYXQgR1VBIG5lZWRzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0 IGJlbG9uZ3MgdG8gdGhlIG9yZ2FuaXNhdGlvbiBvcGVyYXRpbmcgdGhlIHJvdXRlciBpbiBxdWVz dGlvbi4gT3RoZXJ3aXNlIHRoZSB0cmFjZXJvdXRlIHJlc3VsdHMgY2FuIGJlIHZlcnkgY29uZnVz aW5nLiBXZSBkaXNjdXNzZWQgdGhhdCBvbiB2Nm9wcyBiYWNrIGluIE1hcmNoLg0KDQpSZWdhcmRz DQogICBCcmlhbiBDYXJwZW50ZXINCg0KDQoNCg0KT24gMDYvMDgvMjAxMiAxMDowMywgR3VudGVy IFZhbiBkZSBWZWxkZSAoZ3ZhbmRldmUpIHdyb3RlOg0KPiAoZGlzdHJpYnV0ZWQgdG8gT1BTRUMg V0cgYW5kIGluIGNjIHY2b3BzKQ0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiBEdXJpbmcgdGhlIE9Q U0VDIFdHIG1lZXRpbmcgbGFzdCBXZWRuZXNkYXkgdGhlcmUgd2FzIGNvbnNlbnN1cyB0byBhZG9w dCB0aGUgZHJhZnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWxs YS1vbmx5LTAxIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgd2l0aCBJbmZvcm1hdGlvbmFsIHN0 YXR1cy4NCj4gDQo+IFBsZWFzZSByZWFkIHRoZSBkcmFmdCwgYW5kIGlmIHRoZXJlIGlzIG5vIHZp b2xlbnQgb2JqZWN0aW9uIG9uIHRoZSBsaXN0LCB0aGUgZG9jdW1lbnQgd2lsbCBiZSByZXF1ZXN0 ZWQgdG8gYmUgc3VibWl0dGVkIGFzIFdHIGRvY3VtZW50IGluIDcgZGF5cy4NCj4gDQo+IENpYW8s DQo+IEcvLCBLSyAmIFdhcnJlbg0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From brian.e.carpenter@gmail.com Mon Aug 6 02:40:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A23521F861E; Mon, 6 Aug 2012 02:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.173 X-Spam-Level: X-Spam-Status: No, score=-101.173 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C64FxvvADQXS; Mon, 6 Aug 2012 02:40:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1771121F861D; Mon, 6 Aug 2012 02:40:12 -0700 (PDT) Received: by eekb45 with SMTP id b45so682168eek.31 for ; Mon, 06 Aug 2012 02:40:12 -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=2LaRKJdTNNVsXpj7M7bVjuOdd9bi09s+FibsRyrlbjQ=; b=PnXkLWkeWW0rYz8e97lsYmNM1etasaluy9AR7ylJlLJxd59oPYK0IORVIeexC+LX3i 6PWl7vSnlS7+0uXC37N/hP1IJkP28Kf78w2eGENyb0W6JNuwtLJ7C9HUgp0m9x8yxGNX kjVlqGKmu69mz2pdMD8++FLnBetEiH3vI8Gk28h15+taxLrBwcGYc4+pRUYNh1NSsfXh aOEYrCVWPRd7pUqn+PqqeuSXDXts1zNTJD9s1CaTUGLLY2MKX/bNSbIP6YnGilUQUOV5 oDE36j7CVDHDDkWUfoaPq5339L/54kjsUB9AERgYqCVWyg1Ks1BJD1/Fl2SaSWTKO/fp 1V/A== Received: by 10.14.179.71 with SMTP id g47mr12234086eem.21.1344246012266; Mon, 06 Aug 2012 02:40:12 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-73.as13285.net. [2.102.216.73]) by mx.google.com with ESMTPS id u47sm13583324eeo.9.2012.08.06.02.40.10 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 02:40:11 -0700 (PDT) Message-ID: <501F90F8.1050409@gmail.com> Date: Mon, 06 Aug 2012 10:40:08 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:40:14 -0000 Hi Gunter, I have no problem with the passive address idea, but the immediate issue is that routers must not source ICMP packets that other routers must discard - hence no LL source addresses. Brian On 06/08/2012 10:36, Gunter Van de Velde (gvandeve) wrote: > Answer as individual contributor. > > Fred B. and myself did a draft to exactly address the traceability of interfaces without > increasing the attack vector on interfaces: Passive IPv6 addresses > > No new class of addresses at all... no new IANA allocation... just behaviour of the address: > > 1) it is configured as a normal address > 2) just an extra keyword attached to the address identifying its behavior > 3) It can only be used as a 'source' address > 4) if it is used as destination address, then when reaching the router it will be directed to the Null0 interface > > This will help visibility of the trace-route in cases of LL-only... > > G/ > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 06 August 2012 11:25 > To: Gunter Van de Velde (gvandeve) > Cc: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org); opsec-chairs@ietf.org; 'draft-behringer-lla-only@tools.ietf.org' (draft-behringer-lla-only@tools.ietf.org) > Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested > > Hi, > >> o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo >> request ... can be addressed to loopback addresses of routers with >> a global scope address. Router management can also be done over >> out-of-band channels. >> >> o ICMP error message can also be sourced from the global scope >> loopback address. > > These statements seem too weak. Using GUAs for ICMP in particular needs to have a normative MUST somewhere (preferably in a BCP). In the context of this Informational draft, the language needs to state a requirement ("must" not "can") even if you don't use RFC 2119 terminology. > > This matters because packets with a LL source address MUST NOT be forwarded, so a router that is misconfigured to send ICMP replies with a LL source address breaks both ping and traceroute. > > I think the rule is that any packet that is *not* sent to a LL address must have a GUA as the source address. That takes care of ICMP, and everything else as well. > > Furthermore, that GUA needs to be associated with a prefix that belongs to the organisation operating the router in question. Otherwise the traceroute results can be very confusing. We discussed that on v6ops back in March. > > Regards > Brian Carpenter > > > > > On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: >> (distributed to OPSEC WG and in cc v6ops) >> >> Dear all, >> >> During the OPSEC WG meeting last Wednesday there was consensus to adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working group document with Informational status. >> >> Please read the draft, and if there is no violent objection on the list, the document will be requested to be submitted as WG document in 7 days. >> >> Ciao, >> G/, KK & Warren >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Aug 6 03:18:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98BD21F8628; Mon, 6 Aug 2012 03:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wceGfgQ7LHgw; Mon, 6 Aug 2012 03:18:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 94D9E21F8629; Mon, 6 Aug 2012 03:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=6064; q=dns/txt; s=iport; t=1344248313; x=1345457913; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+psj8CAOAOoFBOaNvKF25CMvVW/q51oshA+noCVyR/A=; b=iFiFI+F5GZC0b9EcABB/3WCvFbqZjp8V8S7FwdDF2O3Q84OrKAHHasDC 1T6vX7aVa4utHn0ZtjtQNHhN+Vzfio9hgRAsDWaMufc92gqdNSNg98IzI ZFv76Frj9aYGmDbk5M6y+OcO9dvQPov6mf35WkLSaZ7PQbl6wSZ6dbq2v Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEyZH1CtJXHB/2dsb2JhbABFhXuyTXaBB4IgAQEBBAEBAQ8BEBE6CwwEAgEIEQQBAQECAgYdAwICAh8GCxQBCAgBAQQOBQgah1wDDAubNo0ZiHYNiU6BIYlCZ4VyMmADk3aCZ4l1gx2BZoJf X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208";a="108770680" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 06 Aug 2012 10:18:33 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q76AIWJM019737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 10:18:32 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 05:18:32 -0500 From: "Gunter Van de Velde (gvandeve)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAApGAYD//7IZAIAASnFA Date: Mon, 6 Aug 2012 10:18:31 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240685F6@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> <501F90F8.1050409@gmail.com> In-Reply-To: <501F90F8.1050409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.82.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--48.409400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:18:40 -0000 SSBhbSBjb25mdXNlZC4gUGxlYXNlIGNvcnJlY3QgbXkgdW5kZXJzdGFuZGluZyBpZiBwb3NzaWJs ZS4NCg0KMSkgWW91IGFyZSBvayB3aXRoIHRoZSBCZWhyaW5nZXItTEwgZHJhZnQgYmVpbmcgYW4g aW5mb3JtYXRpb25hbCBkcmFmdD8gKG5vdCBCQ1ApDQoyKSBQYXNzaXZlIGFkZHJlc3NlcyBpcyBz b21ldGhpbmcgdGhhdCBjcmVhdGVzIHBvdGVudGlhbCBpc3N1ZXMgaW4geW91ciB2aWV3Pw0KDQpG b3IgKDIpIEkgd291bGQgc2F5Li4uIEl0IGlzIGp1c3QgYXMgYSBub3JtYWwgYWRkcmVzcy4uLiBu byBuZWVkIGF0IGFsbCB0byBkaXNjYXJkIHRoZW0gb24gYW55IG90aGVyIGJveCB0aGVuIHRoZSBy ZWNlaXZpbmcgYm94IGFzIHRob3NlIGJveGVzIGp1c3Qgc2VlIHRoZSBhZGRyZXNzIGFzIGJlaW5n IGEgbm9ybWFsIElQdjYgYWRkcmVzcy4gTm90aGluZyBzcGVjaWFsIGFib3V0IGl0LiBJdCBpcyBq dXN0IGEgbm9ybWFsIGFkZHJlc3MuIFRoZSBiZWhhdmlvdXIgb2YgcGFzc2l2ZSBhZGRyZXNzZXMg aXMgdG8gZG8gd2l0aCB0aGUgd2F5IHRoZSByZWNpcGllbnQgZGV2aWNlIGRlYWxzIHdpdGggdGhp cyBhZGRyZXNzLg0KDQpHLw0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21d IA0KU2VudDogMDYgQXVndXN0IDIwMTIgMTE6NDANClRvOiBHdW50ZXIgVmFuIGRlIFZlbGRlIChn dmFuZGV2ZSkNCkNjOiBvcHNlY0BpZXRmLm9yZzsgdjZvcHMgdjZvcHMgV0cgKHY2b3BzQGlldGYu b3JnKTsgb3BzZWMtY2hhaXJzQGlldGYub3JnOyAnZHJhZnQtYmVocmluZ2VyLWxsYS1vbmx5QHRv b2xzLmlldGYub3JnJyAoZHJhZnQtYmVocmluZ2VyLWxsYS1vbmx5QHRvb2xzLmlldGYub3JnKQ0K U3ViamVjdDogUmU6IFt2Nm9wc10gSVB2NiBMTC1vbmx5IGFzIFdHIGRvY3VtZW50IC0gZmVlZGJh Y2sgcmVxdWVzdGVkDQoNCkhpIEd1bnRlciwNCg0KSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUg cGFzc2l2ZSBhZGRyZXNzIGlkZWEsIGJ1dCB0aGUgaW1tZWRpYXRlIGlzc3VlIGlzIHRoYXQgcm91 dGVycyBtdXN0IG5vdCBzb3VyY2UgSUNNUCBwYWNrZXRzIHRoYXQgb3RoZXIgcm91dGVycyBtdXN0 IGRpc2NhcmQgLSBoZW5jZSBubyBMTCBzb3VyY2UgYWRkcmVzc2VzLg0KDQogICAgQnJpYW4NCg0K T24gMDYvMDgvMjAxMiAxMDozNiwgR3VudGVyIFZhbiBkZSBWZWxkZSAoZ3ZhbmRldmUpIHdyb3Rl Og0KPiBBbnN3ZXIgYXMgaW5kaXZpZHVhbCBjb250cmlidXRvci4NCj4gDQo+IEZyZWQgQi4gYW5k IG15c2VsZiBkaWQgYSBkcmFmdCB0byBleGFjdGx5IGFkZHJlc3MgdGhlIHRyYWNlYWJpbGl0eSBv ZiANCj4gaW50ZXJmYWNlcyB3aXRob3V0IGluY3JlYXNpbmcgdGhlIGF0dGFjayB2ZWN0b3Igb24g aW50ZXJmYWNlczogUGFzc2l2ZSANCj4gSVB2NiBhZGRyZXNzZXMNCj4gDQo+IE5vIG5ldyBjbGFz cyBvZiBhZGRyZXNzZXMgYXQgYWxsLi4uIG5vIG5ldyBJQU5BIGFsbG9jYXRpb24uLi4ganVzdCBi ZWhhdmlvdXIgb2YgdGhlIGFkZHJlc3M6DQo+IA0KPiAxKSBpdCBpcyBjb25maWd1cmVkIGFzIGEg bm9ybWFsIGFkZHJlc3MNCj4gMikganVzdCBhbiBleHRyYSBrZXl3b3JkIGF0dGFjaGVkIHRvIHRo ZSBhZGRyZXNzIGlkZW50aWZ5aW5nIGl0cyANCj4gYmVoYXZpb3INCj4gMykgSXQgY2FuIG9ubHkg YmUgdXNlZCBhcyBhICdzb3VyY2UnIGFkZHJlc3MNCj4gNCkgaWYgaXQgaXMgdXNlZCBhcyBkZXN0 aW5hdGlvbiBhZGRyZXNzLCB0aGVuIHdoZW4gcmVhY2hpbmcgdGhlIHJvdXRlciANCj4gaXQgd2ls bCBiZSBkaXJlY3RlZCB0byB0aGUgTnVsbDAgaW50ZXJmYWNlDQo+IA0KPiBUaGlzIHdpbGwgaGVs cCB2aXNpYmlsaXR5IG9mIHRoZSB0cmFjZS1yb3V0ZSBpbiBjYXNlcyBvZiBMTC1vbmx5Li4uDQo+ IA0KPiBHLw0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJy aWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBT ZW50OiAwNiBBdWd1c3QgMjAxMiAxMToyNQ0KPiBUbzogR3VudGVyIFZhbiBkZSBWZWxkZSAoZ3Zh bmRldmUpDQo+IENjOiBvcHNlY0BpZXRmLm9yZzsgdjZvcHMgdjZvcHMgV0cgKHY2b3BzQGlldGYu b3JnKTsgDQo+IG9wc2VjLWNoYWlyc0BpZXRmLm9yZzsgJ2RyYWZ0LWJlaHJpbmdlci1sbGEtb25s eUB0b29scy5pZXRmLm9yZycgDQo+IChkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9vbHMuaWV0 Zi5vcmcpDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgTEwtb25seSBhcyBXRyBkb2N1bWVu dCAtIGZlZWRiYWNrIHJlcXVlc3RlZA0KPiANCj4gSGksDQo+IA0KPj4gICAgbyAgTWFuYWdlbWVu dCBwbGFuZSB0cmFmZmljLCBzdWNoIGFzIFNTSCwgVGVsbmV0LCBTTk1QLCBJQ01QIGVjaG8NCj4+ ICAgICAgIHJlcXVlc3QgLi4uIGNhbiBiZSBhZGRyZXNzZWQgdG8gbG9vcGJhY2sgYWRkcmVzc2Vz IG9mIHJvdXRlcnMgd2l0aA0KPj4gICAgICAgYSBnbG9iYWwgc2NvcGUgYWRkcmVzcy4gIFJvdXRl ciBtYW5hZ2VtZW50IGNhbiBhbHNvIGJlIGRvbmUgb3Zlcg0KPj4gICAgICAgb3V0LW9mLWJhbmQg Y2hhbm5lbHMuDQo+Pg0KPj4gICAgbyAgSUNNUCBlcnJvciBtZXNzYWdlIGNhbiBhbHNvIGJlIHNv dXJjZWQgZnJvbSB0aGUgZ2xvYmFsIHNjb3BlDQo+PiAgICAgICBsb29wYmFjayBhZGRyZXNzLg0K PiANCj4gVGhlc2Ugc3RhdGVtZW50cyBzZWVtIHRvbyB3ZWFrLiBVc2luZyBHVUFzIGZvciBJQ01Q IGluIHBhcnRpY3VsYXIgbmVlZHMgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBNVVNUIHNvbWV3aGVyZSAo cHJlZmVyYWJseSBpbiBhIEJDUCkuIEluIHRoZSBjb250ZXh0IG9mIHRoaXMgSW5mb3JtYXRpb25h bCBkcmFmdCwgdGhlIGxhbmd1YWdlIG5lZWRzIHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQgKCJtdXN0 IiBub3QgImNhbiIpIGV2ZW4gaWYgeW91IGRvbid0IHVzZSBSRkMgMjExOSB0ZXJtaW5vbG9neS4N Cj4gDQo+IFRoaXMgbWF0dGVycyBiZWNhdXNlIHBhY2tldHMgd2l0aCBhIExMIHNvdXJjZSBhZGRy ZXNzIE1VU1QgTk9UIGJlIGZvcndhcmRlZCwgc28gYSByb3V0ZXIgdGhhdCBpcyBtaXNjb25maWd1 cmVkIHRvIHNlbmQgSUNNUCByZXBsaWVzIHdpdGggYSBMTCBzb3VyY2UgYWRkcmVzcyBicmVha3Mg Ym90aCBwaW5nIGFuZCB0cmFjZXJvdXRlLg0KPiANCj4gSSB0aGluayB0aGUgcnVsZSBpcyB0aGF0 IGFueSBwYWNrZXQgdGhhdCBpcyAqbm90KiBzZW50IHRvIGEgTEwgYWRkcmVzcyBtdXN0IGhhdmUg YSBHVUEgYXMgdGhlIHNvdXJjZSBhZGRyZXNzLiBUaGF0IHRha2VzIGNhcmUgb2YgSUNNUCwgYW5k IGV2ZXJ5dGhpbmcgZWxzZSBhcyB3ZWxsLg0KPiANCj4gRnVydGhlcm1vcmUsIHRoYXQgR1VBIG5l ZWRzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGJlbG9uZ3MgdG8gdGhlIG9y Z2FuaXNhdGlvbiBvcGVyYXRpbmcgdGhlIHJvdXRlciBpbiBxdWVzdGlvbi4gT3RoZXJ3aXNlIHRo ZSB0cmFjZXJvdXRlIHJlc3VsdHMgY2FuIGJlIHZlcnkgY29uZnVzaW5nLiBXZSBkaXNjdXNzZWQg dGhhdCBvbiB2Nm9wcyBiYWNrIGluIE1hcmNoLg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbiBD YXJwZW50ZXINCj4gDQo+IA0KPiANCj4gDQo+IE9uIDA2LzA4LzIwMTIgMTA6MDMsIEd1bnRlciBW YW4gZGUgVmVsZGUgKGd2YW5kZXZlKSB3cm90ZToNCj4+IChkaXN0cmlidXRlZCB0byBPUFNFQyBX RyBhbmQgaW4gY2MgdjZvcHMpDQo+Pg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gRHVyaW5nIHRoZSBP UFNFQyBXRyBtZWV0aW5nIGxhc3QgV2VkbmVzZGF5IHRoZXJlIHdhcyBjb25zZW5zdXMgdG8gYWRv cHQgdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlaHJpbmdlci1s bGEtb25seS0wMSBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHdpdGggSW5mb3JtYXRpb25hbCBz dGF0dXMuDQo+Pg0KPj4gUGxlYXNlIHJlYWQgdGhlIGRyYWZ0LCBhbmQgaWYgdGhlcmUgaXMgbm8g dmlvbGVudCBvYmplY3Rpb24gb24gdGhlIGxpc3QsIHRoZSBkb2N1bWVudCB3aWxsIGJlIHJlcXVl c3RlZCB0byBiZSBzdWJtaXR0ZWQgYXMgV0cgZG9jdW1lbnQgaW4gNyBkYXlzLg0KPj4NCj4+IENp YW8sDQo+PiBHLywgS0sgJiBXYXJyZW4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4g LQ0KPj4gLS0NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From brian.e.carpenter@gmail.com Mon Aug 6 03:52:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBB821F8619; Mon, 6 Aug 2012 03:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.172 X-Spam-Level: X-Spam-Status: No, score=-101.172 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHdeFn-Qndsp; Mon, 6 Aug 2012 03:52:58 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3267021F8602; Mon, 6 Aug 2012 03:52:58 -0700 (PDT) Received: by eaai11 with SMTP id i11so710784eaa.31 for ; Mon, 06 Aug 2012 03:52:57 -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=sB7v0yztQMGVJuKGn+qC0C04JBFWnoaZj3kVbdvPb0U=; b=RcAnTffIBhwFj3e+K1niJ8GsNSe/RpOLxP8kiQ1Z9u/R4xXl6Y4uBFCYLc+lrSR+Y9 LZov8AIf8A4lCEGRSYUs/LPyo0SQ3sHCE7YUmFejVtA62SPKxIUtI19qAzsQV0STfDUo irwQ+M4HEDCqo8lhcc9RFj+NyxYbhX2TPg4SI+b+jCWdjznzWR5NP0v8yzTsa7VqFE+B TOUp2E2mEtJpaUKM/cMPHQnWSe/OjwXV9zOPhG4O4H8Ja+FwPpjZHyTW1vuo1xCqGGwO EujsGkvMaci7Uq31U1mT1QW2lNzkjp8TYIktI9TbnH65Rc+Ocnf7C9OEXr4pj7rcWXeS gPbw== Received: by 10.14.206.200 with SMTP id l48mr12262978eeo.41.1344250377348; Mon, 06 Aug 2012 03:52:57 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-73.as13285.net. [2.102.216.73]) by mx.google.com with ESMTPS id j4sm46507358eeo.11.2012.08.06.03.52.54 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 03:52:55 -0700 (PDT) Message-ID: <501FA205.1020203@gmail.com> Date: Mon, 06 Aug 2012 11:52:53 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> <501F90F8.1050409@gmail.com> <67832B1175062E48926BF3CB27C49B240685F6@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240685F6@xmb-aln-x12.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:52:59 -0000 On 06/08/2012 11:18, Gunter Van de Velde (gvandeve) wrote: > I am confused. Please correct my understanding if possible. > > 1) You are ok with the Behringer-LL draft being an informational draft? (not BCP) Yes. All I'm saying is that it should insist on a valid source address, which means that a LL source address is not allowed for packets that leave the local link. Section 2.5.6 of RFC 4291 makes this clear but people seem to ignore it: "Link-Local addresses are for use on a single link." Obviously, therefore, packets whose destination is not LL must not have a LL source address. > 2) Passive addresses is something that creates potential issues in your view? I said I have no problem with that. It doesn't affect the above point. Brian > > For (2) I would say... It is just as a normal address... no need at all to discard them on any other box then the receiving box as those boxes just see the address as being a normal IPv6 address. Nothing special about it. It is just a normal address. The behaviour of passive addresses is to do with the way the recipient device deals with this address. > > G/ > > > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 06 August 2012 11:40 > To: Gunter Van de Velde (gvandeve) > Cc: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org); opsec-chairs@ietf.org; 'draft-behringer-lla-only@tools.ietf.org' (draft-behringer-lla-only@tools.ietf.org) > Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested > > Hi Gunter, > > I have no problem with the passive address idea, but the immediate issue is that routers must not source ICMP packets that other routers must discard - hence no LL source addresses. > > Brian > > On 06/08/2012 10:36, Gunter Van de Velde (gvandeve) wrote: >> Answer as individual contributor. >> >> Fred B. and myself did a draft to exactly address the traceability of >> interfaces without increasing the attack vector on interfaces: Passive >> IPv6 addresses >> >> No new class of addresses at all... no new IANA allocation... just behaviour of the address: >> >> 1) it is configured as a normal address >> 2) just an extra keyword attached to the address identifying its >> behavior >> 3) It can only be used as a 'source' address >> 4) if it is used as destination address, then when reaching the router >> it will be directed to the Null0 interface >> >> This will help visibility of the trace-route in cases of LL-only... >> >> G/ >> >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 06 August 2012 11:25 >> To: Gunter Van de Velde (gvandeve) >> Cc: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org); >> opsec-chairs@ietf.org; 'draft-behringer-lla-only@tools.ietf.org' >> (draft-behringer-lla-only@tools.ietf.org) >> Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested >> >> Hi, >> >>> o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo >>> request ... can be addressed to loopback addresses of routers with >>> a global scope address. Router management can also be done over >>> out-of-band channels. >>> >>> o ICMP error message can also be sourced from the global scope >>> loopback address. >> These statements seem too weak. Using GUAs for ICMP in particular needs to have a normative MUST somewhere (preferably in a BCP). In the context of this Informational draft, the language needs to state a requirement ("must" not "can") even if you don't use RFC 2119 terminology. >> >> This matters because packets with a LL source address MUST NOT be forwarded, so a router that is misconfigured to send ICMP replies with a LL source address breaks both ping and traceroute. >> >> I think the rule is that any packet that is *not* sent to a LL address must have a GUA as the source address. That takes care of ICMP, and everything else as well. >> >> Furthermore, that GUA needs to be associated with a prefix that belongs to the organisation operating the router in question. Otherwise the traceroute results can be very confusing. We discussed that on v6ops back in March. >> >> Regards >> Brian Carpenter >> >> >> >> >> On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: >>> (distributed to OPSEC WG and in cc v6ops) >>> >>> Dear all, >>> >>> During the OPSEC WG meeting last Wednesday there was consensus to adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working group document with Informational status. >>> >>> Please read the draft, and if there is no violent objection on the list, the document will be requested to be submitted as WG document in 7 days. >>> >>> Ciao, >>> G/, KK & Warren >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Aug 6 03:57:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBAC21F8634; Mon, 6 Aug 2012 03:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.107 X-Spam-Level: X-Spam-Status: No, score=-10.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHpeIgnN1Gg6; Mon, 6 Aug 2012 03:57:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EA70521F8602; Mon, 6 Aug 2012 03:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=7740; q=dns/txt; s=iport; t=1344250637; x=1345460237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qv0GRkQRMulI7noWw5c+aoKqJ1ZpjlAPDFtzUOQHRec=; b=Lsrn+d4eIvrXv7OOoKI202G5+39/jrzbo2qOPOU9DkcBNX16p4j3M2PD EgLw3GyDw0OfYQ6LeqiiMU/KyX0Uot94Ao4WpuhAUm2Rp/BgB9tmrkAVU 31Q3qzluU+U9adiP6Dx0ZhiVDwytOL5emPdryAAABqquF/kowFLFHr9PB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFuiH1CtJXHA/2dsb2JhbABFhXuyTXaBB4IgAQEBAwEBAQEPARAROgsFBwQCAQgRBAEBAQICBh0DAgICHwYLFAEICAIEDgUIGodcAwYGC5s0jRmIdw2JToEhiUJnhXIyYAOTdoJniXWDHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208";a="108781353" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2012 10:57:16 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q76AvGeY015840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 10:57:16 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 05:57:15 -0500 From: "Gunter Van de Velde (gvandeve)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAApGAYD//7IZAIAASnFA///J44CAAFMmwA== Date: Mon, 6 Aug 2012 10:57:15 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406878F@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> <501F90F8.1050409@gmail.com> <67832B1175062E48926BF3CB27C49B240685F6@xmb-aln-x12.cisco.com> <501FA205.1020203@gmail.com> In-Reply-To: <501FA205.1020203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.82.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--53.889300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:57:18 -0000 SSBhZ3JlZS4uLiBwYWNrZXRzIHdpdGggTEwgc291cmNlLWFkZHJlc3Mgc2hvdWxkIG5vdCBsZWF2 ZSB0aGUgbGluayBpbmRlZWQuDQoNCkkgZXhwZWN0IHRoZSBCZWhyaW5nZXIgZWRpdG9yIHRlYW0g dG8gbWFrZSB0aGF0IG1vcmUgc3BlY2lmaWMgaW4gdGhlIGRyYWZ0IHRleHQuDQoNCkcvDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRv OmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiAwNiBBdWd1c3QgMjAxMiAxMjo1 Mw0KVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5kZXZlKQ0KQ2M6IG9wc2VjQGlldGYub3Jn OyB2Nm9wcyB2Nm9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpOyBvcHNlYy1jaGFpcnNAaWV0Zi5vcmc7 ICdkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9vbHMuaWV0Zi5vcmcnIChkcmFmdC1iZWhyaW5n ZXItbGxhLW9ubHlAdG9vbHMuaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2IExM LW9ubHkgYXMgV0cgZG9jdW1lbnQgLSBmZWVkYmFjayByZXF1ZXN0ZWQNCg0KT24gMDYvMDgvMjAx MiAxMToxOCwgR3VudGVyIFZhbiBkZSBWZWxkZSAoZ3ZhbmRldmUpIHdyb3RlOg0KPiBJIGFtIGNv bmZ1c2VkLiBQbGVhc2UgY29ycmVjdCBteSB1bmRlcnN0YW5kaW5nIGlmIHBvc3NpYmxlLg0KPiAN Cj4gMSkgWW91IGFyZSBvayB3aXRoIHRoZSBCZWhyaW5nZXItTEwgZHJhZnQgYmVpbmcgYW4gaW5m b3JtYXRpb25hbCANCj4gZHJhZnQ/IChub3QgQkNQKQ0KDQpZZXMuIEFsbCBJJ20gc2F5aW5nIGlz IHRoYXQgaXQgc2hvdWxkIGluc2lzdCBvbiBhIHZhbGlkIHNvdXJjZSBhZGRyZXNzLCB3aGljaCBt ZWFucyB0aGF0IGEgTEwgc291cmNlIGFkZHJlc3MgaXMgbm90IGFsbG93ZWQgZm9yIHBhY2tldHMg dGhhdCBsZWF2ZSB0aGUgbG9jYWwgbGluay4NCg0KU2VjdGlvbiAyLjUuNiBvZiBSRkMgNDI5MSBt YWtlcyB0aGlzIGNsZWFyIGJ1dCBwZW9wbGUgc2VlbSB0byBpZ25vcmUgaXQ6DQoiTGluay1Mb2Nh bCBhZGRyZXNzZXMgYXJlIGZvciB1c2Ugb24gYSBzaW5nbGUgbGluay4iDQoNCk9idmlvdXNseSwg dGhlcmVmb3JlLCBwYWNrZXRzIHdob3NlIGRlc3RpbmF0aW9uIGlzIG5vdCBMTCBtdXN0IG5vdCBo YXZlIGEgTEwgc291cmNlIGFkZHJlc3MuDQoNCj4gMikgUGFzc2l2ZSBhZGRyZXNzZXMgaXMgc29t ZXRoaW5nIHRoYXQgY3JlYXRlcyBwb3RlbnRpYWwgaXNzdWVzIGluIHlvdXIgdmlldz8NCg0KSSBz YWlkIEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggdGhhdC4gSXQgZG9lc24ndCBhZmZlY3QgdGhlIGFi b3ZlIHBvaW50Lg0KDQogICBCcmlhbg0KPiANCj4gRm9yICgyKSBJIHdvdWxkIHNheS4uLiBJdCBp cyBqdXN0IGFzIGEgbm9ybWFsIGFkZHJlc3MuLi4gbm8gbmVlZCBhdCBhbGwgdG8gZGlzY2FyZCB0 aGVtIG9uIGFueSBvdGhlciBib3ggdGhlbiB0aGUgcmVjZWl2aW5nIGJveCBhcyB0aG9zZSBib3hl cyBqdXN0IHNlZSB0aGUgYWRkcmVzcyBhcyBiZWluZyBhIG5vcm1hbCBJUHY2IGFkZHJlc3MuIE5v dGhpbmcgc3BlY2lhbCBhYm91dCBpdC4gSXQgaXMganVzdCBhIG5vcm1hbCBhZGRyZXNzLiBUaGUg YmVoYXZpb3VyIG9mIHBhc3NpdmUgYWRkcmVzc2VzIGlzIHRvIGRvIHdpdGggdGhlIHdheSB0aGUg cmVjaXBpZW50IGRldmljZSBkZWFscyB3aXRoIHRoaXMgYWRkcmVzcy4NCj4gDQo+IEcvDQo+IA0K PiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBF IENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDog MDYgQXVndXN0IDIwMTIgMTE6NDANCj4gVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5kZXZl KQ0KPiBDYzogb3BzZWNAaWV0Zi5vcmc7IHY2b3BzIHY2b3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk7 IA0KPiBvcHNlYy1jaGFpcnNAaWV0Zi5vcmc7ICdkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9v bHMuaWV0Zi5vcmcnIA0KPiAoZHJhZnQtYmVocmluZ2VyLWxsYS1vbmx5QHRvb2xzLmlldGYub3Jn KQ0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2IExMLW9ubHkgYXMgV0cgZG9jdW1lbnQgLSBm ZWVkYmFjayByZXF1ZXN0ZWQNCj4gDQo+IEhpIEd1bnRlciwNCj4gDQo+IEkgaGF2ZSBubyBwcm9i bGVtIHdpdGggdGhlIHBhc3NpdmUgYWRkcmVzcyBpZGVhLCBidXQgdGhlIGltbWVkaWF0ZSBpc3N1 ZSBpcyB0aGF0IHJvdXRlcnMgbXVzdCBub3Qgc291cmNlIElDTVAgcGFja2V0cyB0aGF0IG90aGVy IHJvdXRlcnMgbXVzdCBkaXNjYXJkIC0gaGVuY2Ugbm8gTEwgc291cmNlIGFkZHJlc3Nlcy4NCj4g DQo+ICAgICBCcmlhbg0KPiANCj4gT24gMDYvMDgvMjAxMiAxMDozNiwgR3VudGVyIFZhbiBkZSBW ZWxkZSAoZ3ZhbmRldmUpIHdyb3RlOg0KPj4gQW5zd2VyIGFzIGluZGl2aWR1YWwgY29udHJpYnV0 b3IuDQo+Pg0KPj4gRnJlZCBCLiBhbmQgbXlzZWxmIGRpZCBhIGRyYWZ0IHRvIGV4YWN0bHkgYWRk cmVzcyB0aGUgdHJhY2VhYmlsaXR5IG9mIA0KPj4gaW50ZXJmYWNlcyB3aXRob3V0IGluY3JlYXNp bmcgdGhlIGF0dGFjayB2ZWN0b3Igb24gaW50ZXJmYWNlczogDQo+PiBQYXNzaXZlDQo+PiBJUHY2 IGFkZHJlc3Nlcw0KPj4NCj4+IE5vIG5ldyBjbGFzcyBvZiBhZGRyZXNzZXMgYXQgYWxsLi4uIG5v IG5ldyBJQU5BIGFsbG9jYXRpb24uLi4ganVzdCBiZWhhdmlvdXIgb2YgdGhlIGFkZHJlc3M6DQo+ Pg0KPj4gMSkgaXQgaXMgY29uZmlndXJlZCBhcyBhIG5vcm1hbCBhZGRyZXNzDQo+PiAyKSBqdXN0 IGFuIGV4dHJhIGtleXdvcmQgYXR0YWNoZWQgdG8gdGhlIGFkZHJlc3MgaWRlbnRpZnlpbmcgaXRz IA0KPj4gYmVoYXZpb3INCj4+IDMpIEl0IGNhbiBvbmx5IGJlIHVzZWQgYXMgYSAnc291cmNlJyBh ZGRyZXNzDQo+PiA0KSBpZiBpdCBpcyB1c2VkIGFzIGRlc3RpbmF0aW9uIGFkZHJlc3MsIHRoZW4g d2hlbiByZWFjaGluZyB0aGUgDQo+PiByb3V0ZXIgaXQgd2lsbCBiZSBkaXJlY3RlZCB0byB0aGUg TnVsbDAgaW50ZXJmYWNlDQo+Pg0KPj4gVGhpcyB3aWxsIGhlbHAgdmlzaWJpbGl0eSBvZiB0aGUg dHJhY2Utcm91dGUgaW4gY2FzZXMgb2YgTEwtb25seS4uLg0KPj4NCj4+IEcvDQo+Pg0KPj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4+IFNlbnQ6IDA2IEF1Z3VzdCAy MDEyIDExOjI1DQo+PiBUbzogR3VudGVyIFZhbiBkZSBWZWxkZSAoZ3ZhbmRldmUpDQo+PiBDYzog b3BzZWNAaWV0Zi5vcmc7IHY2b3BzIHY2b3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk7IA0KPj4gb3Bz ZWMtY2hhaXJzQGlldGYub3JnOyAnZHJhZnQtYmVocmluZ2VyLWxsYS1vbmx5QHRvb2xzLmlldGYu b3JnJw0KPj4gKGRyYWZ0LWJlaHJpbmdlci1sbGEtb25seUB0b29scy5pZXRmLm9yZykNCj4+IFN1 YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgTEwtb25seSBhcyBXRyBkb2N1bWVudCAtIGZlZWRiYWNr IHJlcXVlc3RlZA0KPj4NCj4+IEhpLA0KPj4NCj4+PiAgICBvICBNYW5hZ2VtZW50IHBsYW5lIHRy YWZmaWMsIHN1Y2ggYXMgU1NILCBUZWxuZXQsIFNOTVAsIElDTVAgZWNobw0KPj4+ICAgICAgIHJl cXVlc3QgLi4uIGNhbiBiZSBhZGRyZXNzZWQgdG8gbG9vcGJhY2sgYWRkcmVzc2VzIG9mIHJvdXRl cnMgd2l0aA0KPj4+ICAgICAgIGEgZ2xvYmFsIHNjb3BlIGFkZHJlc3MuICBSb3V0ZXIgbWFuYWdl bWVudCBjYW4gYWxzbyBiZSBkb25lIG92ZXINCj4+PiAgICAgICBvdXQtb2YtYmFuZCBjaGFubmVs cy4NCj4+Pg0KPj4+ICAgIG8gIElDTVAgZXJyb3IgbWVzc2FnZSBjYW4gYWxzbyBiZSBzb3VyY2Vk IGZyb20gdGhlIGdsb2JhbCBzY29wZQ0KPj4+ICAgICAgIGxvb3BiYWNrIGFkZHJlc3MuDQo+PiBU aGVzZSBzdGF0ZW1lbnRzIHNlZW0gdG9vIHdlYWsuIFVzaW5nIEdVQXMgZm9yIElDTVAgaW4gcGFy dGljdWxhciBuZWVkcyB0byBoYXZlIGEgbm9ybWF0aXZlIE1VU1Qgc29tZXdoZXJlIChwcmVmZXJh Ymx5IGluIGEgQkNQKS4gSW4gdGhlIGNvbnRleHQgb2YgdGhpcyBJbmZvcm1hdGlvbmFsIGRyYWZ0 LCB0aGUgbGFuZ3VhZ2UgbmVlZHMgdG8gc3RhdGUgYSByZXF1aXJlbWVudCAoIm11c3QiIG5vdCAi Y2FuIikgZXZlbiBpZiB5b3UgZG9uJ3QgdXNlIFJGQyAyMTE5IHRlcm1pbm9sb2d5Lg0KPj4NCj4+ IFRoaXMgbWF0dGVycyBiZWNhdXNlIHBhY2tldHMgd2l0aCBhIExMIHNvdXJjZSBhZGRyZXNzIE1V U1QgTk9UIGJlIGZvcndhcmRlZCwgc28gYSByb3V0ZXIgdGhhdCBpcyBtaXNjb25maWd1cmVkIHRv IHNlbmQgSUNNUCByZXBsaWVzIHdpdGggYSBMTCBzb3VyY2UgYWRkcmVzcyBicmVha3MgYm90aCBw aW5nIGFuZCB0cmFjZXJvdXRlLg0KPj4NCj4+IEkgdGhpbmsgdGhlIHJ1bGUgaXMgdGhhdCBhbnkg cGFja2V0IHRoYXQgaXMgKm5vdCogc2VudCB0byBhIExMIGFkZHJlc3MgbXVzdCBoYXZlIGEgR1VB IGFzIHRoZSBzb3VyY2UgYWRkcmVzcy4gVGhhdCB0YWtlcyBjYXJlIG9mIElDTVAsIGFuZCBldmVy eXRoaW5nIGVsc2UgYXMgd2VsbC4NCj4+DQo+PiBGdXJ0aGVybW9yZSwgdGhhdCBHVUEgbmVlZHMg dG8gYmUgYXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4IHRoYXQgYmVsb25ncyB0byB0aGUgb3JnYW5p c2F0aW9uIG9wZXJhdGluZyB0aGUgcm91dGVyIGluIHF1ZXN0aW9uLiBPdGhlcndpc2UgdGhlIHRy YWNlcm91dGUgcmVzdWx0cyBjYW4gYmUgdmVyeSBjb25mdXNpbmcuIFdlIGRpc2N1c3NlZCB0aGF0 IG9uIHY2b3BzIGJhY2sgaW4gTWFyY2guDQo+Pg0KPj4gUmVnYXJkcw0KPj4gICAgQnJpYW4gQ2Fy cGVudGVyDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT24gMDYvMDgvMjAxMiAxMDowMywgR3VudGVyIFZh biBkZSBWZWxkZSAoZ3ZhbmRldmUpIHdyb3RlOg0KPj4+IChkaXN0cmlidXRlZCB0byBPUFNFQyBX RyBhbmQgaW4gY2MgdjZvcHMpDQo+Pj4NCj4+PiBEZWFyIGFsbCwNCj4+Pg0KPj4+IER1cmluZyB0 aGUgT1BTRUMgV0cgbWVldGluZyBsYXN0IFdlZG5lc2RheSB0aGVyZSB3YXMgY29uc2Vuc3VzIHRv IGFkb3B0IHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5n ZXItbGxhLW9ubHktMDEgYXMgd29ya2luZyBncm91cCBkb2N1bWVudCB3aXRoIEluZm9ybWF0aW9u YWwgc3RhdHVzLg0KPj4+DQo+Pj4gUGxlYXNlIHJlYWQgdGhlIGRyYWZ0LCBhbmQgaWYgdGhlcmUg aXMgbm8gdmlvbGVudCBvYmplY3Rpb24gb24gdGhlIGxpc3QsIHRoZSBkb2N1bWVudCB3aWxsIGJl IHJlcXVlc3RlZCB0byBiZSBzdWJtaXR0ZWQgYXMgV0cgZG9jdW1lbnQgaW4gNyBkYXlzLg0KPj4+ DQo+Pj4gQ2lhbywNCj4+PiBHLywgS0sgJiBXYXJyZW4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+IC0NCj4+PiAtDQo+Pj4gLS0NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQo= From mbehring@cisco.com Mon Aug 6 04:27:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDF21F85FC; Mon, 6 Aug 2012 04:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTVVE0oxBluX; Mon, 6 Aug 2012 04:27:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1321F85FF; Mon, 6 Aug 2012 04:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbehring@cisco.com; l=8962; q=dns/txt; s=iport; t=1344252420; x=1345462020; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=D4HHGlZP+1lg8u0t4YIUd53wsbRnOz+/5UoAvJL/Yus=; b=OJmNLUZMALr9rzz7K+bxwJB/4Ul32x7H+5avichSFscEQVAS+eModzaS LVfT9dLXk43Nbr7IJwD3CJyBaeNJg+tpWYK/e2xRVbOpJwpAvLshq/SC+ qpA+lVf83bXi3KJw/ofnh9d31s2QAPgwoTH0LACIacT9xuFPbMATK9neT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIepH1CtJXG8/2dsb2JhbABEhXuyTXaBB4IgAQEBAwEBAQEPARAROgsMBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAgQBDQUIGodcAwYGC5spjRmIeA2JToEhiUJnhXIyYAOTdoJniXWDHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208";a="108787187" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 06 Aug 2012 11:26:59 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76BQx7K007296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 11:26:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 06:26:59 -0500 From: "Michael Behringer (mbehring)" To: "Gunter Van de Velde (gvandeve)" , Brian E Carpenter Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAApGAYD//7IZAIAASnFA///J44CAAFMmwIAAnfCw Date: Mon, 6 Aug 2012 11:26:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E1300@xmb-rcd-x14.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <67832B1175062E48926BF3CB27C49B2406858F@xmb-aln-x12.cisco.com> <501F90F8.1050409@gmail.com> <67832B1175062E48926BF3CB27C49B240685F6@xmb-aln-x12.cisco.com> <501FA205.1020203@gmail.com> <67832B1175062E48926BF3CB27C49B2406878F@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2406878F@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--65.578700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 11:27:07 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHdW50ZXIgVmFuIGRlIFZlbGRl IChndmFuZGV2ZSkNCj4gU2VudDogMDYgQXVndXN0IDIwMTIgMTE6NTcNCj4gVG86IEJyaWFuIEUg Q2FycGVudGVyDQo+IENjOiBvcHNlY0BpZXRmLm9yZzsgdjZvcHMgdjZvcHMgV0cgKHY2b3BzQGll dGYub3JnKTsgb3BzZWMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgJ2RyYWZ0LWJlaHJpbmdlci1sbGEt b25seUB0b29scy5pZXRmLm9yZycgKGRyYWZ0LWJlaHJpbmdlci0NCj4gbGxhLW9ubHlAdG9vbHMu aWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJFOiBbdjZvcHNdIElQdjYgTEwtb25seSBhcyBXRyBkb2N1 bWVudCAtIGZlZWRiYWNrIHJlcXVlc3RlZA0KPiANCj4gSSBhZ3JlZS4uLiBwYWNrZXRzIHdpdGgg TEwgc291cmNlLWFkZHJlc3Mgc2hvdWxkIG5vdCBsZWF2ZSB0aGUgbGluayBpbmRlZWQuDQo+IA0K PiBJIGV4cGVjdCB0aGUgQmVocmluZ2VyIGVkaXRvciB0ZWFtIHRvIG1ha2UgdGhhdCBtb3JlIHNw ZWNpZmljIGluIHRoZSBkcmFmdA0KPiB0ZXh0Lg0KDQpUaGlzIHdhcyBzb3J0IG9mIGltcGxpZWQg KGFuZCBtZW50aW9uZWQgZHVyaW5nIHByZXNlbnRhdGlvbnMpLCBidXQgbmVlZHMgdG8gYmUgbWFk ZSBjbGVhcmVyLCBhZ3JlZWQuIFdlJ2xsIGluY2x1ZGUgdGhpcyBpbiB0aGUgbmV4dCByZXZpc2lv bi4gDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIEJyaWFuISANCg0KTWljaGFlbA0KDQoNCj4g DQo+IEcvDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBF IENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDog MDYgQXVndXN0IDIwMTIgMTI6NTMNCj4gVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5kZXZl KQ0KPiBDYzogb3BzZWNAaWV0Zi5vcmc7IHY2b3BzIHY2b3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk7 IG9wc2VjLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7ICdkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9v bHMuaWV0Zi5vcmcnIChkcmFmdC1iZWhyaW5nZXItDQo+IGxsYS1vbmx5QHRvb2xzLmlldGYub3Jn KQ0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2IExMLW9ubHkgYXMgV0cgZG9jdW1lbnQgLSBm ZWVkYmFjayByZXF1ZXN0ZWQNCj4gDQo+IE9uIDA2LzA4LzIwMTIgMTE6MTgsIEd1bnRlciBWYW4g ZGUgVmVsZGUgKGd2YW5kZXZlKSB3cm90ZToNCj4gPiBJIGFtIGNvbmZ1c2VkLiBQbGVhc2UgY29y cmVjdCBteSB1bmRlcnN0YW5kaW5nIGlmIHBvc3NpYmxlLg0KPiA+DQo+ID4gMSkgWW91IGFyZSBv ayB3aXRoIHRoZSBCZWhyaW5nZXItTEwgZHJhZnQgYmVpbmcgYW4gaW5mb3JtYXRpb25hbA0KPiA+ IGRyYWZ0PyAobm90IEJDUCkNCj4gDQo+IFllcy4gQWxsIEknbSBzYXlpbmcgaXMgdGhhdCBpdCBz aG91bGQgaW5zaXN0IG9uIGEgdmFsaWQgc291cmNlIGFkZHJlc3MsIHdoaWNoDQo+IG1lYW5zIHRo YXQgYSBMTCBzb3VyY2UgYWRkcmVzcyBpcyBub3QgYWxsb3dlZCBmb3IgcGFja2V0cyB0aGF0IGxl YXZlIHRoZQ0KPiBsb2NhbCBsaW5rLg0KPiANCj4gU2VjdGlvbiAyLjUuNiBvZiBSRkMgNDI5MSBt YWtlcyB0aGlzIGNsZWFyIGJ1dCBwZW9wbGUgc2VlbSB0byBpZ25vcmUgaXQ6DQo+ICJMaW5rLUxv Y2FsIGFkZHJlc3NlcyBhcmUgZm9yIHVzZSBvbiBhIHNpbmdsZSBsaW5rLiINCj4gDQo+IE9idmlv dXNseSwgdGhlcmVmb3JlLCBwYWNrZXRzIHdob3NlIGRlc3RpbmF0aW9uIGlzIG5vdCBMTCBtdXN0 IG5vdCBoYXZlIGEgTEwNCj4gc291cmNlIGFkZHJlc3MuDQo+IA0KPiA+IDIpIFBhc3NpdmUgYWRk cmVzc2VzIGlzIHNvbWV0aGluZyB0aGF0IGNyZWF0ZXMgcG90ZW50aWFsIGlzc3VlcyBpbiB5b3Vy DQo+IHZpZXc/DQo+IA0KPiBJIHNhaWQgSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGF0LiBJdCBk b2Vzbid0IGFmZmVjdCB0aGUgYWJvdmUgcG9pbnQuDQo+IA0KPiAgICBCcmlhbg0KPiA+DQo+ID4g Rm9yICgyKSBJIHdvdWxkIHNheS4uLiBJdCBpcyBqdXN0IGFzIGEgbm9ybWFsIGFkZHJlc3MuLi4g bm8gbmVlZCBhdCBhbGwgdG8NCj4gZGlzY2FyZCB0aGVtIG9uIGFueSBvdGhlciBib3ggdGhlbiB0 aGUgcmVjZWl2aW5nIGJveCBhcyB0aG9zZSBib3hlcyBqdXN0DQo+IHNlZSB0aGUgYWRkcmVzcyBh cyBiZWluZyBhIG5vcm1hbCBJUHY2IGFkZHJlc3MuIE5vdGhpbmcgc3BlY2lhbCBhYm91dCBpdC4g SXQNCj4gaXMganVzdCBhIG5vcm1hbCBhZGRyZXNzLiBUaGUgYmVoYXZpb3VyIG9mIHBhc3NpdmUg YWRkcmVzc2VzIGlzIHRvIGRvIHdpdGgNCj4gdGhlIHdheSB0aGUgcmVjaXBpZW50IGRldmljZSBk ZWFscyB3aXRoIHRoaXMgYWRkcmVzcy4NCj4gPg0KPiA+IEcvDQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IDA2IEF1 Z3VzdCAyMDEyIDExOjQwDQo+ID4gVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5kZXZlKQ0K PiA+IENjOiBvcHNlY0BpZXRmLm9yZzsgdjZvcHMgdjZvcHMgV0cgKHY2b3BzQGlldGYub3JnKTsN Cj4gPiBvcHNlYy1jaGFpcnNAaWV0Zi5vcmc7ICdkcmFmdC1iZWhyaW5nZXItbGxhLW9ubHlAdG9v bHMuaWV0Zi5vcmcnDQo+ID4gKGRyYWZ0LWJlaHJpbmdlci1sbGEtb25seUB0b29scy5pZXRmLm9y ZykNCj4gPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2IExMLW9ubHkgYXMgV0cgZG9jdW1lbnQg LSBmZWVkYmFjayByZXF1ZXN0ZWQNCj4gPg0KPiA+IEhpIEd1bnRlciwNCj4gPg0KPiA+IEkgaGF2 ZSBubyBwcm9ibGVtIHdpdGggdGhlIHBhc3NpdmUgYWRkcmVzcyBpZGVhLCBidXQgdGhlIGltbWVk aWF0ZSBpc3N1ZQ0KPiBpcyB0aGF0IHJvdXRlcnMgbXVzdCBub3Qgc291cmNlIElDTVAgcGFja2V0 cyB0aGF0IG90aGVyIHJvdXRlcnMgbXVzdCBkaXNjYXJkDQo+IC0gaGVuY2Ugbm8gTEwgc291cmNl IGFkZHJlc3Nlcy4NCj4gPg0KPiA+ICAgICBCcmlhbg0KPiA+DQo+ID4gT24gMDYvMDgvMjAxMiAx MDozNiwgR3VudGVyIFZhbiBkZSBWZWxkZSAoZ3ZhbmRldmUpIHdyb3RlOg0KPiA+PiBBbnN3ZXIg YXMgaW5kaXZpZHVhbCBjb250cmlidXRvci4NCj4gPj4NCj4gPj4gRnJlZCBCLiBhbmQgbXlzZWxm IGRpZCBhIGRyYWZ0IHRvIGV4YWN0bHkgYWRkcmVzcyB0aGUgdHJhY2VhYmlsaXR5IG9mDQo+ID4+ IGludGVyZmFjZXMgd2l0aG91dCBpbmNyZWFzaW5nIHRoZSBhdHRhY2sgdmVjdG9yIG9uIGludGVy ZmFjZXM6DQo+ID4+IFBhc3NpdmUNCj4gPj4gSVB2NiBhZGRyZXNzZXMNCj4gPj4NCj4gPj4gTm8g bmV3IGNsYXNzIG9mIGFkZHJlc3NlcyBhdCBhbGwuLi4gbm8gbmV3IElBTkEgYWxsb2NhdGlvbi4u LiBqdXN0DQo+IGJlaGF2aW91ciBvZiB0aGUgYWRkcmVzczoNCj4gPj4NCj4gPj4gMSkgaXQgaXMg Y29uZmlndXJlZCBhcyBhIG5vcm1hbCBhZGRyZXNzDQo+ID4+IDIpIGp1c3QgYW4gZXh0cmEga2V5 d29yZCBhdHRhY2hlZCB0byB0aGUgYWRkcmVzcyBpZGVudGlmeWluZyBpdHMNCj4gPj4gYmVoYXZp b3INCj4gPj4gMykgSXQgY2FuIG9ubHkgYmUgdXNlZCBhcyBhICdzb3VyY2UnIGFkZHJlc3MNCj4g Pj4gNCkgaWYgaXQgaXMgdXNlZCBhcyBkZXN0aW5hdGlvbiBhZGRyZXNzLCB0aGVuIHdoZW4gcmVh Y2hpbmcgdGhlDQo+ID4+IHJvdXRlciBpdCB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZSBOdWxsMCBp bnRlcmZhY2UNCj4gPj4NCj4gPj4gVGhpcyB3aWxsIGhlbHAgdmlzaWJpbGl0eSBvZiB0aGUgdHJh Y2Utcm91dGUgaW4gY2FzZXMgb2YgTEwtb25seS4uLg0KPiA+Pg0KPiA+PiBHLw0KPiA+Pg0KPiA+ Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBCcmlhbiBFIENh cnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4gU2VudDog MDYgQXVndXN0IDIwMTIgMTE6MjUNCj4gPj4gVG86IEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5k ZXZlKQ0KPiA+PiBDYzogb3BzZWNAaWV0Zi5vcmc7IHY2b3BzIHY2b3BzIFdHICh2Nm9wc0BpZXRm Lm9yZyk7DQo+ID4+IG9wc2VjLWNoYWlyc0BpZXRmLm9yZzsgJ2RyYWZ0LWJlaHJpbmdlci1sbGEt b25seUB0b29scy5pZXRmLm9yZycNCj4gPj4gKGRyYWZ0LWJlaHJpbmdlci1sbGEtb25seUB0b29s cy5pZXRmLm9yZykNCj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSVB2NiBMTC1vbmx5IGFzIFdH IGRvY3VtZW50IC0gZmVlZGJhY2sgcmVxdWVzdGVkDQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+ Pj4gICAgbyAgTWFuYWdlbWVudCBwbGFuZSB0cmFmZmljLCBzdWNoIGFzIFNTSCwgVGVsbmV0LCBT Tk1QLCBJQ01QIGVjaG8NCj4gPj4+ICAgICAgIHJlcXVlc3QgLi4uIGNhbiBiZSBhZGRyZXNzZWQg dG8gbG9vcGJhY2sgYWRkcmVzc2VzIG9mIHJvdXRlcnMgd2l0aA0KPiA+Pj4gICAgICAgYSBnbG9i YWwgc2NvcGUgYWRkcmVzcy4gIFJvdXRlciBtYW5hZ2VtZW50IGNhbiBhbHNvIGJlIGRvbmUgb3Zl cg0KPiA+Pj4gICAgICAgb3V0LW9mLWJhbmQgY2hhbm5lbHMuDQo+ID4+Pg0KPiA+Pj4gICAgbyAg SUNNUCBlcnJvciBtZXNzYWdlIGNhbiBhbHNvIGJlIHNvdXJjZWQgZnJvbSB0aGUgZ2xvYmFsIHNj b3BlDQo+ID4+PiAgICAgICBsb29wYmFjayBhZGRyZXNzLg0KPiA+PiBUaGVzZSBzdGF0ZW1lbnRz IHNlZW0gdG9vIHdlYWsuIFVzaW5nIEdVQXMgZm9yIElDTVAgaW4gcGFydGljdWxhcg0KPiBuZWVk cyB0byBoYXZlIGEgbm9ybWF0aXZlIE1VU1Qgc29tZXdoZXJlIChwcmVmZXJhYmx5IGluIGEgQkNQ KS4gSW4gdGhlDQo+IGNvbnRleHQgb2YgdGhpcyBJbmZvcm1hdGlvbmFsIGRyYWZ0LCB0aGUgbGFu Z3VhZ2UgbmVlZHMgdG8gc3RhdGUgYQ0KPiByZXF1aXJlbWVudCAoIm11c3QiIG5vdCAiY2FuIikg ZXZlbiBpZiB5b3UgZG9uJ3QgdXNlIFJGQyAyMTE5IHRlcm1pbm9sb2d5Lg0KPiA+Pg0KPiA+PiBU aGlzIG1hdHRlcnMgYmVjYXVzZSBwYWNrZXRzIHdpdGggYSBMTCBzb3VyY2UgYWRkcmVzcyBNVVNU IE5PVCBiZQ0KPiBmb3J3YXJkZWQsIHNvIGEgcm91dGVyIHRoYXQgaXMgbWlzY29uZmlndXJlZCB0 byBzZW5kIElDTVAgcmVwbGllcyB3aXRoIGEgTEwNCj4gc291cmNlIGFkZHJlc3MgYnJlYWtzIGJv dGggcGluZyBhbmQgdHJhY2Vyb3V0ZS4NCj4gPj4NCj4gPj4gSSB0aGluayB0aGUgcnVsZSBpcyB0 aGF0IGFueSBwYWNrZXQgdGhhdCBpcyAqbm90KiBzZW50IHRvIGEgTEwgYWRkcmVzcyBtdXN0DQo+ IGhhdmUgYSBHVUEgYXMgdGhlIHNvdXJjZSBhZGRyZXNzLiBUaGF0IHRha2VzIGNhcmUgb2YgSUNN UCwgYW5kIGV2ZXJ5dGhpbmcNCj4gZWxzZSBhcyB3ZWxsLg0KPiA+Pg0KPiA+PiBGdXJ0aGVybW9y ZSwgdGhhdCBHVUEgbmVlZHMgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4IHRoYXQgYmVs b25ncw0KPiB0byB0aGUgb3JnYW5pc2F0aW9uIG9wZXJhdGluZyB0aGUgcm91dGVyIGluIHF1ZXN0 aW9uLiBPdGhlcndpc2UgdGhlDQo+IHRyYWNlcm91dGUgcmVzdWx0cyBjYW4gYmUgdmVyeSBjb25m dXNpbmcuIFdlIGRpc2N1c3NlZCB0aGF0IG9uIHY2b3BzIGJhY2sgaW4NCj4gTWFyY2guDQo+ID4+ DQo+ID4+IFJlZ2FyZHMNCj4gPj4gICAgQnJpYW4gQ2FycGVudGVyDQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IE9uIDA2LzA4LzIwMTIgMTA6MDMsIEd1bnRlciBWYW4gZGUgVmVsZGUgKGd2 YW5kZXZlKSB3cm90ZToNCj4gPj4+IChkaXN0cmlidXRlZCB0byBPUFNFQyBXRyBhbmQgaW4gY2Mg djZvcHMpDQo+ID4+Pg0KPiA+Pj4gRGVhciBhbGwsDQo+ID4+Pg0KPiA+Pj4gRHVyaW5nIHRoZSBP UFNFQyBXRyBtZWV0aW5nIGxhc3QgV2VkbmVzZGF5IHRoZXJlIHdhcyBjb25zZW5zdXMgdG8NCj4g YWRvcHQgdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlaHJpbmdl ci1sbGEtb25seS0wMSBhcw0KPiB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHdpdGggSW5mb3JtYXRp b25hbCBzdGF0dXMuDQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHJlYWQgdGhlIGRyYWZ0LCBhbmQgaWYg dGhlcmUgaXMgbm8gdmlvbGVudCBvYmplY3Rpb24gb24gdGhlIGxpc3QsIHRoZQ0KPiBkb2N1bWVu dCB3aWxsIGJlIHJlcXVlc3RlZCB0byBiZSBzdWJtaXR0ZWQgYXMgV0cgZG9jdW1lbnQgaW4gNyBk YXlzLg0KPiA+Pj4NCj4gPj4+IENpYW8sDQo+ID4+PiBHLywgS0sgJiBXYXJyZW4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiAtDQo+ID4+PiAtDQo+ID4+PiAt LQ0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4+IHY2b3BzQGlldGYub3JnDQo+ ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From philip_matthews@magma.ca Mon Aug 6 05:33:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6316321F8694 for ; Mon, 6 Aug 2012 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFQHMZib9klf for ; Mon, 6 Aug 2012 05:33:22 -0700 (PDT) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34321F8688 for ; Mon, 6 Aug 2012 05:33:22 -0700 (PDT) Received: from [74.198.165.15] (helo=[172.20.10.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SyMUq-0002qC-0E; Mon, 06 Aug 2012 08:33:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-758616653 From: Philip Matthews In-Reply-To: Date: Sat, 4 Aug 2012 23:40:36 -0400 Message-Id: References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> To: Cameron Byrne , Gert Doering , Alexandru Petrescu X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.15] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:33:23 -0000 --Apple-Mail-6-758616653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gert, Cameron, Alexandru: My main goal with the draft is to document the various pros and cons = behind the options. This allows someone to read the draft and make = his/her own decision on these questions, but make them in an informed = way.=20 Alexandru has given me some comments in favor of using LLAs for static = routes. Alexandru: If you could express this in a more definitive manner = that would be helpful. Gert and Cameron: In your networks, what made you decide to use = GUAs/ULAs as next hops? Was there some factor that I have not yet = captured? Did you give serious consideration to using LLAs? Using = GUAs/ULAs as the next-hop means that v6 redirects do not work -- are = redirects simply unimportant to you? - Philip On 2012-08-03, at 10:05 , Cameron Byrne wrote: >=20 > On Aug 3, 2012 6:52 AM, "Gert Doering" wrote: > > > > Hi, > > > > On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu wrote: > > > Sorry, one preference goes like this: _always_ use ll addresses as = next > > > hop of each static route. > > > > Well, that is *one* preference. > > > > Our preference is "always use GUA addresses as next-hop". > > > > People differ, and so do preferences. > > > +1 >=20 > We use ULA or GUA as next hop and never LLA >=20 > CB >=20 > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-6-758616653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Gert, = Cameron, Alexandru:

My main goal with the draft is to = document the various pros and cons behind the options. This allows = someone to read the draft and make his/her own decision on these = questions, but make them in an informed = way. 

Alexandru has given me some comments = in favor of using LLAs for static routes. Alexandru: If you could = express this in a more definitive manner that would be = helpful.

Gert and Cameron:  In your = networks, what made you decide to use GUAs/ULAs as next hops?  Was = there some factor that I have not yet captured? Did you give serious = consideration to using LLAs?  Using GUAs/ULAs as the next-hop means = that v6 redirects do not work -- are redirects simply unimportant to = you?

- = Philip


On = 2012-08-03, at 10:05 , Cameron Byrne wrote:


On Aug 3, 2012 6:52 AM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu = wrote:
> > Sorry, one preference goes like this: _always_ use ll = addresses as next
> > hop of each static route.
>
> Well, that is *one* preference.
>
> Our preference is "always use GUA addresses as next-hop".
>
> People differ, and so do preferences.
>
+1

We use ULA or GUA as  next hop and never = LLA

CB

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                 =        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14         =  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen               =     HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444           =  USt-IdNr.: DE813185279
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/= mailman/listinfo/v6ops


= --Apple-Mail-6-758616653-- From wwwrun@rfc-editor.org Mon Aug 6 07:29:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3FF21F85C9 for ; Mon, 6 Aug 2012 07:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPcwg5FfSHsA for ; Mon, 6 Aug 2012 07:29:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 48EF421F858F for ; Mon, 6 Aug 2012 07:29:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 81256B1E003; Mon, 6 Aug 2012 07:28:29 -0700 (PDT) To: gunter@cisco.com, cpopovic@cisco.com, tjc@ecs.soton.ac.uk, Olaf.Bonness@t-systems.com, HahnC@t-systems.com, rbonica@juniper.net, bclaise@cisco.com, fred.baker@cisco.com, joelja@bogus.com From: RFC Errata System Message-Id: <20120806142829.81256B1E003@rfc-editor.org> Date: Mon, 6 Aug 2012 07:28:29 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Aug 2012 07:38:05 -0700 Cc: v6ops@ietf.org, livio.zanol.puppim@gmail.com, rfc-editor@rfc-editor.org Subject: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 14:29:26 -0000 The following errata report has been submitted for RFC5375, "IPv6 Unicast Address Assignment Considerations". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309 -------------------------------------- Type: Technical Reported by: Lívio Zanol Pereira de Souza Puppim Section: B.2.2 Original Text ------------- B.2.2. /127 Addresses The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 [RFC3021], is not valid and should be strongly discouraged as documented in RFC 3627 [RFC3627]. Corrected Text -------------- B.2.2. /127 Addresses The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. Notes ----- Maybe just remove the section B.2.2? Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5375 (draft-ietf-v6ops-addcon-10) -------------------------------------- Title : IPv6 Unicast Address Assignment Considerations Publication Date : December 2008 Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From cb.list6@gmail.com Mon Aug 6 08:37:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2521F8518 for ; Mon, 6 Aug 2012 08:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8Lh+UWPljOk for ; Mon, 6 Aug 2012 08:37:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 608EC21F8517 for ; Mon, 6 Aug 2012 08:37:52 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so531195lbb.31 for ; Mon, 06 Aug 2012 08:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=19aEr9UmPzXnBsE3zFvPvJoIxgcJ0z6HCCqf3UHMGOs=; b=ymkzaH3R64SJfUvuWAnCN/6T74arj5bFKNqcIzis01M848YM1x1BZEms4qcwIuduxI DETiBUILpu7WutfWkN9R6p6vEUEa7AILqmrnbzIHjdvhD8+J0mVtmilFEDDGS2q+aMiH oKqqdzXZFLQFU8BSGnA7PLb4b0Jod5kERU6qVggzVI/3PyRa3Kw7Y20GP1PFKVovhB1M 6u2d85RODRF9KgvZjNj3Q9c1H4z/VWhKuGriOzAT39Vq7JdRdSLXfg5hYhHIHW3N9PiU iDlS8c1LT3xWRR5MNFwDgwevW2b574SZ104fIU+7KzHZHLY4c63zfBz+NxbBYwvS/xMO QBeQ== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr11145828lab.48.1344267471195; Mon, 06 Aug 2012 08:37:51 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Mon, 6 Aug 2012 08:37:51 -0700 (PDT) In-Reply-To: References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> Date: Mon, 6 Aug 2012 08:37:51 -0700 Message-ID: From: Cameron Byrne To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:37:53 -0000 On Sat, Aug 4, 2012 at 8:40 PM, Philip Matthews wrote: > Gert, Cameron, Alexandru: > > My main goal with the draft is to document the various pros and cons behind > the options. This allows someone to read the draft and make his/her own > decision on these questions, but make them in an informed way. > > Alexandru has given me some comments in favor of using LLAs for static > routes. Alexandru: If you could express this in a more definitive manner > that would be helpful. > > Gert and Cameron: In your networks, what made you decide to use GUAs/ULAs > as next hops? Was there some factor that I have not yet captured? Did you > give serious consideration to using LLAs? Using GUAs/ULAs as the next-hop > means that v6 redirects do not work -- are redirects simply unimportant to > you? > > - Philip > > We have an addressing scheme that is based on the physical locations, ULA allows us to express the physical location in the address, this may also be possible in LLA ... but not meaningful in troubleshooting since the packets cannot get off the link. We like to troubleshoot routing based on 1 or 2 hops away, (i can ping the local interface, but i can ping 1 router aways... somebody start looking at L3 issues ...) There is also the simplicity of using specifically assigned addresses, if i am on blah:blah::1 i may know the other side of the link, by my own convention, is blah:blah::2 without looking at a network map. In short, the above 3 help us have a common operational practice with IPv4. Common practices are good (i know ipv4 != ipv6). Here is something that is different between IPv4 and IPv4: LLA is always present by default and auto configured. Global scope addresses, like ULA show deliberate intention and configuration. Meaning, when there is a global scope address like ULA / GUA, then you know this link is supposed to be in service and somebody has decided we are going to send packets over it. LLA just means the card is on line. ICMP redirects make my router CPU go high, i generally turn them off. CB > On 2012-08-03, at 10:05 , Cameron Byrne wrote: > > > On Aug 3, 2012 6:52 AM, "Gert Doering" wrote: >> >> Hi, >> >> On Thu, Aug 02, 2012 at 02:05:10PM -0700, Alexandru Petrescu wrote: >> > Sorry, one preference goes like this: _always_ use ll addresses as next >> > hop of each static route. >> >> Well, that is *one* preference. >> >> Our preference is "always use GUA addresses as next-hop". >> >> People differ, and so do preferences. >> > +1 > > We use ULA or GUA as next hop and never LLA > > CB > >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From sthaug@nethelp.no Mon Aug 6 09:06:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264D521F8634 for ; Mon, 6 Aug 2012 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB8n8rwkYSf1 for ; Mon, 6 Aug 2012 09:06:54 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 16DEE21F863F for ; Mon, 6 Aug 2012 09:06:53 -0700 (PDT) Received: (qmail 13527 invoked from network); 6 Aug 2012 16:06:52 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Aug 2012 16:06:52 -0000 Date: Mon, 06 Aug 2012 18:06:52 +0200 (CEST) Message-Id: <20120806.180652.74741289.sthaug@nethelp.no> To: philip_matthews@magma.ca From: sthaug@nethelp.no In-Reply-To: References: <20120803135243.GU38127@Space.Net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:06:55 -0000 > Gert and Cameron: In your networks, what made you decide to use GUAs/ULAs as next hops? Was there some factor that I have not yet captured? Did you give serious consideration to using LLAs? Using GUAs/ULAs as the next-hop means that v6 redirects do not work -- are redirects simply unimportant to you? Not answering for anybody except myself - however, I agree with many of the points made by Cameron Byrne in his message of a few minutes ago, . We use GUAs (and in a few cases ULAs) for all manually configured next hops. We have considered LLAs a few times, and each time concluded that even if LLAs have some advantages, they are simply not worth the trouble. LLA next hops are fine when they are maintained by the router itself (e.g. IS-IS etc). However, we also like our IGP links to have GUAs, for ease of troubleshooting, predictability, similarity to IPv4 etc. IPv6 redirects are indeed unimportant. Steinar Haug, AS 2116 From gert@space.net Mon Aug 6 12:15:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D211E80E5 for ; Mon, 6 Aug 2012 12:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlU6eEBSKqmc for ; Mon, 6 Aug 2012 12:15:37 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 688CC11E80BA for ; Mon, 6 Aug 2012 12:15:36 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 644C7F8C79 for ; Mon, 6 Aug 2012 21:15:35 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 23F4AF8C60 for ; Mon, 6 Aug 2012 21:15:35 +0200 (CEST) Received: (qmail 90185 invoked by uid 1007); 6 Aug 2012 21:15:34 +0200 Date: Mon, 6 Aug 2012 21:15:34 +0200 From: Gert Doering To: Philip Matthews Message-ID: <20120806191534.GY38127@Space.Net> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XoO5jQFkz/fkcUT5" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:15:39 -0000 --XoO5jQFkz/fkcUT5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Aug 04, 2012 at 11:40:36PM -0400, Philip Matthews wrote: > Gert and Cameron: In your networks, what made you decide to use > GUAs/ULAs as next hops? Was there some factor that I have not yet > captured? Did you give serious consideration to using LLAs? Using > GUAs/ULAs as the next-hop means that v6 redirects do not work -- > are redirects simply unimportant to you? I see no advantage to using LLAs. =20 Besides having no advantage, they only complicate things due to=20 aspects like not having a reverse DNS entry (so I can't easily find=20 out "so which router should that route pointing to?" if things are=20 not working). We never point static routes to other routers *in* a network that has end systems - so redirects just do no thappen (if the packet gets send elsewhere, that's happening in backbone segments outside of the end system LAN). =20 End systems see a HSRP/VRRP default route, and send their packets there,=20 end of story (and redirects complicate trouble shooting at the end=20 systems, as you can never be sure where packets are going, depending=20 on the current expiry state of redirects, host implementation, etc). Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --XoO5jQFkz/fkcUT5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUCAX1qkuBuNlUUl1AQJ9egQAiig34wzmHH5latr+etCT/lSp3SmsgqeW K7tnltY2vtqDjMDforRpXQQlSKx6o04R9L8PvDGal6nG94b2VqQGv0bY6G8Km36W MjEOAkDY06bnsj/PJvceTDLWbHsmzzj6uvlLR5d/8ZGagGXzHhwea3aoID0Dlfj2 b8kqTAzNV+A= =3ibW -----END PGP SIGNATURE----- --XoO5jQFkz/fkcUT5-- From markzzzsmith@yahoo.com.au Mon Aug 6 14:32:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551A411E80EE for ; Mon, 6 Aug 2012 14:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQn3EKDI-f-n for ; Mon, 6 Aug 2012 14:32:52 -0700 (PDT) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by ietfa.amsl.com (Postfix) with SMTP id 74A0411E80ED for ; Mon, 6 Aug 2012 14:32:52 -0700 (PDT) Received: from [72.30.22.93] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 21:32:52 -0000 Received: from [98.139.91.47] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 21:32:52 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 21:32:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 345052.67361.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 12210 invoked by uid 60001); 6 Aug 2012 21:32:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344288771; bh=mwE+9GFiPfpv/dzXkYLPpgTiIC81t4qzGGa1zd7SYTY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aaQBiR3Tfj4BWyvuVO+gooZtIz37fmwnK6oumVoaaSv47XOJ0OQvu6tS99xp5zCD9NuX2TZrvQZgaumg+Vwz5MKAdGGd7P+M7yaOq/+RyjyuK6YwkDsIFNKu7a4MllD8VnB46I4PLFxbChNkVfAOon8mhwjXZjN6Xr357tRLzC4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=x1QDj/5a6DnZAkAS0Fw7/mM4ir8xQk+fdUhRyf7zat/AsQx8V9Jwrve57R6B5VBfpWBN45lZPiURRXISdtmOMOzKCY/nJ0wS56p6M8sQsy+Xh8PK0LaLM32oAsfuvMATC4L8ffiCWzx8Cbhzxg8lLgTPItSJUwyucYzfmrMCEzA=; X-YMail-OSG: uoQGrvgVM1nQWY5HjEEea69qUFDbRR0.zAq8p_YGhoH9Uf9 98_CKFlZ24FvEwY24J6x77hn.6st33RUYULEDduMlo7qoe57Cb9WtnmevMIR myKd0qYAXGt492tf4X6WptwaXCdTj7Ym1W3fNcWPEkM5.ng0anlZL5eGvZNk OWcKw.jC5NX4tQlGHojRpVDT47rpADQNVrlnV59Y4AbXGj9Ef2ZsslngLxHZ dgt4zYcm_foyFx04oDnwny5cykhxRXPiZSj3C2Y0dEaePz1dbmhO00lpj.sq tkGvOzgnzpcGt3uR9QqOKO9Ak7SEc_bvT2Uwxbx0jcR0oQw_iK7QFa753B.B td3QL6Ld7BfMvXrDMx3JJvkZd0ABlArNDqLlGg3WuCxhRGPr0Vp73b06IFFb lbcEHdR7V6J6R6MhzRBWK0ZUni5LWhnBG4per9Pqm0cLMLchGr9dYskqa4cK tblCT568dOqZa7rualLJEHVImDXjae_orVfmc0cYaItZAJO1KStYDsRIstz3 JYw-- Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 14:32:51 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> Message-ID: <1344288771.8445.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 14:32:51 -0700 (PDT) From: Mark ZZZ Smith To: Gert Doering , Philip Matthews In-Reply-To: <20120806191534.GY38127@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-981468583-172549112-1344288771=:8445" Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:32:53 -0000 ---981468583-172549112-1344288771=:8445 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=A0=0A=0AIt seems to me that this discussion is mostly and fundamenta= lly about increasing network robustness by reducing or eliminating external= dependencies.=0A=0AUsing LLs as next hops eliminates a dependency on ULA o= r GUA addressing, allowing the ULA or GUA addressing to be changed without = disrupting forwarding for prefixes that don't fall within the changing ULA/= GUAs. I believe this is why the designers of IPv6 chose LLs for next hops a= s the default. IPv6 has tried to make renumbering less onerous than IPv4. U= sing link local next hops avoids them having to be changed when the greater= scope than link local prefixes change.=0A=0AUsing (static) ULAs or GUAs as= next hops eliminates an external dependency on MAC addresses, which can ch= ange if interfaces are changed, when they're, by default, used as part of t= he LL address.=0A=0AThese are both very valid considerations. As the draft = in question mentions, static LL addressing would eliminate both of those ex= ternal dependencies.=0A=0AI think this draft is going to encounter a few is= sues such as this, where there is unlikely to be or will never be consensus= on one particular solution or option. I think it those cases it would be a= cceptable for the draft to try to fully expand both the pros and cons of ea= ch option.=0A=0AOSPF vs IS-IS is going to be another one.=0A=0A=0A----- Ori= ginal Message -----=0AFrom: Gert Doering =0ATo: Philip Matt= hews =0ACc: "v6ops@ietf.org list" =0ASent: Tuesday, 7 August 2012 5:15 AM=0ASubject: Re: [v6ops] about LLAs = pros/cons static routing - auto/self-configuration of addresses, draft-matt= hews-v6ops-design-guidelines=0A=0AHi,=0A=0AOn Sat, Aug 04, 2012 at 11:40:36= PM -0400, Philip Matthews wrote:=0A> Gert and Cameron:=A0 In your networks,= what made you decide to use=0A> GUAs/ULAs as next hops?=A0 Was there some = factor that I have not yet=0A> captured? Did you give serious consideration= to using LLAs?=A0 Using=0A> GUAs/ULAs as the next-hop means that v6 redire= cts do not work --=0A> are redirects simply unimportant to you?=0A=0AI see = no advantage to using LLAs.=A0 =0A=0ABesides having no advantage, they only= complicate things due to =0Aaspects like not having a reverse DNS entry (s= o I can't easily find =0Aout "so which router should that route pointing to= ?" if things are =0Anot working).=0A=0AWe never point static routes to othe= r routers *in* a network that=0Ahas end systems - so redirects just do no t= happen (if the packet gets=0Asend elsewhere, that's happening in backbone s= egments outside of the=0Aend system LAN).=A0 =0A=0AEnd systems see a HSRP/V= RRP default route, and send their packets there, =0Aend of story (and redir= ects complicate trouble shooting at the end =0Asystems, as you can never be= sure where=A0 packets are going, depending =0Aon the current expiry state = of redirects, host implementation, etc).=0A=0AGert Doering=0A=A0 =A0 =A0 = =A0 -- NetMaster=0A-- =0Ahave you enabled IPv6 on something today...?=0A=0A= SpaceNet AG=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vorstand: Sebast= ian v. Bomhard=0AJoseph-Dollinger-Bogen 14=A0 =A0 =A0 =A0 =A0 Aufsichtsrats= vors.: A. Grundner-Culemann=0AD-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 HRB: 136055 (AG Muenchen)=0ATel: +49 (89) 32356-444=A0 =A0 =A0 =A0= =A0 =A0 USt-IdNr.: DE813185279=0A=0A______________________________________= _________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/v6ops=0A ---981468583-172549112-1344288771=:8445 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 

It seems to me that this discu= ssion is mostly and fundamentally about increasing network robustness by re= ducing or eliminating external dependencies.

Using= LLs as next hops eliminates a dependency on ULA or GUA addressing, allowin= g the ULA or GUA addressing to be changed without disrupting forwarding for= prefixes that don't fall within the changing ULA/GUAs. I believe this is w= hy the designers of IPv6 chose LLs for next hops as the default. IPv6 has t= ried to make renumbering less onerous than IPv4. Using link local next hops= avoids them having to be changed when the greater scope than link local pr= efixes change.

Using (static) ULAs or GUAs as next= hops eliminates an external dependency on MAC addresses, which can change if interfaces are changed, when they're, by default, used as part o= f the LL address.

These are both very valid consid= erations. As the draft in question mentions, static LL addressing would eli= minate both of those external dependencies.

I thin= k this draft is going to encounter a few issues such as this, where there i= s unlikely to be or will never be consensus on one particular solution or o= ption. I think it those cases it would be acceptable for the draft to try t= o fully expand both the pros and cons of each option.

<= div>OSPF vs IS-IS is going to be another one.


=
----- Original Message -----
From: Gert Doering &= lt;gert@space.net>
To: Philip Matthews <philip_matthews@magma.ca&= gt;
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>
Sent: Tuesday,= 7 August 2012 5:15 AM
Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6op= s-design-guidelines

Hi,

On Sat, Aug 04, 2012 at 11:40:36PM -= 0400, Philip Matthews wrote:
> Gert and Cameron:  In your networ= ks, what made you decide to use
> GUAs/ULAs as next hops?  Was t= here some factor that I have not yet
> captured? Did you give serious= consideration to using LLAs?  Using
> GUAs/ULAs as the next-hop= means that v6 redirects do not work --
> are redirects simply unimpo= rtant to you?

I see no advantage to using LLAs. 

Beside= s having no advantage, they only complicate things due to
aspects like = not having a reverse DNS entry (so I can't easily find
out "so which ro= uter should that route pointing to?" if things are
not working).
We never point static routes to other routers *in* a network that
has e= nd systems - so redirects just do no thappen (if the packet gets
send elsewhere, that's happening in backbone segments outside of t= he
end system LAN). 

End systems see a HSRP/VRRP default ro= ute, and send their packets there,
end of story (and redirects complica= te trouble shooting at the end
systems, as you can never be sure where&= nbsp; packets are going, depending
on the current expiry state of redir= ects, host implementation, etc).

Gert Doering
     = ;   -- NetMaster
--
have you enabled IPv6 on something today...= ?

SpaceNet AG               =         Vorstand: Sebastian v. Bomhard
Joseph-Dolli= nger-Bogen 14          Aufsichtsratsvors.: A. Grun= dner-Culemann
D-80807 Muenchen            =       HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444&= nbsp;           USt-IdNr.: DE813185279

_______________________________________________
v6op= s mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops=
---981468583-172549112-1344288771=:8445-- From victor.kuarsingh@gmail.com Mon Aug 6 18:51:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5021E8043 for ; Mon, 6 Aug 2012 18:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsiQy6EILQQK for ; Mon, 6 Aug 2012 18:51:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D91D21E803F for ; Mon, 6 Aug 2012 18:51:23 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3487796ggn.31 for ; Mon, 06 Aug 2012 18:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=LR0sFmXX+EfeOk01UOBbp0XIbWjJ1SAi2oanPPf8JZ8=; b=IlAt04qb1ldxuGibeMU59HTJ1G2tIgJBPJlMS6SwVdBtRuUwwcPAmqXajQPI8IqyKG U+QHXuxFhrH4z1iH5oiTOgYJ/80Vpb1gYBfCqkN5hZkTPfOcoNazQXVJeMiAGhR5VO0k rsV13dA0rf5h8JrZRYX9AFDc1N2omrtOQjbOUnumM0ECHc2VNdTr042CR+TbcmzGVAX7 MyAglodnhyOX20RPwA6Nh0R7XT6bk6D/9gWnc20SlZZS1oJzqh1wRYSv3e1xspeWUwmd AmFaNzltdcEo5x+qu1qRlVK7XYrmFSagwSpF9/EpZAn8Jye3gbYtzKqVbaxkq1aZEhps jJtg== Received: by 10.66.75.225 with SMTP id f1mr22296488paw.35.1344304282356; Mon, 06 Aug 2012 18:51:22 -0700 (PDT) Received: from [172.20.10.86] ([12.1.203.3]) by mx.google.com with ESMTPS id qd10sm10054334pbb.38.2012.08.06.18.51.18 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 18:51:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 06 Aug 2012 18:51:14 -0400 From: Victor Kuarsingh To: "Fred Baker (fred)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-icp-guidance WGLC In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:51:24 -0000 Brian/Sheng, Overall, this came out quite good. Did a full read over, and only had one comment/suggestions. In section 5.3 [DNS] , you made good note of some devices such as XP which may only use IPv4 connectivity for DNS with query capability for A and AAAA. Would it be advisable to also add the reverse case were an IPv6-only addressed (or DNSv6 address supplied) host can make queries for A records? (perhaps this detail is not important and the existing point gets the thought across). Other then that trivial item, looks good. Support Regards, Victor K On 12-08-06 1:29 AM, "Fred Baker (fred)" wrote: >perception From cb.list6@gmail.com Mon Aug 6 20:59:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FC521F86B9 for ; Mon, 6 Aug 2012 20:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuzY3pXuDLLE for ; Mon, 6 Aug 2012 20:59:04 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1B4C21F86B5 for ; Mon, 6 Aug 2012 20:59:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so2020285lah.31 for ; Mon, 06 Aug 2012 20:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RD2H3Sd2uStmTL2qpYYQvgQq3SxzDJ6o3wyIzRC9v/8=; b=gwSZlMNQnzpU2A+nkK2iJTEDmusc7HJUBmIhyEtuWXsOvKvFT6+er6hY9uBLO9Lfbj c8ubCf3GS28WWuQuxZ2x8VnaKMBYLLTxzJUyeT97QPI8MWUmWLJtYtgC9asAVTRgBRra EedjmeIF+29DIypYDMKi+FpXsk+SPM9fjVc3dM30oMUKmqa9KhBHNOPoDlau8ALjSEaq ALNPC4Is9Z1HzoaGeom8Wc0zzrr5bjgnpLANcDX8q/CBIJnCzL+sKA0Yx5y6GLlJxLxq 2eFEpHUU1bpB4/EJfEl7YNAuvUaENS1ICq49rW0RyTn2+vZZZscyVNMtXfeoGMvlCf4+ nRbw== MIME-Version: 1.0 Received: by 10.112.84.39 with SMTP id v7mr5676765lby.15.1344311942705; Mon, 06 Aug 2012 20:59:02 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Mon, 6 Aug 2012 20:59:02 -0700 (PDT) In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Date: Mon, 6 Aug 2012 20:59:02 -0700 Message-ID: From: Cameron Byrne To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 03:59:08 -0000 On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) wrote: > This is to open a two week Working Group last Call on > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance > "IPv6 Guidance for Internet Content and Application Service Providers", > Brian Carpenter, Sheng Jiang, 10-Jul-12 > > Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. Useful. Support. Few technical comments here, few editorial comments sent direct to authors Does this exist in the "real world" ? "An ICP that has multiple connections via multiple ISPs will have multiple PA prefixes. This results in multiple PA-based addresses for the servers, or for load balancers if they are in use." It seems like NPTv6 is a much more modern approach that is much more likely to be deployed ... or some method involving the load balancers doing a proxy / load balancing function for the new and legacy prefix. It would also be good to reference RA Guard (rfc 6105), ND Cache issues (RFC6583), p2p /127 (RFC 6164) It might also be prudent to mention that proxies are commonly implemented in load balancers. Nearly all load balancers i know of have an Ipv6 to ipv4 proxy function (including Amazon ELB) 12. Operations and Management -- might be worth noting that many large entities have not fully made IPv6 work just like IPv4 in OAM... and in many cases, some hashing or aliasing is used to represnt the 128 bit IPv6 address into the legacy IPv4 data base field. This is not what people should do, but this is what many "IPv6 leaders" have done to make IPv6 work without boiling the ocean in terms of project costs and timelines. From internet-drafts@ietf.org Mon Aug 6 21:35:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1021F855D; Mon, 6 Aug 2012 21:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX5Z066VH9jJ; Mon, 6 Aug 2012 21:35:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343AE21F855E; Mon, 6 Aug 2012 21:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Date: Mon, 06 Aug 2012 21:35:32 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 04:35:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-06.txt Pages : 19 Date : 2012-08-06 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kawashimam@vx.jp.nec.com Mon Aug 6 21:39:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3DD11E8087 for ; Mon, 6 Aug 2012 21:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=1.320, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxpc7QZGwjg1 for ; Mon, 6 Aug 2012 21:39:43 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E821F855D for ; Mon, 6 Aug 2012 21:39:42 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q774dYjh028409; Tue, 7 Aug 2012 13:39:34 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q774dYr10950; Tue, 7 Aug 2012 13:39:34 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q774dYGi004529; Tue, 7 Aug 2012 13:39:34 +0900 (JST) Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-812197; Tue, 7 Aug 2012 13:39:08 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Tue, 7 Aug 2012 13:39:08 +0900 To: fred@cisco.com, joelja@bogus.com, v6ops-chairs@tools.ietf.org In-reply-to: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Message-Id: <20120807133908kawashimam@mail.jp.nec.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 7 Aug 2012 13:39:07 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 04:39:45 -0000 v6ops chairs, We have published draft-ietf-v6ops-464xlat-06. This draft is simply adding section 2 "BCP Scenario". Could you please start WGLC? Thank you for your time and consideration. Regards, Masanobu > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-06.txt > Pages : 19 > Date : 2012-08-06 > >Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-06 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From fred@cisco.com Mon Aug 6 22:53:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8221F86D4 for ; Mon, 6 Aug 2012 22:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMZTyzzxFEzH for ; Mon, 6 Aug 2012 22:53:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D200721F86CB for ; Mon, 6 Aug 2012 22:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3317; q=dns/txt; s=iport; t=1344318824; x=1345528424; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yMPr691g9kUkZ04e5X5OR/kfPYT17n29D6xpcn2oUE8=; b=Ubio47dzFkrrPHk7v6yHKnBrT016WLE3Rvz0Dfqu8m/F7uK6mOZw2IO+ lGQdRIJr1f4K5mhUqAKF7MJFeXpwpaFaXU2Dz4i+blMd3l0yEcojvXVOP NRAAS74P3aPzu5arF9dYjauK8WPNzQC3QUgZaFX6iRi9zYypkNrd7iBJC Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEmsIFCtJV2a/2dsb2JhbABFuVKBB4IgAQEBAwEBAQEPAVsLEAIBCBI0JwsXDgIEDgUJBRSHZQYLmxugO4tKFIV5YAOOWYEghVCBFI0SgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,725,1336348800"; d="asc'?scan'208";a="109029077" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 07 Aug 2012 05:53:43 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q775rhp6000366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 05:53:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 00:53:43 -0500 From: "Fred Baker (fred)" To: Masanobu Kawashima Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdGD/7mEGCfqV10aOJ87SeZyR4g== Date: Tue, 7 Aug 2012 05:53:42 +0000 Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> In-Reply-To: <20120807133908kawashimam@mail.jp.nec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.218] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004 x-tm-as-result: No--44.527900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_0D5D5E2B-76A0-4FF1-8A51-A114A96295C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 05:53:45 -0000 --Apple-Mail=_0D5D5E2B-76A0-4FF1-8A51-A114A96295C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'll let the current WGLC run and then open one for 464XLAT. On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >=20 > v6ops chairs, >=20 > We have published draft-ietf-v6ops-464xlat-06. > This draft is simply adding section 2 "BCP Scenario". > Could you please start WGLC? >=20 > Thank you for your time and consideration. >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >>=20 >> Title : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-06.txt >> Pages : 19 >> Date : 2012-08-06 >>=20 >> Abstract: >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in = the >> core and stateless protocol translation RFC 6145 at the edge. = 464XLAT >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-06 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_0D5D5E2B-76A0-4FF1-8A51-A114A96295C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQIK1kbjEdbHIsm0MRAvstAKD0QN2rW7ZKMwXO/7NQjkVjd2315wCcCqF6 3RmoH04o0z8A3uhpfvE5UMY= =z/fx -----END PGP SIGNATURE----- --Apple-Mail=_0D5D5E2B-76A0-4FF1-8A51-A114A96295C6-- From liushucheng@huawei.com Mon Aug 6 23:36:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6721F8644 for ; Mon, 6 Aug 2012 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LReHTlRsslJl for ; Mon, 6 Aug 2012 23:36:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D302021F858F for ; Mon, 6 Aug 2012 23:36:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIO87153; Mon, 06 Aug 2012 22:36:01 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 6 Aug 2012 23:33:04 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 6 Aug 2012 23:33:07 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 14:33:01 +0800 From: "Will Liu (Shucheng)" To: "fred@cisco.com" , "wesley.george@twcable.com" , "lorenzo@google.com" Thread-Topic: Answers to the on-site questions for draft-zhang-v6ops-ipv6oa-iwf-00.txt Thread-Index: AQHNdGZ9wrnDDKCo4U6J8Agv5K/xKA== Date: Tue, 7 Aug 2012 06:33:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , =?gb2312?B?s8LW2buq?= <18918588897@189.cn> Subject: [v6ops] Answers to the on-site questions for draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 06:36:03 -0000 SGksDQoNCkkgYW0gc2VuZGluZyB0aGUgYW5zd2VycyB0byB0aG9zZSBxdWVzdGlvbnMgSSBkaWRu J3QgYW5zd2VyZWQgZHVyaW5nIG15IHByZXNlbnRhdGlvbiBvZiBkcmFmdC16aGFuZy12Nm9wcy1p cHY2b2EtaXdmLTAwLnR4dC4gUGxlYXNlIHNlZSBiZWxvdy4NCg0KWzE3OjI5OjA0XSA8am9lbCBq YWVnZ2xpPiBmcmVkIC0gcXVlc3Rpb24gLSBpbnRlcm5ldCBhcmNoaXRlY3R1cmVsIGhhcyBhIGRl ZmluZWQgaW50ZXJuZXR3b3JraW5nIGZ1bmN0aW9uIC0gd2hpY2ggeW91IGRpZG4ndCB1c2UuDQpB OiBGcmVkLCBJIGFtIHJlYWxseSBzb3JyeSBJIGFtIG5vdCBzdXJlIHdoaWNoIGludGVybmV0d29y a2luZyBmdW5jdGlvbiB5b3Ugd2VyZSByZWZlcmluZyB0by4gQ291bGQgeW91IHBsZWFzZSByZXBs eSB3aXRoIHRoZSBzcGVjaWZpYyBvbmU/IFRoYW5rcy4NCg0KWzE3OjI5OjQzXSA8am9lbCBqYWVn Z2xpPiB3ZXMgZ2VvcmdlIC0gd2hlcmUgZGlkIHlvdSBmaW5kIGEgc2xhbSB0aGF0IGRvZXMgYXRt IGJ1dCBzcGVha3MgaXB2Ng0KQTogSSBzYWlkICJ0aGUgc2NlbmFyaW8gaGVyZSBpcyBjb21lIGZy b20gZnJvbSBjaGluYSB0ZWxlY29tIiBhdCB0aGUgbWVldGluZy4NCg0KWzE3OjMxOjI2XSA8am9l bCBqYWVnZ2xpPiBsb3JlbnpvIC0gYSBsYXJnZSBudW1iZXIgb2YgdGhlc2UgZGV2aWNlcyBhcmUg ZG9pbmcgaXBvZSB3aGljaCBkb2Vzbid0IHN1cHBvcnQgdjYuIEkgdGhpbmsgeW91IG1pZ2h0IGJl IHdpbGxpbmcgdG8gcmVwbGFjZSB0aGUgYm5nIGFuZCBkbyB5b3Ugd2FudC4NCkE6IElXRiBvbiBC TkcgaXMgYSBhbHRlcm5hdGl2ZSBzb2x1dGlvbiwgd2hpY2ggd2UgbWlnaHQgdGhpbmsgYWJvdXQg dG8gYWRkIGludG8gb3VyIGRyYWZ0LiBIb3dldmVyLCB0aGUgc2NlbmFyaW8gaGVyZSBpcyBsaWtl IHRoaXMsICJDUEUtLSgxKS0tQU4tLSgyKS0tQk5HIi4gTmV0d29yayAoMikgaXMgZXRoZXJuZXQg YmFzZWQgaXB2NiBuZXR3b3JrIGluIGN1cnJlbnQgZGVwbG95bWVudC4gVGhhdCdzIHdoeSB3ZSBh cmUgc3VnZ2VzdGluZyB0byBkbyB0aGlzIG9uIEFOLiANCg0KUmVnYXJkcywNCldpbGwNCg== From tore.anderson@redpill-linpro.com Tue Aug 7 00:32:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA411E809C for ; Tue, 7 Aug 2012 00:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il2Rg3ARE9rM for ; Tue, 7 Aug 2012 00:32:31 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 446AD11E8087 for ; Tue, 7 Aug 2012 00:32:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 2F2B4182000F; Tue, 7 Aug 2012 09:32:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1KEtLvQQeVM; Tue, 7 Aug 2012 09:32:29 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 98262182000C; Tue, 7 Aug 2012 09:32:29 +0200 (CEST) Message-ID: <5020C48D.6040507@redpill-linpro.com> Date: Tue, 07 Aug 2012 09:32:29 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 07:32:33 -0000 * Fred Baker (fred) > This is to open a two week Working Group last Call on > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6 > Guidance for Internet Content and Application Service Providers", > Brian Carpenter, Sheng Jiang, 10-Jul-12 > > Please read it now. We are interested in, among other things, > technical commentary on the draft and the working group's perception > on its usefulness to its target audience. Support. One comment, regarding section 5.2: «It is worth noting that whereas OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the advantage of handling them both in a single instance of the protocol». I am under the impression that OSPFv3 also has this advantage (cf. RFC 5838: «Support of Address Families in OSPFv3»). I haven't yet played with this functionality myself, though. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From brian.e.carpenter@gmail.com Tue Aug 7 02:17:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDD221F85C4 for ; Tue, 7 Aug 2012 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.107 X-Spam-Level: X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuBsAEWWfdFE for ; Tue, 7 Aug 2012 02:17:16 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 651A021F8463 for ; Tue, 7 Aug 2012 02:17:16 -0700 (PDT) Received: by eekb45 with SMTP id b45so1032937eek.31 for ; Tue, 07 Aug 2012 02:17: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=JttN3vQqngwo16sXrS+jFT/mrtwPCrviz4GzHf9avec=; b=LYk6Ol16aXAAwDMxRhAsnLpLlCU5nMGG+iIgMrAOJqfTsWOrAOF6nS7KVyp7g1vQse Mizz5JEgHpUcSsCaMz/G1t4rr/7lEab6Yt80I4DD4U5SwXDst3M5POZ2yeAo2aIYfD7p eWsfwvJpjET2gAxy/9etn4xQtHxvsuY3EjfT9ZHw+eWDpIzdrnzjVSLNOwmIH/NCJ9G6 IPsCo1nhaoG+FZF5gnUhGhdb9IGS8AYfuRbVmh+sJSKKRWtYJV6f4yPZz6LLiycmM1Ai uweIhaLCKvekQJC6Jybpanmx7tpSLCHUQq00E2BlS3X3P+Jj8+IFNZtdSsBne1a/3stW Wdxg== Received: by 10.14.207.9 with SMTP id m9mr16755391eeo.5.1344331035512; Tue, 07 Aug 2012 02:17:15 -0700 (PDT) Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id e7sm18254717eep.2.2012.08.07.02.17.13 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 02:17:14 -0700 (PDT) Message-ID: <5020DD1B.3010702@gmail.com> Date: Tue, 07 Aug 2012 10:17:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:17:17 -0000 On 06/08/2012 23:51, Victor Kuarsingh wrote: > Brian/Sheng, > > Overall, this came out quite good. Did a full read over, and only had one > comment/suggestions. > > In section 5.3 [DNS] , you made good note of some devices such as XP which > may only use IPv4 connectivity for DNS with query capability for A and > AAAA. > > Would it be advisable to also add the reverse case were an IPv6-only > addressed (or DNSv6 address supplied) host can make queries for A records? > (perhaps this detail is not important and the existing point gets the > thought across). Isn't that case going to be tied intimately to techniques such as DNS64, because the A record is of no immediate use to an IPv6-only node? A dual stack node provisioned only with a v6-accessible DNS server is certainly a theoretical possibility, but is it likely? I agree we could mention the point. Thanks Brian > > Other then that trivial item, looks good. > > Support > > Regards, > > Victor K > > > > On 12-08-06 1:29 AM, "Fred Baker (fred)" wrote: > >> perception > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From brian.e.carpenter@gmail.com Tue Aug 7 02:24:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626821F8621 for ; Tue, 7 Aug 2012 02:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.396 X-Spam-Level: X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcZfIetoccrI for ; Tue, 7 Aug 2012 02:24:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D748D21F85EF for ; Tue, 7 Aug 2012 02:24:16 -0700 (PDT) Received: by eaai11 with SMTP id i11so1036154eaa.31 for ; Tue, 07 Aug 2012 02:24: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=mjJhzuuwuXOyCwK3jT/RnTp17p33jnrW+P85fjZtVOc=; b=C+pRS2sglPJusaajOgbaeAQLPCo3RyKmIFsJW3NKez3DUse6zcgPUhvynHlOdeWpD4 cX5SdluNzsGQu/uu0le1N2zGUQDjAmRON41Mj1UHBEyvCzkCLBILGDm0aM6rdMHWbq0X HP6Gu24kFG+Kq70QG5i7WPwUmULbHCnqeyo1JggyO+vm4TBdqwrdXU1mnamwMyi+qcJV KKnfLgYM1+zbpaBEe+EA3CQijxAzIUBQWT7cuyPQjOsqgLzXrSCHJ+pTSDNgmcB/QFTw FU1evRCckOyg8ODS92avKJeYXqBR3nbk3veqqf8mIRK4us+ArMaHUQg7Xa3RYGM5INeW gN4w== Received: by 10.14.175.7 with SMTP id y7mr16671666eel.29.1344331455677; Tue, 07 Aug 2012 02:24:15 -0700 (PDT) Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id h2sm11548284eeo.3.2012.08.07.02.24.13 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 02:24:14 -0700 (PDT) Message-ID: <5020DEC0.1090601@gmail.com> Date: Tue, 07 Aug 2012 10:24:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:24:18 -0000 On 07/08/2012 04:59, Cameron Byrne wrote: > On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) wrote: >> This is to open a two week Working Group last Call on >> >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >> "IPv6 Guidance for Internet Content and Application Service Providers", >> Brian Carpenter, Sheng Jiang, 10-Jul-12 >> >> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. > > Useful. > > Support. > > Few technical comments here, few editorial comments sent direct to authors > > Does this exist in the "real world" ? > > "An ICP that has multiple connections via multiple ISPs will have > multiple PA prefixes. This results in multiple PA-based addresses > for the servers, or for load balancers if they are in use." I know that there are instances of this, and it is certainly supposed to work. Numerically, it's probably not important today, because early-adopter ICPs are big enough to request a PI prefix. > > It seems like NPTv6 is a much more modern approach that is much more > likely to be deployed ... For content providers??? > or some method involving the load balancers > doing a proxy / load balancing function for the new and legacy prefix. That could be, but do we have any current practice to describe? > > It would also be good to reference RA Guard (rfc 6105), ND Cache > issues (RFC6583), p2p /127 (RFC 6164) Yes > > It might also be prudent to mention that proxies are commonly > implemented in load balancers. Nearly all load balancers i know of > have an Ipv6 to ipv4 proxy function (including Amazon ELB) Yes, if you are doing that sort of LB. There are other approaches, but that's a whole other topic. > > 12. Operations and Management -- might be worth noting that many > large entities have not fully made IPv6 work just like IPv4 in OAM... > and in many cases, some hashing or aliasing is used to represnt the > 128 bit IPv6 address into the legacy IPv4 data base field. This is > not what people should do, but this is what many "IPv6 leaders" have > done to make IPv6 work without boiling the ocean in terms of project > costs and timelines. Oh yuck! If we mention this, surely it should be in a negative way? Thanks Brian From markzzzsmith@yahoo.com.au Tue Aug 7 02:25:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B321F863B for ; Tue, 7 Aug 2012 02:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EVH89WHXTF6 for ; Tue, 7 Aug 2012 02:25:03 -0700 (PDT) Received: from nm5-vm3.bullet.mail.ne1.yahoo.com (nm5-vm3.bullet.mail.ne1.yahoo.com [98.138.91.135]) by ietfa.amsl.com (Postfix) with SMTP id BF5AC21F8634 for ; Tue, 7 Aug 2012 02:25:02 -0700 (PDT) Received: from [98.138.90.53] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2012 09:24:59 -0000 Received: from [98.138.89.193] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2012 09:24:59 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 07 Aug 2012 09:24:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35830.69264.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 73856 invoked by uid 60001); 7 Aug 2012 09:24:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344331498; bh=9r0w8hFB9aiVEYFh4nAJ8zAbmJr8HYzQqE1jz0HMSxY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xvoszqJwGMAZrotQQQJdmwvBSF+7ZS88Ncr47pg+xc6gdWiPwXWV5adyJy+hy/R48hyJ5ipN5mwkaoxj9OvpJ/Hlg/zq0aQ5asSaQofC6sZoIqwMEs7MCREazwSkriUI5JSswss6iL80Tk/JAPEevOlS86ZTzu0tP7uLXhIG/pw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hzxqi2AtbXFYllwmmmFAcyG0W/WqxgHQcI+hZ2NcFfNTNRGMfpANE5e5Bm84/g1AMAXvNvO37PaizqXeKKQ2mPmxtErRZltys4S6Tq47cebodiOIboe96FXt+j8ljN2VeKSVX6DAgu70tJB6dRfxIfFeSpbdJiT1awsviPikM6Y=; X-YMail-OSG: hCja.QcVM1kPSsA_R7Skob.CkzvjEclb91xXDEgXubp8f8X A7dGAkzKLbcdP7WyLj7l0II9OKwcrLXkJHFNQ9qe1ZqOPwDO7vfCV7sD1U5A SpP7BN6lE_2a9ehxK58HX8EUE8EOi6lSRRJYYjnB7eCbXhvpq33rOMPh2R5V Dk_mXLw7igZxu3NN2V0rLzTGMkxHYZ1r2x9rYbWiFQAYScStIpWbMZxymJX6 ogrQqoB_CsPexWnh.dl1p_1SeR9abVqLa_KawTo4iDl54vvZywicdZSSS1hW 54HhcPk6xq7MEtapvvlaDi2N_Ts1CsRM.UtHfCHfOtWLxkoXibmcN_SmUSdc X253S6fpfL_G9o3rrrlwz_MFpqGoj4XgN.0uMBWL9NxFkjX8K8FcemXngDPh EdwVKxXILZW1UYy.wfAEi1yQdaFFEA_NWiTHt84g8oZJu11qOKzxJWafopcg L6vBhc0TE3J5wgSOW12BSyfYS2beVYbBm8uktypFXMgqULirMAvKZyNbzJc1 5y47BwXZzZ7iTltFZ6sAAq3E0v_5QikjtzR3KdsoXbRmzk1l7Xt3M9Lh5d5T ZxS58_W6C905eytrZsbKRejtHoeY3xG2uDDU- Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Tue, 07 Aug 2012 02:24:58 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Message-ID: <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> Date: Tue, 7 Aug 2012 02:24:58 -0700 (PDT) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , "v6ops@ietf.org" In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:25:03 -0000 Hi,=0A=0A>________________________________=0A> From: Fred Baker (fred) =0A>To: "v6ops@ietf.org" =0A>Cc: V6ops Chairs = ; Ron Bonica =0A>Sent: Monday= , 6 August 2012 3:29 PM=0A>Subject: [v6ops] draft-ietf-v6ops-icp-guidance W= GLC=0A> =0A>This is to open a two week Working Group last Call on =0A>=0A>h= ttp://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance=0A>=A0 "IPv6 G= uidance for Internet Content and Application Service Providers",=0A>=A0 Bri= an Carpenter, Sheng Jiang, 10-Jul-12=0A>=0A>Please read it now. We are inte= rested in, among other things, technical commentary on the draft and the wo= rking group's perception on its usefulness to its target audience.=0A>_=0A= =0AHaving reviewed it recently and reviewed the results of the changes I su= ggested, I think it is fine as it is and should be published.=0A=0AAs for u= sefulness to it's target audience, I think it will be very useful, as perha= ps it may have prevented the following ICP choosing to deploy an IPv6 only = production network and then completely misusing NAT64 to try to provide IPv= 4 and IPv6 client facing services.=0A=0A=0A"IPv6 is hard."=0A=0Ahttp://list= s.ausnog.net/pipermail/ausnog/2012-July/014038.html=0A=0A=0ARegards,=0AMark= . From brian.e.carpenter@gmail.com Tue Aug 7 02:31:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E5E21F8600 for ; Tue, 7 Aug 2012 02:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.414 X-Spam-Level: X-Spam-Status: No, score=-103.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66o9+UnrJY4N for ; Tue, 7 Aug 2012 02:31:54 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E321F85F9 for ; Tue, 7 Aug 2012 02:31:53 -0700 (PDT) Received: by eekb45 with SMTP id b45so1038727eek.31 for ; Tue, 07 Aug 2012 02:31:52 -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=R1YTcBA4Vm3Tc60v8ZUuHcRF/HcGauYnzjdOqnRycfs=; b=aorT5ZV9OB+zRz1G8nh+VZIASX3nrI701hLuY0+GNKE+tfuBAMZW+C5dDuZTrBFJg9 kvQur69eurdgjzBfZRmBAnBXDxnKAMTaZUpm7WhhsTVxf7zfblW9aib1Di6o++ZvWhnM nZXUJ2u+ljLQhg7FC2s1VHcE+NrvstRcnatxdgkCmhCN5ivX8E1AYmdtWkzZ26sKjuns BSZR5F6hduKpYCcqo+Wlnz9+F3z+gjVYLuLodd99HmTI/2ZREnaABg8Yj861QS8ZuW+p vsDVjRLRVnIqNO5BtD5LHmCIAQxl/3C6c4LJ6BvaBulOEDXhoMF7qRsMvwsSiNZ/jb5u DxwQ== Received: by 10.14.218.134 with SMTP id k6mr16946631eep.14.1344331912811; Tue, 07 Aug 2012 02:31:52 -0700 (PDT) Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id h2sm11604360eeo.3.2012.08.07.02.31.51 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 02:31:51 -0700 (PDT) Message-ID: <5020E089.30201@gmail.com> Date: Tue, 07 Aug 2012 10:31:53 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020C48D.6040507@redpill-linpro.com> In-Reply-To: <5020C48D.6040507@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:31:54 -0000 Tore, On 07/08/2012 08:32, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> This is to open a two week Working Group last Call on >> >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6 >> Guidance for Internet Content and Application Service Providers", >> Brian Carpenter, Sheng Jiang, 10-Jul-12 >> >> Please read it now. We are interested in, among other things, >> technical commentary on the draft and the working group's perception >> on its usefulness to its target audience. >=20 > Support. >=20 > One comment, regarding section 5.2: =C2=ABIt is worth noting that where= as > OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the > advantage of handling them both in a single instance of the protocol=C2= =BB. >=20 > I am under the impression that OSPFv3 also has this advantage (cf. RFC > 5838: =C2=ABSupport of Address Families in OSPFv3=C2=BB). I haven't yet= played > with this functionality myself, though. Good question. I have no idea, so I have sent a query to the cluenet list= =2E Thanks Brian >=20 > Best regards, From markzzzsmith@yahoo.com.au Tue Aug 7 02:40:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4D421F8672 for ; Tue, 7 Aug 2012 02:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRXgSusC2zEg for ; Tue, 7 Aug 2012 02:40:02 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ac4.yahoo.com (nm17-vm0.bullet.mail.ac4.yahoo.com [98.139.53.208]) by ietfa.amsl.com (Postfix) with SMTP id B5F9421F8671 for ; Tue, 7 Aug 2012 02:40:01 -0700 (PDT) Received: from [98.139.52.193] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 07 Aug 2012 09:39:58 -0000 Received: from [98.139.52.148] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 07 Aug 2012 09:39:58 -0000 Received: from [127.0.0.1] by omp1031.mail.ac4.yahoo.com with NNFMP; 07 Aug 2012 09:39:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 289148.82094.bm@omp1031.mail.ac4.yahoo.com Received: (qmail 94180 invoked by uid 60001); 7 Aug 2012 09:39:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344332397; bh=wIEPJkQfVVbYWaiwylPe8aQtrILCZKUS8xrY2l2M8Cg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NK3BC5OJqmuTEBghL7NooS74xnnpppyrmKzOkG9ZInKkdou0W3fTtrEJDVBQ9crKlP5KpmkkE4So1gmuvTtJFjS5olfrLaN3I2WZXhjz8wgQCKteLOnk59ipi+XyHi1A5AqZVBhTP8mOynCpIy8deW4ncDAC0l5S/Li1cY3/oZE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pTLwanBIwynmOgWWLwGpLwQD2lLlYc5td1WbGxUAulT3wezXIN2PW4OcJ+XN17whpEp+1lRbLvL9oKrxG4oTLLfaCUemSVlUCB0s9mDu6H+iAhmEfqlw3YzM6BRprPUkl7MTyyDMcSuKL+5HgidKoCg4iTuxtRYAPoQko4ei+RM=; X-YMail-OSG: 5DEvjfoVM1nnZCGpqFke10yYcgluVgC1eTEhyhl2Z.xeoVz VtycLUvv21kifSqo2uPY8t.KfPyRvKlBATfbYPzMUu373ycjgtuGTqu_gG2o rpk_Bn19zOW80tK_P6JQTZIlnALuwFFOdfNy_BuYf4nU7ZI32BbCvmQURPT8 z75FjRWurwxvb3oS0WCAr50CjKgtw2JHPpb2jt.TZYp.RXMG1MZvkjDayMvW 1vXTEJg_IN4P_JtxUOUBK3jmfyPDFTOshfrGlXB9EnI4_TUD4EgTEJZ4iLZ0 EfJx0XO4wSFuz.PdYJigEFiHiJBEmauUjpYLXPQV0gy_AbYHCtq71VRhjPGj csigMl68Mm2HTRWmaCpiuwFrAJ9ra8TZlYxEZjAlhtXAhrJO70dv0RbYriu9 JzsGD9F73sOzHYlckwGaLz5FCzEy6xeJp9ipNtd5pC7xBucHZ5HJCD7Jfwt1 B5DT1gUHrFO8KcQ6yYfhKIHyPkmp_KllSBKQnN6Bpb63aBw-- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Tue, 07 Aug 2012 02:39:57 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> Message-ID: <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Tue, 7 Aug 2012 02:39:57 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter , Cameron Byrne In-Reply-To: <5020DEC0.1090601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:40:03 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Cameron Byrne =0A> Cc: = "v6ops@ietf.org" ; V6ops Chairs ; Ron Bonica =0A> Sent: Tuesday, 7 August 2012 7:24 PM=0A= > Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC=0A> =0A> On 07/08= /2012 04:59, Cameron Byrne wrote:=0A>> On Sun, Aug 5, 2012 at 10:29 PM, Fr= ed Baker (fred) =0A> wrote:=0A>>> This is to open a two w= eek Working Group last Call on=0A>>> =0A>>> http://datatracker.ietf.org/do= c/draft-ietf-v6ops-icp-guidance=0A>>> =A0 "IPv6 Guidance for Internet Cont= ent and Application Service =0A> Providers",=0A>>> =A0 Brian Carpenter, Sh= eng Jiang, 10-Jul-12=0A>>> =0A<>=0A>> =0A>> It seems like NPTv6 is a much = more modern approach that is much more=0A>> likely to be deployed ... =0A>= =0A> For content providers???=0A> =0A=0A=0AWouldn't NPTv6's Experimental s= tatus mean it shouldn't really be suggested in an advisory document like th= is? If it was mentioned, then I think there'd have to be text discussing it= 's drawbacks in ICP scenarios e.g. the consequences of content hosts/applic= ations not knowing their own IPv6 identity, and discussion around NPTv6 in = a situation where the "cloud" application traffic is encrypted (I think thi= s is going to increase significantly with the rapid adoption of BYO devices= and Wifi offload).=0A=0ARegards,=0AMark. From ietfc@btconnect.com Tue Aug 7 02:59:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E948621F85C5; Tue, 7 Aug 2012 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N12TEdBoUsrv; Tue, 7 Aug 2012 02:59:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id D06D321F85DF; Tue, 7 Aug 2012 02:59:23 -0700 (PDT) Received: from mail112-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 09:59:22 +0000 Received: from mail112-db3 (localhost [127.0.0.1]) by mail112-db3-R.bigfish.com (Postfix) with ESMTP id 53CE8C031A; Tue, 7 Aug 2012 09:59:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I1be0I542Mzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail112-db3 (localhost.localdomain [127.0.0.1]) by mail112-db3 (MessageSwitch) id 1344333560458261_25474; Tue, 7 Aug 2012 09:59:20 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.231]) by mail112-db3.bigfish.com (Postfix) with ESMTP id 6DB5B1A00BB; Tue, 7 Aug 2012 09:59:20 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 09:59:19 +0000 Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 7 Aug 2012 09:59:19 +0000 Message-ID: <039d01cd7482$b1b65720$4001a8c0@gateway.2wire.net> From: t.petch To: "Gunter Van de Velde (gvandeve)" , References: <67832B1175062E48926BF3CB27C49B240674DA@xmb-aln-x12.cisco.com> Date: Tue, 7 Aug 2012 10:54:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-OriginatorOrg: btconnect.com Cc: draft-vyncke-opsec-v6@tools.ietf.org, v6ops@ietf.org, draft-jdurant-bgp-security-01@tools.ietf.org Subject: Re: [v6ops] IPv6 OPSEC drafts need review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:59:25 -0000 ----- Original Message ----- From: "Gunter Van de Velde (gvandeve)" To: Cc: ; ; Sent: Monday, August 06, 2012 9:51 AM Dear all, As mentioned during the OPSEC WG meeting, the following 2 drafts will in 3 weeks be considered for WG documents, after a call for feedback on the email list. During the WG meeting it became clear that not that many people read the documents until now. Please read drafts: 2) http://tools.ietf.org/html/draft-jdurand-bgp-security-01 Why OPSEC, when we have GROW or even IDR, neither of whom are copied on this e-mail? What do the chairs of those WGs say? Tom Petch On Monday 27th the chairs of OPSEC WG will ask the WG during a period of 7 days for feedback on these drafts to support or deny acceptance as WG documents. Kind Regards, G/, KK & Warren ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gert@space.net Tue Aug 7 05:11:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C358E21F859F for ; Tue, 7 Aug 2012 05:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngv9r-yRUdeT for ; Tue, 7 Aug 2012 05:11:22 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5630221F8593 for ; Tue, 7 Aug 2012 05:11:21 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A56CDF8CAE for ; Tue, 7 Aug 2012 14:11:16 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7D6D2F8CA1 for ; Tue, 7 Aug 2012 14:11:16 +0200 (CEST) Received: (qmail 5686 invoked by uid 1007); 7 Aug 2012 14:11:16 +0200 Date: Tue, 7 Aug 2012 14:11:16 +0200 From: Gert Doering To: Mark ZZZ Smith Message-ID: <20120807121116.GI38127@Space.Net> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 12:11:24 -0000 Hi, On Tue, Aug 07, 2012 at 02:24:58AM -0700, Mark ZZZ Smith wrote: > As for usefulness to it's target audience, I think it will be > very useful, as perhaps it may have prevented the following ICP > choosing to deploy an IPv6 only production network and then completely > misusing NAT64 to try to provide IPv4 and IPv6 client facing services. So how exactly would that be "misuse"? It's quite reasonable to run single-stack inside, and if you need lots of addresses, make that IPv6-only. The outside needs to be dual-stacked, and NAT64 (with preconfigured mappings) will do that for you, in a nice and stateless way. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From zveno.chen@gmail.com Tue Aug 7 05:51:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8194921F8589 for ; Tue, 7 Aug 2012 05:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+wRsNe0aM7W for ; Tue, 7 Aug 2012 05:51:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC4E621F853E for ; Tue, 7 Aug 2012 05:51:34 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5568178pbb.31 for ; Tue, 07 Aug 2012 05:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=OtQf076P3EU0+4MIcnbl9ix+PZf/tCtvrPFm2blWo1w=; b=JkoLwx9i2/MGcWCnRCIPFiATxG0YfwfEe/cmzKZcRyXuPpzzQUfpqnnO+OKVnvD+r6 AZTIbFvFvwR3CxKAUr2raXtuuNq55qMFI/vNd/+TB04ewXy0IlOYiHAc91bInrJlqska +X9S9I91jrb/LJjeFOY+RiWJhQfNjBefdEH/8ibQ4CunGu6D947Y9N2izVxefoJqd8YJ 8j2lUNiTp/dP22IaMMbv61YRWUZI20rDqX5QifDwvwu9GJVHwIuVk3wRWTQmdCD0RKmd Z5DCvRRGUrI7T5eN2Pvb/5zae51/BDm/fqKTuZhizxAfo7dHH9/4OZl8chD3Ff5bJiTE Ly4Q== Received: by 10.68.231.170 with SMTP id th10mr27590216pbc.104.1344343894517; Tue, 07 Aug 2012 05:51:34 -0700 (PDT) Received: from chenzhonghua-nb ([116.230.108.97]) by mx.google.com with ESMTPS id pe8sm7716334pbc.76.2012.08.07.05.51.30 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 05:51:34 -0700 (PDT) Date: Tue, 7 Aug 2012 20:51:36 +0800 From: "zveno.chen" To: "Will Liu (Shucheng)" , "fred@cisco.com" , "wesley.george" , "lorenzo" Message-ID: <201208072051330785547@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: v6ops Subject: [v6ops] senario of draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 12:57:54 -0000 HI, The senario of IPv6oA is exist in Chinatelecom network. In our IPV4 network some of our customers uses a service called ATM private-Line. In this service, user's CPE device connect to core network by IPoA (PVC/SVC) , and uses stable IP address. In the future, with the development of IPv6 ,these customer will hope to transfer their service to IPv6,but they donot want to use IP access network(maybe they donot want to change their network sharply). In this secanrio, we think IPv6oA will be a choice to solve the problem. And upgrade a IPv4 IWF to DS IWF may be economical -------------- ZhongHua Chen Chinatelecom 2012-08-07 From cb.list6@gmail.com Tue Aug 7 06:12:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C773621F8672 for ; Tue, 7 Aug 2012 06:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry-vBSQfLfiF for ; Tue, 7 Aug 2012 06:12:10 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E95421F8650 for ; Tue, 7 Aug 2012 06:12:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so2280024lah.31 for ; Tue, 07 Aug 2012 06:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Iu/VUYLOGjv5kR6fr6XOHwRk88RQwlNhjWj3MCY4p1Y=; b=C2nLKu0OavFKPnrX8aFH5k9DegMOKb2JJJcaCwk+/GRmXk3uqHeDXOgFtpqopUGYsM ZN+Wut8KfFp6Ux/ZukNWIMmC70NyQPgCaKvrz3zD2j3C+bo2kGQ/NivPDoZ113AihGpg jSWqgb3PUU+h5sQp0x4IPsutebKMITC6bmOSlhs9mQq1oPlkiF6xMOKaqAOtDd8Xg8j4 SmWjdqDuqh3NpGrKT63ZX99eKUZPrDFXUgFNzqWDxFYJVrgPyVqzpQqn2147yqqsDxRw PSMZDAvlKX/1adDvwtuVSI7ClTOImOJu/POV9X0ifk0C/cfrhswDLLywm6lEfeqi1uSz lBPA== MIME-Version: 1.0 Received: by 10.112.84.39 with SMTP id v7mr6370284lby.15.1344345128992; Tue, 07 Aug 2012 06:12:08 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 06:12:08 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 06:12:08 -0700 (PDT) In-Reply-To: <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Tue, 7 Aug 2012 06:12:08 -0700 Message-ID: From: Cameron Byrne To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=f46d04016d5dde831904c6acbd05 Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:12:11 -0000 --f46d04016d5dde831904c6acbd05 Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" wrote: > > Hi, > > > ----- Original Message ----- > > From: Brian E Carpenter > > To: Cameron Byrne > > Cc: "v6ops@ietf.org" ; V6ops Chairs < v6ops-chairs@tools.ietf.org>; Ron Bonica > > Sent: Tuesday, 7 August 2012 7:24 PM > > Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC > > > > On 07/08/2012 04:59, Cameron Byrne wrote: > >> On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) > > wrote: > >>> This is to open a two week Working Group last Call on > >>> > >>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance > >>> "IPv6 Guidance for Internet Content and Application Service > > Providers", > >>> Brian Carpenter, Sheng Jiang, 10-Jul-12 > >>> > <> > >> > >> It seems like NPTv6 is a much more modern approach that is much more > >> likely to be deployed ... > > > > For content providers??? > > > > > Wouldn't NPTv6's Experimental status mean it shouldn't really be suggested in an advisory document like this? If it was mentioned, then I think there'd have to be text discussing it's drawbacks in ICP scenarios e.g. the consequences of content hosts/applications not knowing their own IPv6 identity, and discussion around NPTv6 in a situation where the "cloud" application traffic is encrypted (I think this is going to increase significantly with the rapid adoption of BYO devices and Wifi offload). > > Regards, > Mark. NPTv6 is not really the focus of my comment. The focus was supposed to be using 2 prefixes for multihoming or migrating isps. I dont think anyone would do this today. Doing it, afaik, would be a science experiment and therefore should not be a recommended approach. I understand ipv6 was designed to work this way. .... But afaik, it is not really exercised. If someone has done it in a production network, that would be good to know CB --f46d04016d5dde831904c6acbd05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" <markzzzsmith@yahoo.com.au> wrote:
>
> Hi,
>
>
> ----- Original Message -----
> > From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > To: Cameron Byrne <cb.li= st6@gmail.com>
> > Cc: "v6ops@ietf.org&qu= ot; <v6ops@ietf.org>; V6ops Cha= irs <v6ops-chairs@tools.i= etf.org>; Ron Bonica <ron@bonic= a.org>
> > Sent: Tuesday, 7 August 2012 7:24 PM
> > Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC
> >
> > On 07/08/2012 04:59, Cameron Byrne wrote:
> >> =A0On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) <fred@cisco.com>
> > wrote:
> >>> =A0This is to open a two week Working Group last Call on<= br> > >>>
> >>> =A0http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-gu= idance
> >>> =A0 =A0"IPv6 Guidance for Internet Content and Appli= cation Service
> > Providers",
> >>> =A0 =A0Brian Carpenter, Sheng Jiang, 10-Jul-12
> >>>
> <>
> >>
> >> =A0It seems like NPTv6 is a much more modern approach that is= much more
> >> =A0likely to be deployed ...
> >
> > For content providers???
> >
>
>
> Wouldn't NPTv6's Experimental status mean it shouldn't rea= lly be suggested in an advisory document like this? If it was mentioned, th= en I think there'd have to be text discussing it's drawbacks in ICP= scenarios e.g. the consequences of content hosts/applications not knowing = their own IPv6 identity, and discussion around NPTv6 in a situation where t= he "cloud" application traffic is encrypted (I think this is goin= g to increase significantly with the rapid adoption of BYO devices and Wifi= offload).
>
> Regards,
> Mark.

NPTv6 is not really the focus of my comment. The focus was supposed to b= e using 2 prefixes for multihoming or migrating isps.

I dont think anyone would do this today. Doing it, afaik, would be a sci= ence experiment and therefore should not be a recommended approach. I under= stand ipv6 was designed to work this way. .... But afaik, it is not really = exercised.=A0 If someone has done it in a production network, that would be= good to know

CB

--f46d04016d5dde831904c6acbd05-- From roberta.maglione@telecomitalia.it Tue Aug 7 06:12:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FECE21F86C7 for ; Tue, 7 Aug 2012 06:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.656 X-Spam-Level: X-Spam-Status: No, score=0.656 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMVxJUr4NVCI for ; Tue, 7 Aug 2012 06:12:40 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE921F86CB for ; Tue, 7 Aug 2012 06:12:38 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 7 Aug 2012 15:12:32 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 7 Aug 2012 15:12:32 +0200 From: Maglione Roberta To: 'zveno.chen' , "Will Liu (Shucheng)" , "fred@cisco.com" , wesley.george , lorenzo Date: Tue, 7 Aug 2012 15:12:32 +0200 Thread-Topic: [v6ops] scenario of draft-zhang-v6ops-ipv6oa-iwf-00.txt Thread-Index: Ac10nFHNdLsaK3K9QnuWVAqQ3IBQMQAAPqsg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F135@GRFMBX704BA020.griffon.local> References: <201208072051330785547@gmail.com> In-Reply-To: <201208072051330785547@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops Subject: Re: [v6ops] scenario of draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:12:40 -0000 Hello, If I understand your draft correctly you are proposing a new interworkin= g function on the Access Node, so you are basically specifying new requirem= ents for the Access Node. Why are you discussing this topic in IETF? Isn't this Broadband Forum's ter= ritory? BBF is the SDO that specifies requirements for Access Node and if I= remember correctly this interworking function was discussed and finally no= t included in TR-177 some years. If you think this work is needed, for the scenario you described, I would s= uggest discussing this proposal in BBF first. Best Regards, Roberta -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of z= veno.chen Sent: marted=EC 7 agosto 2012 14.52 To: Will Liu (Shucheng); fred@cisco.com; wesley.george; lorenzo Cc: v6ops Subject: [v6ops] senario of draft-zhang-v6ops-ipv6oa-iwf-00.txt HI, The senario of IPv6oA is exist in Chinatelecom network. In our IPV4 net= work some of our customers uses a service called ATM private-Line. In this = service, user's CPE device connect to core network by IPoA (PVC/SVC) , and = uses stable IP address. In the future, with the development of IPv6 ,these = customer will hope to transfer their service to IPv6,but they donot want to= use IP access network(maybe they donot want to change their network sharpl= y). In this secanrio, we think IPv6oA will be a choice to solve the problem= . And upgrade a IPv4 IWF to DS IWF may be economical -------------- ZhongHua Chen Chinatelecom 2012-08-07 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From brian.e.carpenter@gmail.com Tue Aug 7 06:43:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC6721F867D for ; Tue, 7 Aug 2012 06:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.13 X-Spam-Level: X-Spam-Status: No, score=-103.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdMYgDF0HSNw for ; Tue, 7 Aug 2012 06:43:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40F21F867C for ; Tue, 7 Aug 2012 06:43:00 -0700 (PDT) Received: by eaai11 with SMTP id i11so1134486eaa.31 for ; Tue, 07 Aug 2012 06:42:59 -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=2UrcFNwd/vOQE4Lx42JQY/ljp0prSnY9pQX5Y/VrADU=; b=c7PkPJPfGneUlGg1RfoXHfkSamv/Z2aSFHpd7aGUsu/g/kyQH8KwYBzXC+z1uCyR4l OuJKRoHF1Ze2r9uy/0W5TN3FsMxdh5J7jJxOpuhpDCbrhcYVJBmx+YDXTuMg6A8w/AFQ 36mW6mNnSQ4Tsr02oclC34M6F0rbVCwE5H3VA6D5XgBCHqjWWuZpUD5hsYHxjw0bR23h qxVghDvUPv52+FfO8I64EMiUaK+lhkuSqbfPZamIehLalVJ7Y3aw8j2IcLXJBkkNQRRq gYW7x1UcF9ATxcIAO63F/MX2HzvJuo9hP7ZftPeT9PMbtfMSaR2VooxE0Y5wVXOyd65R mcOA== Received: by 10.14.173.71 with SMTP id u47mr17909595eel.22.1344346979545; Tue, 07 Aug 2012 06:42:59 -0700 (PDT) Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id e7sm20234847eep.2.2012.08.07.06.42.57 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 06:42:58 -0700 (PDT) Message-ID: <50211B63.3020203@gmail.com> Date: Tue, 07 Aug 2012 14:42:59 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: V6ops Chairs , "v6ops@ietf.org" , Ron Bonica Subject: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:43:02 -0000 Change of subject header, to separate out this topic: On 07/08/2012 14:12, Cameron Byrne wrote: > On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" wrote: >> Hi, >> >> >> ----- Original Message ----- >>> From: Brian E Carpenter >>> To: Cameron Byrne >>> Cc: "v6ops@ietf.org" ; V6ops Chairs < > v6ops-chairs@tools.ietf.org>; Ron Bonica >>> Sent: Tuesday, 7 August 2012 7:24 PM >>> Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC >>> >>> On 07/08/2012 04:59, Cameron Byrne wrote: >>>> On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) >>> wrote: >>>>> This is to open a two week Working Group last Call on >>>>> >>>>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >>>>> "IPv6 Guidance for Internet Content and Application Service >>> Providers", >>>>> Brian Carpenter, Sheng Jiang, 10-Jul-12 >>>>> >> <> >>>> It seems like NPTv6 is a much more modern approach that is much more >>>> likely to be deployed ... >>> For content providers??? >>> >> >> Wouldn't NPTv6's Experimental status mean it shouldn't really be > suggested in an advisory document like this? If it was mentioned, then I > think there'd have to be text discussing it's drawbacks in ICP scenarios > e.g. the consequences of content hosts/applications not knowing their own > IPv6 identity, and discussion around NPTv6 in a situation where the "cloud" > application traffic is encrypted (I think this is going to increase > significantly with the rapid adoption of BYO devices and Wifi offload). >> Regards, >> Mark. > > NPTv6 is not really the focus of my comment. The focus was supposed to be > using 2 prefixes for multihoming or migrating isps. > > I dont think anyone would do this today. Doing it, afaik, would be a > science experiment I think that's unfair and kind of ignores draft-v6ops-multihoming-without-ipv6nat It works today. There are known difficulties with address selection and with ingress filtering, of course. And it's a bit more fiddly to configure routing and DNS for IT crews used to the old way of doing things. But it really isn't unknown territory. > and therefore should not be a recommended approach. I If we are only addressing a few thousand sites, sure, but how else do you suggest we deal with content providers by the million? > understand ipv6 was designed to work this way. .... But afaik, it is not > really exercised. If someone has done it in a production network, that > would be good to know Yes, facts are always good. Brian From zveno.chen@gmail.com Tue Aug 7 06:57:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3B21F86EF for ; Tue, 7 Aug 2012 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPXyoJTy6ESN for ; Tue, 7 Aug 2012 06:57:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF44521F86D1 for ; Tue, 7 Aug 2012 06:57:48 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5648202pbb.31 for ; Tue, 07 Aug 2012 06:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; bh=GUikEcBFsfqggyRoei2hFS2SKXL0sD46j40jhvVagLk=; b=GrUt/gaXe6yHKqXvZ6rDXuNml2ldZsRggUTi6Mss9bLNJCSY9ncqKE0tWFiZJD8ESC 81sVCIOSq9JFYFRJ2AunYVotbZdF9L+MASqjMxvy0veJ3qouGLrIIPpC8qpAoHBj/5hv uok+/6cJdCnKwzBizumSZKNcL+agyrNFNaOhQk3Ve7tJWMFX/HqQkAG15jNWyePT2lMC Lmxdnnsbo1ZqfgvihqKQK0KeAR8cKngi+Yi5yXj1L1LhtNzAuR1Qqe9J3n7f/27GGWXu 1Hv3c6ao8Z5eilQIUi5WZzayAGuzwj4cJXp32eEx+MOs6rrmBtrjxSLCwYwXyLs0dYfw 7zmQ== Received: by 10.68.242.228 with SMTP id wt4mr27925676pbc.89.1344347868665; Tue, 07 Aug 2012 06:57:48 -0700 (PDT) Received: from chenzhonghua-nb ([116.230.108.97]) by mx.google.com with ESMTPS id pz10sm1179141pbb.60.2012.08.07.06.57.44 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 06:57:48 -0700 (PDT) Date: Tue, 7 Aug 2012 21:57:51 +0800 From: "=?utf-8?B?enZlbm8uY2hlbg==?=" To: "=?utf-8?B?TWFnbGlvbmUgUm9iZXJ0YQ==?=" , "=?utf-8?B?V2lsbCBMaXUgKFNodWNoZW5nKQ==?=" , "=?utf-8?B?ZnJlZEBjaXNjby5jb20=?=" , "=?utf-8?B?d2VzbGV5Lmdlb3JnZQ==?=" , "=?utf-8?B?bG9yZW56bw==?=" References: <201208072051330785547@gmail.com> Message-ID: <201208072157487032856@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon775850540103_=====" Cc: =?utf-8?B?djZvcHM=?= Subject: Re: [v6ops] =?utf-8?q?scenario_of_draft-zhang-v6ops-ipv6oa-iwf-00=2Et?= =?utf-8?q?xt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:57:50 -0000 This is a multi-part message in MIME format. --=====003_Dragon775850540103_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGkNCg0KICAgSSBqdXN0IGRlc2NyaWJlIHRoZSB1c2VjYXNlIG9mIElQdjZvQSwgYnV0IHdlIGRp c2N1c3MgbW9yZSBpbiB0aGUgZHJhZnQgaW5jbHVkaW5nIE5EIHByb3h5LGxpbmsgbGF5ZXIgYWRk cmVzcyBjaGFuZ2UuLi4gSXQncyBub3QganVzdCBhIHJlcXVpcmVtZW50LCBpIHRoaW5rDQoNCg0K MjAxMi0wOC0wNyANCg0KDQoNCnp2ZW5vLmNoZW4gDQoNCg0KDQrlj5Hku7bkurrvvJogTWFnbGlv bmUgUm9iZXJ0YSANCuWPkemAgeaXtumXtO+8miAyMDEyLTA4LTA3ICAyMToxMjozNCANCuaUtuS7 tuS6uu+8miAnenZlbm8uY2hlbic7IFdpbGwgTGl1IChTaHVjaGVuZyk7IGZyZWRAY2lzY28uY29t OyB3ZXNsZXkuZ2VvcmdlOyBsb3JlbnpvIA0K5oqE6YCB77yaIHY2b3BzIA0K5Li76aKY77yaIFJF OiBbdjZvcHNdIHNjZW5hcmlvIG9mIGRyYWZ0LXpoYW5nLXY2b3BzLWlwdjZvYS1pd2YtMDAudHh0 IA0KIA0KSGVsbG8sDQogICBJZiBJIHVuZGVyc3RhbmQgeW91ciBkcmFmdCBjb3JyZWN0bHkgeW91 IGFyZSBwcm9wb3NpbmcgYSBuZXcgaW50ZXJ3b3JraW5nIGZ1bmN0aW9uIG9uIHRoZSBBY2Nlc3Mg Tm9kZSwgc28geW91IGFyZSBiYXNpY2FsbHkgc3BlY2lmeWluZyBuZXcgcmVxdWlyZW1lbnRzIGZv ciB0aGUgQWNjZXNzIE5vZGUuDQpXaHkgYXJlIHlvdSBkaXNjdXNzaW5nIHRoaXMgdG9waWMgaW4g SUVURj8gSXNuJ3QgdGhpcyBCcm9hZGJhbmQgRm9ydW0ncyB0ZXJyaXRvcnk/IEJCRiBpcyB0aGUg U0RPIHRoYXQgc3BlY2lmaWVzIHJlcXVpcmVtZW50cyBmb3IgQWNjZXNzIE5vZGUgYW5kIGlmIEkg cmVtZW1iZXIgY29ycmVjdGx5IHRoaXMgaW50ZXJ3b3JraW5nIGZ1bmN0aW9uIHdhcyBkaXNjdXNz ZWQgYW5kIGZpbmFsbHkgbm90IGluY2x1ZGVkIGluIFRSLTE3NyBzb21lIHllYXJzLg0KSWYgeW91 IHRoaW5rIHRoaXMgd29yayBpcyBuZWVkZWQsIGZvciB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJl ZCwgSSB3b3VsZCBzdWdnZXN0IGRpc2N1c3NpbmcgdGhpcyBwcm9wb3NhbCBpbiBCQkYgZmlyc3Qu DQpCZXN0IFJlZ2FyZHMsDQpSb2JlcnRhDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiB6dmVuby5jaGVuDQpTZW50OiBtYXJ0ZWTDrCA3IGFnb3N0byAyMDEyIDE0 LjUyDQpUbzogV2lsbCBMaXUgKFNodWNoZW5nKTsgZnJlZEBjaXNjby5jb207IHdlc2xleS5nZW9y Z2U7IGxvcmVuem8NCkNjOiB2Nm9wcw0KU3ViamVjdDogW3Y2b3BzXSBzZW5hcmlvIG9mIGRyYWZ0 LXpoYW5nLXY2b3BzLWlwdjZvYS1pd2YtMDAudHh0DQpISSwNCiAgICBUaGUgc2VuYXJpbyBvZiBJ UHY2b0EgaXMgZXhpc3QgaW4gQ2hpbmF0ZWxlY29tIG5ldHdvcmsuIEluIG91ciBJUFY0IG5ldHdv cmsgc29tZSBvZiBvdXIgY3VzdG9tZXJzIHVzZXMgYSBzZXJ2aWNlIGNhbGxlZCBBVE0gcHJpdmF0 ZS1MaW5lLiBJbiB0aGlzIHNlcnZpY2UsIHVzZXIncyBDUEUgZGV2aWNlIGNvbm5lY3QgdG8gY29y ZSBuZXR3b3JrIGJ5IElQb0EgKFBWQy9TVkMpICwgYW5kIHVzZXMgc3RhYmxlIElQIGFkZHJlc3Mu IEluIHRoZSBmdXR1cmUsIHdpdGggdGhlIGRldmVsb3BtZW50IG9mIElQdjYgLHRoZXNlIGN1c3Rv bWVyIHdpbGwgaG9wZSB0byB0cmFuc2ZlciB0aGVpciBzZXJ2aWNlIHRvIElQdjYsYnV0IHRoZXkg ZG9ub3Qgd2FudCB0byB1c2UgSVAgYWNjZXNzIG5ldHdvcmsobWF5YmUgdGhleSBkb25vdCB3YW50 IHRvIGNoYW5nZSB0aGVpciBuZXR3b3JrIHNoYXJwbHkpLiBJbiB0aGlzIHNlY2FucmlvLCB3ZSB0 aGluayBJUHY2b0Egd2lsbCBiZSBhIGNob2ljZSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4gQW5kIHVw Z3JhZGUgYSBJUHY0IElXRiB0byBEUyBJV0YgbWF5IGJlIGVjb25vbWljYWwNCi0tLS0tLS0tLS0t LS0tDQpaaG9uZ0h1YSBDaGVuDQpDaGluYXRlbGVjb20NCjIwMTItMDgtMDcNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QN CnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkg ZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3Bp YSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkg cXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBh YmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNl bWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50 ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NClRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHku IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2Ug aXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2Ug dGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo= --=====003_Dragon775850540103_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg5MjgiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFu YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpV U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20g MGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVw dA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVY VC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAx MC41cHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5k b3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0K CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9 DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPmhpPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MD4mbmJzcDsmbmJzcDsgSSBqdXN0IGRlc2NyaWJlIHRoZSB1c2VjYXNl IG9mIElQdjZvQSwgYnV0IA0Kd2UgZGlzY3VzcyBtb3JlIGluIHRoZSBkcmFmdCBpbmNsdWRpbmcg TkQgcHJveHksbGluayBsYXllciBhZGRyZXNzIGNoYW5nZS4uLiANCkl0J3Mgbm90IGp1c3QgYSBy ZXF1aXJlbWVudCwgaSB0aGluazwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4 MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjIwMTItMDgtMDcgPC9GT05U PjwvRElWPjxGT05UIA0KY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0 eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9O VD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPnp2 ZW5vLmNoZW48L1NQQU4+IA0KPC9GT05UPjwvRElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0y IGZhY2U9VmVyZGFuYT4NCjxIUj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48U1RST05HPuWPkeS7tuS6uu+8mjwvU1RST05HPiBNYWdsaW9uZSBSb2JlcnRhIA0KPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Y+R6YCB 5pe26Ze077yaPC9TVFJPTkc+IDIwMTItMDgtMDcmbmJzcDsgMjE6MTI6MzQgDQo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mlLbku7bkurrvvJo8 L1NUUk9ORz4gJ3p2ZW5vLmNoZW4nOyBXaWxsIExpdSANCihTaHVjaGVuZyk7IGZyZWRAY2lzY28u Y29tOyB3ZXNsZXkuZ2VvcmdlOyBsb3JlbnpvIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuaKhOmAge+8mjwvU1RST05HPiB2Nm9wcyA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7kuLvpopjvvJo8 L1NUUk9ORz4gUkU6IFt2Nm9wc10gc2NlbmFyaW8gb2YgDQpkcmFmdC16aGFuZy12Nm9wcy1pcHY2 b2EtaXdmLTAwLnR4dCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRh bmE+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+ SGVsbG8sPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO0lmJm5ic3A7SSZuYnNwO3VuZGVy c3RhbmQmbmJzcDt5b3VyJm5ic3A7ZHJhZnQmbmJzcDtjb3JyZWN0bHkmbmJzcDt5b3UmbmJzcDth cmUmbmJzcDtwcm9wb3NpbmcmbmJzcDthJm5ic3A7bmV3Jm5ic3A7aW50ZXJ3b3JraW5nJm5ic3A7 ZnVuY3Rpb24mbmJzcDtvbiZuYnNwO3RoZSZuYnNwO0FjY2VzcyZuYnNwO05vZGUsJm5ic3A7c28m bmJzcDt5b3UmbmJzcDthcmUmbmJzcDtiYXNpY2FsbHkmbmJzcDtzcGVjaWZ5aW5nJm5ic3A7bmV3 Jm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7QWNjZXNzJm5ic3A7Tm9k ZS48L0RJVj4NCjxESVY+V2h5Jm5ic3A7YXJlJm5ic3A7eW91Jm5ic3A7ZGlzY3Vzc2luZyZuYnNw O3RoaXMmbmJzcDt0b3BpYyZuYnNwO2luJm5ic3A7SUVURj8mbmJzcDtJc24ndCZuYnNwO3RoaXMm bmJzcDtCcm9hZGJhbmQmbmJzcDtGb3J1bSdzJm5ic3A7dGVycml0b3J5PyZuYnNwO0JCRiZuYnNw O2lzJm5ic3A7dGhlJm5ic3A7U0RPJm5ic3A7dGhhdCZuYnNwO3NwZWNpZmllcyZuYnNwO3JlcXVp cmVtZW50cyZuYnNwO2ZvciZuYnNwO0FjY2VzcyZuYnNwO05vZGUmbmJzcDthbmQmbmJzcDtpZiZu YnNwO0kmbmJzcDtyZW1lbWJlciZuYnNwO2NvcnJlY3RseSZuYnNwO3RoaXMmbmJzcDtpbnRlcndv cmtpbmcmbmJzcDtmdW5jdGlvbiZuYnNwO3dhcyZuYnNwO2Rpc2N1c3NlZCZuYnNwO2FuZCZuYnNw O2ZpbmFsbHkmbmJzcDtub3QmbmJzcDtpbmNsdWRlZCZuYnNwO2luJm5ic3A7VFItMTc3Jm5ic3A7 c29tZSZuYnNwO3llYXJzLjwvRElWPg0KPERJVj5JZiZuYnNwO3lvdSZuYnNwO3RoaW5rJm5ic3A7 dGhpcyZuYnNwO3dvcmsmbmJzcDtpcyZuYnNwO25lZWRlZCwmbmJzcDtmb3ImbmJzcDt0aGUmbmJz cDtzY2VuYXJpbyZuYnNwO3lvdSZuYnNwO2Rlc2NyaWJlZCwmbmJzcDtJJm5ic3A7d291bGQmbmJz cDtzdWdnZXN0Jm5ic3A7ZGlzY3Vzc2luZyZuYnNwO3RoaXMmbmJzcDtwcm9wb3NhbCZuYnNwO2lu Jm5ic3A7QkJGJm5ic3A7Zmlyc3QuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5CZXN0Jm5ic3A7 UmVnYXJkcyw8L0RJVj4NCjxESVY+Um9iZXJ0YTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0t LS1PcmlnaW5hbCZuYnNwO01lc3NhZ2UtLS0tLTwvRElWPg0KPERJVj5Gcm9tOiZuYnNwO3Y2b3Bz LWJvdW5jZXNAaWV0Zi5vcmcmbmJzcDtbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddJm5i c3A7T24mbmJzcDtCZWhhbGYmbmJzcDtPZiZuYnNwO3p2ZW5vLmNoZW48L0RJVj4NCjxESVY+U2Vu dDombmJzcDttYXJ0ZWTDrCZuYnNwOzcmbmJzcDthZ29zdG8mbmJzcDsyMDEyJm5ic3A7MTQuNTI8 L0RJVj4NCjxESVY+VG86Jm5ic3A7V2lsbCZuYnNwO0xpdSZuYnNwOyhTaHVjaGVuZyk7Jm5ic3A7 ZnJlZEBjaXNjby5jb207Jm5ic3A7d2VzbGV5Lmdlb3JnZTsmbmJzcDtsb3JlbnpvPC9ESVY+DQo8 RElWPkNjOiZuYnNwO3Y2b3BzPC9ESVY+DQo8RElWPlN1YmplY3Q6Jm5ic3A7W3Y2b3BzXSZuYnNw O3NlbmFyaW8mbmJzcDtvZiZuYnNwO2RyYWZ0LXpoYW5nLXY2b3BzLWlwdjZvYS1pd2YtMDAudHh0 PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5ISSw8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSZuYnNwO3NlbmFyaW8mbmJzcDtvZiZuYnNwO0lQdjZv QSZuYnNwO2lzJm5ic3A7ZXhpc3QmbmJzcDtpbiZuYnNwO0NoaW5hdGVsZWNvbSZuYnNwO25ldHdv cmsuJm5ic3A7SW4mbmJzcDtvdXImbmJzcDtJUFY0Jm5ic3A7bmV0d29yayZuYnNwO3NvbWUmbmJz cDtvZiZuYnNwO291ciZuYnNwO2N1c3RvbWVycyZuYnNwO3VzZXMmbmJzcDthJm5ic3A7c2Vydmlj ZSZuYnNwO2NhbGxlZCZuYnNwO0FUTSZuYnNwO3ByaXZhdGUtTGluZS4mbmJzcDtJbiZuYnNwO3Ro aXMmbmJzcDtzZXJ2aWNlLCZuYnNwO3VzZXIncyZuYnNwO0NQRSZuYnNwO2RldmljZSZuYnNwO2Nv bm5lY3QmbmJzcDt0byZuYnNwO2NvcmUmbmJzcDtuZXR3b3JrJm5ic3A7YnkmbmJzcDtJUG9BJm5i c3A7KFBWQy9TVkMpJm5ic3A7LCZuYnNwO2FuZCZuYnNwO3VzZXMmbmJzcDtzdGFibGUmbmJzcDtJ UCZuYnNwO2FkZHJlc3MuJm5ic3A7SW4mbmJzcDt0aGUmbmJzcDtmdXR1cmUsJm5ic3A7d2l0aCZu YnNwO3RoZSZuYnNwO2RldmVsb3BtZW50Jm5ic3A7b2YmbmJzcDtJUHY2Jm5ic3A7LHRoZXNlJm5i c3A7Y3VzdG9tZXImbmJzcDt3aWxsJm5ic3A7aG9wZSZuYnNwO3RvJm5ic3A7dHJhbnNmZXImbmJz cDt0aGVpciZuYnNwO3NlcnZpY2UmbmJzcDt0byZuYnNwO0lQdjYsYnV0Jm5ic3A7dGhleSZuYnNw O2Rvbm90Jm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7dXNlJm5ic3A7SVAmbmJzcDthY2Nlc3MmbmJz cDtuZXR3b3JrKG1heWJlJm5ic3A7dGhleSZuYnNwO2Rvbm90Jm5ic3A7d2FudCZuYnNwO3RvJm5i c3A7Y2hhbmdlJm5ic3A7dGhlaXImbmJzcDtuZXR3b3JrJm5ic3A7c2hhcnBseSkuJm5ic3A7SW4m bmJzcDt0aGlzJm5ic3A7c2VjYW5yaW8sJm5ic3A7d2UmbmJzcDt0aGluayZuYnNwO0lQdjZvQSZu YnNwO3dpbGwmbmJzcDtiZSZuYnNwO2EmbmJzcDtjaG9pY2UmbmJzcDt0byZuYnNwO3NvbHZlJm5i c3A7dGhlJm5ic3A7cHJvYmxlbS4mbmJzcDtBbmQmbmJzcDt1cGdyYWRlJm5ic3A7YSZuYnNwO0lQ djQmbmJzcDtJV0YmbmJzcDt0byZuYnNwO0RTJm5ic3A7SVdGJm5ic3A7bWF5Jm5ic3A7YmUmbmJz cDtlY29ub21pY2FsPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLTwvRElW Pg0KPERJVj5aaG9uZ0h1YSZuYnNwO0NoZW48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkNoaW5h dGVsZWNvbTwvRElWPg0KPERJVj4yMDEyLTA4LTA3PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj52Nm9wcyZuYnNwO21haWxp bmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPnY2b3BzQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPlF1ZXN0byZuYnNwO21lc3NhZ2dpbyZuYnNwO2UmbmJzcDtpJm5ic3A7c3VvaSZuYnNw O2FsbGVnYXRpJm5ic3A7c29ubyZuYnNwO2luZGlyaXp6YXRpJm5ic3A7ZXNjbHVzaXZhbWVudGUm bmJzcDthbGxlJm5ic3A7cGVyc29uZSZuYnNwO2luZGljYXRlLiZuYnNwO0xhJm5ic3A7ZGlmZnVz aW9uZSwmbmJzcDtjb3BpYSZuYnNwO28mbmJzcDtxdWFsc2lhc2kmbmJzcDthbHRyYSZuYnNwO2F6 aW9uZSZuYnNwO2Rlcml2YW50ZSZuYnNwO2RhbGxhJm5ic3A7Y29ub3NjZW56YSZuYnNwO2RpJm5i c3A7cXVlc3RlJm5ic3A7aW5mb3JtYXppb25pJm5ic3A7c29ubyZuYnNwO3JpZ29yb3NhbWVudGUm bmJzcDt2aWV0YXRlLiZuYnNwO1F1YWxvcmEmbmJzcDthYmJpYXRlJm5ic3A7cmljZXZ1dG8mbmJz cDtxdWVzdG8mbmJzcDtkb2N1bWVudG8mbmJzcDtwZXImbmJzcDtlcnJvcmUmbmJzcDtzaWV0ZSZu YnNwO2NvcnRlc2VtZW50ZSZuYnNwO3ByZWdhdGkmbmJzcDtkaSZuYnNwO2Rhcm5lJm5ic3A7aW1t ZWRpYXRhJm5ic3A7Y29tdW5pY2F6aW9uZSZuYnNwO2FsJm5ic3A7bWl0dGVudGUmbmJzcDtlJm5i c3A7ZGkmbmJzcDtwcm92dmVkZXJlJm5ic3A7YWxsYSZuYnNwO3N1YSZuYnNwO2Rpc3RydXppb25l LCZuYnNwO0dyYXppZS48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoaXMmbmJzcDtlLW1haWwm bmJzcDthbmQmbmJzcDthbnkmbmJzcDthdHRhY2htZW50cyZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsJm5ic3A7YW5kJm5ic3A7bWF5Jm5ic3A7Y29udGFpbiZuYnNwO3ByaXZpbGVnZWQmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO2ludGVuZGVkJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7YWRkcmVzc2Vl KHMpJm5ic3A7b25seS4mbmJzcDtEaXNzZW1pbmF0aW9uLCZuYnNwO2NvcHlpbmcsJm5ic3A7cHJp bnRpbmcmbmJzcDtvciZuYnNwO3VzZSZuYnNwO2J5Jm5ic3A7YW55Ym9keSZuYnNwO2Vsc2UmbmJz cDtpcyZuYnNwO3VuYXV0aG9yaXNlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO25v dCZuYnNwO3RoZSZuYnNwO2ludGVuZGVkJm5ic3A7cmVjaXBpZW50LCZuYnNwO3BsZWFzZSZuYnNw O2RlbGV0ZSZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7YXR0 YWNobWVudHMmbmJzcDthbmQmbmJzcDthZHZpc2UmbmJzcDt0aGUmbmJzcDtzZW5kZXImbmJzcDti eSZuYnNwO3JldHVybiZuYnNwO2UtbWFpbCwmbmJzcDtUaGFua3MuPC9ESVY+DQo8RElWPjwvRElW PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon775850540103_=====-- From gvandeve@cisco.com Tue Aug 7 07:25:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4921F86DA; Tue, 7 Aug 2012 07:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.09 X-Spam-Level: X-Spam-Status: No, score=-10.09 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0drFfIYdyBO; Tue, 7 Aug 2012 07:25:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 544FA21F86C5; Tue, 7 Aug 2012 07:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=8884; q=dns/txt; s=iport; t=1344349511; x=1345559111; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=S0TuV3z8aZumqzHe8b4WWvLWlh33I2tNKif9qJiwpxc=; b=JE86AvYuVqF3Mo752Tu9Mg0ftXs7TMAyOLnxol3VVs/WFErR1eo6i/MZ nffsNdMxEn9ZkpynuhaGa5wuP8auzJI3FOit/kegmYUKUN3m/CUeUBuk1 H00xc2HlgdKkwbfiVc5JgBfpWtdiaAz5VyNiuyI3Iu23cKE2vMUtyQo32 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKIkIVCtJXHB/2dsb2JhbAA7CoJKtnyBB4IgAQEBBBIBGkwQAgEIEQQBAQsdBzIUCQgBAQQBDQUIDA6Ha5tXoFaLDxCFfWADo26BZoJf X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="scan'208,217";a="109176836" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 07 Aug 2012 14:25:10 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77EPA6X015508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 14:25:10 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 09:25:10 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" , "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71ApgA+bzKA Date: Tue, 7 Aug 2012 14:25:09 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406BE1F@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.43] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--38.664700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B2406BE1Fxmbalnx12ciscocom_" MIME-Version: 1.0 Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:25:12 -0000 --_000_67832B1175062E48926BF3CB27C49B2406BE1Fxmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I received a note that Eric Vyncke volunteered to review this draft. A 3rd candidate is still looked for. Kind Regards, G/ From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: 06 August 2012 10:43 To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implica= tions-on-ipv4-nets Dear all, Can I request the WG members for 3 volunteers to read the draft draft-gont-= opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list? This will help the OPSEC chairs to identify if the work is ready for WG ado= ption or not. The work targets are within charter of the WG, and seems to b= e interesting work for the community. Questions we are looking answers for: 1) Should it be targeted BCP or Informational? 2) Is the work quality ok to be accepted as WG document? 3) Is the topic inline with the OPSEC charter? 4) Any missing or over-described points? Many thanks in advance, Kind Regards, OPSEC Chairs, (G/, KK, Warren) --_000_67832B1175062E48926BF3CB27C49B2406BE1Fxmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I received a note that= Eric Vyncke volunteered to review this draft.

 

A 3rd candi= date is still looked for.

 

Kind Regards,

G/

 

From:= opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (g= vandeve)
Sent: 06 August 2012 10:43
To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org)
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-= implications-on-ipv4-nets

 

Dear all,

 

Can I request the WG members for 3 volunteers to rea= d the draft draft-gont-opsec-ipv6-implications-on-ipv4-nets and provide fee= dback to the list?

 

This will help the OPSEC chairs to identify if the w= ork is ready for WG adoption or not. The work targets are within charter of= the WG, and seems to be interesting work for the community.

 

Questions we are looking answers for:

 

1)      Should it be targeted BCP or Informational?

2)      Is the work quality ok to be accepted as WG documen= t?

3)      Is the topic inline with the OPSEC charter?

4)      Any missing or over-described points?

 

Many thanks in advance,

 

Kind Regards,

OPSEC Chairs,

(G/, KK, Warren)

--_000_67832B1175062E48926BF3CB27C49B2406BE1Fxmbalnx12ciscocom_-- From despres.remi@laposte.net Tue Aug 7 07:40:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747AE21F870E for ; Tue, 7 Aug 2012 07:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfVjDl4FZaBo for ; Tue, 7 Aug 2012 07:40:00 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21F21F870B for ; Tue, 7 Aug 2012 07:40:00 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id C867170000B1; Tue, 7 Aug 2012 16:39:58 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id 540A4700009F; Tue, 7 Aug 2012 16:39:53 +0200 (CEST) X-SFR-UUID: 20120807143953344.540A4700009F@msfrf2512.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 7 Aug 2012 16:39:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:40:01 -0000 Hi, Fred, I agree that adding an applicability statement, as you requested last = week, is an approach that improves acceptability of BCP status (as = opposed to Informational recommended by some participants in Vancouver). This statement is currently: " 2. BCP Scenario =09 This BCP only applies when the following two criteria are present:=09 1. There is an IPv6-only access network that uses stateful translation = [RFC6146]=09 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet In my understanding, it should be more complete, e.g. as follows: " 2. Applicability of 464XLAT =09 This BCP only applies when the following three criteria are present:=09 1. There is an IPv6-only access network that doesn't support DS-lite = [RFC6333] but supports NAT64 stateful translation [RFC6146] 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet 3. The lack of transparency to source-fragmented IPv4 packets that, as = recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. = have DF=3D1), is considered acceptable. Comments welcome. Regards, RD 2012-08-07 07:53, Fred Baker (fred) : > I'll let the current WGLC run and then open one for 464XLAT. >=20 > On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >=20 >>=20 >> v6ops chairs, >>=20 >> We have published draft-ietf-v6ops-464xlat-06. >> This draft is simply adding section 2 "BCP Scenario". >> Could you please start WGLC? >>=20 >> Thank you for your time and consideration. >>=20 >> Regards, >> Masanobu From gvandeve@cisco.com Tue Aug 7 07:47:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D80021F873B; Tue, 7 Aug 2012 07:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.784 X-Spam-Level: X-Spam-Status: No, score=-9.784 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5GBCXkcDs7L; Tue, 7 Aug 2012 07:47:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4B21F873A; Tue, 7 Aug 2012 07:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1847; q=dns/txt; s=iport; t=1344350850; x=1345560450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3BMGJjdAMOv9Bl8mXByeEvq7oIFJKG40Vu0J5/1WvwI=; b=Ur7TpJu8+u5uqo7HolRAR30Tty9QbXLDhm1h2mDiLDOlVkZiikpaitEx AqUn9ssSNIX1wHxXYv7WfnK+HO6hOEYgwB307mh6rzeQnvF4U1W81Zcgu KLn8LExNXaMpVQlIgS2eBz+T4TP+qUoAoNtRTsWK1skz/1K48aiweFgIt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAoqIVCtJV2b/2dsb2JhbABFuUaBB4IgAQEBBAEBAQ8BCh00CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIGodrC5tWoFmLDxqFc2ADllyNEoFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="scan'208";a="109167149" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 07 Aug 2012 14:47:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q77ElTVW003660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 14:47:29 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 09:47:28 -0500 From: "Gunter Van de Velde (gvandeve)" To: "t.petch" , "opsec@ietf.org" , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: [v6ops] IPv6 OPSEC drafts need review Thread-Index: Ac1zr7XviImO0VW9ShaYOQMMM67U3AA059NkAAn2Y+A= Date: Tue, 7 Aug 2012 14:47:28 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406BF8D@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240674DA@xmb-aln-x12.cisco.com> <039d01cd7482$b1b65720$4001a8c0@gateway.2wire.net> In-Reply-To: <039d01cd7482$b1b65720$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.43] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--36.613900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-vyncke-opsec-v6@tools.ietf.org" , "v6ops@ietf.org" , "draft-jdurant-bgp-security-01@tools.ietf.org" Subject: Re: [v6ops] IPv6 OPSEC drafts need review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:47:31 -0000 Hi Tom, Good question. Added idr and grow for their feedback on this work. Reason for OPSEC is as it deals with operational security on BGP deployment= s. If general consensus is that other WG is more appropriate, then that is = ok for me also. I will leave that to the IAD's to decide. G/ -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: 07 August 2012 11:54 To: Gunter Van de Velde (gvandeve); opsec@ietf.org Cc: draft-vyncke-opsec-v6@tools.ietf.org; v6ops@ietf.org; draft-jdurant-bgp= -security-01@tools.ietf.org Subject: Re: [v6ops] IPv6 OPSEC drafts need review ----- Original Message ----- From: "Gunter Van de Velde (gvandeve)" To: Cc: ; ; Sent: Monday, August 06, 2012 9:51 AM Dear all, As mentioned during the OPSEC WG meeting, the following 2 drafts will in 3 weeks be considered for WG documents, after a call for feedback on the em= ail list. During the WG meeting it became clear that not that many people r= ead the documents until now. Please read drafts: 2) http://tools.ietf.org/html/draft-jdurand-bgp-security-01 Why OPSEC, when we have GROW or even IDR, neither of whom are copied on thi= s e-mail? What do the chairs of those WGs say? Tom Petch On Monday 27th the chairs of OPSEC WG will ask the WG during a period of 7 days for feedback on these drafts to support or deny acceptance as WG doc= uments. Kind Regards, G/, KK & Warren ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Tue Aug 7 08:27:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765B21F867B for ; Tue, 7 Aug 2012 08:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.28 X-Spam-Level: X-Spam-Status: No, score=-110.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzB6w5y12Vv9 for ; Tue, 7 Aug 2012 08:27:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 64CEA21F8652 for ; Tue, 7 Aug 2012 08:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2015; q=dns/txt; s=iport; t=1344353266; x=1345562866; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gEzNcqocYViXg7t8DCOSHzhmuy+P63ifTseI9mtUkNM=; b=NuR0oAE3ihCG1XMa4eW7s5keyjIxUFzebBcsTlRlAAK6wsmGQuTi/C9z fPuKwAsQYK4ntredZtE4lvGbDOEK547H0IIJIIwRdn5y3zsmcUHjj44bb JPdhpimK48rtu2LLtLiPMV0e32nkn+HywNihbcDneVb2a8EroQ/4Aaloc 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADoyIVCtJV2d/2dsb2JhbABFuUaBB4IhAQEEEgFmEAIBCEYyJQIEDhMUh2sLm1egWYsPhg1gA45YgSCFUIEUjRKBZoJf X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="asc'?scan'208";a="109183652" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 07 Aug 2012 15:27:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77FRjkJ003860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:27:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:27:45 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNdLExhwHVQAJZkE+xzTTprvINyA== Date: Tue, 7 Aug 2012 15:27:44 +0000 Message-ID: <7FA29CAA-49B0-4C3A-BED3-1A81D92578E4@cisco.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020C48D.6040507@redpill-linpro.com> In-Reply-To: <5020C48D.6040507@redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004 x-tm-as-result: No--34.487500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_3FB113D2-1A54-45DC-8537-08C9A1FD3419"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:27:47 -0000 --Apple-Mail=_3FB113D2-1A54-45DC-8537-08C9A1FD3419 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In the context of RFC 5838, OSPFv3 can now handle both protocols. So the = operator has a choice. On Aug 7, 2012, at 12:32 AM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> This is to open a two week Working Group last Call on >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6 >> Guidance for Internet Content and Application Service Providers", >> Brian Carpenter, Sheng Jiang, 10-Jul-12 >>=20 >> Please read it now. We are interested in, among other things, >> technical commentary on the draft and the working group's perception >> on its usefulness to its target audience. >=20 > Support. >=20 > One comment, regarding section 5.2: =ABIt is worth noting that whereas > OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the > advantage of handling them both in a single instance of the protocol=BB.= >=20 > I am under the impression that OSPFv3 also has this advantage (cf. RFC > 5838: =ABSupport of Address Families in OSPFv3=BB). I haven't yet = played > with this functionality myself, though. >=20 > Best regards, > --=20 > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_3FB113D2-1A54-45DC-8537-08C9A1FD3419 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQITPubjEdbHIsm0MRAmf7AKD12Ixou70B8jIcE/t81M6367wdKgCfSmch cpbD3gq05/0QuR2Rzkp5L44= =a0Ja -----END PGP SIGNATURE----- --Apple-Mail=_3FB113D2-1A54-45DC-8537-08C9A1FD3419-- From fred@cisco.com Tue Aug 7 08:36:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757A21F8720 for ; Tue, 7 Aug 2012 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.615 X-Spam-Level: X-Spam-Status: No, score=-109.615 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCoa4o-JC5Hf for ; Tue, 7 Aug 2012 08:36:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C89D221F871E for ; Tue, 7 Aug 2012 08:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3018; q=dns/txt; s=iport; t=1344353781; x=1345563381; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1Wm5d+9N52pmDrCnFqycXIpD+2nGq0OlLeci2wlqxT4=; b=Sq+Z+GAgsEL0P2UyDklZSQWDsaQKBVM0inrLCg1BaU4TAFhzQeEP98K+ 3AOdaYslMswYcoFTVkiPUI0m2j8qux8XAxMfatDC6LCr9SLxpBn8XtSW7 etlRMXUVnzYZf2D3YSD87T7BO90okadB47lp9tXJo+rKZ+hMSOUp5HfHG I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALM0IVCtJV2b/2dsb2JhbABFuUaBB4IgAQEBAwESAWYFCwIBCBguMiUCBAoEExSHZQabXqBaiw+GDWADjliBIIVQjiaBZoJf X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="asc'?scan'208";a="109232781" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 07 Aug 2012 15:36:16 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q77FaGA8028174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:36:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:36:16 -0500 From: "Fred Baker (fred)" To: "zveno.chen" Thread-Topic: senario of draft-zhang-v6ops-ipv6oa-iwf-00.txt Thread-Index: AQHNdLJh1zIqGiTXOEWRJLLUlZiwFw== Date: Tue, 7 Aug 2012 15:36:15 +0000 Message-ID: References: <201208072051330785547@gmail.com> In-Reply-To: <201208072051330785547@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--22.913300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_5A975D51-772D-44E8-AE38-86E6F91B992C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: v6ops Subject: Re: [v6ops] senario of draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:36:23 -0000 --Apple-Mail=_5A975D51-772D-44E8-AE38-86E6F91B992C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 7, 2012, at 5:51 AM, zveno.chen wrote: > The senario of IPv6oA is exist in Chinatelecom network. In our IPV4 = network some of our customers uses a service called ATM private-Line. In = this service, user's CPE device connect to core network by IPoA = (PVC/SVC) , and uses stable IP address. In the future, with the = development of IPv6 ,these customer will hope to transfer their service = to IPv6,but they donot want to use IP access network(maybe they donot = want to change their network sharply). In this secanrio, we think IPv6oA = will be a choice to solve the problem. And upgrade a IPv4 IWF to DS IWF = may be economical=20 First, I owe you an apology. I was unnecessarily rough with you Friday, = and that was inappropriate of me. On Aug 7, 2012, at 6:12 AM, Maglione Roberta wrote: > If I understand your draft correctly you are proposing a new = interworking function on the Access Node, so you are basically = specifying new requirements for the Access Node. >=20 > Why are you discussing this topic in IETF? Isn't this Broadband = Forum's territory? BBF is the SDO that specifies requirements for Access = Node and if I remember correctly this interworking function was = discussed and finally not included in TR-177 some years. >=20 > If you think this work is needed, for the scenario you described, I = would suggest discussing this proposal in BBF first. That said, I agree with Maglione. Direct interworking of a virtual = circuit protocol (ATM) with a LAN protocol (Ethernet) is not something = the IETF has chosen to specify in the past. Reason: we have a defined = interworking function between any two link layer interfaces, which one = might use between interfaces of the same type for management reasons and = in any event one would use between interfaces of different types. It is = correct that by directly connecting the two devices, one removes the = necessity of a two-port router; one does so at the cost of adding = significant complexity to both the protocols, as your draft describes, = and the functionality of the switch. Personally, I think you will be far = better off with a router. And in any event, this is BBF territory; if = the BBF wants to have IETF collusion, we can discuss that, but I think = you need first to discuss it with them.= --Apple-Mail=_5A975D51-772D-44E8-AE38-86E6F91B992C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQITXtbjEdbHIsm0MRAqJtAKCn0JOXAZRXW0h4t0TXMQiq1btkSQCfX3Vl AEtRsjybWjsXR+QtrxPI/a8= =IkTw -----END PGP SIGNATURE----- --Apple-Mail=_5A975D51-772D-44E8-AE38-86E6F91B992C-- From fred@cisco.com Tue Aug 7 08:43:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981421F8796 for ; Tue, 7 Aug 2012 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.046 X-Spam-Level: X-Spam-Status: No, score=-110.046 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu3ddVJVQ45w for ; Tue, 7 Aug 2012 08:43:37 -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 8B39F21F8794 for ; Tue, 7 Aug 2012 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3263; q=dns/txt; s=iport; t=1344354217; x=1345563817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mJOW+0dAnpkc07JrbpGqysY2W5aR01Ck1241nUauXok=; b=byGoP8a3Y19gTyFDXhyK4SM2gb9vN9Lg7yy9n9U+lD+jW8xV4BgZVWP1 qHcRV+UX7cpwezrFGx0/NfFcTPXz3Yw6ZsqGRxQOlGi9qG9kLyAkrBnm1 pIvcd0et/RCwB1mun1ruPhm8H9bQ2bICNRQwQp6RbuMDB9d8uVExDgmqU k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGY3IVCtJV2d/2dsb2JhbABFthyDKoEHgiABAQEDARIBZgULAgEIGC4yJQIEDhMNB4dlBptdoFqLD4YNYAOOWIEghVCOJoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="asc'?scan'208";a="109217627" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 15:43:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77FhWc8014680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:43:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:43:32 -0500 From: "Fred Baker (fred)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdLNldY2QyXFTlEW2g+qdiKZ87g== Date: Tue, 7 Aug 2012 15:43:31 +0000 Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> In-Reply-To: <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--43.561300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_DA4235F3-140F-423B-83CC-AAF70929E0CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:43:38 -0000 --Apple-Mail=_DA4235F3-140F-423B-83CC-AAF70929E0CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: > Hi, Fred, >=20 > I agree that adding an applicability statement, as you requested last = week, is an approach that improves acceptability of BCP status (as = opposed to Informational recommended by some participants in Vancouver). >=20 > This statement is currently: > " 2. BCP Scenario =09 > This BCP only applies when the following two criteria are present:=09 > 1. There is an IPv6-only access network that uses stateful translation = [RFC6146]=09 > 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet >=20 > In my understanding, it should be more complete, e.g. as follows: >=20 > " 2. Applicability of 464XLAT =09 > This BCP only applies when the following three criteria are present:=09= > 1. There is an IPv6-only access network that doesn't support DS-lite = [RFC6333] but supports NAT64 stateful translation [RFC6146] > 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet > 3. The lack of transparency to source-fragmented IPv4 packets that, as = recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. = have DF=3D1), is considered acceptable. So you're arguing that we need a comment in this applicability statement = regarding each other solution, or just that one? It seems to me that at = most (1) might add "to access an IPv4 network" or "to access the IPv4 = Internet" - which are different statements. There is no reason to go = into what the other options the operator might have chosen might be. I'll let others comment on your third bullet. Personally, I would not = expect the implementation to require fragmentation, but would expect it = to use configuration or PMTU to ensure that the packets were small = enough. > Comments welcome. >=20 > Regards, > RD >=20 >=20 > 2012-08-07 07:53, Fred Baker (fred) : >=20 >> I'll let the current WGLC run and then open one for 464XLAT. >>=20 >> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>=20 >>>=20 >>> v6ops chairs, >>>=20 >>> We have published draft-ietf-v6ops-464xlat-06. >>> This draft is simply adding section 2 "BCP Scenario". >>> Could you please start WGLC? >>>=20 >>> Thank you for your time and consideration. >>>=20 >>> Regards, >>> Masanobu ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_DA4235F3-140F-423B-83CC-AAF70929E0CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQITehbjEdbHIsm0MRAm4VAJ96Idm8qIeH5UNRMX62T/gcicgdOgCgn49n q6yD9MhZ2a98gW6wEvxNdf4= =VHG+ -----END PGP SIGNATURE----- --Apple-Mail=_DA4235F3-140F-423B-83CC-AAF70929E0CE-- From fred@cisco.com Tue Aug 7 08:51:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6D321F8658 for ; Tue, 7 Aug 2012 08:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.99 X-Spam-Level: X-Spam-Status: No, score=-109.99 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6CMt+jGdqYI for ; Tue, 7 Aug 2012 08:51:13 -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 D425D21F8650 for ; Tue, 7 Aug 2012 08:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3651; q=dns/txt; s=iport; t=1344354673; x=1345564273; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nQ/1Tqb4+sKk93yAP2e/FMlUP/fzkrWLL+t5Kqyr7os=; b=mz7JnYQAgZem0Cpdt7+ERItzWvNdxsqn/2cz+WtzjO5vdGZ9q7wGw/uN 9m1ulD9ZP2IiwbTV9D06zeW7XKUHiXZh2TjcUlqB/DR9lRLLQyV4wnBJ3 btPZGe/sFbcJ0BCIIXbFXy274lvfRu1XaHlIhB91KVv2378McZGRgj8Nh Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIg4IVCtJV2b/2dsb2JhbABFhXyzSoEHgiABAQEDARIBZgULAgEIEjICMhcOAgQOEw0Hh2UGm1KNEwiTO4sPCoVNNmADjliBIIVQjiaBZoJf X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="asc'?scan'208";a="109220546" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 15:51:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q77FpCEA016861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:51:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:51:11 -0500 From: "Fred Baker (fred)" To: "Will Liu (Shucheng)" Thread-Topic: Answers to the on-site questions for draft-zhang-v6ops-ipv6oa-iwf-00.txt Thread-Index: AQHNdLR3thKm4qOjmE+QiP1XAYE6ow== Date: Tue, 7 Aug 2012 15:51:10 +0000 Message-ID: <23C86A26-281C-44B4-80E9-744717D45397@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--34.365400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_3A4A218D-D200-48C6-ADFC-0ED48120AD56"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" , =?gb2312?B?s8LW2buq?= <18918588897@189.cn> Subject: Re: [v6ops] Answers to the on-site questions for draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:51:14 -0000 --Apple-Mail=_3A4A218D-D200-48C6-ADFC-0ED48120AD56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Aug 6, 2012, at 11:33 PM, Will Liu (Shucheng) wrote: > Hi, >=20 > I am sending the answers to those questions I didn't answered during = my presentation of draft-zhang-v6ops-ipv6oa-iwf-00.txt. Please see = below. >=20 > [17:29:04] fred - question - internet architecturel has = a defined internetworking function - which you didn't use. > A: Fred, I am really sorry I am not sure which internetworking = function you were refering to. Could you please reply with the specific = one? Thanks. As I noted to Zveno Chen, First, I owe you an apology. I was = unnecessarily rough with you Friday, and that was inappropriate of me. The defined interworking function between any two link layer networks, = in the IP architecture, is an IP router, also historically called a = "gateway". > [17:29:43] wes george - where did you find a slam that = does atm but speaks ipv6 > A: I said "the scenario here is come from from china telecom" at the = meeting. >=20 > [17:31:26] lorenzo - a large number of these devices = are doing ipoe which doesn't support v6. I think you might be willing to = replace the bng and do you want. > A: IWF on BNG is a alternative solution, which we might think about to = add into our draft. However, the scenario here is like this, = "CPE--(1)--AN--(2)--BNG". Network (2) is ethernet based ipv6 network in = current deployment. That's why we are suggesting to do this on AN.=20 Where you have drawn: 4.1. A general topology for IPv4 and IPv6 networks ---------- /// \\\ +------+ IPv6 over +-------------+ // \\ +----------+ | | ATM | || || | | CPE +-----------+ IPv6oA IWF | Ethernet base | BNG | | | | | IPv6 network | | +------+ +-------------+| |+----------+ \\ // \\\ /// ---------- I would expect to see ---------- +-------------+ /// \\\ +------+ IPv6 over | IP Router | // \\ +----------+ | | ATM +-----+-------+| || | | CPE +-----------+ATM | 802.3+ Ethernet base | BNG | | | +-----+-------+ IPv6 network | | +------+ | |+----------+ \\ // \\\ /// ---------- This type of structure is very common, although ATM is in less use than = it was before.= --Apple-Mail=_3A4A218D-D200-48C6-ADFC-0ED48120AD56 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQITlsbjEdbHIsm0MRAnsvAKDuT3pH5AexabUq8wXyZefSb7MpUQCgvYT7 ynV3/wd9Ujpv8z0crTysRFc= =w39v -----END PGP SIGNATURE----- --Apple-Mail=_3A4A218D-D200-48C6-ADFC-0ED48120AD56-- From fred@cisco.com Mon Aug 6 10:28:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABF311E80A3 for ; Mon, 6 Aug 2012 10:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5et4qi9OGib for ; Mon, 6 Aug 2012 10:28:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DC11E808A for ; Mon, 6 Aug 2012 10:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2800; q=dns/txt; s=iport; t=1344274091; x=1345483691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nBikjY2WOKmr6xPJJ4hGLQ9s5aY0R1q2wVFPEjCHeKY=; b=jLjc+dHygzVIVBRx3L48aWK1k2xqf6JFMJz3Cvrx0ezMbT6mcj/Bv1ai eBSDO9vBxEkjr3LxlK9WzRtQQaM/HayqSX7v8ZRG/dNsTJp4tK9Bi50eU wm0QVsyxNX8JDA4ryZVXfOuGMKopRW5yNVBa4yLi+QDN64CXSCSH2OrQh o=; X-Files: signature.asc : 195 X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="asc'?scan'208";a="108871669" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2012 17:28:11 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q76HSB0k005846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 17:28:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 12:28:10 -0500 From: "Fred Baker (fred)" To: "gunter@cisco.com" , "cpopovic@cisco.com" , Tim Chown , Olaf Bonness , "HahnC@t-systems.com" , "Benoit Claise (bclaise)" , joel jaeggli , "livio.zanol.puppim@gmail.com" , v6ops v6ops WG Thread-Topic: [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNc/jYD8p8havrqUG3CmQWSwJYmg== Date: Mon, 6 Aug 2012 17:28:09 +0000 Message-ID: References: <20120806142829.81256B1E003@rfc-editor.org> In-Reply-To: <20120806142829.81256B1E003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--40.204100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_CE9B59A5-AC19-4EC7-9469-0B8E2CD21A9D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:28:12 -0000 --Apple-Mail=_CE9B59A5-AC19-4EC7-9469-0B8E2CD21A9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 My perception: we should accept the erratum. Agree? On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5375, > "IPv6 Unicast Address Assignment Considerations". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >=20 > -------------------------------------- > Type: Technical > Reported by: L=EDvio Zanol Pereira de Souza Puppim = >=20 > Section: B.2.2 >=20 > Original Text > ------------- > B.2.2. /127 Addresses >=20 >=20 >=20 > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >=20 > [RFC3021], is not valid and should be strongly discouraged as >=20 > documented in RFC 3627 [RFC3627]. >=20 > Corrected Text > -------------- > B.2.2. /127 Addresses >=20 >=20 >=20 > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >=20 > [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >=20 > Notes > ----- > Maybe just remove the section B.2.2? >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5375 (draft-ietf-v6ops-addcon-10) > -------------------------------------- > Title : IPv6 Unicast Address Assignment Considerations > Publication Date : December 2008 > Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. = Bonness, C. Hahn > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_CE9B59A5-AC19-4EC7-9469-0B8E2CD21A9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQH/6objEdbHIsm0MRAufxAJ9KJ57h/FJg2ar54fJuIWaG6HBT3QCfbb/N rpp/tl8UemjWycp7lbHSK+s= =Uff2 -----END PGP SIGNATURE----- --Apple-Mail=_CE9B59A5-AC19-4EC7-9469-0B8E2CD21A9D-- From Donald.Smith@CenturyLink.com Mon Aug 6 10:48:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83121F8526; Mon, 6 Aug 2012 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IDKudoNKVyV; Mon, 6 Aug 2012 10:48:42 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1B921F8523; Mon, 6 Aug 2012 10:48:42 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q76Hmfe5011470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 11:48:41 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id CF9661E0065; Mon, 6 Aug 2012 12:48:35 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id B52211E004D; Mon, 6 Aug 2012 12:48:35 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q76HmZDt023658; Mon, 6 Aug 2012 12:48:35 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q76HmYoO023655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 12:48:35 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Mon, 6 Aug 2012 11:48:34 -0600 From: "Smith, Donald" To: "'Gunter Van de Velde (gvandeve)'" , "'opsec@ietf.org'" , "'v6ops v6ops WG (v6ops@ietf.org)'" Thread-Topic: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71ApgATRZrw Date: Mon, 6 Aug 2012 17:48:33 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D05B7E2@PDDCWMBXEX503.ctl.intranet> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:48:43 -0000 I will volunteer. With the understanding that my review would be technical = not a "IETF nit" review. When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com=20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Gunter Van de Velde (gvandeve) > Sent: Monday, August 06, 2012 2:43 AM > To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) > Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6- > implications-on-ipv4-nets >=20 > Dear all, >=20 >=20 >=20 > Can I request the WG members for 3 volunteers to read the draft draft- > gont-opsec-ipv6-implications-on-ipv4-nets and provide feedback to the > list? >=20 >=20 >=20 > This will help the OPSEC chairs to identify if the work is ready for WG > adoption or not. The work targets are within charter of the WG, and > seems to be interesting work for the community. >=20 >=20 >=20 > Questions we are looking answers for: >=20 >=20 >=20 > 1) Should it be targeted BCP or Informational? >=20 > 2) Is the work quality ok to be accepted as WG document? >=20 > 3) Is the topic inline with the OPSEC charter? >=20 > 4) Any missing or over-described points? >=20 >=20 >=20 > Many thanks in advance, >=20 >=20 >=20 > Kind Regards, >=20 > OPSEC Chairs, >=20 > (G/, KK, Warren) From joelja@bogus.com Mon Aug 6 19:06:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E677221F8666 for ; Mon, 6 Aug 2012 19:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS42+1vOqfoh for ; Mon, 6 Aug 2012 19:06:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4221F8661 for ; Mon, 6 Aug 2012 19:06:45 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7724ta6056665 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 7 Aug 2012 02:04:55 GMT (envelope-from joelja@bogus.com) Message-ID: <502077C6.2080609@bogus.com> Date: Mon, 06 Aug 2012 19:04:54 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20120806142829.81256B1E003@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 07 Aug 2012 02:04:57 +0000 (UTC) X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Cc: v6ops v6ops WG , "livio.zanol.puppim@gmail.com" , Olaf Bonness , "cpopovic@cisco.com" , "gunter@cisco.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 02:06:46 -0000 On 8/6/12 10:28 AM, Fred Baker (fred) wrote: > My perception: we should accept the erratum. Agree? so my interpretation. 3627 was moved to historic by 6547. 6164 allows the use of /127s... 5375 maybe wrong now but the reference to 3021 is temporally correct. so yeah I guess. On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309 >> >> -------------------------------------- >> Type: Technical >> Reported by: Lívio Zanol Pereira de Souza Puppim >> >> Section: B.2.2 >> >> Original Text >> ------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is not valid and should be strongly discouraged as >> >> documented in RFC 3627 [RFC3627]. >> >> Corrected Text >> -------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >> >> Notes >> ----- >> Maybe just remove the section B.2.2? >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5375 (draft-ietf-v6ops-addcon-10) >> -------------------------------------- >> Title : IPv6 Unicast Address Assignment Considerations >> Publication Date : December 2008 >> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > From gvandeve@cisco.com Tue Aug 7 01:24:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E16F21F8510 for ; Tue, 7 Aug 2012 01:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjKPONM7b435 for ; Tue, 7 Aug 2012 01:24:30 -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 47F3921F850D for ; Tue, 7 Aug 2012 01:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2802; q=dns/txt; s=iport; t=1344327870; x=1345537470; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UsE5GfPsGITBiCrvRHEQkEPBIxm2ZTXNP/KqXKRwCNA=; b=PUpH347YgMgrHVVYURCmwlfAVqwmXnd6GyMtpVU7OFwDl5RY3+otPNVt QC45TWg2FD4YrDqRN+4sufckrgtLqkIMbcXwv0Ic+xY5DDk70F30c16IG Cx33Ce2s2n8EZb2CWtYuMS9k5OLVl0xy2hgfUHUj/uCUAPliz5xX5tFkO k=; X-IronPort-AV: E=Sophos;i="4.77,725,1336348800"; d="scan'208";a="109090407" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 08:24:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q778OTnp024583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 08:24:29 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 03:24:29 -0500 From: "Gunter Van de Velde (gvandeve)" To: joel jaeggli , "Fred Baker (fred)" Thread-Topic: [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNc9/hDzwzSeK+NE2Vr68ZU+v1+JdNXcOAgACQYQCAABYfgA== Date: Tue, 7 Aug 2012 08:24:28 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406AC0F@xmb-aln-x12.cisco.com> References: <20120806142829.81256B1E003@rfc-editor.org> <502077C6.2080609@bogus.com> In-Reply-To: <502077C6.2080609@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.83.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004 x-tm-as-result: No--43.736400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Cc: v6ops v6ops WG , "livio.zanol.puppim@gmail.com" , Olaf Bonness , "cpopovic@cisco.com" , "gunter@cisco.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 08:24:31 -0000 Yes, agree. Anything the authors need to do on this? G/ -----Original Message----- From: joel jaeggli [mailto:joelja@bogus.com]=20 Sent: 07 August 2012 04:05 To: Fred Baker (fred) Cc: gunter@cisco.com; cpopovic@cisco.com; Tim Chown; Olaf Bonness; HahnC@t-= systems.com; Benoit Claise (bclaise); livio.zanol.puppim@gmail.com; v6ops v= 6ops WG; Ron Bonica Subject: Re: [Technical Errata Reported] RFC5375 (3309) On 8/6/12 10:28 AM, Fred Baker (fred) wrote: > My perception: we should accept the erratum. Agree? so my interpretation. 3627 was moved to historic by 6547. 6164 allows the use of /127s... 5375 maybe wrong now but the reference to 3021 is temporally correct. so yeah I guess. On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >> >> -------------------------------------- >> Type: Technical >> Reported by: L=EDvio Zanol Pereira de Souza Puppim=20 >> >> >> Section: B.2.2 >> >> Original Text >> ------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is not valid and should be strongly discouraged as >> >> documented in RFC 3627 [RFC3627]. >> >> Corrected Text >> -------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >> >> Notes >> ----- >> Maybe just remove the section B.2.2? >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please=20 >> use "Reply All" to discuss whether it should be verified or rejected.=20 >> When a decision is reached, the verifying party (IESG) can log in to=20 >> change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5375 (draft-ietf-v6ops-addcon-10) >> -------------------------------------- >> Title : IPv6 Unicast Address Assignment Considerations >> Publication Date : December 2008 >> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonnes= s, C. Hahn >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > From HahnC@t-systems.com Tue Aug 7 03:36:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19521F8609 for ; Tue, 7 Aug 2012 03:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXFxcalvlRiV for ; Tue, 7 Aug 2012 03:36:28 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 970A221F85D6 for ; Tue, 7 Aug 2012 03:36:24 -0700 (PDT) From: Received: from he113599.emea1.cds.t-internal.com ([10.125.65.118]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 07 Aug 2012 12:36:21 +0200 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE113599.emea1.cds.t-internal.com (10.125.65.118) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 7 Aug 2012 12:36:20 +0200 Received: from HE113566.emea1.cds.t-internal.com ([169.254.2.168]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Tue, 7 Aug 2012 12:36:20 +0200 To: , Date: Tue, 7 Aug 2012 12:36:18 +0200 Thread-Topic: [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNc/jYD8p8havrqUG3CmQWSwJYmpdOJ73g Message-ID: References: <20120806142829.81256B1E003@rfc-editor.org> <19217284.9895.1344274094167.JavaMail.trustmail@he111460> In-Reply-To: <19217284.9895.1344274094167.JavaMail.trustmail@he111460> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Cc: v6ops@ietf.org, livio.zanol.puppim@gmail.com, cpopovic@cisco.com, gunter@cisco.com Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 10:36:29 -0000 Yes, agreed. This looks reasonable. thanks, Christian <><><><><><><><><><><><><><> Christian Hahn T-Systems International GmbH Telekom IT Systems Integration Telekom IT Holzhauser Stra=DFe 4-8, 13509 Berlin Tel +49 30 -8353 24212 Mobile +49 170 7641791 E-Mail: hahnc@t-systems.com Internet: <> ---------------------------------- >-----Original Message----- >From: Fred Baker (fred) [mailto:fred@cisco.com]=20 >Sent: Monday, August 06, 2012 7:28 PM >To: gunter@cisco.com; cpopovic@cisco.com; Tim Chown; Olaf=20 >Bonness; Hahn, Christian; Benoit Claise (bclaise); joel=20 >jaeggli; livio.zanol.puppim@gmail.com; v6ops v6ops WG >Cc: Ron Bonica >Subject: ***CAUTION_Invalid_Signature*** Re: [Technical Errata=20 >Reported] RFC5375 (3309) > >My perception: we should accept the erratum. Agree? > >On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >>=20 >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: L=EDvio Zanol Pereira de Souza Puppim=20 >> >>=20 >> Section: B.2.2 >>=20 >> Original Text >> ------------- >> B.2.2. /127 Addresses >>=20 >>=20 >>=20 >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >>=20 >> [RFC3021], is not valid and should be strongly discouraged as >>=20 >> documented in RFC 3627 [RFC3627]. >>=20 >> Corrected Text >> -------------- >> B.2.2. /127 Addresses >>=20 >>=20 >>=20 >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >>=20 >> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >>=20 >> Notes >> ----- >> Maybe just remove the section B.2.2? >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please=20 >> use "Reply All" to discuss whether it should be verified or=20 >rejected.=20 >> When a decision is reached, the verifying party (IESG) can log in to=20 >> change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5375 (draft-ietf-v6ops-addcon-10) >> -------------------------------------- >> Title : IPv6 Unicast Address Assignment Considerations >> Publication Date : December 2008 >> Author(s) : G. Van de Velde, C. Popoviciu, T.=20 >Chown, O. Bonness, C. Hahn >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > >---------------------------------------------------- >The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan > >= From fred@cisco.com Tue Aug 7 08:23:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC16621F8717 for ; Tue, 7 Aug 2012 08:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHOkLZCSzCwe for ; Tue, 7 Aug 2012 08:23:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C55D121F8608 for ; Tue, 7 Aug 2012 08:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2785; q=dns/txt; s=iport; t=1344353029; x=1345562629; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P/x+uL/FPj8++ZaiTHZkDXPs02HJb/FD8gKh2qnYpKY=; b=LOSpxhOUTpNaR89eYB2p5Nl4FjmBCVf68JFVO/YC8GlMDZg+9KajRb3d qnUy5SWf8McRKKPpgGHGQQ5htp3o3F3aPNEWByLwJN98DZ+1zQJs99F84 NL+9ZpJWlxQMgRSM43VcODYhXf7nzPa1equP6lu9+pdYM8SQpuauZlGN5 U=; X-Files: signature.asc : 195 X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="asc'?scan'208";a="109197919" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2012 15:23:48 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q77FNmMS029450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:23:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:23:48 -0500 From: "Fred Baker (fred)" To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNdLCjD8p8havrqUG3CmQWSwJYmg== Date: Tue, 7 Aug 2012 15:23:47 +0000 Message-ID: References: <20120806142829.81256B1E003@rfc-editor.org> In-Reply-To: <20120806142829.81256B1E003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--40.204100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_5F7E1475-B28B-430E-B3D5-3F88BA2C2DB4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700 Cc: "" , "" , "" , "" , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:23:49 -0000 --Apple-Mail=_5F7E1475-B28B-430E-B3D5-3F88BA2C2DB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 We agree that this erratum is valid. On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5375, > "IPv6 Unicast Address Assignment Considerations". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >=20 > -------------------------------------- > Type: Technical > Reported by: L=EDvio Zanol Pereira de Souza Puppim = >=20 > Section: B.2.2 >=20 > Original Text > ------------- > B.2.2. /127 Addresses >=20 >=20 >=20 > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >=20 > [RFC3021], is not valid and should be strongly discouraged as >=20 > documented in RFC 3627 [RFC3627]. >=20 > Corrected Text > -------------- > B.2.2. /127 Addresses >=20 >=20 >=20 > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >=20 > [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >=20 > Notes > ----- > Maybe just remove the section B.2.2? >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5375 (draft-ietf-v6ops-addcon-10) > -------------------------------------- > Title : IPv6 Unicast Address Assignment Considerations > Publication Date : December 2008 > Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. = Bonness, C. Hahn > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_5F7E1475-B28B-430E-B3D5-3F88BA2C2DB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQITL+bjEdbHIsm0MRAhaVAJ9ecK4BK4syppkM3sE4SOZbrxoa7QCfS0qK 1kpWumtDdRaZV8te0ih94Fs= =vNYs -----END PGP SIGNATURE----- --Apple-Mail=_5F7E1475-B28B-430E-B3D5-3F88BA2C2DB4-- From joelja@bogus.com Tue Aug 7 09:34:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38FA21F84FD for ; Tue, 7 Aug 2012 09:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkb-Z0LvpSqp for ; Tue, 7 Aug 2012 09:34:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8421F84F2 for ; Tue, 7 Aug 2012 09:34:02 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q77GXwvt061903 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 7 Aug 2012 16:33:58 GMT (envelope-from joelja@bogus.com) Message-ID: <50214371.1080003@bogus.com> Date: Tue, 07 Aug 2012 09:33:53 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201208072051330785547@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 07 Aug 2012 16:33:59 +0000 (UTC) Cc: v6ops Subject: Re: [v6ops] senario of draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:34:03 -0000 On 8/7/12 8:36 AM, Fred Baker (fred) wrote: > Personally, I think you will be far better off with a router. And in any event, this is BBF territory; if the BBF wants to have IETF collusion, we can discuss that, but I think you need first to discuss it with them. Realistically if there's one customer and one or two vendors they don't need the blessing of a standards body to solve their problem... I see discussing this in the IETF essentially a question of determining if there are other networks with a similar or related problem. I agree that layer-2 interworking is not generally the domain of IETF. From despres.remi@laposte.net Tue Aug 7 10:23:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57B21F8686 for ; Tue, 7 Aug 2012 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXZhACmo3Ogq for ; Tue, 7 Aug 2012 10:23:53 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC4C21F8682 for ; Tue, 7 Aug 2012 10:23:53 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 68B4F7000083; Tue, 7 Aug 2012 19:23:52 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 0BFF370000BC; Tue, 7 Aug 2012 19:23:51 +0200 (CEST) X-SFR-UUID: 20120807172351492.0BFF370000BC@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 7 Aug 2012 19:23:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 17:23:55 -0000 Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >=20 > On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >=20 >> Hi, Fred, >>=20 >> I agree that adding an applicability statement, as you requested last = week, is an approach that improves acceptability of BCP status (as = opposed to Informational recommended by some participants in Vancouver). >>=20 >> This statement is currently: >> " 2. BCP Scenario =09 >> This BCP only applies when the following two criteria are present:=09 >> 1. There is an IPv6-only access network that uses stateful = translation [RFC6146]=09 >> 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet >>=20 >> In my understanding, it should be more complete, e.g. as follows: >>=20 >> " 2. Applicability of 464XLAT =09 >> This BCP only applies when the following three criteria are present:=09= >> 1. There is an IPv6-only access network that doesn't support DS-lite = [RFC6333] but supports NAT64 stateful translation [RFC6146] >> 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet >> 3. The lack of transparency to source-fragmented IPv4 packets that, = as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. = have DF=3D1), is considered acceptable. >=20 > So you're arguing that we need a comment in this applicability = statement regarding each other solution, or just that one? Just that one (no hidden intention!). DS-Lite is an already specified stateful solution for IPv4 customers = that have no public addresses to reach the IPv4 Internet across = IPv6-only access networks. It hasn't the limitation of item 3. If there are IPv6-only deployments where NAT64s are available but not = DS-Lite, in particular in the short term, 464XLAT is AFAIK better than = nothing, and is therefore, as said from the beginning, worth = documenting. =20 However, if DS-lite is available, using it is AFAIK better practice = (more transparent to IPv4, and very simple too in CPE/UEs). (Something more might be said for stateless solutions, but this is AFAIK = out of scope for 464XLAT.) > It seems to me that at most (1) might add "to access an IPv4 network" = or "to access the IPv4 Internet" - which are different statements. There = is no reason to go into what the other options the operator might have = chosen might be. >=20 > I'll let others comment on your third bullet. Personally, I would not = expect the implementation to require fragmentation, but would expect it = to use configuration or PMTU to ensure that the packets were small = enough. a. Applications that send UDP datagrams longer than PMTUs, which is the = case of some games AFAIK, have to fragment. (If there would be no such = applications, why to have any fragmentation in IPv6?) b. In case of UE tethering, such applications are not controlled by UEs = themselves. RD >=20 >> Comments welcome. >>=20 >> Regards, >> RD >>=20 >>=20 >> 2012-08-07 07:53, Fred Baker (fred) : >>=20 >>> I'll let the current WGLC run and then open one for 464XLAT. >>>=20 >>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>>=20 >>>>=20 >>>> v6ops chairs, >>>>=20 >>>> We have published draft-ietf-v6ops-464xlat-06. >>>> This draft is simply adding section 2 "BCP Scenario". >>>> Could you please start WGLC? >>>>=20 >>>> Thank you for your time and consideration. >>>>=20 >>>> Regards, >>>> Masanobu >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 From brian.e.carpenter@gmail.com Tue Aug 7 10:59:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44FF21F875D for ; Tue, 7 Aug 2012 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.178 X-Spam-Level: X-Spam-Status: No, score=-101.178 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfpolNZ43wpe for ; Tue, 7 Aug 2012 10:59:02 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C120221F875B for ; Tue, 7 Aug 2012 10:59:01 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2407051wib.13 for ; Tue, 07 Aug 2012 10:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rq7gzknPjb0y0+pRXUnzOq4WoITkSMF3w5Rw/r0vnlY=; b=DKP1j1QV9a+EY3kOxgK2FtEkYaJQIgM1s0mZhcU5KTSS8QAXUlR7t6kbh2YzYnv7JF CncQDpxEufytZbMHgsgWs3t6MC0yUpA/geM5rQQpUOEq2nAIWOcUUmq8wVVDcP+L8WDz cWZA9gB6ehPcAijbChCv5AnT8CP1SiIQEndSA2QFu55pKJyQkQnLR8laHqjj+5tw/D+q ERWavrdQKHPb5UZJfqHz4w2fOTVLFW6oGsAwL8HETagJmoCY3oba3jY/Z3rV1Y72N1Vy 3LXUtTrobcBT3WNfbdo/JXQF0wLT1//mwuxOwmYi5RJzKGEgLgSN56Hsqbsy6FasCgfx 0TQQ== Received: by 10.216.233.25 with SMTP id o25mr8667958weq.130.1344362340901; Tue, 07 Aug 2012 10:59:00 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-145.as13285.net. [2.102.216.145]) by mx.google.com with ESMTPS id b7sm695103wiz.9.2012.08.07.10.58.59 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 10:59:00 -0700 (PDT) Message-ID: <50215765.7060406@gmail.com> Date: Tue, 07 Aug 2012 18:59:01 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20120806142829.81256B1E003@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , "" , "" , "" , "" , "" , RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 17:59:02 -0000 Wait a minute. How can this be described as an error in 5375? 5375 was not wrong when published. The error was in 6164, which failed to formally update 5375. Surely this is a "hold for update" not "verified". Regards Brian On 07/08/2012 16:23, Fred Baker (fred) wrote: > We agree that this erratum is valid. >=20 > On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >=20 >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >> >> -------------------------------------- >> Type: Technical >> Reported by: L=C3=ADvio Zanol Pereira de Souza Puppim >> >> Section: B.2.2 >> >> Original Text >> ------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is not valid and should be strongly discouraged as >> >> documented in RFC 3627 [RFC3627]. >> >> Corrected Text >> -------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >> >> Notes >> ----- >> Maybe just remove the section B.2.2? >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >> >> -------------------------------------- >> RFC5375 (draft-ietf-v6ops-addcon-10) >> -------------------------------------- >> Title : IPv6 Unicast Address Assignment Considerations >> Publication Date : December 2008 >> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonn= ess, C. Hahn >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rbonica@juniper.net Tue Aug 7 11:37:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0972521F8653 for ; Tue, 7 Aug 2012 11:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.275 X-Spam-Level: X-Spam-Status: No, score=-106.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhWVdvKdQsMp for ; Tue, 7 Aug 2012 11:37:46 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55421F860B for ; Tue, 7 Aug 2012 11:37:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUCFgc0pgeRQRWVVIwyStYwSrSwQWxr+k@postini.com; Tue, 07 Aug 2012 11:37:44 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 11:36:34 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 11:36:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 14:36:07 -0400 From: Ronald Bonica To: Brian E Carpenter , "Fred Baker (fred)" Date: Tue, 7 Aug 2012 14:36:05 -0400 Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: Ac10xlbn+y/0VNo0TIKK93MUlTrDMAAAwHUg Message-ID: <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> In-Reply-To: <50215765.7060406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 18:37:47 -0000 QnJpYW4sDQoNCkkgYWdyZWUgdGhhdCBFcnJhdGEgMzMwOSBzaG91bGQgYmUgcHV0IGludG8gdGhl ICJob2xkIGZvciB1cGRhdGUiIHN0YXRlLCBiZWNhdXNlIFJGQyA1Mzc1IHdhcyBub3Qgd3Jvbmcg d2hlbiBpdCB3YXMgcHVibGlzaGVkLiANCg0KSG93ZXZlciwgd2UgbmVlZCB0byBmaWd1cmUgb3V0 IHdoYXQgdG8gZG8gYWJvdXQgUkZDIDYxNjQuIEkgZGltbHkgcmVjYWxsIGEgY29udmVyc2F0aW9u IGFib3V0IHRoaXMgd2hlbiBSRkMgNjE2NCB3YXMgcHVibGlzaGVkLiBUaGUgY29uc2Vuc3VzIHdh cyB0aGF0IFJGQyA2MTY0IHRydW1wcyBSRkMgNTM3NSBiZWNhdXNlIHRoZSBmb3JtZXIgaXMgb24g dGhlIFN0YW5kYXJkcyBUcmFjayB3aGlsZSB0aGUgbGF0ZXIgaXMgb25seSBJTkZPUk1BVElPTkFM LiBTbywgUkZDIDYxNjQgZG9lc24ndCBuZWVkIHRvIHVwZGF0ZSBSRkMgNTM3NS4NCg0KTG9va2lu ZyBiYWNrIG9uIGl0LCB0aGlzIGFyZ3VtZW50IGlzIHdlYWsuIEhvdyB3b3VsZCB0aGUgcmVhZGVy IG9mIDUzNzUga25vdyB0aGF0IFJGQyA2MTY0IGV4aXN0cyBpZiBpdCB3ZXJlbid0IGZvciB0aGUg dXBkYXRlIGluZm9ybWF0aW9uIGluIHRoZSBtZXRhZGF0YT8NCg0KSSB3aWxsIGNoZWNrIHdpdGgg dGhlIFJGQyBlZGl0b3IgdG8gc2VlIGlmIGl0IGlzIE9LIHRvIGFkZCBhbiBVUERBVEUgaW4gYW4g ZXJyYXRhLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJvbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K PiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDcsIDIwMTIg MTo1OSBQTQ0KPiBUbzogRnJlZCBCYWtlciAoZnJlZCkNCj4gQ2M6IDx2Nm9wc0BpZXRmLm9yZz47 IDxsaXZpby56YW5vbC5wdXBwaW1AZ21haWwuY29tPjsNCj4gPGZyZWQuYmFrZXJAY2lzY28uY29t PjsgPE9sYWYuQm9ubmVzc0B0LXN5c3RlbXMuY29tPjsNCj4gPGNwb3BvdmljQGNpc2NvLmNvbT47 IDxndW50ZXJAY2lzY28uY29tPjsgUkZDIEVycmF0YSBTeXN0ZW0NCj4gU3ViamVjdDogUmU6IFt2 Nm9wc10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzUzNzUgKDMzMDkpDQo+IA0KPiBX YWl0IGEgbWludXRlLg0KPiANCj4gSG93IGNhbiB0aGlzIGJlIGRlc2NyaWJlZCBhcyBhbiBlcnJv ciBpbiA1Mzc1PyA1Mzc1IHdhcyBub3Qgd3Jvbmcgd2hlbg0KPiBwdWJsaXNoZWQuDQo+IA0KPiBU aGUgZXJyb3Igd2FzIGluIDYxNjQsIHdoaWNoIGZhaWxlZCB0byBmb3JtYWxseSB1cGRhdGUgNTM3 NS4NCj4gDQo+IFN1cmVseSB0aGlzIGlzIGEgImhvbGQgZm9yIHVwZGF0ZSIgbm90ICJ2ZXJpZmll ZCIuDQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAwNy8wOC8yMDEyIDE2OjIz LCBGcmVkIEJha2VyIChmcmVkKSB3cm90ZToNCj4gPiBXZSBhZ3JlZSB0aGF0IHRoaXMgZXJyYXR1 bSBpcyB2YWxpZC4NCj4gPg0KPiA+IE9uIEF1ZyA2LCAyMDEyLCBhdCA3OjI4IEFNLCBSRkMgRXJy YXRhIFN5c3RlbSB3cm90ZToNCj4gPg0KPiA+PiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQg aGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM1Mzc1LA0KPiA+PiAiSVB2NiBVbmljYXN0IEFkZHJl c3MgQXNzaWdubWVudCBDb25zaWRlcmF0aW9ucyIuDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQg YmVsb3cgYW5kIGF0Og0KPiA+PiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFy Y2gucGhwP3JmYz01Mzc1JmVpZD0zMzA5DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IFR5cGU6IFRlY2huaWNhbA0KPiA+PiBSZXBvcnRlZCBi eTogTMOtdmlvIFphbm9sIFBlcmVpcmEgZGUgU291emEgUHVwcGltDQo+ID4+IDxsaXZpby56YW5v bC5wdXBwaW1AZ21haWwuY29tPg0KPiA+Pg0KPiA+PiBTZWN0aW9uOiBCLjIuMg0KPiA+Pg0KPiA+ PiBPcmlnaW5hbCBUZXh0DQo+ID4+IC0tLS0tLS0tLS0tLS0NCj4gPj4gQi4yLjIuIC8xMjcgQWRk cmVzc2VzDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAgVGhlIHVzYWdlIG9mIHRoZSAvMTI3IGFk ZHJlc3NlcywgdGhlIGVxdWl2YWxlbnQgb2YgSVB2NCdzIFJGQyAzMDIxDQo+ID4+DQo+ID4+ICAg W1JGQzMwMjFdLCBpcyBub3QgdmFsaWQgYW5kIHNob3VsZCBiZSBzdHJvbmdseSBkaXNjb3VyYWdl ZCBhcw0KPiA+Pg0KPiA+PiAgIGRvY3VtZW50ZWQgaW4gUkZDIDM2MjcgW1JGQzM2MjddLg0KPiA+ Pg0KPiA+PiBDb3JyZWN0ZWQgVGV4dA0KPiA+PiAtLS0tLS0tLS0tLS0tLQ0KPiA+PiBCLjIuMi4g LzEyNyBBZGRyZXNzZXMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICBUaGUgdXNhZ2Ugb2YgdGhl IC8xMjcgYWRkcmVzc2VzLCB0aGUgZXF1aXZhbGVudCBvZiBJUHY0J3MgUkZDIDMwMjENCj4gPj4N Cj4gPj4gICBbUkZDMzAyMV0sIGlzIHZhbGlkIGFzIHN0YXRlZCBpbiBSRkMgNjE2NCBbUkZDIDYx NjRdLg0KPiA+Pg0KPiA+PiBOb3Rlcw0KPiA+PiAtLS0tLQ0KPiA+PiBNYXliZSBqdXN0IHJlbW92 ZSB0aGUgc2VjdGlvbiBCLjIuMj8NCj4gPj4NCj4gPj4gSW5zdHJ1Y3Rpb25zOg0KPiA+PiAtLS0t LS0tLS0tLS0tDQo+ID4+IFRoaXMgZXJyYXRhIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9y dGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4gPj4gdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1 c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3INCj4gcmVqZWN0ZWQuDQo+ID4+IFdo ZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKSBjYW4g bG9nIGluIHRvDQo+ID4+IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlm IG5lY2Vzc2FyeS4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPj4gUkZDNTM3NSAoZHJhZnQtaWV0Zi12Nm9wcy1hZGRjb24tMTApDQo+ID4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IFRpdGxlICAgICAgICAg ICAgICAgOiBJUHY2IFVuaWNhc3QgQWRkcmVzcyBBc3NpZ25tZW50IENvbnNpZGVyYXRpb25zDQo+ ID4+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBEZWNlbWJlciAyMDA4DQo+ID4+IEF1dGhvcihzKSAg ICAgICAgICAgOiBHLiBWYW4gZGUgVmVsZGUsIEMuIFBvcG92aWNpdSwgVC4gQ2hvd24sIE8uDQo+ IEJvbm5lc3MsIEMuIEhhaG4NCj4gPj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IElORk9STUFUSU9O QUwNCj4gPj4gU291cmNlICAgICAgICAgICAgICA6IElQdjYgT3BlcmF0aW9ucw0KPiA+PiBBcmVh ICAgICAgICAgICAgICAgIDogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudA0KPiA+PiBTdHJlYW0g ICAgICAgICAgICAgIDogSUVURg0KPiA+PiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IFRoZSBpZ25vcmFuY2Ugb2YgaG93IHRvIHVzZSBuZXcga25vd2xlZGdlIHN0b2NrcGls ZXMgZXhwb25lbnRpYWxseS4NCj4gPiAgICAtIE1hcnNoYWxsIE1jTHVoYW4NCj4gPg0KPiA+DQo+ ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+IC0tDQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlz dA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From markzzzsmith@yahoo.com.au Tue Aug 7 13:31:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5A21F8672 for ; Tue, 7 Aug 2012 13:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaH5dO3ZDxdg for ; Tue, 7 Aug 2012 13:31:52 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id 99C8E21F859F for ; Tue, 7 Aug 2012 13:31:52 -0700 (PDT) Received: from [98.139.91.69] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 07 Aug 2012 20:31:48 -0000 Received: from [98.139.91.19] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 07 Aug 2012 20:31:48 -0000 Received: from [127.0.0.1] by omp1019.mail.sp2.yahoo.com with NNFMP; 07 Aug 2012 20:31:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 419466.27161.bm@omp1019.mail.sp2.yahoo.com Received: (qmail 59791 invoked by uid 60001); 7 Aug 2012 20:31:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344371507; bh=OX2bhfAb3T6+EZKqYbr3M8TLiTVfbrjIRqRMaHIGPrM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=c/yk6rcUzb1DscskIgBRHVrig/ppR+wDPTh16Ohi/exzNEdV+jvjZ1+Nt0IGCdRtPJIq67nJQb0UR76T1j/YQWU41x2/inidcJFT+QkXH8URZ+RAjWOZx+cGF99sgUAE5uJN+NpiWBsr9CFDcG2/S6jMcE34YMvei4ORnuviwiQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rJq+DRzJVj7VhfW3jKiPGN8p2gQJP4gAw0EaWMWEgXS7w8YQAl8fcyHEQ2uH1fqnnlXYHRxH87XL6jlolFb1AC1Afqid8OLdtKa+b4VtpNGwR6DNwX2wDy8TJ8kP+H/1OwRXQIqb75H2MMFKtmi8FOL2HZeJSfKSkitZpSM1H54=; X-YMail-OSG: Wyd3kZMVM1lfukQCBrxcgawn_FXNRLhN_zWIVrJLvj4iuYL .pKvzNuvCwNvNGd4jN4tuMeAsx3.Fhvgql2MMU5skVXL2rKFqjsdEDjxItLL kTKCAMit1frZHDHhKRSpZ_Pi8QvNWMiAjmbbRSKvTnTGKQS_VZd_7PxXcg_Y UXBAxp8zOnY4EGdfA4s1glDheFPPb0X_.rkzfA1f4bPA69ZGCVJYtBTiYCwa 6l8LDrzGQE8DH6vTQGzAx77AQjYS4YaD6CJ5ewDhVATfEXgtCv9D1oYy6P6k TYkk2GSwkLp8Q0fVwJ28PrVoNXXYQvoEsH9luosethh1t1HiFvUYCSQKTKx9 QWrlKTNT4QqP70417DZgfrMpfuSy667mlJjFuj5uEVKF.25TnZFQLDlQT7YI PmpEOuCUOC7SWKjMHeKQWH9XLzPwqfogysBrpbmHIBe_2RlWwhiAIvFlwXlS 3z7DO9asLOG9w9n3nGHFjGLLymuUuT_bUguLYfTQGAy0- Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Tue, 07 Aug 2012 13:31:47 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> <20120807121116.GI38127@Space.Net> Message-ID: <1344371507.52191.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Tue, 7 Aug 2012 13:31:47 -0700 (PDT) From: Mark ZZZ Smith To: Gert Doering In-Reply-To: <20120807121116.GI38127@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:31:53 -0000 Hi Gert,=0A=0A=0A----- Original Message -----=0A> From: Gert Doering =0A> To: Mark ZZZ Smith =0A> Cc: Fred = Baker (fred) ; "v6ops@ietf.org" ; V6ops Cha= irs ; Ron Bonica =0A> Sent: Tu= esday, 7 August 2012 10:11 PM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-icp= -guidance WGLC=0A> =0A> Hi,=0A> =0A> On Tue, Aug 07, 2012 at 02:24:58AM -07= 00, Mark ZZZ Smith wrote:=0A>> As for usefulness to it's target audience, = I think it will be=0A>> very useful, as perhaps it may have prevented the = following ICP=0A>> choosing to deploy an IPv6 only production network and = then completely=0A>> misusing NAT64 to try to provide IPv4 and IPv6 client= facing services.=0A> =0A> So how exactly would that be "misuse"?=0A>=A0=0A= > It's quite reasonable to run single-stack inside, and if you need lots=0A= =0A> of addresses, make that IPv6-only.=A0 The outside needs to be dual-sta= cked,=0A> and NAT64 (with preconfigured mappings) will do that for you, in = a =0A> nice and stateless way.=0A>=A0=0A=0AI think when you use something o= utside of the scenario it was designed for, there is a risk that things won= 't work well.=0A=0AAccording to RFC6145,=A0=0A=0A=A0 =A0This document descr= ibes stateful NAT64 translation, which allows=0A=A0 =A0IPv6-only clients to= contact IPv4 servers using unicast UDP, TCP, or=0A=A0 =A0ICMP. =A0One or m= ore public IPv4 addresses assigned to a NAT64=0A=A0 =A0translator are share= d among several IPv6-only clients. =A0When stateful=0A=A0 =A0NAT64 is used = in conjunction with DNS64, no changes are usually=0A=A0 =A0required in the = IPv6 client or the IPv4 server.=0A=0ASo NAT64 wasn't designed for a scenari= o where IPv4-only clients contact IPv6 servers. That's not to say it won't = work, but it may not work well, and with their very general conclusion that= "IPv6 is hard" (and plenty of people's experience is that it isn't anywher= e near as hard as their story suggests), it didn't work well for them. That= says to me that they weren't using the right tool for the job. They were m= isusing the tool by choosing the wrong one.=0A=0AI think they developed or = were given false expectations of what NAT64 would do for them, and that is = where they were let down. Unfortunately some brief Internet searching on de= ployment choices or advice, or even an email to the mailing list they poste= d their story to, asking people's advice, would probably have saved them a = lot of grief.=A0This draft should hopefully prevent those sorts of false ex= pectations, and false conclusions about how hard or not IPv6 is deploy in t= he future.=0A=0ARegards,=0AMark. From fred@cisco.com Tue Aug 7 14:07:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8621F85CC for ; Tue, 7 Aug 2012 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny3A-duCaMkY for ; Tue, 7 Aug 2012 14:07:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87521F859A for ; Tue, 7 Aug 2012 14:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2081; q=dns/txt; s=iport; t=1344373678; x=1345583278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8qVkfpElu/NIi8v8Ny8OY69NNHAZbskJ23VYyne/b8U=; b=UWFfsXJdsGVSZK7+9mh4CwR+NFQjoH1TyzUv+OKVzIDgcxXb/i9E1i0b P12QRtX1v+Wi9mYAR3QrpJnTutAg45JCJPh9EQiRjWzQ5jvYv34mIc+kl GAySab1+OWejq6Qy0UVVvEed5TCRUQEDZ847C6dUb4SirPwUeQ13jTiej Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFiCIVCtJV2Y/2dsb2JhbABFuWaBB4IgAQEBAwESAWYFCwIBCEYyJQIEDieHZQYLmyugXQSLD4YAYAOIGI0wjiaBZoJf X-IronPort-AV: E=Sophos;i="4.77,728,1336348800"; d="scan'208";a="109353043" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 07 Aug 2012 21:07:57 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q77L7viE015285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 21:07:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 16:07:57 -0500 From: "Fred Baker (fred)" To: Mark ZZZ Smith Thread-Topic: [v6ops] draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNdOC37ojmETvFgEKXJWRgW2RPjA== Date: Tue, 7 Aug 2012 21:07:56 +0000 Message-ID: <7826A281-0D1A-430D-8523-156F900C4E4E@cisco.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> <20120807121116.GI38127@Space.Net> <1344371507.52191.YahooMailNeo@web32502.mail.mud.yahoo.com> In-Reply-To: <1344371507.52191.YahooMailNeo@web32502.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.001 x-tm-as-result: No--39.085800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:07:58 -0000 On Aug 7, 2012, at 1:31 PM, Mark ZZZ Smith wrote: > According to RFC6145,=20 >=20 > This document describes stateful NAT64 translation, which allows > IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or > ICMP. One or more public IPv4 addresses assigned to a NAT64 > translator are shared among several IPv6-only clients. When stateful > NAT64 is used in conjunction with DNS64, no changes are usually > required in the IPv6 client or the IPv4 server. >=20 > So NAT64 wasn't designed for a scenario where IPv4-only clients contact I= Pv6 servers.=20 Your quote is from RFC 6146, and you are correct with regard to stateful NA= T64.=20 RFC 6145, which is stateless and uses an IPv6 address that contains an embe= dded IPv4 address, is very much defined to enable bidirectional session ini= tiation between systems with the stated type of address. https://tools.ietf.org/html/rfc6052 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 bytes= ) (Updates RFC4291) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6144 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc6145 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Status: PROPOSE= D STANDARD) https://tools.ietf.org/html/rfc6146 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6147 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED STANDARD) From arusso@amsl.com Tue Aug 7 12:54:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A8221F8758 for ; Tue, 7 Aug 2012 12:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+gncIijT+Fg for ; Tue, 7 Aug 2012 12:54:58 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 17ED021F8744 for ; Tue, 7 Aug 2012 12:54:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D3B4F12C8B8; Tue, 7 Aug 2012 12:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhvYbVBldaoG; Tue, 7 Aug 2012 12:54:57 -0700 (PDT) Received: from [192.168.0.105] (unknown [184.71.9.26]) by c8a.amsl.com (Postfix) with ESMTPSA id D1DE412C88F; Tue, 7 Aug 2012 12:54:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Alice Russo In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> Date: Tue, 7 Aug 2012 12:54:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 07 Aug 2012 16:14:06 -0700 Cc: "" , "" , "" , "" , RFC Errata System , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:54:58 -0000 Ron, > I will check with the RFC editor to see if it is OK to add an UPDATE = in an errata. Please see this IESG statement: = http://www.ietf.org/iesg/statement/rfc-metadata-errata.html. If there = is an errata report regarding the metadata of an RFC *and* the verifying = party marks it as Verified, the RFC Editor will update the RFC's = metadata accordingly (which appears in the RFC Index, info page, etc.). Thank you. RFC Editor/ar On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > Brian, >=20 > I agree that Errata 3309 should be put into the "hold for update" = state, because RFC 5375 was not wrong when it was published.=20 >=20 > However, we need to figure out what to do about RFC 6164. I dimly = recall a conversation about this when RFC 6164 was published. The = consensus was that RFC 6164 trumps RFC 5375 because the former is on the = Standards Track while the later is only INFORMATIONAL. So, RFC 6164 = doesn't need to update RFC 5375. >=20 > Looking back on it, this argument is weak. How would the reader of = 5375 know that RFC 6164 exists if it weren't for the update information = in the metadata? >=20 > I will check with the RFC editor to see if it is OK to add an UPDATE = in an errata. >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Brian E Carpenter >> Sent: Tuesday, August 07, 2012 1:59 PM >> To: Fred Baker (fred) >> Cc: ; ; >> ; ; >> ; ; RFC Errata System >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) >>=20 >> Wait a minute. >>=20 >> How can this be described as an error in 5375? 5375 was not wrong = when >> published. >>=20 >> The error was in 6164, which failed to formally update 5375. >>=20 >> Surely this is a "hold for update" not "verified". >>=20 >> Regards >> Brian >>=20 >> On 07/08/2012 16:23, Fred Baker (fred) wrote: >>> We agree that this erratum is valid. >>>=20 >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: >>>=20 >>>> The following errata report has been submitted for RFC5375, >>>> "IPv6 Unicast Address Assignment Considerations". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim >>>> >>>>=20 >>>> Section: B.2.2 >>>>=20 >>>> Original Text >>>> ------------- >>>> B.2.2. /127 Addresses >>>>=20 >>>>=20 >>>>=20 >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >>>>=20 >>>> [RFC3021], is not valid and should be strongly discouraged as >>>>=20 >>>> documented in RFC 3627 [RFC3627]. >>>>=20 >>>> Corrected Text >>>> -------------- >>>> B.2.2. /127 Addresses >>>>=20 >>>>=20 >>>>=20 >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >>>>=20 >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >>>>=20 >>>> Notes >>>> ----- >>>> Maybe just remove the section B.2.2? >>>>=20 >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >> rejected. >>>> When a decision is reached, the verifying party (IESG) can log in = to >>>> change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC5375 (draft-ietf-v6ops-addcon-10) >>>> -------------------------------------- >>>> Title : IPv6 Unicast Address Assignment = Considerations >>>> Publication Date : December 2008 >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. >> Bonness, C. Hahn >>>> Category : INFORMATIONAL >>>> Source : IPv6 Operations >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>=20 >>> ---------------------------------------------------- >>> The ignorance of how to use new knowledge stockpiles exponentially. >>> - Marshall McLuhan >>>=20 >>>=20 >>>=20 >>> = --------------------------------------------------------------------- >> - >>> -- >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From livio.zanol.puppim@gmail.com Tue Aug 7 16:07:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2021F8653 for ; Tue, 7 Aug 2012 16:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seJzg7IL-tPW for ; Tue, 7 Aug 2012 16:07:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68C7221F863B for ; Tue, 7 Aug 2012 16:07:33 -0700 (PDT) Received: by yhq56 with SMTP id 56so177820yhq.31 for ; Tue, 07 Aug 2012 16:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rL3ln8UvijzEpi1yPt+vdI0X+LYSKhKGCDL7EsBcDc4=; b=PadgJTbqE2oEoZbz2rYYh/OSLCENpByTqleIkirZLZpTCi4+zFuKj/Dojj3rP5yaFt Ycv/bruTc7yQ5nwAfPIGrqNNfL2iDiSm5hiF0KMwFB0IMy6lbAaB5ijrbUlmEn9SVokZ yyTxqnQ6Fxlu7PKhQOD9UuT/jXv/NSmqAFn0XiIPGSgMv3hycQUQ0HT/q4ObfS9IT8jh hBey40iWRFLTcGSsILMLmkevQ2i87t7uKRbLrhsz+aBAO1g+ebb+QzOzJIE/PSvmmHAK iWUp6axFCHXlOLLyIccW+FqbloCZelIF+Zcbu1k0TwwGabxsbluvUC/RuD+naLbJ8Epu HmwQ== MIME-Version: 1.0 Received: by 10.60.2.3 with SMTP id 3mr27809000oeq.0.1344380852716; Tue, 07 Aug 2012 16:07:32 -0700 (PDT) Received: by 10.76.22.230 with HTTP; Tue, 7 Aug 2012 16:07:32 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> Date: Tue, 7 Aug 2012 20:07:32 -0300 Message-ID: From: Livio Zanol Puppim To: Ronald Bonica Content-Type: multipart/alternative; boundary=e89a8fb205f22b453d04c6b50fab X-Mailman-Approved-At: Tue, 07 Aug 2012 16:14:06 -0700 Cc: "" , "" , Alice Russo , "" , RFC Errata System , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 23:09:48 -0000 --e89a8fb205f22b453d04c6b50fab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello guys. Just to give you more information: - RFC 5375 state that you should not use /127 address and makes a reference to RFC 3627. - RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 and 5375 are potentially wrong, but did not make any recommendation about it. - RFC 6547 was published to overcome this error, and proposes that RFC 3627 should move to historic status, updating the RFC 6177, but again, did not mention RFC 5375. - An e-mail has been sent to the WG of the RFC 6547, but no answers were given. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html) - I've sent an erratum to RFC 5375 about this, which you guys are discussing. So, what to do next? Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update to RFC 5375? I really don't know. As I've stated in an e-mail to rfc-interest mailing list, I'm just a reader and saw this /127 text while reading RFC 5375. The only thing that I'm sure, is that other readers of RFC 5375 would not want to know that the recommendation about /127, at B.2.2 sector is misguided after they have elaborated an address assignment project. Sometimes, you only read the text, and do not click on every RFC linked in it. I have full confidence in the WG, and I'm sure you will find the right solution. Thank you for your time. Best regards, L=EDvio Zanol Puppim 2012/8/7 Ronald Bonica > Hi Alice, > > Thanks for this reminder! I will consult with the WG and IESG to make sur= e > that nobody objects. > > Ron > > > -----Original Message----- > > From: Alice Russo [mailto:arusso@amsl.com] > > Sent: Tuesday, August 07, 2012 3:55 PM > > To: Ronald Bonica > > Cc: Brian E Carpenter; Fred Baker (fred); ; > > ; ; > > ; ; ; > > RFC Errata System > > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > > > Ron, > > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > > in an errata. > > > > > > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > > metadata-errata.html. If there is an errata report regarding the > > metadata of an RFC *and* the verifying party marks it as Verified, the > > RFC Editor will update the RFC's metadata accordingly (which appears in > > the RFC Index, info page, etc.). > > > > Thank you. > > RFC Editor/ar > > > > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > > > > > Brian, > > > > > > I agree that Errata 3309 should be put into the "hold for update" > > state, because RFC 5375 was not wrong when it was published. > > > > > > However, we need to figure out what to do about RFC 6164. I dimly > > recall a conversation about this when RFC 6164 was published. The > > consensus was that RFC 6164 trumps RFC 5375 because the former is on > > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > > doesn't need to update RFC 5375. > > > > > > Looking back on it, this argument is weak. How would the reader of > > 5375 know that RFC 6164 exists if it weren't for the update information > > in the metadata? > > > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > > in an errata. > > > > > > Ron > > > > > > > > >> -----Original Message----- > > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > >> Behalf Of Brian E Carpenter > > >> Sent: Tuesday, August 07, 2012 1:59 PM > > >> To: Fred Baker (fred) > > >> Cc: ; ; > > >> ; ; > > >> ; ; RFC Errata System > > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > >> > > >> Wait a minute. > > >> > > >> How can this be described as an error in 5375? 5375 was not wrong > > >> when published. > > >> > > >> The error was in 6164, which failed to formally update 5375. > > >> > > >> Surely this is a "hold for update" not "verified". > > >> > > >> Regards > > >> Brian > > >> > > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > > >>> We agree that this erratum is valid. > > >>> > > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > > >>> > > >>>> The following errata report has been submitted for RFC5375, > > >>>> "IPv6 Unicast Address Assignment Considerations". > > >>>> > > >>>> -------------------------------------- > > >>>> You may review the report below and at: > > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > > >>>> > > >>>> -------------------------------------- > > >>>> Type: Technical > > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > > >>>> > > >>>> > > >>>> Section: B.2.2 > > >>>> > > >>>> Original Text > > >>>> ------------- > > >>>> B.2.2. /127 Addresses > > >>>> > > >>>> > > >>>> > > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > > 3021 > > >>>> > > >>>> [RFC3021], is not valid and should be strongly discouraged as > > >>>> > > >>>> documented in RFC 3627 [RFC3627]. > > >>>> > > >>>> Corrected Text > > >>>> -------------- > > >>>> B.2.2. /127 Addresses > > >>>> > > >>>> > > >>>> > > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > > 3021 > > >>>> > > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > > >>>> > > >>>> Notes > > >>>> ----- > > >>>> Maybe just remove the section B.2.2? > > >>>> > > >>>> Instructions: > > >>>> ------------- > > >>>> This errata is currently posted as "Reported". If necessary, > > please > > >>>> use "Reply All" to discuss whether it should be verified or > > >> rejected. > > >>>> When a decision is reached, the verifying party (IESG) can log in > > >>>> to change the status and edit the report, if necessary. > > >>>> > > >>>> -------------------------------------- > > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > > >>>> -------------------------------------- > > >>>> Title : IPv6 Unicast Address Assignment > > Considerations > > >>>> Publication Date : December 2008 > > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > > >> Bonness, C. Hahn > > >>>> Category : INFORMATIONAL > > >>>> Source : IPv6 Operations > > >>>> Area : Operations and Management > > >>>> Stream : IETF > > >>>> Verifying Party : IESG > > >>> > > >>> ---------------------------------------------------- > > >>> The ignorance of how to use new knowledge stockpiles exponentially. > > >>> - Marshall McLuhan > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------------------- > > - > > >>> - > > >> - > > >>> -- > > >>> > > >>> _______________________________________________ > > >>> v6ops mailing list > > >>> v6ops@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/v6ops > > >> > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > -- --e89a8fb205f22b453d04c6b50fab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello guys.

Just to give you more information= :
- RFC 5375 state that you should not use /127 address and makes= a reference to RFC 3627.

- RFC 6177 came out as a= standard, and in section 4 states that RFCs 3627 and 5375 are potentially = wrong, but did not make any recommendation about it.

- RFC 6547 was published to overcome this error, and pr= oposes that RFC 3627 should move to historic status, updating the RFC 6177,= but again, did not mention RFC 5375.

- An e-mail = has been sent to the WG of the RFC 6547, but no answers were given. (http:= //www.ietf.org/mail-archive/web/ipv6/current/msg16203.html)

- I've sent an erratum to RFC 5375 about this, whic= h you guys are discussing.

So, what to do next?
Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an = update to RFC 5375?

I really don't know. As I've stated in an e-mai= l to rfc-interest mailing list, I'm just a reader and saw this /127 tex= t while reading RFC 5375.

The only thing that I= 9;m sure, is that other readers of RFC 5375 would not want to know that the= recommendation about /127, at B.2.2 sector is misguided after they have el= aborated an address assignment project. Sometimes, you only read the text, = and do not click on every RFC linked in it.

I have full confidence in the WG, and I'm sure you = will find the right solution.

Thank you for your t= ime. Best regards,

L=EDvio Zanol Puppim

2012/8/7 Ronald Bonica <= ;rbonica@juniper.n= et>
Hi Alice,

Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ron

> -----Original Message-----
> From: Alice Russo [mailto:arusso@amsl.com]
> Sent: Tuesday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Carpenter; Fred Baker (fred); <v6ops@ietf.org>;
> <= livio.zanol.puppim@gmail.com>; <fred.baker@cisco.com>;
> <Ol= af.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>;
> RFC Errata System
> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)
>
> Ron,
>
> > I will check with the RFC editor to see if it is OK to add an UPD= ATE
> in an errata.
>
>
> Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc-=
> metadata-errata.html. =A0If there is an errata report regarding the > metadata of an RFC *and* the verifying party marks it as Verified, the=
> RFC Editor will update the RFC's metadata accordingly (which appea= rs in
> the RFC Index, info page, etc.).
>
> Thank you.
> RFC Editor/ar
>
> On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote:
>
> > Brian,
> >
> > I agree that Errata 3309 should be put into the "hold for up= date"
> state, because RFC 5375 was not wrong when it was published.
> >
> > However, we need to figure out what to do about RFC 6164. I dimly=
> recall a conversation about this when RFC 6164 was published. The
> consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 616= 4
> doesn't need to update RFC 5375.
> >
> > Looking back on it, this argument is weak. How would the reader o= f
> 5375 know that RFC 6164 exists if it weren't for the update inform= ation
> in the metadata?
> >
> > I will check with the RFC editor to see if it is OK to add an UPD= ATE
> in an errata.
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron
> >
> >
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> >> Behalf Of Brian E Carpenter
> >> Sent: Tuesday, August 07, 2012 1:59 PM
> >> To: Fred Baker (fred)
> >> Cc: <v= 6ops@ietf.org>; <livio.zanol.puppim@gmail.com>;
> >> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems.com>;
> >> <c= popovic@cisco.com>; <gunter@cisco.com>; RFC Errata System
> >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (330= 9)
> >>
> >> Wait a minute.
> >>
> >> How can this be described as an error in 5375? 5375 was not w= rong
> >> when published.
> >>
> >> The error was in 6164, which failed to formally update 5375.<= br> > >>
> >> Surely this is a "hold for update" not "verifi= ed".
> >>
> >> Regards
> >> =A0 Brian
> >>
> >> On 07/08/2012 16:23, Fred Baker (fred) wrote:
> >>> We agree that this erratum is valid.
> >>>
> >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote:
> >>>
> >>>> The following errata report has been submitted for RF= C5375,
> >>>> "IPv6 Unicast Address Assignment Considerations&= quot;.
> >>>>
> >>>> --------------------------------------
> >>>> You may review the report below and at:
> >>>> http://www.rfc-editor.org/er= rata_search.php?rfc=3D5375&eid=3D3309
> >>>>
> >>>> --------------------------------------
> >>>> Type: Technical
> >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> <livio.zanol.puppim@gmail.com>
> >>>>
> >>>> Section: B.2.2
> >>>>
> >>>> Original Text
> >>>> -------------
> >>>> B.2.2. /127 Addresses
> >>>>
> >>>>
> >>>>
> >>>> =A0The usage of the /127 addresses, the equivalent of= IPv4's RFC
> 3021
> >>>>
> >>>> =A0[RFC3021], is not valid and should be strongly dis= couraged as
> >>>>
> >>>> =A0documented in RFC 3627 [RFC3627].
> >>>>
> >>>> Corrected Text
> >>>> --------------
> >>>> B.2.2. /127 Addresses
> >>>>
> >>>>
> >>>>
> >>>> =A0The usage of the /127 addresses, the equivalent of= IPv4's RFC
> 3021
> >>>>
> >>>> =A0[RFC3021], is valid as stated in RFC 6164 [RFC 616= 4].
> >>>>
> >>>> Notes
> >>>> -----
> >>>> Maybe just remove the section B.2.2?
> >>>>
> >>>> Instructions:
> >>>> -------------
> >>>> This errata is currently posted as "Reported&quo= t;. If necessary,
> please
> >>>> use "Reply All" to discuss whether it shoul= d be verified or
> >> rejected.
> >>>> When a decision is reached, the verifying party (IESG= ) can log in
> >>>> to change the status and edit the report, if necessar= y.
> >>>>
> >>>> --------------------------------------
> >>>> RFC5375 (draft-ietf-v6ops-addcon-10)
> >>>> --------------------------------------
> >>>> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : IPv6 Unicast Addr= ess Assignment
> Considerations
> >>>> Publication Date =A0 =A0: December 2008
> >>>> Author(s) =A0 =A0 =A0 =A0 =A0 : G. Van de Velde, C. P= opoviciu, T. Chown, O.
> >> Bonness, C. Hahn
> >>>> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL
> >>>> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: IPv6 Operations > >>>> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and = Management
> >>>> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> >>>> Verifying Party =A0 =A0 : IESG
> >>>
> >>> ----------------------------------------------------
> >>> The ignorance of how to use new knowledge stockpiles expo= nentially.
> >>> =A0 - Marshall McLuhan
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------= ----------
> -
> >>> -
> >> -
> >>> --
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/v6ops




--
=
--e89a8fb205f22b453d04c6b50fab-- From rbonica@juniper.net Tue Aug 7 13:02:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958FB11E80B8 for ; Tue, 7 Aug 2012 13:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.273 X-Spam-Level: X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFSZpmr3EOsZ for ; Tue, 7 Aug 2012 13:02:57 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 035F121F86D5 for ; Tue, 7 Aug 2012 13:02:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUCF0atJ2b8NY779FBTc3nbE1hA9n/dUd@postini.com; Tue, 07 Aug 2012 13:02:57 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 13:02:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 16:02:47 -0400 From: Ronald Bonica To: Alice Russo Date: Tue, 7 Aug 2012 16:02:46 -0400 Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: Ac101oewTNkmNWdjRUG5SRp5bDSb4gAAFx2w Message-ID: <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> In-Reply-To: <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Aug 2012 16:14:11 -0700 Cc: "" , "" , "" , "" , RFC Errata System , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:02:58 -0000 Hi Alice, Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects. Ron > -----Original Message----- > From: Alice Russo [mailto:arusso@amsl.com] > Sent: Tuesday, August 07, 2012 3:55 PM > To: Ronald Bonica > Cc: Brian E Carpenter; Fred Baker (fred); ; > ; ; > ; ; ; > RFC Errata System > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) >=20 > Ron, >=20 > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. >=20 >=20 > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > metadata-errata.html. If there is an errata report regarding the > metadata of an RFC *and* the verifying party marks it as Verified, the > RFC Editor will update the RFC's metadata accordingly (which appears in > the RFC Index, info page, etc.). >=20 > Thank you. > RFC Editor/ar >=20 > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: >=20 > > Brian, > > > > I agree that Errata 3309 should be put into the "hold for update" > state, because RFC 5375 was not wrong when it was published. > > > > However, we need to figure out what to do about RFC 6164. I dimly > recall a conversation about this when RFC 6164 was published. The > consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > doesn't need to update RFC 5375. > > > > Looking back on it, this argument is weak. How would the reader of > 5375 know that RFC 6164 exists if it weren't for the update information > in the metadata? > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > > Ron > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Tuesday, August 07, 2012 1:59 PM > >> To: Fred Baker (fred) > >> Cc: ; ; > >> ; ; > >> ; ; RFC Errata System > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > >> > >> Wait a minute. > >> > >> How can this be described as an error in 5375? 5375 was not wrong > >> when published. > >> > >> The error was in 6164, which failed to formally update 5375. > >> > >> Surely this is a "hold for update" not "verified". > >> > >> Regards > >> Brian > >> > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > >>> We agree that this erratum is valid. > >>> > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >>> > >>>> The following errata report has been submitted for RFC5375, > >>>> "IPv6 Unicast Address Assignment Considerations". > >>>> > >>>> -------------------------------------- > >>>> You may review the report below and at: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > >>>> > >>>> -------------------------------------- > >>>> Type: Technical > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> > >>>> > >>>> Section: B.2.2 > >>>> > >>>> Original Text > >>>> ------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is not valid and should be strongly discouraged as > >>>> > >>>> documented in RFC 3627 [RFC3627]. > >>>> > >>>> Corrected Text > >>>> -------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > >>>> > >>>> Notes > >>>> ----- > >>>> Maybe just remove the section B.2.2? > >>>> > >>>> Instructions: > >>>> ------------- > >>>> This errata is currently posted as "Reported". If necessary, > please > >>>> use "Reply All" to discuss whether it should be verified or > >> rejected. > >>>> When a decision is reached, the verifying party (IESG) can log in > >>>> to change the status and edit the report, if necessary. > >>>> > >>>> -------------------------------------- > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > >>>> -------------------------------------- > >>>> Title : IPv6 Unicast Address Assignment > Considerations > >>>> Publication Date : December 2008 > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > >> Bonness, C. Hahn > >>>> Category : INFORMATIONAL > >>>> Source : IPv6 Operations > >>>> Area : Operations and Management > >>>> Stream : IETF > >>>> Verifying Party : IESG > >>> > >>> ---------------------------------------------------- > >>> The ignorance of how to use new knowledge stockpiles exponentially. > >>> - Marshall McLuhan > >>> > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> - > >> - > >>> -- > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Tue Aug 7 16:22:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4021F8674 for ; Tue, 7 Aug 2012 16:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGqHEH6Y3TkA for ; Tue, 7 Aug 2012 16:22:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9F621F8652 for ; Tue, 7 Aug 2012 16:22:20 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so175879vcb.31 for ; Tue, 07 Aug 2012 16:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jayNcbKUxpil4lkqtzGFSdXDZ+AKlpN/yUOWYx0aGxs=; b=p4tD/YAliFRp+doa94wYF6U07664eqMK+KZeb2YkJMa6qtq4GrzgvNZ0YCapvw75El CfbHNnqXWQUx3Zp0HtM7yT45um3GIBkcJLS14uWQFsPpj5V9gdV65Px2MJquH5YTes60 E3vlkfipeIokbvfmaftYNcutsXNFESmGoVeeG7WU4WXqGKR1FS9gSyLHNLG5kMF7BmwD vklUs6lXTqB/32PIn5h4ljplaRneuIQIW9sT6UN0DgfIjtQ90KXZJJQkx0z4i3pyvWyO Woup8t72YiEUKaLNnnWPMu1JocQnYZYQaoM7oBeGcYQdCnOJpEqOBUsLOrCNhNrjgOa3 amFA== MIME-Version: 1.0 Received: by 10.220.119.204 with SMTP id a12mr7244093vcr.66.1344381739731; Tue, 07 Aug 2012 16:22:19 -0700 (PDT) Received: by 10.58.106.114 with HTTP; Tue, 7 Aug 2012 16:22:19 -0700 (PDT) In-Reply-To: <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> Date: Wed, 8 Aug 2012 07:22:19 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 23:22:25 -0000 Hello Remi and authors, I'm supporting the BCP status because it is essential to guarantee multiple compatible implementations. More comments and proposed texts are inline. 2012/8/8, R=E9mi Despr=E9s : > > Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : > >> >> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >> >>> Hi, Fred, >>> >>> I agree that adding an applicability statement, as you requested last >>> week, is an approach that improves acceptability of BCP status (as >>> opposed to Informational recommended by some participants in Vancouver)= . >>> >>> This statement is currently: >>> " 2. BCP Scenario =09 >>> This BCP only applies when the following two criteria are present:=09 >>> 1. There is an IPv6-only access network that uses stateful translation >>> [RFC6146]=09 >>> 2. There are IPv4-only applications or hosts that must communicate acro= ss >>> the IPv6-only access network to reach the IPv4 Internet >>> >>> In my understanding, it should be more complete, e.g. as follows: >>> >>> " 2. Applicability of 464XLAT =09 >>> This BCP only applies when the following three criteria are present:=09 >>> 1. There is an IPv6-only access network that doesn't support DS-lite >>> [RFC6333] but supports NAT64 stateful translation [RFC6146] >>> 2. There are IPv4-only applications or hosts that must communicate acro= ss >>> the IPv6-only access network to reach the IPv4 Internet >>> 3. The lack of transparency to source-fragmented IPv4 packets that, as >>> recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. ha= ve >>> DF=3D1), is considered acceptable. >> >> So you're arguing that we need a comment in this applicability statement >> regarding each other solution, or just that one? > > Just that one (no hidden intention!). > > DS-Lite is an already specified stateful solution for IPv4 customers tha= t > have no public addresses to reach the IPv4 Internet across IPv6-only acce= ss > networks. It hasn't the limitation of item 3. > If there are IPv6-only deployments where NAT64s are available but not > DS-Lite, in particular in the short term, 464XLAT is AFAIK better than > nothing, and is therefore, as said from the beginning, worth documenting. > However, if DS-lite is available, using it is AFAIK better practice (more > transparent to IPv4, and very simple too in CPE/UEs). I see the fairy decision choosing NAT64 other than DS-lite in 464xlat because it could provide functional compability with ACL and many network provisioning facilities, especially in a mobile environment. Also agree Fred's comments "There is no reason to go into what the other options the operator might have chosen might be." > (Something more might be said for stateless solutions, but this is AFAIK = out > of scope for 464XLAT.) > > >> It seems to me that at most (1) might add "to access an IPv4 network" or >> "to access the IPv4 Internet" - which are different statements. There is >> no reason to go into what the other options the operator might have chos= en >> might be. >> >> I'll let others comment on your third bullet. Personally, I would not >> expect the implementation to require fragmentation, but would expect it = to >> use configuration or PMTU to ensure that the packets were small enough. > > a. Applications that send UDP datagrams longer than PMTUs, which is the c= ase > of some games AFAIK, have to fragment. (If there would be no such > applications, why to have any fragmentation in IPv6?) > > b. In case of UE tethering, such applications are not controlled by UEs > themselves. RFC 4821 says: "It is RECOMMENDED that IPv4 implementations use a strategy that mimics IPv6 functionality. When an application sends datagrams that are larger than the effective Path MTU, they SHOULD be fragmented to the Path MTU in the host IP layer even if they are smaller than the MTU of the first link, directly attached to the host. The DF bit SHOULD be set on the fragments, so they will not be fragmented again in the network." If I understood correctly, that would result in the case "DF=3D1 MF=3D1". Some discussions reported that is a rare case. AFAIK, there were no obsevered impacts to network so far. Therefore, I guess that should not be a stumbling block to BCP if we could identify the problem properly. Considering above, I'm trying to propose some texts to fix the gap. Hope that could help. " This BCP is applied because 464xlat leverages available host/router implementations by combining existing and well-known stateful protocol translation [RFC6146] and stateless protocol translation [RFC6145]. It's helpful to promote the mechanism introduction as an immediate instantiation, which is justified as a good applicability to BCP status [RFC2026]. On the other hand, it's worth to be noted that the processing involved in the framework may not achieve fully reversible translations, e.g. DF bits may not kept in the case of DF=3D1 and MF=3D1. The impacts of those cases are likely to be identified as a long-term issue, since it's reported that the cases occurred rarely and not observed as negative effects in practice. This BCP can be applied when the following two criteria are present: 1. There is an IPv6-only access network that uses stateful translation [RFC6146] 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only access network to reach the IPv4 Internet " Many thanks Gang > RD > > > >> >>> Comments welcome. >>> >>> Regards, >>> RD >>> >>> >>> 2012-08-07 07:53, Fred Baker (fred) : >>> >>>> I'll let the current WGLC run and then open one for 464XLAT. >>>> >>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>>> >>>>> >>>>> v6ops chairs, >>>>> >>>>> We have published draft-ietf-v6ops-464xlat-06. >>>>> This draft is simply adding section 2 "BCP Scenario". >>>>> Could you please start WGLC? >>>>> >>>>> Thank you for your time and consideration. >>>>> >>>>> Regards, >>>>> Masanobu >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From randy@psg.com Tue Aug 7 16:26:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4521F85C6 for ; Tue, 7 Aug 2012 16:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyAfwQ1mVUgu for ; Tue, 7 Aug 2012 16:26:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2321F85C3 for ; Tue, 7 Aug 2012 16:26:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SytAq-000O4f-Ca; Tue, 07 Aug 2012 23:26:52 +0000 Date: Tue, 07 Aug 2012 16:26:57 -0700 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: References: <20120806142829.81256B1E003@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 23:26:53 -0000 > My perception: we should accept the erratum. Agree? >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". this is not an erratum, it is revisionism. this way lies madness. there are thousands of older docs which have been superseded in some way. don't start on this path. i am sure we have better things to do with our small bit of time on this earth. randy From jiangsheng@huawei.com Tue Aug 7 18:37:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A100D11E80DF for ; Tue, 7 Aug 2012 18:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqjjxH-Ulh3I for ; Tue, 7 Aug 2012 18:37:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67311E80D2 for ; Tue, 7 Aug 2012 18:37:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP57922; Tue, 07 Aug 2012 17:37:53 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:35:37 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:35:39 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 09:35:35 +0800 From: Sheng Jiang To: Cameron Byrne , Mark ZZZ Smith Thread-Topic: [v6ops] draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNc5SEZaOo7GeIYE+zCAtJF8/cLJdNNLAAgABa3wCAAARhgIAAO0kAgAFSwAA= Date: Wed, 8 Aug 2012 01:35:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F025BD@szxeml545-mbx.china.huawei.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F025BDszxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:37:54 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F025BDszxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBib3RoIG11bHRpcGxlIHByZWZpeCBhbmQgTlBUdjYgZm9yIG11bHRpaG9taW5nIHNo b3VsZCBiZSBtZW50aW9uZWQgYW5kIHN0YXRlZCB0aGF0IGVhY2ggb2YgdGhlbSBoYXMgdGhlaXIg b3duIGlzc3Vlcy4NCg0KQXMgZGlzY3Vzc2VkIGluIElOVEFSRUEgbWVldGluZyBpbiBWYW5jb3V2 ZXIsIE5QVHY2IGhhcyByZWZlcnJhbCBpc3N1ZXMsIHdoaWNoIGFyZSBkaWZmaWN1bHQgdG8gc29s dmUuIE11bHRpcGxlIHByZWZpeCBtb2RlbCB3YXMgaW4gb3JpZ2luYWwgSVB2NiBkZXNpZ24sIGJ1 dCBoYXMgbm90IHlldCBiZWVuIHdpZGVseSBwcm92ZWQgeWV0LiBXZSBhdCBsZWFzdCBrbm93IHRo ZXJlIGFyZSBmaWx0ZXJpbmcgYW5kIGFkZHJlc3Mgc2VsZWN0aW9uIGlzc3Vlcy4NCg0KR2l2aW5n IHRoZSBmYWN0LCB0aGVyZSBpcyBubyBiZXN0IGN1cnJlbnQgcHJhY3RpY2UgeWV0LCB3ZSBzaG91 bGQgZG9jdW1lbnQgcG90ZW50aWFsIHNvbHV0aW9ucyBhbmQgdGhlaXIgaXNzdWVzIFdJVEhPVVQg YSByZWNvbW1lbmRhdGlvbiwgaWYgd2UgYXJlIGdvaW5nIHRvIGRpc2N1c3MgdGhlIGJlc3Qgd2F5 IGZvciBtdWx0aWhvbWluZy4NCg0KSG93ZXZlciwgYXMgZmFyIGFzIEkgY29uY2VybiwgdGhpcyBk b2N1bWVudCBkb2VzIG5vdCBkaXNjdXNzIG11bHRpaG9taW5nIHNvbHV0aW9ucyBhdCBhbGwuIEl0 IG9ubHkgbWVudGlvbnMgdGhlc2Ugc29sdXRpb25zIGFzIHBvdGVudGlhbCBzY2VuYXJpb3Mgd2hl biBkaXNjdXNzZXMgcm91dGluZyBpbXBhY3RzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoN CkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2FtZXJvbiBCeXJuZQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDA3 LCAyMDEyIDk6MTIgUE0NClRvOiBNYXJrIFpaWiBTbWl0aA0KQ2M6IHY2b3BzQGlldGYub3JnOyBW Nm9wcyBDaGFpcnM7IFJvbiBCb25pY2ENClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYt djZvcHMtaWNwLWd1aWRhbmNlIFdHTEMNCg0KDQpPbiBBdWcgNywgMjAxMiAyOjM5IEFNLCAiTWFy ayBaWlogU21pdGgiIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PG1haWx0bzptYXJrenp6c21p dGhAeWFob28uY29tLmF1Pj4gd3JvdGU6DQo+DQo+IEhpLA0KPg0KPg0KPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj4NCj4g PiBUbzogQ2FtZXJvbiBCeXJuZSA8Y2IubGlzdDZAZ21haWwuY29tPG1haWx0bzpjYi5saXN0NkBn bWFpbC5jb20+Pg0KPiA+IENjOiAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3Jn PiIgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+OyBWNm9wcyBDaGFpcnMg PHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86djZvcHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPj47IFJvbiBCb25pY2EgPHJvbkBib25pY2Eub3JnPG1haWx0bzpyb25AYm9uaWNhLm9y Zz4+DQo+ID4gU2VudDogVHVlc2RheSwgNyBBdWd1c3QgMjAxMiA3OjI0IFBNDQo+ID4gU3ViamVj dDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFuY2UgV0dMQw0KPiA+DQo+ ID4gT24gMDcvMDgvMjAxMiAwNDo1OSwgQ2FtZXJvbiBCeXJuZSB3cm90ZToNCj4gPj4gIE9uIFN1 biwgQXVnIDUsIDIwMTIgYXQgMTA6MjkgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2Nv LmNvbTxtYWlsdG86ZnJlZEBjaXNjby5jb20+Pg0KPiA+IHdyb3RlOg0KPiA+Pj4gIFRoaXMgaXMg dG8gb3BlbiBhIHR3byB3ZWVrIFdvcmtpbmcgR3JvdXAgbGFzdCBDYWxsIG9uDQo+ID4+Pg0KPiA+ Pj4gIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pY3At Z3VpZGFuY2UNCj4gPj4+ICAgICJJUHY2IEd1aWRhbmNlIGZvciBJbnRlcm5ldCBDb250ZW50IGFu ZCBBcHBsaWNhdGlvbiBTZXJ2aWNlDQo+ID4gUHJvdmlkZXJzIiwNCj4gPj4+ICAgIEJyaWFuIENh cnBlbnRlciwgU2hlbmcgSmlhbmcsIDEwLUp1bC0xMg0KPiA+Pj4NCj4gPD4NCj4gPj4NCj4gPj4g IEl0IHNlZW1zIGxpa2UgTlBUdjYgaXMgYSBtdWNoIG1vcmUgbW9kZXJuIGFwcHJvYWNoIHRoYXQg aXMgbXVjaCBtb3JlDQo+ID4+ICBsaWtlbHkgdG8gYmUgZGVwbG95ZWQgLi4uDQo+ID4NCj4gPiBG b3IgY29udGVudCBwcm92aWRlcnM/Pz8NCj4gPg0KPg0KPg0KPiBXb3VsZG4ndCBOUFR2NidzIEV4 cGVyaW1lbnRhbCBzdGF0dXMgbWVhbiBpdCBzaG91bGRuJ3QgcmVhbGx5IGJlIHN1Z2dlc3RlZCBp biBhbiBhZHZpc29yeSBkb2N1bWVudCBsaWtlIHRoaXM/IElmIGl0IHdhcyBtZW50aW9uZWQsIHRo ZW4gSSB0aGluayB0aGVyZSdkIGhhdmUgdG8gYmUgdGV4dCBkaXNjdXNzaW5nIGl0J3MgZHJhd2Jh Y2tzIGluIElDUCBzY2VuYXJpb3MgZS5nLiB0aGUgY29uc2VxdWVuY2VzIG9mIGNvbnRlbnQgaG9z dHMvYXBwbGljYXRpb25zIG5vdCBrbm93aW5nIHRoZWlyIG93biBJUHY2IGlkZW50aXR5LCBhbmQg ZGlzY3Vzc2lvbiBhcm91bmQgTlBUdjYgaW4gYSBzaXR1YXRpb24gd2hlcmUgdGhlICJjbG91ZCIg YXBwbGljYXRpb24gdHJhZmZpYyBpcyBlbmNyeXB0ZWQgKEkgdGhpbmsgdGhpcyBpcyBnb2luZyB0 byBpbmNyZWFzZSBzaWduaWZpY2FudGx5IHdpdGggdGhlIHJhcGlkIGFkb3B0aW9uIG9mIEJZTyBk ZXZpY2VzIGFuZCBXaWZpIG9mZmxvYWQpLg0KPg0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KDQpOUFR2 NiBpcyBub3QgcmVhbGx5IHRoZSBmb2N1cyBvZiBteSBjb21tZW50LiBUaGUgZm9jdXMgd2FzIHN1 cHBvc2VkIHRvIGJlIHVzaW5nIDIgcHJlZml4ZXMgZm9yIG11bHRpaG9taW5nIG9yIG1pZ3JhdGlu ZyBpc3BzLg0KDQpJIGRvbnQgdGhpbmsgYW55b25lIHdvdWxkIGRvIHRoaXMgdG9kYXkuIERvaW5n IGl0LCBhZmFpaywgd291bGQgYmUgYSBzY2llbmNlIGV4cGVyaW1lbnQgYW5kIHRoZXJlZm9yZSBz aG91bGQgbm90IGJlIGEgcmVjb21tZW5kZWQgYXBwcm9hY2guIEkgdW5kZXJzdGFuZCBpcHY2IHdh cyBkZXNpZ25lZCB0byB3b3JrIHRoaXMgd2F5LiAuLi4uIEJ1dCBhZmFpaywgaXQgaXMgbm90IHJl YWxseSBleGVyY2lzZWQuICBJZiBzb21lb25lIGhhcyBkb25lIGl0IGluIGEgcHJvZHVjdGlvbiBu ZXR3b3JrLCB0aGF0IHdvdWxkIGJlIGdvb2QgdG8ga25vdw0KDQpDQg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9239F025BDszxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgYm90aCBtdWx0aXBsZSBwcmVmaXgg YW5kIE5QVHY2IGZvciBtdWx0aWhvbWluZyBzaG91bGQgYmUgbWVudGlvbmVkIGFuZCBzdGF0ZWQg dGhhdCBlYWNoIG9mIHRoZW0gaGFzIHRoZWlyIG93biBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGRpc2N1c3NlZCBpbiBJTlRBUkVBIG1lZXRpbmcgaW4gVmFu Y291dmVyLCBOUFR2NiBoYXMgcmVmZXJyYWwgaXNzdWVzLCB3aGljaCBhcmUgZGlmZmljdWx0IHRv IHNvbHZlLiBNdWx0aXBsZSBwcmVmaXggbW9kZWwgd2FzIGluIG9yaWdpbmFsIElQdjYNCiBkZXNp Z24sIGJ1dCBoYXMgbm90IHlldCBiZWVuIHdpZGVseSBwcm92ZWQgeWV0LiBXZSBhdCBsZWFzdCBr bm93IHRoZXJlIGFyZSBmaWx0ZXJpbmcgYW5kIGFkZHJlc3Mgc2VsZWN0aW9uIGlzc3Vlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2l2aW5nIHRoZSBmYWN0LCB0aGVyZSBp cyBubyBiZXN0IGN1cnJlbnQgcHJhY3RpY2UgeWV0LCB3ZSBzaG91bGQgZG9jdW1lbnQgcG90ZW50 aWFsIHNvbHV0aW9ucyBhbmQgdGhlaXIgaXNzdWVzIFdJVEhPVVQgYSByZWNvbW1lbmRhdGlvbiwg aWYgd2UNCiBhcmUgZ29pbmcgdG8gZGlzY3VzcyB0aGUgYmVzdCB3YXkgZm9yIG11bHRpaG9taW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBhcyBmYXIgYXMg SSBjb25jZXJuLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGRpc2N1c3MgbXVsdGlob21pbmcgc29s dXRpb25zIGF0IGFsbC4gSXQgb25seSBtZW50aW9ucyB0aGVzZSBzb2x1dGlvbnMgYXMgcG90ZW50 aWFsIHNjZW5hcmlvcw0KIHdoZW4gZGlzY3Vzc2VzIHJvdXRpbmcgaW1wYWN0cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5TaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9w cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Q2FtZXJvbiBCeXJuZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBB dWd1c3QgMDcsIDIwMTIgOToxMiBQTTxicj4NCjxiPlRvOjwvYj4gTWFyayBaWlogU21pdGg8YnI+ DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnOyBWNm9wcyBDaGFpcnM7IFJvbiBCb25pY2E8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFu Y2UgV0dMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCk9uIEF1ZyA3LCAyMDEyIDI6MzkgQU0sICZx dW90O01hcmsgWlpaIFNtaXRoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRo QHlhaG9vLmNvbS5hdSI+bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEJyaWFuIEUgQ2Fy cGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIj5i cmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBUbzogQ2Ft ZXJvbiBCeXJuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNvbSI+Y2IubGlz dDZAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90OzxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDs7IFY2b3BzIENo YWlycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+djZv cHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZndDs7IFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9 Im1haWx0bzpyb25AYm9uaWNhLm9yZyI+cm9uQGJvbmljYS5vcmc8L2E+Jmd0Ozxicj4NCiZndDsg Jmd0OyBTZW50OiBUdWVzZGF5LCA3IEF1Z3VzdCAyMDEyIDc6MjQgUE08YnI+DQomZ3Q7ICZndDsg U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFuY2UgV0dMQzxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAwNy8wOC8yMDEyIDA0OjU5LCBDYW1lcm9u IEJ5cm5lIHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7T24gU3VuLCBBdWcgNSwgMjAx MiBhdCAxMDoyOSBQTSwgRnJlZCBCYWtlciAoZnJlZCkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVk QGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyB3cm90ZTo8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAmbmJzcDtUaGlzIGlzIHRvIG9wZW4gYSB0d28gd2VlayBX b3JraW5nIEdyb3VwIGxhc3QgQ2FsbCBvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXY2b3BzLWljcC1ndWlkYW5jZSI+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWljcC1ndWlkYW5jZTwvYT48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7JnF1b3Q7SVB2NiBHdWlkYW5jZSBmb3IgSW50ZXJuZXQg Q29udGVudCBhbmQgQXBwbGljYXRpb24gU2VydmljZTxicj4NCiZndDsgJmd0OyBQcm92aWRlcnMm cXVvdDssPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0JyaWFuIENhcnBlbnRl ciwgU2hlbmcgSmlhbmcsIDEwLUp1bC0xMjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmbHQ7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwO0l0 IHNlZW1zIGxpa2UgTlBUdjYgaXMgYSBtdWNoIG1vcmUgbW9kZXJuIGFwcHJvYWNoIHRoYXQgaXMg bXVjaCBtb3JlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDtsaWtlbHkgdG8gYmUgZGVwbG95ZWQg Li4uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEZvciBjb250ZW50IHByb3ZpZGVycz8/ Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXb3VsZG4ndCBO UFR2NidzIEV4cGVyaW1lbnRhbCBzdGF0dXMgbWVhbiBpdCBzaG91bGRuJ3QgcmVhbGx5IGJlIHN1 Z2dlc3RlZCBpbiBhbiBhZHZpc29yeSBkb2N1bWVudCBsaWtlIHRoaXM/IElmIGl0IHdhcyBtZW50 aW9uZWQsIHRoZW4gSSB0aGluayB0aGVyZSdkIGhhdmUgdG8gYmUgdGV4dCBkaXNjdXNzaW5nIGl0 J3MgZHJhd2JhY2tzIGluIElDUCBzY2VuYXJpb3MgZS5nLiB0aGUgY29uc2VxdWVuY2VzIG9mIGNv bnRlbnQgaG9zdHMvYXBwbGljYXRpb25zDQogbm90IGtub3dpbmcgdGhlaXIgb3duIElQdjYgaWRl bnRpdHksIGFuZCBkaXNjdXNzaW9uIGFyb3VuZCBOUFR2NiBpbiBhIHNpdHVhdGlvbiB3aGVyZSB0 aGUgJnF1b3Q7Y2xvdWQmcXVvdDsgYXBwbGljYXRpb24gdHJhZmZpYyBpcyBlbmNyeXB0ZWQgKEkg dGhpbmsgdGhpcyBpcyBnb2luZyB0byBpbmNyZWFzZSBzaWduaWZpY2FudGx5IHdpdGggdGhlIHJh cGlkIGFkb3B0aW9uIG9mIEJZTyBkZXZpY2VzIGFuZCBXaWZpIG9mZmxvYWQpLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBNYXJrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5OUFR2NiBpcyBub3QgcmVhbGx5IHRoZSBmb2N1cyBvZiBt eSBjb21tZW50LiBUaGUgZm9jdXMgd2FzIHN1cHBvc2VkIHRvIGJlIHVzaW5nIDIgcHJlZml4ZXMg Zm9yIG11bHRpaG9taW5nIG9yIG1pZ3JhdGluZyBpc3BzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbnQgdGhpbmsgYW55b25lIHdvdWxkIGRvIHRoaXMg dG9kYXkuIERvaW5nIGl0LCBhZmFpaywgd291bGQgYmUgYSBzY2llbmNlIGV4cGVyaW1lbnQgYW5k IHRoZXJlZm9yZSBzaG91bGQgbm90IGJlIGEgcmVjb21tZW5kZWQgYXBwcm9hY2guIEkgdW5kZXJz dGFuZCBpcHY2IHdhcyBkZXNpZ25lZCB0byB3b3JrIHRoaXMgd2F5LiAuLi4uIEJ1dCBhZmFpaywg aXQgaXMgbm90IHJlYWxseSBleGVyY2lzZWQuJm5ic3A7IElmDQogc29tZW9uZSBoYXMgZG9uZSBp dCBpbiBhIHByb2R1Y3Rpb24gbmV0d29yaywgdGhhdCB3b3VsZCBiZSBnb29kIHRvIGtub3cgPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkNCPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F025BDszxeml545mbxchi_-- From fibrib@gmail.com Tue Aug 7 19:42:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE811E8110 for ; Tue, 7 Aug 2012 19:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSgtHjyLgn1x for ; Tue, 7 Aug 2012 19:42:58 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1B5011E80EE for ; Tue, 7 Aug 2012 19:42:57 -0700 (PDT) Received: by eekb45 with SMTP id b45so52282eek.31 for ; Tue, 07 Aug 2012 19:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=si434TbNgKj4bcxyZv/5irt2oZwoE4lfIPP4vDnRkqs=; b=vqt6JoQlMcr5NXV6Tm0LzPNR8JSEK1FiYktLJWrVV/Y8rVIj59T7khwjLfq6NMeW31 DZgZQ+ICnPoKV665o8ml5LSxzwm+1kD2KPqk9WTuj4DnEu4V3Cd3f+H3D3c0dyCtXwVT EuUNolHPJu9LL80QXT3SATwnALrT1uRNYkNeDXkx+u1RQY03aMq4WX3WkwbbXFNP5Diw XJf7S83Gszm+fcM4H4ulUfSufdFDeSsecBoeaEHzyhZx+tLR+P5iazeTkzkhy5EV6pPP bPDaYNgesmusS0rvvN/m5Twv6ggGQEDrgw+4BejYuXQhSDXCNLGUuF1CPEdjTJIcZxyT GQ7Q== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr20508272eep.14.1344393776821; Tue, 07 Aug 2012 19:42:56 -0700 (PDT) Received: by 10.14.211.131 with HTTP; Tue, 7 Aug 2012 19:42:56 -0700 (PDT) In-Reply-To: <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> Date: Wed, 8 Aug 2012 11:42:56 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c281776d04c6b811cf Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 02:42:59 -0000 --047d7b6224c281776d04c6b811cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, 2012/8/7 R=E9mi Despr=E9s > Hi, Fred, > > I agree that adding an applicability statement, as you requested last > week, is an approach that improves acceptability of BCP status (as oppose= d > to Informational recommended by some participants in Vancouver). > > This statement is currently: > " 2. BCP Scenario > This BCP only applies when the following two criteria are present: > 1. There is an IPv6-only access network that uses stateful translation > [RFC6146] > 2. There are IPv4-only applications or hosts that must communicate acros= s > the IPv6-only access network to reach the IPv4 Internet > > In my understanding, it should be more complete, e.g. as follows: > > " 2. Applicability of 464XLAT > This BCP only applies when the following three criteria are present: > 1. There is an IPv6-only access network that doesn't support DS-lite > [RFC6333] but supports NAT64 stateful translation [RFC6146] 2. There are IPv4-only applications or hosts that must communicate across > the IPv6-only access network to reach the IPv4 Internet > 3. The lack of transparency to source-fragmented IPv4 packets that, as > recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have > DF=3D1), is considered acceptable. > as a translation-fashion solution, i don't think the DF transparency is of the design goal. and i have observed that: #1. the RFC6146 has proposed the required behavior regarding the fragment handling(sec 3.4), leaving the detailed method to the implementation that includes the reassembly before translating. it is also stated that the size of outgoing packets as well and the potential need for fragmentation is done according to the behavior defined in RFC6145. #2. even if any host behind CLAT is implemented complaint with RFC4821, please note that the RFC6145 states "the translator should not add fragment header" "if the DF bit is set and the packet is not a fragment (i.e., the More Fragments (MF) flag is not set and the Fragment Offset is equal to zero)", and confirms "there is a need to add a Fragment Header" means "the DF bit is not set or the packet is a fragment", therefore, the case with (DF=3D1 && (MF=3D1 || Offset is not zero) will be translated WITH fragment header, indicating the packet could be further fragmented after being translated back to IPv4 (with DF=3D0) by PLAT. sure this doesn't ensure DF= =3D1 not changed through the 464xlat domain but it works even in the case RFC4821 host makes out DF=3DMF=3D1. again the full DF transparency, to my understanding, is not the design goal of 464xlat. therefore adding the text in response to RFC4821 is not necessary. i support the BCP status of the doc with current applicability statement. - maoke > > Comments welcome. > > Regards, > RD > > > 2012-08-07 07:53, Fred Baker (fred) : > > > I'll let the current WGLC run and then open one for 464XLAT. > > > > On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: > > > >> > >> v6ops chairs, > >> > >> We have published draft-ietf-v6ops-464xlat-06. > >> This draft is simply adding section 2 "BCP Scenario". > >> Could you please start WGLC? > >> > >> Thank you for your time and consideration. > >> > >> Regards, > >> Masanobu > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b6224c281776d04c6b811cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi,=A0

2012/8/7 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi, Fred,

I agree that adding an applicability statement, as you requested last week,= is an approach that improves acceptability of BCP status (as opposed to In= formational recommended by some participants in Vancouver).

This statement is currently:
" 2. BCP Scenario
=A0This BCP only applies when the following two criteria are present:
=A01. There is an IPv6-only access network that uses stateful translation [= RFC6146]
=A02. There are IPv4-only applications or hosts that must communicate acros= s the IPv6-only access network to reach the IPv4 Internet

In my understanding, it should be more complete, e.g. as follows:

" 2. Applicability of 464XLAT
=A0This BCP only applies when the following three criteria are present:
= =A0 1. There is an IPv6-only access network that doesn't support DS-lit= e [RFC6333] but supports NAT64 stateful translation [RFC6146]
=A02. There are IPv4-only applications or hosts that must communicate acros= s the IPv6-only access network to reach the IPv4 Internet
=A03. The lack of transparency to source-fragmented IPv4 packets that, as r= ecommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have DF= =3D1), is considered acceptable.

as a t= ranslation-fashion solution, i don't think the DF transparency is of th= e design goal. and i have observed that:

#1. the RFC6146 has proposed the required behavior rega= rding the fragment handling(sec 3.4), leaving the detailed method to the im= plementation that includes the reassembly before translating. it is also st= ated that the size of outgoing packets as well and the potential need for f= ragmentation is done according to the behavior defined in RFC6145.=A0

#2. even if any host behind CLAT is implemented complai= nt with RFC4821, please note that the RFC6145 states "the translator s= hould not add fragment header" "if the DF bit is set and the pack= et is not a fragment (i.e., the More Fragments (MF) flag is not set and the= Fragment Offset is equal to zero)", and confirms "there is a nee= d to add a Fragment Header" means "the DF bit is not set or the p= acket is a fragment", therefore, the case with (DF=3D1 && (MF= =3D1 || Offset is not zero) will be translated WITH fragment header, indica= ting the packet could be further fragmented after being translated back to = IPv4 (with DF=3D0)=A0 by PLAT. sure this doesn't ensure DF=3D1 not chan= ged through the 464xlat domain but it works even in the case RFC4821 host m= akes out DF=3DMF=3D1. again the full DF transparency, to my understanding, = is not the design goal of 464xlat.=A0

therefore adding the text in response to RFC4821 is not= necessary. i support the=A0BCP status of the doc with current applicabilit= y statement.=A0

- maoke=A0
=A0

Comments welcome.

Regards,
RD


2012-08-07 07:53, Fred Baker (fred) :

> I'll let the current WGLC run and then open one for 464XLAT.
>
> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote:
>
>>
>> v6ops chairs,
>>
>> We have published draft-ietf-v6ops-464xlat-06.
>> This draft is simply adding section 2 "BCP Scenario". >> Could you please start WGLC?
>>
>> Thank you for your time and consideration.
>>
>> Regards,
>> Masanobu
_____________________________= __________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b6224c281776d04c6b811cf-- From fibrib@gmail.com Tue Aug 7 19:51:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42721F85A0 for ; Tue, 7 Aug 2012 19:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsE8APQjfg5H for ; Tue, 7 Aug 2012 19:51:54 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25121F859F for ; Tue, 7 Aug 2012 19:51:53 -0700 (PDT) Received: by eekb45 with SMTP id b45so53125eek.31 for ; Tue, 07 Aug 2012 19:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g0jqTHPUyZF/0mSkLa+C0/et9i9E1KhPheNaRI41G14=; b=F4ZD7F0gSzoZNn8oeHbXcO8tBg3r0W3FWZ9cHTXPn3h+DC2td1k/R8XR568LJWiL3R uHEJbytX2bP0gmnl/QOB3T0r4NmESAvQ5M8oKsJGSW7IjQBj46wmp2kpA0OcZ2Mhn9FV U38j0dNA9OhxFqYKSjzJ8s1OLWn/peqmFaZH4We5XR54D+n2TTUwZkswFkI22xkQ2oGy Jbl6+GRPQi2L6Mjdo3EJBQBoq3hkDzfjCSF5wiUIyxmpQkBd2we4/a4P+z6VpqTz20st Q35K/R6+HbubrlznN9HeOvrjNyYWc9YdEGojRLFt5jHXf6RVKVf+3q1Nja1XAH3nTKSf ESjA== MIME-Version: 1.0 Received: by 10.14.216.198 with SMTP id g46mr20585747eep.32.1344394312842; Tue, 07 Aug 2012 19:51:52 -0700 (PDT) Received: by 10.14.211.131 with HTTP; Tue, 7 Aug 2012 19:51:52 -0700 (PDT) In-Reply-To: <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> Date: Wed, 8 Aug 2012 11:51:52 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b603c1c747c4b04c6b8314d Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 02:51:55 -0000 --047d7b603c1c747c4b04c6b8314d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/8/8 R=E9mi Despr=E9s > > Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : > > > > > On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: > > > >> Hi, Fred, > >> > >> I agree that adding an applicability statement, as you requested last > week, is an approach that improves acceptability of BCP status (as oppose= d > to Informational recommended by some participants in Vancouver). > >> > >> This statement is currently: > >> " 2. BCP Scenario > >> This BCP only applies when the following two criteria are present: > >> 1. There is an IPv6-only access network that uses stateful translation > [RFC6146] > >> 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only access network to reach the IPv4 Internet > >> > >> In my understanding, it should be more complete, e.g. as follows: > >> > >> " 2. Applicability of 464XLAT > >> This BCP only applies when the following three criteria are present: > >> 1. There is an IPv6-only access network that doesn't support DS-lite > [RFC6333] but supports NAT64 stateful translation [RFC6146] > >> 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only access network to reach the IPv4 Internet > >> 3. The lack of transparency to source-fragmented IPv4 packets that, as > recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have > DF=3D1), is considered acceptable. > > > > So you're arguing that we need a comment in this applicability statemen= t > regarding each other solution, or just that one? > > Just that one (no hidden intention!). > > DS-Lite is an already specified stateful solution for IPv4 customers tha= t > have no public addresses to reach the IPv4 Internet across IPv6-only acce= ss > networks. It hasn't the limitation of item 3. > If there are IPv6-only deployments where NAT64s are available but not > DS-Lite, in particular in the short term, 464XLAT is AFAIK better than > nothing, and is therefore, as said from the beginning, worth documenting. > However, if DS-lite is available, using it is AFAIK better practice (more > transparent to IPv4, and very simple too in CPE/UEs). > i may say they are different practices but stating DS-lite *more transparent to ipv4* is confusing. as there is a CGN, it is not end-to-end transparent anyway. > > (Something more might be said for stateless solutions, but this is AFAIK > out of scope for 464XLAT.) > > > > It seems to me that at most (1) might add "to access an IPv4 network" o= r > "to access the IPv4 Internet" - which are different statements. There is = no > reason to go into what the other options the operator might have chosen > might be. > > > > I'll let others comment on your third bullet. Personally, I would not > expect the implementation to require fragmentation, but would expect it t= o > use configuration or PMTU to ensure that the packets were small enough. > > a. Applications that send UDP datagrams longer than PMTUs, which is the > case of some games AFAIK, have to fragment. (If there would be no such > applications, why to have any fragmentation in IPv6?) > true that some games that poorly designed often do the big datagram. on the other hand, there is no problem that these UDP datagrams will be fragmented in the RFC6145/6146 combination. may you identify what the concern is? - maoke > > b. In case of UE tethering, such applications are not controlled by UEs > themselves. > > RD > > > > > > >> Comments welcome. > >> > >> Regards, > >> RD > >> > >> > >> 2012-08-07 07:53, Fred Baker (fred) : > >> > >>> I'll let the current WGLC run and then open one for 464XLAT. > >>> > >>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: > >>> > >>>> > >>>> v6ops chairs, > >>>> > >>>> We have published draft-ietf-v6ops-464xlat-06. > >>>> This draft is simply adding section 2 "BCP Scenario". > >>>> Could you please start WGLC? > >>>> > >>>> Thank you for your time and consideration. > >>>> > >>>> Regards, > >>>> Masanobu > > > > ---------------------------------------------------- > > The ignorance of how to use new knowledge stockpiles exponentially. > > - Marshall McLuhan > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b603c1c747c4b04c6b8314d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/8/8 R=E9mi Despr=E9s = <despres.r= emi@laposte.net>

Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit :

>
> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote:
>
>> Hi, Fred,
>>
>> I agree that adding an applicability statement, as you requested l= ast week, is an approach that improves acceptability of BCP status (as oppo= sed to Informational recommended by some participants in Vancouver).
>>
>> This statement is currently:
>> " 2. BCP Scenario
>> This BCP only applies when the following two criteria are present:=
>> 1. There is an IPv6-only access network that uses stateful transla= tion [RFC6146]
>> 2. There are IPv4-only applications or hosts that must communicate= across the IPv6-only access network to reach the IPv4 Internet
>>
>> In my understanding, it should be more complete, e.g. as follows:<= br> >>
>> " 2. Applicability of 464XLAT
>> This BCP only applies when the following three criteria are presen= t:
>> 1. There is an IPv6-only access network that doesn't support D= S-lite [RFC6333] but supports NAT64 stateful translation [RFC6146]
>> 2. There are IPv4-only applications or hosts that must communicate= across the IPv6-only access network to reach the IPv4 Internet
>> 3. The lack of transparency to source-fragmented IPv4 packets that= , as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. h= ave DF=3D1), is considered acceptable.
>
> So you're arguing that we need a comment in this applicability sta= tement regarding each other solution, or just that one?

Just that one (no hidden intention!).

DS-Lite is an =A0already specified stateful solution for IPv4 customers tha= t have no public addresses to reach the IPv4 Internet across IPv6-only acce= ss networks. It hasn't the limitation of item 3.
If there are IPv6-only deployments where NAT64s are available but not DS-Li= te, in particular in the short term, 464XLAT is AFAIK better than nothing, = and is therefore, as said from the beginning, worth documenting.
However, if DS-lite is available, using it is AFAIK better practice (more t= ransparent to IPv4, and very simple too in CPE/UEs).
<= br>
i may say they are different practices but stating DS-lite *m= ore transparent to ipv4* is confusing. as there is a CGN, it is not end-to-= end transparent anyway.=A0
=A0

(Something more might be said for stateless solutions, but this is AFAIK ou= t of scope for 464XLAT.)


> It seems to me that at most (1) might add "to access an IPv4 netw= ork" or "to access the IPv4 Internet" - which are different = statements. There is no reason to go into what the other options the operat= or might have chosen might be.
>
> I'll let others comment on your third bullet. Personally, I would = not expect the implementation to require fragmentation, but would expect it= to use configuration or PMTU to ensure that the packets were small enough.=

a. Applications that send UDP datagrams longer than PMTUs, which is t= he case of some games AFAIK, have to fragment. (If there would be no such a= pplications, why to have any fragmentation in IPv6?)

true that some games that poorly designed often do the big d= atagram. on the other hand, there is no problem that these UDP datagrams wi= ll be fragmented in the RFC6145/6146 combination. may you identify what the= concern is?=A0

- maoke
=A0

b. In case of UE tethering, such applications are not controlled by UEs the= mselves.

RD



>
>> Comments welcome.
>>
>> Regards,
>> RD
>>
>>
>> 2012-08-07 07:53, Fred Baker (fred) :
>>
>>> I'll let the current WGLC run and then open one for 464XLA= T.
>>>
>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote:
>>>
>>>>
>>>> v6ops chairs,
>>>>
>>>> We have published draft-ietf-v6ops-464xlat-06.
>>>> This draft is simply adding section 2 "BCP Scenario&q= uot;.
>>>> Could you please start WGLC?
>>>>
>>>> Thank you for your time and consideration.
>>>>
>>>> Regards,
>>>> Masanobu
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially. > =A0 - Marshall McLuhan
>
_____________________________= __________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b603c1c747c4b04c6b8314d-- From sm@resistor.net Tue Aug 7 20:46:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B66211E8098 for ; Tue, 7 Aug 2012 20:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ff1+0Cr7xnO for ; Tue, 7 Aug 2012 20:46:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58B11E8087 for ; Tue, 7 Aug 2012 20:46:41 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q783kNVB020334; Tue, 7 Aug 2012 20:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344397593; bh=fVxhbWHQGnNy9a3HYzHWKwveljgKS16xzyba3FAQCr4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=riZdzGYjRIPx6oI0KkVNxGVaN6881njM+nOLoP3r9y/TMT2pRmAnMbRf1bRw+Fbyn pYxOIVULedGTCB/TEIEld4VYAkXU0CYoDtqeaVAxgVGf0hT+tAGoDi6vktFR88HK0w WRQ30Qp+CPNCFVjSb0gbHa5iNk9HQv5OQK7wswGo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1344397593; i=@resistor.net; bh=fVxhbWHQGnNy9a3HYzHWKwveljgKS16xzyba3FAQCr4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1Jnzf9wP8AUEQ2rsHvL66hy5xYOZdARg7SlwZgliOo9muLBY/C2S9ayLi+rzahWhL sCMHb101DAuGXL/E4x4/ONwGikparbLYKhWRgA/TsfjTBVVFHnh8++iSSS5/oMjRmp Wd9I6qcEGd4SqgFmJpUxkLJXlTR1D0hy5uy3Ajdc= Message-Id: <6.2.5.6.2.20120807203008.0a6ca648@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Aug 2012 20:41:41 -0700 To: Brian E Carpenter , "Fred Baker (fred)" From: SM In-Reply-To: <50215765.7060406@gmail.com> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "" , "" , "" , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 03:46:46 -0000 At 10:59 07-08-2012, Brian E Carpenter wrote: >Wait a minute. > >How can this be described as an error in 5375? 5375 was not wrong when >published. > >The error was in 6164, which failed to formally update 5375. > >Surely this is a "hold for update" not "verified". I don't think that the erratum fits as verified. RFC 5375 was published in December 2008. RFC 6164 was published in April 2011. RFC 5375 was correct at the time of publication. I suggest leaving it as is. Regards, -sm From cb.list6@gmail.com Tue Aug 7 21:06:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8B11E80EA for ; Tue, 7 Aug 2012 21:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haO-U8ulIbdT for ; Tue, 7 Aug 2012 21:06:22 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7311E80F3 for ; Tue, 7 Aug 2012 21:06:21 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so218988wib.13 for ; Tue, 07 Aug 2012 21:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7P8YuRcflzKf7i1qDpvE2IQQC93YzIipYfT80cewVN4=; b=kt/JtZTRikVmENey6xbHIbLdvTwWRTZ3iGIiMXaUXxbht5N19jd0d29aTtGF7znfin Icg5JvIMYpQSzs1m2AAvWhGQwl1uWiyhu3Yj6A2/0ZQLe2jtBI7xshMWQD70H82k+vip FnN2XJtDy16mYT/TayqAitOs3O+svgjnIH3C8oFtDgiQ9qq7FKnLYtC8QfXZeYD6F7sM sDD0SrA7FuKLH3eQ9GckNraWnb7F5yO6Bqvvi15ouutHo8GE7aeyMIExWxR8qWhlNSgS mmFTsbRUrrU1T38CDz3/AVkNrMI55FwTUnZqpF2IrPhcngFYI6fzuNVn6L6mJQk/45u/ HiAw== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr2271744wib.3.1344398780640; Tue, 07 Aug 2012 21:06:20 -0700 (PDT) Received: by 10.194.38.170 with HTTP; Tue, 7 Aug 2012 21:06:20 -0700 (PDT) In-Reply-To: <50211B63.3020203@gmail.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> Date: Tue, 7 Aug 2012 21:06:20 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: V6ops Chairs , "v6ops@ietf.org" , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 04:06:22 -0000 On Tue, Aug 7, 2012 at 6:42 AM, Brian E Carpenter wrote: > Change of subject header, to separate out this topic: > > On 07/08/2012 14:12, Cameron Byrne wrote: >> On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" wrote: >>> Hi, >>> >>> >>> ----- Original Message ----- >>>> From: Brian E Carpenter >>>> To: Cameron Byrne >>>> Cc: "v6ops@ietf.org" ; V6ops Chairs < >> v6ops-chairs@tools.ietf.org>; Ron Bonica >>>> Sent: Tuesday, 7 August 2012 7:24 PM >>>> Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC >>>> >>>> On 07/08/2012 04:59, Cameron Byrne wrote: >>>>> On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) >>>> wrote: >>>>>> This is to open a two week Working Group last Call on >>>>>> >>>>>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >>>>>> "IPv6 Guidance for Internet Content and Application Service >>>> Providers", >>>>>> Brian Carpenter, Sheng Jiang, 10-Jul-12 >>>>>> >>> <> >>>>> It seems like NPTv6 is a much more modern approach that is much more >>>>> likely to be deployed ... >>>> For content providers??? >>>> >>> >>> Wouldn't NPTv6's Experimental status mean it shouldn't really be >> suggested in an advisory document like this? If it was mentioned, then I >> think there'd have to be text discussing it's drawbacks in ICP scenarios >> e.g. the consequences of content hosts/applications not knowing their own >> IPv6 identity, and discussion around NPTv6 in a situation where the "cloud" >> application traffic is encrypted (I think this is going to increase >> significantly with the rapid adoption of BYO devices and Wifi offload). >>> Regards, >>> Mark. >> >> NPTv6 is not really the focus of my comment. The focus was supposed to be >> using 2 prefixes for multihoming or migrating isps. >> >> I dont think anyone would do this today. Doing it, afaik, would be a >> science experiment > > I think that's unfair and kind of ignores draft-v6ops-multihoming-without-ipv6nat > > It works today. There are known difficulties with address selection > and with ingress filtering, of course. And it's a bit more fiddly to > configure routing and DNS for IT crews used to the old way of doing things. > But it really isn't unknown territory. > >> and therefore should not be a recommended approach. I > > If we are only addressing a few thousand sites, sure, but how else do > you suggest we deal with content providers by the million? > >> understand ipv6 was designed to work this way. .... But afaik, it is not >> really exercised. If someone has done it in a production network, that >> would be good to know > > Yes, facts are always good. > > Brian > One of the keys here that i overlooked is the ICP will certainly not be using SLAAC. They will be using static addresses manual, automated manually (Puppet, ...) , or via DHCPv6. That said, this is an issue of automation and instrumentation on how addresses are assigned and therefore should not be much of challenge, including running multiple prefixs in a short transition period. Meaning, this problem is solved in IPv4 for ICPs and those same IPv4 solution apply in IPv6. CB From joelja@bogus.com Tue Aug 7 22:29:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAC511E812D for ; Tue, 7 Aug 2012 22:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgsuGh8YzZCw for ; Tue, 7 Aug 2012 22:29:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id ED2B311E812B for ; Tue, 7 Aug 2012 22:29:17 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q785TDvH066782 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 8 Aug 2012 05:29:13 GMT (envelope-from joelja@bogus.com) Message-ID: <5021F928.1030502@bogus.com> Date: Tue, 07 Aug 2012 22:29:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Cameron Byrne References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Aug 2012 05:29:14 +0000 (UTC) Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 05:29:18 -0000 On 8/7/12 9:06 PM, Cameron Byrne wrote: > On Tue, Aug 7, 2012 at 6:42 AM, Brian E Carpenter > wrote: >> I think that's unfair and kind of ignores >> draft-v6ops-multihoming-without-ipv6nat It works today. There are >> known difficulties with address selection and with ingress filtering, >> of course. And it's a bit more fiddly to configure routing and DNS >> for IT crews used to the old way of doing things. But it really isn't >> unknown territory. I think characterizing the criticism as unfair is unfair. As far as I'm aware nobody actually serves from two PA prefixes from the same hosts in practice... While DNS GLB is suitable for doing that, what it isn't suitable for is optimizing provider exit selection, which BGP is rather good for and which proper BCP 38 RPF checks prevent unless I advertise the respective prefixes to my upstream... So either my hosting provider needs to be multihomed using pi or delegates PA that others are willing to carry, or I need to be... and what I use the GLB for is to direct traffic to one instance of a service or another. finding a multi-homed hosting provider in ipv4 land isn't that hard it shouldn't be in IPv6 either. >>> and therefore should not be a recommended approach. I >> If we are only addressing a few thousand sites, sure, but how else do >> you suggest we deal with content providers by the million? >> >>> understand ipv6 was designed to work this way. .... But afaik, it is not >>> really exercised. If someone has done it in a production network, that >>> would be good to know >> Yes, facts are always good. >> >> Brian >> > > One of the keys here that i overlooked is the ICP will certainly not > be using SLAAC. They will be using static addresses manual, automated > manually (Puppet, ...) , or via DHCPv6. That said, this is an issue > of automation and instrumentation on how addresses are assigned and > therefore should not be much of challenge, including running multiple > prefixs in a short transition period. > > Meaning, this problem is solved in IPv4 for ICPs and those same IPv4 > solution apply in IPv6. > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Tue Aug 7 22:34:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88F11E812D for ; Tue, 7 Aug 2012 22:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4A2jGZ4oN61 for ; Tue, 7 Aug 2012 22:34:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 336BE11E812B for ; Tue, 7 Aug 2012 22:34:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so728964obb.31 for ; Tue, 07 Aug 2012 22:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=I3N+DUanVKPwW+dfTzF+O3perxITJliM40JDOyLktcQ=; b=bhy+Sqzbsa3HY6XEJGef8R8QI9ukNbSQxmkmsz/Zwm5XXqGdc96fK3PSf6SJuxsa8x qG272HXQPv6dGHbjqZ1hUxIwrwZD00W819aKIFCe3KV4o8JEGL+/g8LKQ5KBdo/ifU8m hE9OVeHHK+QG0Q1j7erVwiwZw1jHMdtHp8meErkPuy1BtR0gGtiPJbXTf+Jlq/Sk3wve stidpXDmFcCoOn1V6wKOWQsoJXkQY5WiCGVYWtKnlkt8px6sQIT9MVYqqFEiXnyTLsDj eU+gFkdKTiVRFWbDHXli3DjgJ0WMIt1XZN6/zz6V4MUVbiQbR5oqj2bgnUfvNbi0NXhM mOkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=I3N+DUanVKPwW+dfTzF+O3perxITJliM40JDOyLktcQ=; b=FORNu/EzReUys1T10kZDqsRt9m5520pLH7rNTRqsjjsxTeHKKuTLdPgnxci3lrIpG6 qOlqcDzSMeVzmYmsqcpbiJ0mXqIxktaZ1S4l8oFP3LdQwCoV35uIvMa3qF9MvhUv8S0/ 7VhkrmY1BBg+6PxKfysIFrwke0NhYqhSAYNfuwLk5WlGLEoJOd8SJZYXmYTZ0KycxanF W72gf1Mjtdp8tVbZJBxDdOpFhugbaZafR/iKfV5Sm2K6/MkLyU5JsswLrYujM6eFv8DJ udZItBHewvnXyzKBHC7U6Gc0Lo5C8k1BUhaVQLkMLWxqLXTLDF4wjrbH2HzAPUk09DdG plQw== Received: by 10.182.17.99 with SMTP id n3mr28328335obd.8.1344404055755; Tue, 07 Aug 2012 22:34:15 -0700 (PDT) Received: by 10.182.17.99 with SMTP id n3mr28328323obd.8.1344404055623; Tue, 07 Aug 2012 22:34:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 7 Aug 2012 22:33:55 -0700 (PDT) In-Reply-To: <50211B63.3020203@gmail.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> From: Lorenzo Colitti Date: Wed, 8 Aug 2012 14:33:55 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d04446bfb2b880204c6ba7601 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkElB7Qxdrua/3eXCXtp7pmu1sgrCZDOuQrP95g/uY5subyKy6wvnkufkCXN4iJ+GCG3jcmBE2kboF/vAaw6JKF+JVTBIOYEebgEiKjsLRPa4tNIml5trfegbJmp+IlQSzJbRkvdBwynyTMn3uPAwjrfMN628KzoZKs66SubmWfFhpjXyYWeMPuiWPIpCWn6GErmwdA Cc: V6ops Chairs , "v6ops@ietf.org" , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 05:34:17 -0000 --f46d04446bfb2b880204c6ba7601 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think that's unfair and kind of ignores > draft-v6ops-multihoming-without-ipv6nat > > It works today. There are known difficulties with address selection > and with ingress filtering, of course. And it's a bit more fiddly to > configure routing and DNS for IT crews used to the old way of doing things. > But it really isn't unknown territory. > If I were a content provider, I would think twice before choosing an architecture that breaks TCP connections when upstreams go down. --f46d04446bfb2b880204c6ba7601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpent= er <brian.e.carpenter@gmail.com> wrote:
I think that's unfair and kind of ignores draft-v6ops-multihoming-witho= ut-ipv6nat

It works today. There are known difficulties with address selection
and with ingress filtering, of course. And it's a bit more fiddly to configure routing and DNS for IT crews used to the old way of doing things.=
But it really isn't unknown territory.

<= div>If I were a content provider, I would think twice before choosing an ar= chitecture that breaks TCP connections when upstreams go down.
--f46d04446bfb2b880204c6ba7601-- From despres.remi@laposte.net Wed Aug 8 00:13:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71B411E80E4 for ; Wed, 8 Aug 2012 00:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc0WeOVSujoL for ; Wed, 8 Aug 2012 00:13:33 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83111E808E for ; Wed, 8 Aug 2012 00:13:30 -0700 (PDT) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 74DAA82275; Wed, 8 Aug 2012 09:13:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Aug 2012 09:13:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:13:34 -0000 Hi, Gang, Thanks for your comments. More inline. 2012-08-08 01:22, GangChen : > Hello Remi and authors, >=20 > I'm supporting the BCP status because it is essential to guarantee > multiple compatible implementations. > More comments and proposed texts are inline. >=20 >=20 > 2012/8/8, R=E9mi Despr=E9s : >>=20 >> Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >>=20 >>>=20 >>> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >>>=20 >>>> Hi, Fred, >>>>=20 >>>> I agree that adding an applicability statement, as you requested = last >>>> week, is an approach that improves acceptability of BCP status (as >>>> opposed to Informational recommended by some participants in = Vancouver). >>>>=20 >>>> This statement is currently: >>>> " 2. BCP Scenario =09 >>>> This BCP only applies when the following two criteria are present:=09= >>>> 1. There is an IPv6-only access network that uses stateful = translation >>>> [RFC6146]=09 >>>> 2. There are IPv4-only applications or hosts that must communicate = across >>>> the IPv6-only access network to reach the IPv4 Internet >>>>=20 >>>> In my understanding, it should be more complete, e.g. as follows: >>>>=20 >>>> " 2. Applicability of 464XLAT =09 >>>> This BCP only applies when the following three criteria are = present:=09 >>>> 1. There is an IPv6-only access network that doesn't support = DS-lite >>>> [RFC6333] but supports NAT64 stateful translation [RFC6146] >>>> 2. There are IPv4-only applications or hosts that must communicate = across >>>> the IPv6-only access network to reach the IPv4 Internet >>>> 3. The lack of transparency to source-fragmented IPv4 packets that, = as >>>> recommended by RFC 4821, MUST NOT be fragmented by the network = (i.e. have >>>> DF=3D1), is considered acceptable. >>>=20 >>> So you're arguing that we need a comment in this applicability = statement >>> regarding each other solution, or just that one? >>=20 >> Just that one (no hidden intention!). >>=20 >> DS-Lite is an already specified stateful solution for IPv4 customers = that >> have no public addresses to reach the IPv4 Internet across IPv6-only = access >> networks. It hasn't the limitation of item 3. >> If there are IPv6-only deployments where NAT64s are available but not >> DS-Lite, in particular in the short term, 464XLAT is AFAIK better = than >> nothing, and is therefore, as said from the beginning, worth = documenting. >> However, if DS-lite is available, using it is AFAIK better practice = (more >> transparent to IPv4, and very simple too in CPE/UEs). >=20 > I see the fairy decision choosing NAT64 other than DS-lite in 464xlat > because it could provide functional compability with ACL and many > network provisioning facilities, especially in a mobile environment. > Also agree Fred's comments "There is no reason to go into what the > other options the operator might have chosen might be." Understood. With the addition I propose:=20 - I no longer object to BCP - Where NAT64 is supported and DS-Lite isn't, this BCP recommends = 464XLAT This, I think, covers your need.=20 >> (Something more might be said for stateless solutions, but this is = AFAIK out >> of scope for 464XLAT.) >>=20 >>=20 >>> It seems to me that at most (1) might add "to access an IPv4 = network" or >>> "to access the IPv4 Internet" - which are different statements. = There is >>> no reason to go into what the other options the operator might have = chosen >>> might be. >>>=20 >>> I'll let others comment on your third bullet. Personally, I would = not >>> expect the implementation to require fragmentation, but would expect = it to >>> use configuration or PMTU to ensure that the packets were small = enough. >>=20 >> a. Applications that send UDP datagrams longer than PMTUs, which is = the case >> of some games AFAIK, have to fragment. (If there would be no such >> applications, why to have any fragmentation in IPv6?) >>=20 >> b. In case of UE tethering, such applications are not controlled by = UEs >> themselves. >=20 > RFC 4821 says: "It is RECOMMENDED that IPv4 implementations use a > strategy that mimics IPv6 functionality. When an application sends > datagrams that are larger than the effective Path MTU, they SHOULD be > fragmented to the Path MTU in the host IP layer even if they are > smaller than the MTU of the first link, directly attached to the host. > The DF bit SHOULD be set on the fragments, so they will not be > fragmented again in the network." =20 > If I understood correctly, that > would result in the case "DF=3D1 MF=3D1". Yes. And also, to be complete, the case "DF=3D1 and Offset>0". > Some discussions reported that is a rare case. AFAIK, there were no > obsevered impacts to network so far. Therefore, I guess that should > not be a stumbling block to BCP if we could identify the problem > properly. Same view. =20 > Considering above, I'm trying to propose some texts to fix the gap. > Hope that could help. >=20 > " > This BCP is applied because 464xlat leverages available host/router > implementations by combining existing and well-known stateful protocol > translation [RFC6146] and stateless protocol translation [RFC6145]. > It's helpful to promote the mechanism introduction as an immediate > instantiation, which is justified as a good applicability to BCP > status [RFC2026]. On the other hand, it's worth to be noted that the > processing involved in the framework may not achieve fully reversible > translations, e.g. DF bits may not kept in the case of DF=3D1 and = MF=3D1. > The impacts of those cases are likely to be identified as a long-term > issue, since it's reported that the cases occurred rarely and not > observed as negative effects in practice. I don't think this last sentence has rigorous enough logic in face of = the fact that RFC4821 is standard track. An alternative to proposed item 3 could be: " 3. The fact that IPv4 packets that are fragmented by sources, and not = fragmentable in the network as recommended by [RFC4821], become = fragmentable again is considered of limited enough consequence and = considered rare enough and to be consciously accepted. (Packets sourced = with DF=3D1 and MF=3D1 and/or Offset>0 become MF=3D0 after 464 = translation)." =20 Kind regards, RD >=20 > This BCP can be applied when the following two criteria are present: >=20 > 1. There is an IPv6-only access network that uses stateful > translation [RFC6146] >=20 > 2. There are IPv4-only applications or hosts that must = communicate > across the IPv6-only access network to reach the IPv4 = Internet > " >=20 > Many thanks >=20 > Gang >=20 >=20 >=20 >> RD >>=20 >>=20 >>=20 >>>=20 >>>> Comments welcome. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>> 2012-08-07 07:53, Fred Baker (fred) : >>>>=20 >>>>> I'll let the current WGLC run and then open one for 464XLAT. >>>>>=20 >>>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>>>>=20 >>>>>>=20 >>>>>> v6ops chairs, >>>>>>=20 >>>>>> We have published draft-ietf-v6ops-464xlat-06. >>>>>> This draft is simply adding section 2 "BCP Scenario". >>>>>> Could you please start WGLC? >>>>>>=20 >>>>>> Thank you for your time and consideration. >>>>>>=20 >>>>>> Regards, >>>>>> Masanobu >>>=20 >>> ---------------------------------------------------- >>> The ignorance of how to use new knowledge stockpiles exponentially. >>> - Marshall McLuhan >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From despres.remi@laposte.net Wed Aug 8 00:23:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE611E80DF for ; Wed, 8 Aug 2012 00:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8sX4z-6l2sL for ; Wed, 8 Aug 2012 00:23:50 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 97D8711E80AD for ; Wed, 8 Aug 2012 00:23:49 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id 1912D70000D0; Wed, 8 Aug 2012 09:23:48 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id 20BC370000CE; Wed, 8 Aug 2012 09:23:45 +0200 (CEST) X-SFR-UUID: 20120808072345134.20BC370000CE@msfrf2204.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1031204757 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Aug 2012 09:23:44 +0200 Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:23:51 -0000 --Apple-Mail-1-1031204757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Maoke, Thanks for your comments. More inline. 2012-08-08 04:51, Maoke : >=20 > 2012/8/8 R=E9mi Despr=E9s >=20 > Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >=20 > > > > On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: > > > >> Hi, Fred, > >> > >> I agree that adding an applicability statement, as you requested = last week, is an approach that improves acceptability of BCP status (as = opposed to Informational recommended by some participants in Vancouver). > >> > >> This statement is currently: > >> " 2. BCP Scenario > >> This BCP only applies when the following two criteria are present: > >> 1. There is an IPv6-only access network that uses stateful = translation [RFC6146] > >> 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet > >> > >> In my understanding, it should be more complete, e.g. as follows: > >> > >> " 2. Applicability of 464XLAT > >> This BCP only applies when the following three criteria are = present: > >> 1. There is an IPv6-only access network that doesn't support = DS-lite [RFC6333] but supports NAT64 stateful translation [RFC6146] > >> 2. There are IPv4-only applications or hosts that must communicate = across the IPv6-only access network to reach the IPv4 Internet > >> 3. The lack of transparency to source-fragmented IPv4 packets that, = as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. = have DF=3D1), is considered acceptable. > > > > So you're arguing that we need a comment in this applicability = statement regarding each other solution, or just that one? >=20 > Just that one (no hidden intention!). >=20 > DS-Lite is an already specified stateful solution for IPv4 customers = that have no public addresses to reach the IPv4 Internet across = IPv6-only access networks. It hasn't the limitation of item 3. > If there are IPv6-only deployments where NAT64s are available but not = DS-Lite, in particular in the short term, 464XLAT is AFAIK better than = nothing, and is therefore, as said from the beginning, worth = documenting. > However, if DS-lite is available, using it is AFAIK better practice = (more transparent to IPv4, and very simple too in CPE/UEs). >=20 > i may say they are different practices but stating DS-lite *more = transparent to ipv4* is confusing. as there is a CGN, it is not = end-to-end transparent anyway.=20 Well, "more transparent" doesn't mean "fully transparent".=20 In any case, I propose to explain in what it is so, thus avoiding = confusion. > =20 >=20 > (Something more might be said for stateless solutions, but this is = AFAIK out of scope for 464XLAT.) >=20 >=20 > > It seems to me that at most (1) might add "to access an IPv4 = network" or "to access the IPv4 Internet" - which are different = statements. There is no reason to go into what the other options the = operator might have chosen might be. > > > > I'll let others comment on your third bullet. Personally, I would = not expect the implementation to require fragmentation, but would expect = it to use configuration or PMTU to ensure that the packets were small = enough. >=20 > a. Applications that send UDP datagrams longer than PMTUs, which is = the case of some games AFAIK, have to fragment. (If there would be no = such applications, why to have any fragmentation in IPv6?) >=20 > true that some games that poorly designed often do the big datagram. = on the other hand, there is no problem that these UDP datagrams will be = fragmented in the RFC6145/6146 combination. may you identify what the = concern is?=20 The only problem I see is that incompatibility with the logic = recommended by RFC 4821 needs to be signaled. No objection to accepting this fact, but objection to hiding it. Regards, RD >=20 > - maoke > =20 >=20 > b. In case of UE tethering, such applications are not controlled by = UEs themselves. >=20 > RD >=20 >=20 >=20 > > > >> Comments welcome. > >> > >> Regards, > >> RD > >> > >> > >> 2012-08-07 07:53, Fred Baker (fred) : > >> > >>> I'll let the current WGLC run and then open one for 464XLAT. > >>> > >>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: > >>> > >>>> > >>>> v6ops chairs, > >>>> > >>>> We have published draft-ietf-v6ops-464xlat-06. > >>>> This draft is simply adding section 2 "BCP Scenario". > >>>> Could you please start WGLC? > >>>> > >>>> Thank you for your time and consideration. > >>>> > >>>> Regards, > >>>> Masanobu > > > > ---------------------------------------------------- > > The ignorance of how to use new knowledge stockpiles exponentially. > > - Marshall McLuhan > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-1-1031204757 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Maoke,

Thanks for your comments.More inline.

2012/8/8 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit :

>
> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote:
>
>> Hi, Fred,
>>
>> I agree that adding an applicability statement, as you = requested last week, is an approach that improves acceptability of BCP = status (as opposed to Informational recommended by some participants in = Vancouver).
>>
>> This statement is currently:
>> " 2. BCP Scenario
>> This BCP only applies when the following two criteria are = present:
>> 1. There is an IPv6-only access network that uses stateful = translation [RFC6146]
>> 2. There are IPv4-only applications or hosts that must = communicate across the IPv6-only access network to reach the IPv4 = Internet
>>
>> In my understanding, it should be more complete, e.g. as = follows:
>>
>> " 2. Applicability of 464XLAT
>> This BCP only applies when the following three criteria are = present:
>> 1. There is an IPv6-only access network that doesn't support = DS-lite [RFC6333] but supports NAT64 stateful translation [RFC6146]
>> 2. There are IPv4-only applications or hosts that must = communicate across the IPv6-only access network to reach the IPv4 = Internet
>> 3. The lack of transparency to source-fragmented IPv4 packets = that, as recommended by RFC 4821, MUST NOT be fragmented by the network = (i.e. have DF=3D1), is considered acceptable.
>
> So you're arguing that we need a comment in this applicability = statement regarding each other solution, or just that one?

Just that one (no hidden intention!).

DS-Lite is an  already specified stateful solution for IPv4 = customers that have no public addresses to reach the IPv4 Internet = across IPv6-only access networks. It hasn't the limitation of item = 3.
If there are IPv6-only deployments where NAT64s are available but not = DS-Lite, in particular in the short term, 464XLAT is AFAIK better than = nothing, and is therefore, as said from the beginning, worth = documenting.
However, if DS-lite is available, using it is AFAIK better practice = (more transparent to IPv4, and very simple too in = CPE/UEs).

i may say they are = different practices but stating DS-lite *more transparent to ipv4* is = confusing. as there is a CGN, it is not end-to-end transparent = anyway. 

Well, "more = transparent" doesn't mean "fully transparent". 
In any = case, I propose to explain in what it is so, thus avoiding = confusion.

 

(Something more might be said for stateless solutions, but this is AFAIK = out of scope for 464XLAT.)


> It seems to me that at most (1) might add "to access an IPv4 = network" or "to access the IPv4 Internet" - which are different = statements. There is no reason to go into what the other options the = operator might have chosen might be.
>
> I'll let others comment on your third bullet. Personally, I would = not expect the implementation to require fragmentation, but would expect = it to use configuration or PMTU to ensure that the packets were small = enough.

a. Applications that send UDP datagrams longer than PMTUs, which = is the case of some games AFAIK, have to fragment. (If there would be no = such applications, why to have any fragmentation in = IPv6?)

true that some games that poorly designed often do the = big datagram. on the other hand, there is no problem that these UDP = datagrams will be fragmented in the RFC6145/6146 combination. may you = identify what the concern = is? 

The only problem I = see is that incompatibility with the logic recommended by RFC 4821 needs = to be signaled.
No objection to accepting this fact, but = objection to hiding = it.

Regards,
RD


- maoke
 

b. In case of UE tethering, such applications are not controlled by UEs = themselves.

RD



>
>> Comments welcome.
>>
>> Regards,
>> RD
>>
>>
>> 2012-08-07 07:53, Fred Baker (fred) :
>>
>>> I'll let the current WGLC run and then open one for = 464XLAT.
>>>
>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote:
>>>
>>>>
>>>> v6ops chairs,
>>>>
>>>> We have published draft-ietf-v6ops-464xlat-06.
>>>> This draft is simply adding section 2 "BCP = Scenario".
>>>> Could you please start WGLC?
>>>>
>>>> Thank you for your time and consideration.
>>>>
>>>> Regards,
>>>> Masanobu
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles = exponentially.
>   - Marshall McLuhan
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


= --Apple-Mail-1-1031204757-- From fibrib@gmail.com Wed Aug 8 00:49:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405C521F86B7 for ; Wed, 8 Aug 2012 00:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaHhdak178Hb for ; Wed, 8 Aug 2012 00:49:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84421F86B2 for ; Wed, 8 Aug 2012 00:49:50 -0700 (PDT) Received: by eekb45 with SMTP id b45so105640eek.31 for ; Wed, 08 Aug 2012 00:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gSs3DEeBlfpvCqdtSxyrvQMEG0o7JVTuuYQ/3X7EWWk=; b=Mpyats/l/lHCzCaswkj0atkZGEerFEKD1qyP8Tg5P8rnU2E0IZdgXXm16CIszi85vn BEowZIF2tWjN/Vq8tX5iYLnvdBJdwJVlpkCJfDkuGWIK7dnpxj9ZTHd0JZtlzEx+RFyO yRmDBaPrcMKLeZ4+beAimRQRMxfPhQxkZQQhDXc/MlEW6inqQIVDgXZPXxvew/yGP9Sm avOOhqO9/Z4JZ2eFKFKBQlbDWe8+U5Yec0Z6jfnjFfv3BYGtXeS7HB2t09l17MuOqxVf nOwM66cysYJh2fFO7Pnm2VfPJFLWuj4P4tcwZwYJGz7gm2xcXVEf8uzaS7NmvthSObin W9xA== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr21151913eep.14.1344412189709; Wed, 08 Aug 2012 00:49:49 -0700 (PDT) Received: by 10.14.211.131 with HTTP; Wed, 8 Aug 2012 00:49:49 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> Date: Wed, 8 Aug 2012 16:49:49 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c2ffd5fb04c6bc5a8d Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:49:52 -0000 --047d7b6224c2ffd5fb04c6bc5a8d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/8/8 R=E9mi Despr=E9s > Hi, Maoke, > > Thanks for your comments. > More inline. > > 2012-08-08 04:51, Maoke : > > > 2012/8/8 R=E9mi Despr=E9s > >> >> Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >> >> > >> > On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >> > >> >> Hi, Fred, >> >> >> >> I agree that adding an applicability statement, as you requested last >> week, is an approach that improves acceptability of BCP status (as oppos= ed >> to Informational recommended by some participants in Vancouver). >> >> >> >> This statement is currently: >> >> " 2. BCP Scenario >> >> This BCP only applies when the following two criteria are present: >> >> 1. There is an IPv6-only access network that uses stateful translatio= n >> [RFC6146] >> >> 2. There are IPv4-only applications or hosts that must communicate >> across the IPv6-only access network to reach the IPv4 Internet >> >> >> >> In my understanding, it should be more complete, e.g. as follows: >> >> >> >> " 2. Applicability of 464XLAT >> >> This BCP only applies when the following three criteria are present: >> >> 1. There is an IPv6-only access network that doesn't support DS-lite >> [RFC6333] but supports NAT64 stateful translation [RFC6146] >> >> 2. There are IPv4-only applications or hosts that must communicate >> across the IPv6-only access network to reach the IPv4 Internet >> >> 3. The lack of transparency to source-fragmented IPv4 packets that, a= s >> recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. hav= e >> DF=3D1), is considered acceptable. >> > >> > So you're arguing that we need a comment in this applicability >> statement regarding each other solution, or just that one? >> >> Just that one (no hidden intention!). >> >> DS-Lite is an already specified stateful solution for IPv4 customers >> that have no public addresses to reach the IPv4 Internet across IPv6-onl= y >> access networks. It hasn't the limitation of item 3. >> If there are IPv6-only deployments where NAT64s are available but not >> DS-Lite, in particular in the short term, 464XLAT is AFAIK better than >> nothing, and is therefore, as said from the beginning, worth documenting= . >> However, if DS-lite is available, using it is AFAIK better practice (mor= e >> transparent to IPv4, and very simple too in CPE/UEs). >> > > i may say they are different practices but stating DS-lite *more > transparent to ipv4* is confusing. as there is a CGN, it is not end-to-en= d > transparent anyway. > > > Well, "more transparent" doesn't mean "fully transparent". > In any case, I propose to explain in what it is so, thus avoiding > confusion. > > > >> >> (Something more might be said for stateless solutions, but this is AFAIK >> out of scope for 464XLAT.) >> >> >> > It seems to me that at most (1) might add "to access an IPv4 network" >> or "to access the IPv4 Internet" - which are different statements. There= is >> no reason to go into what the other options the operator might have chos= en >> might be. >> > >> > I'll let others comment on your third bullet. Personally, I would not >> expect the implementation to require fragmentation, but would expect it = to >> use configuration or PMTU to ensure that the packets were small enough. >> >> a. Applications that send UDP datagrams longer than PMTUs, which is the >> case of some games AFAIK, have to fragment. (If there would be no such >> applications, why to have any fragmentation in IPv6?) >> > > true that some games that poorly designed often do the big datagram. on > the other hand, there is no problem that these UDP datagrams will be > fragmented in the RFC6145/6146 combination. may you identify what the > concern is? > > > The only problem I see is that incompatibility with the logic recommended > by RFC 4821 needs to be signaled. > i think RFC4821 is more of recommending a host implementation that mimics ipv6's host fragmentation behavior by setting DF=3D1 no matter the anyway. CLAT RFC6145 can handle such DF=3D1 / MF=3D1 or offset > 0 but the only pro= blem is it cannot keep the intention of the host making the DF=3D1. i do agree to signal such an observation. i only don't think it should be in the applicability statement because the transparency of DF is not the design goal. :) - maoke > No objection to accepting this fact, but objection to hiding it. > > Regards, > RD > > > > - maoke > > >> >> b. In case of UE tethering, such applications are not controlled by UEs >> themselves. >> >> RD >> >> >> >> > >> >> Comments welcome. >> >> >> >> Regards, >> >> RD >> >> >> >> >> >> 2012-08-07 07:53, Fred Baker (fred) : >> >> >> >>> I'll let the current WGLC run and then open one for 464XLAT. >> >>> >> >>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >> >>> >> >>>> >> >>>> v6ops chairs, >> >>>> >> >>>> We have published draft-ietf-v6ops-464xlat-06. >> >>>> This draft is simply adding section 2 "BCP Scenario". >> >>>> Could you please start WGLC? >> >>>> >> >>>> Thank you for your time and consideration. >> >>>> >> >>>> Regards, >> >>>> Masanobu >> > >> > ---------------------------------------------------- >> > The ignorance of how to use new knowledge stockpiles exponentially. >> > - Marshall McLuhan >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > --047d7b6224c2ffd5fb04c6bc5a8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi,

2012/8/8 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi, Maoke,

Thanks for your comments.
More inline.

2012-08-08 04:51, Maoke :


2012/8= /8 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit :

>
> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote:
>
>> Hi, Fred,
>>
>> I agree that adding an applicability statement, as you requested l= ast week, is an approach that improves acceptability of BCP status (as oppo= sed to Informational recommended by some participants in Vancouver).
>>
>> This statement is currently:
>> " 2. BCP Scenario
>> This BCP only applies when the following two criteria are present:=
>> 1. There is an IPv6-only access network that uses stateful transla= tion [RFC6146]
>> 2. There are IPv4-only applications or hosts that must communicate= across the IPv6-only access network to reach the IPv4 Internet
>>
>> In my understanding, it should be more complete, e.g. as follows:<= br> >>
>> " 2. Applicability of 464XLAT
>> This BCP only applies when the following three criteria are presen= t:
>> 1. There is an IPv6-only access network that doesn't support D= S-lite [RFC6333] but supports NAT64 stateful translation [RFC6146]
>> 2. There are IPv4-only applications or hosts that must communicate= across the IPv6-only access network to reach the IPv4 Internet
>> 3. The lack of transparency to source-fragmented IPv4 packets that= , as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. h= ave DF=3D1), is considered acceptable.
>
> So you're arguing that we need a comment in this applicability sta= tement regarding each other solution, or just that one?

Just that one (no hidden intention!).

DS-Lite is an =A0already specified stateful solution for IPv4 customers tha= t have no public addresses to reach the IPv4 Internet across IPv6-only acce= ss networks. It hasn't the limitation of item 3.
If there are IPv6-only deployments where NAT64s are available but not DS-Li= te, in particular in the short term, 464XLAT is AFAIK better than nothing, = and is therefore, as said from the beginning, worth documenting.
However, if DS-lite is available, using it is AFAIK better practice (more t= ransparent to IPv4, and very simple too in CPE/UEs).
<= br>
i may say they are different practices but stating DS-lite *m= ore transparent to ipv4* is confusing. as there is a CGN, it is not end-to-= end transparent anyway.=A0

Well, "more transparent&q= uot; doesn't mean "fully transparent".=A0
In any ca= se, I propose to explain in what it is so, thus avoiding confusion.

=A0

(Something more might be said for stateless solutions, but this is AFAIK ou= t of scope for 464XLAT.)


> It seems to me that at most (1) might add "to access an IPv4 netw= ork" or "to access the IPv4 Internet" - which are different = statements. There is no reason to go into what the other options the operat= or might have chosen might be.
>
> I'll let others comment on your third bullet. Personally, I would = not expect the implementation to require fragmentation, but would expect it= to use configuration or PMTU to ensure that the packets were small enough.=

a. Applications that send UDP datagrams longer than PMTUs, which is t= he case of some games AFAIK, have to fragment. (If there would be no such a= pplications, why to have any fragmentation in IPv6?)

true that some games that poorly designed often do the big d= atagram. on the other hand, there is no problem that these UDP datagrams wi= ll be fragmented in the RFC6145/6146 combination. may you identify what the= concern is?=A0

The only problem I see is that= incompatibility with the logic recommended by RFC 4821 needs to be signale= d.

i think RF= C4821 is more of recommending a host implementation that mimics ipv6's = host fragmentation behavior by setting DF=3D1 no matter the anyway. CLAT RF= C6145 can handle such DF=3D1 / MF=3D1 or offset > 0 but the only problem= is it cannot keep the intention of the host making the DF=3D1.=A0

i do agree to signal such an observation. i only don= 9;t think it should be in the applicability statement because the transpare= ncy of DF is not the design goal. :)

- maoke
=A0
No objection to accepting this fact, but objectio= n to hiding it.

Regards,
RD

<= /div>

- maoke
=A0

b. In case of UE tethering, such applications are not controlled by UEs the= mselves.

RD



>
>> Comments welcome.
>>
>> Regards,
>> RD
>>
>>
>> 2012-08-07 07:53, Fred Baker (fred) :
>>
>>> I'll let the current WGLC run and then open one for 464XLA= T.
>>>
>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote:
>>>
>>>>
>>>> v6ops chairs,
>>>>
>>>> We have published draft-ietf-v6ops-464xlat-06.
>>>> This draft is simply adding section 2 "BCP Scenario&q= uot;.
>>>> Could you please start WGLC?
>>>>
>>>> Thank you for your time and consideration.
>>>>
>>>> Regards,
>>>> Masanobu
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially. > =A0 - Marshall McLuhan
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--047d7b6224c2ffd5fb04c6bc5a8d-- From phdgang@gmail.com Wed Aug 8 00:53:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEF821F86C9 for ; Wed, 8 Aug 2012 00:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hChFpcza4KHf for ; Wed, 8 Aug 2012 00:53:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C04C521F86B2 for ; Wed, 8 Aug 2012 00:53:55 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so501330vcb.31 for ; Wed, 08 Aug 2012 00:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9RmaOG38W8smRiDwZVYY1/jEzZ26spNC3WPPDE8RjNw=; b=v9oj+xrhQnOM99c0jncbwbB+P4YB4xBUqYoAePKudQHJua84mDCxF9aI1X+QNPQKaL h4XtsuEfitDQP5xCRq2IDhHPZrqVW2oHabKHCZp2Z1OQXHau2QXuvpeXyiBqtFVRS/RT 35gPYwfbQg7JUhJu/Rr0PdEniZgBNOiluv+q2AjIvO1RfBZM+0OkIswXi4seKzu3CS5/ 7RaXw+lFeW7UQ4W1UPdKr3JXSH6JZFuCXmw7zaYG/8vmDVevR9qW26iGWY2X+/EUNfC6 Y5A9u8j690WBKSV6wyljmruifPLPrzDLUEiNeUesaLjATnJFmt0aPfLUrvsFn/sEf/O2 Goow== MIME-Version: 1.0 Received: by 10.52.22.50 with SMTP id a18mr11474746vdf.60.1344412434882; Wed, 08 Aug 2012 00:53:54 -0700 (PDT) Received: by 10.58.79.34 with HTTP; Wed, 8 Aug 2012 00:53:54 -0700 (PDT) In-Reply-To: <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> Date: Wed, 8 Aug 2012 15:53:54 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:53:57 -0000 2012/8/8, R=E9mi Despr=E9s : > Hi, Gang, > > Thanks for your comments. > More inline. > > 2012-08-08 01:22, GangChen : > >> Hello Remi and authors, >> >> I'm supporting the BCP status because it is essential to guarantee >> multiple compatible implementations. >> More comments and proposed texts are inline. >> >> >> 2012/8/8, R=E9mi Despr=E9s : >>> >>> Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >>> >>>> >>>> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >>>> >>>>> Hi, Fred, >>>>> >>>>> I agree that adding an applicability statement, as you requested last >>>>> week, is an approach that improves acceptability of BCP status (as >>>>> opposed to Informational recommended by some participants in >>>>> Vancouver). >>>>> >>>>> This statement is currently: >>>>> " 2. BCP Scenario =09 >>>>> This BCP only applies when the following two criteria are present:=09 >>>>> 1. There is an IPv6-only access network that uses stateful translatio= n >>>>> [RFC6146]=09 >>>>> 2. There are IPv4-only applications or hosts that must communicate >>>>> across >>>>> the IPv6-only access network to reach the IPv4 Internet >>>>> >>>>> In my understanding, it should be more complete, e.g. as follows: >>>>> >>>>> " 2. Applicability of 464XLAT =09 >>>>> This BCP only applies when the following three criteria are present:= =09 >>>>> 1. There is an IPv6-only access network that doesn't support DS-lite >>>>> [RFC6333] but supports NAT64 stateful translation [RFC6146] >>>>> 2. There are IPv4-only applications or hosts that must communicate >>>>> across >>>>> the IPv6-only access network to reach the IPv4 Internet >>>>> 3. The lack of transparency to source-fragmented IPv4 packets that, a= s >>>>> recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. >>>>> have >>>>> DF=3D1), is considered acceptable. >>>> >>>> So you're arguing that we need a comment in this applicability >>>> statement >>>> regarding each other solution, or just that one? >>> >>> Just that one (no hidden intention!). >>> >>> DS-Lite is an already specified stateful solution for IPv4 customers >>> that >>> have no public addresses to reach the IPv4 Internet across IPv6-only >>> access >>> networks. It hasn't the limitation of item 3. >>> If there are IPv6-only deployments where NAT64s are available but not >>> DS-Lite, in particular in the short term, 464XLAT is AFAIK better than >>> nothing, and is therefore, as said from the beginning, worth >>> documenting. >>> However, if DS-lite is available, using it is AFAIK better practice >>> (more >>> transparent to IPv4, and very simple too in CPE/UEs). >> >> I see the fairy decision choosing NAT64 other than DS-lite in 464xlat >> because it could provide functional compability with ACL and many >> network provisioning facilities, especially in a mobile environment. >> Also agree Fred's comments "There is no reason to go into what the >> other options the operator might have chosen might be." > > Understood. With the addition I propose: > - I no longer object to BCP > - Where NAT64 is supported and DS-Lite isn't, this BCP recommends 464XLAT > This, I think, covers your need. It's great to hear that. Thanks > >>> (Something more might be said for stateless solutions, but this is AFAI= K >>> out >>> of scope for 464XLAT.) >>> >>> >>>> It seems to me that at most (1) might add "to access an IPv4 network" >>>> or >>>> "to access the IPv4 Internet" - which are different statements. There >>>> is >>>> no reason to go into what the other options the operator might have >>>> chosen >>>> might be. >>>> >>>> I'll let others comment on your third bullet. Personally, I would not >>>> expect the implementation to require fragmentation, but would expect i= t >>>> to >>>> use configuration or PMTU to ensure that the packets were small enough= . >>> >>> a. Applications that send UDP datagrams longer than PMTUs, which is the >>> case >>> of some games AFAIK, have to fragment. (If there would be no such >>> applications, why to have any fragmentation in IPv6?) >>> >>> b. In case of UE tethering, such applications are not controlled by UEs >>> themselves. >> >> RFC 4821 says: "It is RECOMMENDED that IPv4 implementations use a >> strategy that mimics IPv6 functionality. When an application sends >> datagrams that are larger than the effective Path MTU, they SHOULD be >> fragmented to the Path MTU in the host IP layer even if they are >> smaller than the MTU of the first link, directly attached to the host. >> The DF bit SHOULD be set on the fragments, so they will not be >> fragmented again in the network." > >> If I understood correctly, that >> would result in the case "DF=3D1 MF=3D1". > > Yes. > And also, to be complete, the case "DF=3D1 and Offset>0". > >> Some discussions reported that is a rare case. AFAIK, there were no >> obsevered impacts to network so far. Therefore, I guess that should >> not be a stumbling block to BCP if we could identify the problem >> properly. > > Same view. > > >> Considering above, I'm trying to propose some texts to fix the gap. >> Hope that could help. >> >> " >> This BCP is applied because 464xlat leverages available host/router >> implementations by combining existing and well-known stateful protocol >> translation [RFC6146] and stateless protocol translation [RFC6145]. >> It's helpful to promote the mechanism introduction as an immediate >> instantiation, which is justified as a good applicability to BCP >> status [RFC2026]. On the other hand, it's worth to be noted that the >> processing involved in the framework may not achieve fully reversible >> translations, e.g. DF bits may not kept in the case of DF=3D1 and MF=3D1= . > >> The impacts of those cases are likely to be identified as a long-term >> issue, since it's reported that the cases occurred rarely and not >> observed as negative effects in practice. > > I don't think this last sentence has rigorous enough logic in face of the > fact that RFC4821 is standard track. > An alternative to proposed item 3 could be: > " 3. The fact that IPv4 packets that are fragmented by sources, and not > fragmentable in the network as recommended by [RFC4821], become fragmenta= ble > again is considered of limited enough consequence and considered rare eno= ugh > and to be consciously accepted. (Packets sourced with DF=3D1 and MF=3D1 a= nd/or > Offset>0 become MF=3D0 after 464 translation)." Rigorous statements are always desirable I made second try on texts proposal to converge the discussion as following= . The general logic is to state the observation of BCP in advance. And then, BCP scenario is described. Is that acceptable to you? Same question is also to authors. =3D=3D=3D> Proposed texts This BCP is applied because 464xlat leverages available host/router implementations by combining existing and well-known stateful protocol translation [RFC6146] and stateless protocol translation [RFC6145]. It's helpful to promote the mechanism introduction as an immediate instantiation, which is justified as a good applicability to BCP status [RFC2026]. On the other hand, it's worth to be noted that the processing involved in the framework may not achieve fully reversible translations, e.g. packets sourced with DF=3D1 and MF=3D1 and/or Offset>0 become MF=3D0 after 464 translation. The fact that IPv4 packets that are fragmented by sources, and not fragmentable in the network as recommended by [RFC4821], become fragmentable again is considered of limited enough consequence and rare enough and to be consciously accepted. In regards to above observation, this BCP can be applied when the following two criteria are present: 1. There is an IPv6-only access network that uses stateful translation [RFC6146] 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only access network to reach the IPv4 Internet =3D=3D=3D> the end Many thanks Gang > > Kind regards, > RD > > >> >> This BCP can be applied when the following two criteria are present: >> >> 1. There is an IPv6-only access network that uses stateful >> translation [RFC6146] >> >> 2. There are IPv4-only applications or hosts that must communicat= e >> across the IPv6-only access network to reach the IPv4 Internet >> " >> >> Many thanks >> >> Gang >> >> >> >>> RD >>> >>> >>> >>>> >>>>> Comments welcome. >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>> 2012-08-07 07:53, Fred Baker (fred) : >>>>> >>>>>> I'll let the current WGLC run and then open one for 464XLAT. >>>>>> >>>>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>>>>> >>>>>>> >>>>>>> v6ops chairs, >>>>>>> >>>>>>> We have published draft-ietf-v6ops-464xlat-06. >>>>>>> This draft is simply adding section 2 "BCP Scenario". >>>>>>> Could you please start WGLC? >>>>>>> >>>>>>> Thank you for your time and consideration. >>>>>>> >>>>>>> Regards, >>>>>>> Masanobu >>>> >>>> ---------------------------------------------------- >>>> The ignorance of how to use new knowledge stockpiles exponentially. >>>> - Marshall McLuhan >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > From markzzzsmith@yahoo.com.au Wed Aug 8 02:14:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02F121F8710 for ; Wed, 8 Aug 2012 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA5CvwPqpHvH for ; Wed, 8 Aug 2012 02:14:07 -0700 (PDT) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by ietfa.amsl.com (Postfix) with SMTP id 59DA321F850D for ; Wed, 8 Aug 2012 02:14:07 -0700 (PDT) Received: from [98.139.91.65] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:14:04 -0000 Received: from [98.139.91.53] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:14:04 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:14:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 686579.61838.bm@omp1053.mail.sp2.yahoo.com Received: (qmail 28347 invoked by uid 60001); 8 Aug 2012 09:14:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344417244; bh=ZK/km+aCVlsaCvndnDrUqYzENgus3dwHOuAbMTBpTR4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dFzNlJDzGZA13795X2OswtphzyIS+rj7/p/MufpWs2rHRnHj4c+Y8eo3xyXkPc8BV4A8FAjAoQpPr90PGFV76hnMlJzUhCCdKdvbYzjrH260TpREg20kjP0G1i32XSqDU8u4bQaI4KK/KvBFjAcQgz8q0SuyMYwH0qHO6fiuaeo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KJb1maD1cwH8523FHnPNhv5LB/QY2bzxR/7XML5wvsAmIbTCZ/tOK0WW/JBbvEBZ/JFE/VMKHTQQEQRp033cdYDYnsLHkKoLlKZevrhCu+r08Hnn+m8CAajE9LUXx/9kQo075YDXWCGKS1EqIydG65B/syeYBNu/PkXgWB7Lcis=; X-YMail-OSG: RKO3HloVM1kTb.UdRl5ywUC_HQKLgholKKYpsReF8u_eCVI Wfro33YhBPwTrSxpw7jzDJz_SGt2X7FkRV.qLmKth084vOHlhTYq95kfhaul _IXjxB_tZY.dHwGUryQefKBVhkYn63ekLtWVhYHMxQAFgqibBfvrIYNUuCVX 9WAe45so3AEGZKUdjKAhSrSFp7r0MardnkN958V_sS1sGnEA3dg2yTBoI6_W dkJJmEq1iUAo4a73XgDvJTsoZdKZ5EQ_DiAXCUe8497U3zlPCL1p1nGxhgXg rpxV77xCLwqWBNeb162R22CQg8uPRV_LtG_nTD7f0Mu9glRwUFL0Wg7yNU69 wlGM0MFT3OQpBFa3n7ZycqiTYCxexvJxB2PWKZ4C6XZrpUvIIH.0ee40iDIb e6dRysGtvpiE1yA7jNztXvlsWj.FYmp8eNJV058ROnd7j3drAvq8p8fYpYXM TBsSzDyrQh3JFLO4tKRLun0MFbYC3GJiUeJmhMYjgjffa Received: from [150.101.221.237] by web32506.mail.mud.yahoo.com via HTTP; Wed, 08 Aug 2012 02:14:04 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <1344331498.66980.YahooMailNeo@web32508.mail.mud.yahoo.com> <20120807121116.GI38127@Space.Net> <1344371507.52191.YahooMailNeo@web32502.mail.mud.yahoo.com> <7826A281-0D1A-430D-8523-156F900C4E4E@cisco.com> Message-ID: <1344417244.18151.YahooMailNeo@web32506.mail.mud.yahoo.com> Date: Wed, 8 Aug 2012 02:14:04 -0700 (PDT) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" In-Reply-To: <7826A281-0D1A-430D-8523-156F900C4E4E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 09:14:08 -0000 Hi Fred,=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) <= fred@cisco.com>=0A> To: Mark ZZZ Smith =0A> Cc: = Gert Doering ; "v6ops@ietf.org" ; V6ops Cha= irs ; Ron Bonica =0A> Sent: We= dnesday, 8 August 2012 7:07 AM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-ic= p-guidance WGLC=0A> =0A> =0A> On Aug 7, 2012, at 1:31 PM, Mark ZZZ Smith wr= ote:=0A> =0A>> According to RFC6145, =0A>> =0A>> =A0 =A0 This document des= cribes stateful NAT64 translation, which allows=0A>> =A0 =A0 IPv6-only clie= nts to contact IPv4 servers using unicast UDP, TCP, or=0A>> =A0 =A0 ICMP.= =A0 One or more public IPv4 addresses assigned to a NAT64=0A>> =A0 =A0 tran= slator are shared among several IPv6-only clients.=A0 When stateful=0A>> = =A0 =A0 NAT64 is used in conjunction with DNS64, no changes are usually=0A>= > =A0 =A0 required in the IPv6 client or the IPv4 server.=0A>> =0A>> So NA= T64 wasn't designed for a scenario where IPv4-only clients contact =0A> IPv= 6 servers. =0A> =0A> =0A> Your quote is from RFC 6146, and you are correct = with regard to stateful NAT64. =0A> =0A> RFC 6145, which is stateless and u= ses an IPv6 address that contains an embedded =0A> IPv4 address, is very mu= ch defined to enable bidirectional session initiation =0A> between systems = with the stated type of address.=0A> =0A=0A=0AThanks for the referenc= es. To clarify, this ICP used Stateful NAT64.=0A=0ARegards,=0AMark. From markzzzsmith@yahoo.com.au Wed Aug 8 02:34:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058A21F8685 for ; Wed, 8 Aug 2012 02:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFPwt1ujCigs for ; Wed, 8 Aug 2012 02:34:22 -0700 (PDT) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by ietfa.amsl.com (Postfix) with SMTP id E568421F867A for ; Wed, 8 Aug 2012 02:34:22 -0700 (PDT) Received: from [98.139.91.66] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:34:22 -0000 Received: from [98.139.91.57] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:34:22 -0000 Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 08 Aug 2012 09:34:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 840023.11618.bm@omp1057.mail.sp2.yahoo.com Received: (qmail 65933 invoked by uid 60001); 8 Aug 2012 09:34:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344418462; bh=T+jF5On/S0MWkaYR/TCnCY/2LapkIN2lIIUuA35pt7I=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P3YapLpzM7CsxSIO4YlVdd8JIkRAmmG3X4ysSl/CsxUNJ088aFLgNF+nQFp67T5z1Dw2vH/PVmKfHK5gV2UCPXU0dSqQiqrFm/OzYWG968rkQmI1Zi04K38F2fpS3gGOOZXrVsDUQH9AQEQZvaMzka23tI0gkzft1Y6+XJ5HHgs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4qD5EACFGHOBhVAv8Pi1couoDZVnMUDTzTav+3cfHFPD8Tw+tOl7O5G6lvoGDEiFwMXb7sK6HdLnU4vEFc59RnviXeOtsjpoy3nR2x7RWLmDN3zBzOfAeNPwZnpQhCvYk53DarBni0Skq5xO8xlpK4NKtWMfZMebNtUEVvTPfgI=; X-YMail-OSG: BhrfCAcVM1llS_8ssoxldQBezaXN_i4AA7nkE0ECMGQTOAh 9WyOyJZlgEv_10FmSl9WhGC3IN5ILFhc.LAUvqpwybBb3gs0OH9JPj1DRs6m eRwqJmNLnP5M1z3JXAuopWb3WnwjkTqDUj8x6VNi9wOzItM61PHd1MxgpVbb v0u4Te4dw0Ll8R8ZdbqbJTclfVyoiZrVKG23DmkiOqrSYuWqEDYpVDHs2UhM OapJW3GeIEpnk4M_zqFsroa6P_yz_ynWFQelzjJZTjo4HQ1vRrOg1mkxVF5T Deu96SJH9fpx3goY1tX3w0WwQEal7JM41pSnNmLXVsBFR54uDNCDVnn7neN. KbVhyOeXkfgfLRmAMxaIIShyJG2ajKL1nqMgeMP10s0JEA2sgYZHhYQmNvYN Mg7ESLd2gACfBO9JqaD8052YFbmH7FZHSfP6OMUUfwyS57nmHvb6n0Y21CBM eESpVNtoWzgOMGhZJRYSDHxmVQu59mvbzetHTKFkRLQ2wdg-- Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Wed, 08 Aug 2012 02:34:22 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> Message-ID: <1344418462.42995.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Wed, 8 Aug 2012 02:34:22 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 09:34:23 -0000 =0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Brian E Carpenter =0A>Cc: V6o= ps Chairs ; "v6ops@ietf.org" ;= Ron Bonica =0A>Sent: Wednesday, 8 August 2012 3:33 PM=0A>= Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC]=0A> = =0A>=0A>On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpenter wrote:=0A>=0A>I think that's unfair and kind of ignores draft= -v6ops-multihoming-without-ipv6nat=0A>>=0A>>It works today. There are known= difficulties with address selection=0A>>and with ingress filtering, of cou= rse. And it's a bit more fiddly to=0A>>configure routing and DNS for IT cre= ws used to the old way of doing things.=0A>>But it really isn't unknown ter= ritory.=0A>>=0A>=0A>=0A>If I were a content provider, I would think twice b= efore choosing an architecture that breaks TCP connections when upstreams g= o down.=0A=0AStateful LBs and NPTv6s also performing stateful payload addre= ss translation (e.g. because TCP sequence numbers have to be bumped) going = down would also be similarly disruptive to TCP connections wouldn't they?= =0A=0ANPTv6 is better than traditional IPv4 NAPT because the address transl= ation in the IPv6 headers is stateless, however translating addresses in ap= plication payloads may not be, and your NPTv6 devices also then have to be = application protocol aware, creating constraints if you want deploy new app= lication protocols. My experience on the residential eyeball side of IPv4 l= oad balances and the troubleshooting problems they've caused me or workarou= nds I've had to deploy at the network layer makes me hope they'll be far le= ss common in IPv6.=0A=0ARegards,=0AMark. From despres.remi@laposte.net Wed Aug 8 03:29:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AEE21F86C4 for ; Wed, 8 Aug 2012 03:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99fpEhUsYT3x for ; Wed, 8 Aug 2012 03:29:34 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD221F8685 for ; Wed, 8 Aug 2012 03:29:34 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 01CE170000A3; Wed, 8 Aug 2012 12:29:33 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 56FF070000A1; Wed, 8 Aug 2012 12:29:29 +0200 (CEST) X-SFR-UUID: 20120808102929356.56FF070000A1@msfrf2412.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Aug 2012 12:29:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 10:29:35 -0000 2012-08-08 09:53, GangChen : > 2012/8/8, R=E9mi Despr=E9s : >> Hi, Gang, >>=20 >> Thanks for your comments. >> More inline. >>=20 >> 2012-08-08 01:22, GangChen : >>=20 >>> Hello Remi and authors, >>>=20 >>> I'm supporting the BCP status because it is essential to guarantee >>> multiple compatible implementations. >>> More comments and proposed texts are inline. >>>=20 >>>=20 >>> 2012/8/8, R=E9mi Despr=E9s : >>>>=20 >>>> Le 2012-08-07 =E0 17:43, Fred Baker (fred) a =E9crit : >>>>=20 >>>>>=20 >>>>> On Aug 7, 2012, at 7:39 AM, R=E9mi Despr=E9s wrote: >>>>>=20 >>>>>> Hi, Fred, >>>>>>=20 >>>>>> I agree that adding an applicability statement, as you requested = last >>>>>> week, is an approach that improves acceptability of BCP status = (as >>>>>> opposed to Informational recommended by some participants in >>>>>> Vancouver). >>>>>>=20 >>>>>> This statement is currently: >>>>>> " 2. BCP Scenario =09 >>>>>> This BCP only applies when the following two criteria are = present:=09 >>>>>> 1. There is an IPv6-only access network that uses stateful = translation >>>>>> [RFC6146]=09 >>>>>> 2. There are IPv4-only applications or hosts that must = communicate >>>>>> across >>>>>> the IPv6-only access network to reach the IPv4 Internet >>>>>>=20 >>>>>> In my understanding, it should be more complete, e.g. as follows: >>>>>>=20 >>>>>> " 2. Applicability of 464XLAT =09 >>>>>> This BCP only applies when the following three criteria are = present:=09 >>>>>> 1. There is an IPv6-only access network that doesn't support = DS-lite >>>>>> [RFC6333] but supports NAT64 stateful translation [RFC6146] >>>>>> 2. There are IPv4-only applications or hosts that must = communicate >>>>>> across >>>>>> the IPv6-only access network to reach the IPv4 Internet >>>>>> 3. The lack of transparency to source-fragmented IPv4 packets = that, as >>>>>> recommended by RFC 4821, MUST NOT be fragmented by the network = (i.e. >>>>>> have >>>>>> DF=3D1), is considered acceptable. >>>>>=20 >>>>> So you're arguing that we need a comment in this applicability >>>>> statement >>>>> regarding each other solution, or just that one? >>>>=20 >>>> Just that one (no hidden intention!). >>>>=20 >>>> DS-Lite is an already specified stateful solution for IPv4 = customers >>>> that >>>> have no public addresses to reach the IPv4 Internet across = IPv6-only >>>> access >>>> networks. It hasn't the limitation of item 3. >>>> If there are IPv6-only deployments where NAT64s are available but = not >>>> DS-Lite, in particular in the short term, 464XLAT is AFAIK better = than >>>> nothing, and is therefore, as said from the beginning, worth >>>> documenting. >>>> However, if DS-lite is available, using it is AFAIK better practice >>>> (more >>>> transparent to IPv4, and very simple too in CPE/UEs). >>>=20 >>> I see the fairy decision choosing NAT64 other than DS-lite in = 464xlat >>> because it could provide functional compability with ACL and many >>> network provisioning facilities, especially in a mobile environment. >>> Also agree Fred's comments "There is no reason to go into what the >>> other options the operator might have chosen might be." >>=20 >> Understood. With the addition I propose: >> - I no longer object to BCP >> - Where NAT64 is supported and DS-Lite isn't, this BCP recommends = 464XLAT >> This, I think, covers your need. >=20 > It's great to hear that. > Thanks >=20 >>=20 >>>> (Something more might be said for stateless solutions, but this is = AFAIK >>>> out >>>> of scope for 464XLAT.) >>>>=20 >>>>=20 >>>>> It seems to me that at most (1) might add "to access an IPv4 = network" >>>>> or >>>>> "to access the IPv4 Internet" - which are different statements. = There >>>>> is >>>>> no reason to go into what the other options the operator might = have >>>>> chosen >>>>> might be. >>>>>=20 >>>>> I'll let others comment on your third bullet. Personally, I would = not >>>>> expect the implementation to require fragmentation, but would = expect it >>>>> to >>>>> use configuration or PMTU to ensure that the packets were small = enough. >>>>=20 >>>> a. Applications that send UDP datagrams longer than PMTUs, which is = the >>>> case >>>> of some games AFAIK, have to fragment. (If there would be no such >>>> applications, why to have any fragmentation in IPv6?) >>>>=20 >>>> b. In case of UE tethering, such applications are not controlled by = UEs >>>> themselves. >>>=20 >>> RFC 4821 says: "It is RECOMMENDED that IPv4 implementations use a >>> strategy that mimics IPv6 functionality. When an application sends >>> datagrams that are larger than the effective Path MTU, they SHOULD = be >>> fragmented to the Path MTU in the host IP layer even if they are >>> smaller than the MTU of the first link, directly attached to the = host. >>> The DF bit SHOULD be set on the fragments, so they will not be >>> fragmented again in the network." >>=20 >>> If I understood correctly, that >>> would result in the case "DF=3D1 MF=3D1". >>=20 >> Yes. >> And also, to be complete, the case "DF=3D1 and Offset>0". >>=20 >>> Some discussions reported that is a rare case. AFAIK, there were no >>> obsevered impacts to network so far. Therefore, I guess that should >>> not be a stumbling block to BCP if we could identify the problem >>> properly. >>=20 >> Same view. >>=20 >>=20 >>> Considering above, I'm trying to propose some texts to fix the gap. >>> Hope that could help. >>>=20 >>> " >>> This BCP is applied because 464xlat leverages available host/router >>> implementations by combining existing and well-known stateful = protocol >>> translation [RFC6146] and stateless protocol translation [RFC6145]. >>> It's helpful to promote the mechanism introduction as an immediate >>> instantiation, which is justified as a good applicability to BCP >>> status [RFC2026]. On the other hand, it's worth to be noted that the >>> processing involved in the framework may not achieve fully = reversible >>> translations, e.g. DF bits may not kept in the case of DF=3D1 and = MF=3D1. >>=20 >>> The impacts of those cases are likely to be identified as a = long-term >>> issue, since it's reported that the cases occurred rarely and not >>> observed as negative effects in practice. >>=20 >> I don't think this last sentence has rigorous enough logic in face of = the >> fact that RFC4821 is standard track. >> An alternative to proposed item 3 could be: >> " 3. The fact that IPv4 packets that are fragmented by sources, and = not >> fragmentable in the network as recommended by [RFC4821], become = fragmentable >> again is considered of limited enough consequence and considered rare = enough >> and to be consciously accepted. (Packets sourced with DF=3D1 and MF=3D1= and/or >> Offset>0 become MF=3D0 after 464 translation)." >=20 > Rigorous statements are always desirable > I made second try on texts proposal to converge the discussion as = following. >=20 > The general logic is to state the observation of BCP in advance. And > then, BCP scenario is described. > Is that acceptable to you? > Same question is also to authors. >=20 >=20 > =3D=3D=3D> Proposed texts >=20 > This BCP is applied because 464xlat leverages available host/router > implementations by combining existing and well-known stateful protocol > translation [RFC6146] and stateless protocol translation [RFC6145]. > It's helpful to promote the mechanism introduction as an immediate > instantiation, which is justified as a good applicability to BCP > status [RFC2026]. On the other hand, it's worth to be noted that the > processing involved in the framework may not achieve fully reversible > translations, e.g. packets sourced with DF=3D1 and MF=3D1 and/or = Offset>0 > become MF=3D0 after 464 translation. The fact that IPv4 packets that = are > fragmented by sources, and not fragmentable in the network as > recommended by [RFC4821], become fragmentable again is considered of > limited enough consequence and rare enough and to be consciously > accepted. >=20 > In regards to above observation, this BCP can be applied when the > following two criteria are present: >=20 > 1. There is an IPv6-only access network that uses stateful > translation [RFC6146] >=20 > 2. There are IPv4-only applications or hosts that must = communicate > across the IPv6-only access network to reach the IPv4 = Internet a. Concerning DF bit, this works for me, thanks. b. As also discussed, the applicability statement should clarify that, = in access networks where both NAT64 and DS-Lite are available, using = DS-Lite should be recommended (better IPv4 transparency). For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would = be enough for me. Accepted? RD >=20 > =3D=3D=3D> the end >=20 > Many thanks >=20 > Gang >>=20 >> Kind regards, >> RD >>=20 >>=20 >>>=20 >>> This BCP can be applied when the following two criteria are present: >>>=20 >>> 1. There is an IPv6-only access network that uses stateful >>> translation [RFC6146] >>>=20 >>> 2. There are IPv4-only applications or hosts that must = communicate >>> across the IPv6-only access network to reach the IPv4 = Internet >>> " >>>=20 >>> Many thanks >>>=20 >>> Gang >>>=20 >>>=20 >>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> Comments welcome. >>>>>>=20 >>>>>> Regards, >>>>>> RD >>>>>>=20 >>>>>>=20 >>>>>> 2012-08-07 07:53, Fred Baker (fred) : >>>>>>=20 >>>>>>> I'll let the current WGLC run and then open one for 464XLAT. >>>>>>>=20 >>>>>>> On Aug 6, 2012, at 9:39 PM, Masanobu Kawashima wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> v6ops chairs, >>>>>>>>=20 >>>>>>>> We have published draft-ietf-v6ops-464xlat-06. >>>>>>>> This draft is simply adding section 2 "BCP Scenario". >>>>>>>> Could you please start WGLC? >>>>>>>>=20 >>>>>>>> Thank you for your time and consideration. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Masanobu >>>>>=20 >>>>> ---------------------------------------------------- >>>>> The ignorance of how to use new knowledge stockpiles = exponentially. >>>>> - Marshall McLuhan >>>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 >>=20 From gert@space.net Wed Aug 8 04:28:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C990821F863B for ; Wed, 8 Aug 2012 04:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+pZnYMCK55I for ; Wed, 8 Aug 2012 04:28:29 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90C21F85DA for ; Wed, 8 Aug 2012 04:28:28 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 6B591F8C78 for ; Wed, 8 Aug 2012 13:28:26 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 490C8F8C6D for ; Wed, 8 Aug 2012 13:28:26 +0200 (CEST) Received: (qmail 11063 invoked by uid 1007); 8 Aug 2012 13:28:26 +0200 Date: Wed, 8 Aug 2012 13:28:26 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20120808112826.GS38127@Space.Net> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 11:28:29 -0000 Hi, On Wed, Aug 08, 2012 at 02:33:55PM +0900, Lorenzo Colitti wrote: > If I were a content provider, I would think twice before choosing an > architecture that breaks TCP connections when upstreams go down. So you'll not use anything BGP based, then? (Upstreams going down usually lead to transient loops and ICMP unreachables, and those usually kill TCP sessions, at least if Windows stacks are involved) Dual-/48 + shim6 actually reconverges *faster* on outage than anything BGP based. Just sayin' Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From brian.e.carpenter@gmail.com Wed Aug 8 05:12:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE3521F8600 for ; Wed, 8 Aug 2012 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.485 X-Spam-Level: X-Spam-Status: No, score=-101.485 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eDlOoBj6rml for ; Wed, 8 Aug 2012 05:12:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F521F85F7 for ; Wed, 8 Aug 2012 05:12:20 -0700 (PDT) Received: by eaai11 with SMTP id i11so209524eaa.31 for ; Wed, 08 Aug 2012 05:12:19 -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=TYx3eJhPwbJCbpO5U1KoF+MSLtTyHjSN4ZO5MED5pkc=; b=zLzb1Zj8B+SnVCh8UjkI4A20LMZv9eS2tLbFH/qzHXWHD6os4BY9RakmiqC9+rJi0B bjY/ZyPz0edD1e3WZDGcNiFr9ibPN0zNtBGnNytsGch5nM3Mi0RkxrKNGjAYmB/ROvMv 6A9MQ4lCah1PHalXn1IVFLO+SMMn2JR7QpVtaVwqvBN425dTPFM3mwb8BDL8fVmolEL1 agF+B3g7asu0NGQTn1L8LfA7ONHxuqlTwTvrE7NZkF0CIr7iwVQaMOaNuMP2BHzCNzcL pRghG9wWdfMbgwRfbFSiQVQJ4ZUfzusUjlHnZZITpMDpbEv2z9MhnQelyCH2uWZU/OuO qQNg== Received: by 10.14.210.197 with SMTP id u45mr22086770eeo.42.1344427939755; Wed, 08 Aug 2012 05:12:19 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-169.as13285.net. [2.102.217.169]) by mx.google.com with ESMTPS id h42sm64204346eem.5.2012.08.08.05.12.18 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 05:12:18 -0700 (PDT) Message-ID: <502257A7.7080208@gmail.com> Date: Wed, 08 Aug 2012 13:12:23 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: V6ops Chairs , "v6ops@ietf.org" , Ron Bonica Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 12:12:21 -0000 On 08/08/2012 06:33, Lorenzo Colitti wrote: > On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> I think that's unfair and kind of ignores >> draft-v6ops-multihoming-without-ipv6nat >> >> It works today. There are known difficulties with address selection >> and with ingress filtering, of course. And it's a bit more fiddly to >> configure routing and DNS for IT crews used to the old way of doing things. >> But it really isn't unknown territory. >> > > If I were a content provider, I would think twice before choosing an > architecture that breaks TCP connections when upstreams go down. Yes, and that certainly deserves a warning in the text. My concern here, as I've already hinted, is publishing advice that is valid for the N thousand enterprises that can reasonably expect to get a PI prefix but nothing for the N million others that may wish to serve up content *and* be multihomed. Brian > From aservin@lacnic.net Wed Aug 8 08:00:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70AC21F8679 for ; Wed, 8 Aug 2012 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=2.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylSTmDXBSk+E for ; Wed, 8 Aug 2012 08:00:03 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [200.7.84.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8867221F8628 for ; Wed, 8 Aug 2012 08:00:02 -0700 (PDT) Received: from [IPv6:2001:13c7:7001:5128:7939:808a:7478:e7bd] (unknown [IPv6:2001:13c7:7001:5128:7939:808a:7478:e7bd]) by mail.lacnic.net.uy (Postfix) with ESMTP id D056A308465; Wed, 8 Aug 2012 11:59:29 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_ADCEBA31-3814-4F59-8304-DFC370D4615C" From: Arturo Servin In-Reply-To: <502257A7.7080208@gmail.com> Date: Wed, 8 Aug 2012 11:59:29 -0300 Message-Id: <4E118319-8D7F-40FC-B966-C7F44963A2F2@lacnic.net> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> <502257A7.7080208@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: Ron Bonica , "v6ops@ietf.org" , V6ops Chairs Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:00:04 -0000 --Apple-Mail=_ADCEBA31-3814-4F59-8304-DFC370D4615C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, But we are not talking about enterprises, we are talking about = ICPs, which IMHO are two different problems and advices. For Enterprises, yes PA and PI are debatable (as discussed in = many places, many times) and more dependent on the size and type of = enterprise, for ICPs I think we are more or less in consensus that PI is = more much common (and IMO the recommendation). Perhaps, the corner case are "small ICPs" which if they are = uni-homed, then PA is fine, if they are multi-homed then BGP+PI should = be the recommendation no matter if they are small or large. Regards, as On 8 Aug 2012, at 09:12, Brian E Carpenter wrote: > My concern here, as I've already hinted, is publishing advice that is > valid for the N thousand enterprises that can reasonably expect to get > a PI prefix but nothing for the N million others that may wish to = serve > up content *and* be multihomed. --Apple-Mail=_ADCEBA31-3814-4F59-8304-DFC370D4615C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii But we are not talking about = enterprises, we are talking about ICPs, which IMHO are two different = problems and advices.

For = Enterprises, yes PA and PI are debatable (as discussed in many places, = many times) and more dependent on the size and type of enterprise, for = ICPs I think we are more or less in consensus that PI is more much = common (and IMO the recommendation).

Perhaps, = the corner case are "small ICPs" which if they are uni-homed, then PA is = fine, if they are multi-homed then BGP+PI should be the recommendation = no matter if they are small or = large.

Regards,
as

O= n 8 Aug 2012, at 09:12, Brian E Carpenter wrote:

My concern = here, as I've already hinted, is publishing advice that is
valid for = the N thousand enterprises that can reasonably expect to get
a PI = prefix but nothing for the N million others that may wish to serve
up = content *and* be multihomed.

= --Apple-Mail=_ADCEBA31-3814-4F59-8304-DFC370D4615C-- From brian.e.carpenter@gmail.com Wed Aug 8 08:16:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E8F11E80C5 for ; Wed, 8 Aug 2012 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.189 X-Spam-Level: X-Spam-Status: No, score=-101.189 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+HshkvuztJF for ; Wed, 8 Aug 2012 08:16:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50021F8679 for ; Wed, 8 Aug 2012 08:16:52 -0700 (PDT) Received: by eaai11 with SMTP id i11so280034eaa.31 for ; Wed, 08 Aug 2012 08:16:52 -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=jHdZOEHWwN57d2sFE3M+jiYiLU46uY/Ij31Mq8RtdQQ=; b=OJFKMsOVHJqBIE3Z4cKM+bqKrD4h6xnICwJyTG6EHAIsYiMuhb8pLVo0L93HJ8ZCAX yj0Z4Ow+EszYdeGsNIWoJPv+cZCHk1Bi/Dz8B+TLss6F1MHvH2tXA/1qjPDFAc4unU6h lZEad7mkQFdWIis3aA0qAW6krqVuoaEY4hOZWi9QJPrbLelgP2sik/P5cxRv09VxoEnh s0oqJR9ak1OiseTphZ6si6TOa2B01+93BdYdlz0nIl3M2/VR8prv7Smyt0C5Qp9tEQ6Q 4sJrEogQwAe76OBpZalARI6aSq4Rc/4+mwAzV1PkkHMjLNXuHpLTKUhxulM66STrRMix qjGA== Received: by 10.14.215.197 with SMTP id e45mr22602446eep.36.1344439012350; Wed, 08 Aug 2012 08:16:52 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-169.as13285.net. [2.102.217.169]) by mx.google.com with ESMTPS id g46sm65169231eep.15.2012.08.08.08.16.50 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 08:16:51 -0700 (PDT) Message-ID: <502282E7.3050502@gmail.com> Date: Wed, 08 Aug 2012 16:16:55 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arturo Servin References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> <502257A7.7080208@gmail.com> <4E118319-8D7F-40FC-B966-C7F44963A2F2@lacnic.net> In-Reply-To: <4E118319-8D7F-40FC-B966-C7F44963A2F2@lacnic.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , "v6ops@ietf.org" , V6ops Chairs Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:16:54 -0000 On 08/08/2012 15:59, Arturo Servin wrote: > Brian, > > But we are not talking about enterprises, we are talking about ICPs, which IMHO are two different problems and advices. To be clear, I intended to talk about either pure specialised ICPs, or an enterprise that wishes to behave as an ICP for its own content. > For Enterprises, yes PA and PI are debatable (as discussed in many places, many times) and more dependent on the size and type of enterprise, for ICPs I think we are more or less in consensus that PI is more much common (and IMO the recommendation). > > Perhaps, the corner case are "small ICPs" which if they are uni-homed, then PA is fine, if they are multi-homed then BGP+PI should be the recommendation no matter if they are small or large. But that's the case that doesn't scale to millions. Are you suggesting that we have to tell them "you can't serve your own content reliably, because you're too small"? Brian > Regards, > as > > On 8 Aug 2012, at 09:12, Brian E Carpenter wrote: > >> My concern here, as I've already hinted, is publishing advice that is >> valid for the N thousand enterprises that can reasonably expect to get >> a PI prefix but nothing for the N million others that may wish to serve >> up content *and* be multihomed. > > From arturo.servin@gmail.com Wed Aug 8 08:29:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BF421F86CB for ; Wed, 8 Aug 2012 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbjgq0ed7TZr for ; Wed, 8 Aug 2012 08:28:59 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3A421F86B9 for ; Wed, 8 Aug 2012 08:28:59 -0700 (PDT) Received: by yhq56 with SMTP id 56so993041yhq.31 for ; Wed, 08 Aug 2012 08:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fv9oukAJOXmYPuuX5ynMuQhLnIcrE8AHvPNag8DW1tc=; b=BOS0p/covJn7/M6TDhhI7aTz5wEVaIzVS4sVKU1/pmA0FFL8qLLV2CNb5jb8S2hNNc D3mG28exycIvlefEc8VfQDKI4lbS9uzRKS5GFCc62wrGyZ6qpD4v3bbwYtqBIVQPGUgc 0aVKGwHMhu29G4BPzb9vknViWz1hDspNMpo9V2NmSjAyI+Yfdk2s1e8kz6MU6WA4LruP IDSO9HOCiIhjDA3rNrKFPeIH+6C7fFQS/5g1R/MIBL7rNsUYa8o8ch/unHvLZU7kAcSO iTi0kT7b4T6yfU5getyOQwd5hDHSYp8qnH406L9EQO5oAHCDm+b3095O93YzL9nEe3r+ R9Uw== Received: by 10.101.134.32 with SMTP id l32mr5373622ann.12.1344439738872; Wed, 08 Aug 2012 08:28:58 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.140]) by mx.google.com with ESMTPS id s12sm14043807anh.2.2012.08.08.08.28.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 08:28:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <502282E7.3050502@gmail.com> Date: Wed, 8 Aug 2012 12:28:52 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <49BE778F-5C3C-4BA6-8E2C-AC068EA68943@gmail.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> <502257A7.7080208@gmail.com> <4E118319-8D7F-40FC-B966-C7F44963A2F2@lacnic.net> <502282E7.3050502@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1278) Cc: Ron Bonica , "v6ops@ietf.org" , V6ops Chairs Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:29:00 -0000 No, I didn't say that. 1) if you are small, multi-homed you should use BGP+PI. 2) if you are small and uni-home use PA. =09 If 1 does not scale (I would question that), it is a problem = that we should solve elsewhere. There are other solutions for 1, but I would not recommend them = as a best practice, just like workarounds to use PA and avoid BGP. 1 and 2 are orthogonal to the fact that the ICP is as well an = enterprise or not. Regards, as On 8 Aug 2012, at 12:16, Brian E Carpenter wrote: > On 08/08/2012 15:59, Arturo Servin wrote: >> Brian, >>=20 >> But we are not talking about enterprises, we are talking about = ICPs, which IMHO are two different problems and advices. >=20 > To be clear, I intended to talk about either pure specialised ICPs, or = an enterprise that > wishes to behave as an ICP for its own content. >=20 >> For Enterprises, yes PA and PI are debatable (as discussed in = many places, many times) and more dependent on the size and type of = enterprise, for ICPs I think we are more or less in consensus that PI is = more much common (and IMO the recommendation). >>=20 >> Perhaps, the corner case are "small ICPs" which if they are = uni-homed, then PA is fine, if they are multi-homed then BGP+PI should = be the recommendation no matter if they are small or large. >=20 > But that's the case that doesn't scale to millions. Are you suggesting = that > we have to tell them "you can't serve your own content reliably, = because > you're too small"? >=20 > Brian >=20 >> Regards, >> as >>=20 >> On 8 Aug 2012, at 09:12, Brian E Carpenter wrote: >>=20 >>> My concern here, as I've already hinted, is publishing advice that = is >>> valid for the N thousand enterprises that can reasonably expect to = get >>> a PI prefix but nothing for the N million others that may wish to = serve >>> up content *and* be multihomed. >>=20 >>=20 From phdgang@gmail.com Wed Aug 8 08:48:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3EC21F86DC for ; Wed, 8 Aug 2012 08:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGOOaFi7X605 for ; Wed, 8 Aug 2012 08:47:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00AB921F86D9 for ; Wed, 8 Aug 2012 08:47:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so982486vbb.31 for ; Wed, 08 Aug 2012 08:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZiqlMZTlbMkRdrKV9z9ryjoWg3FC8HBNAHADUd3xaEI=; b=J6WGlxO0NsFWpgWVKsf+rpP4JI9RdyDivBrPz+ytRjjmU/m1POmqpa1O5qTgHbr9Dg uGn+j2SNQHaNAWEsefBBQtDAri7H4wQsaDnZn5lP2nmIPTgTQQTSthHCTwbsTx9pqxyR nTTmEGDP9XENX+IjTr+SGszcFxgjBsfVJJZkuDlLruRQa7+9T9QD2QxTC6Kn/4Z1Qg2R dcjBEJkXQjjFZn/Z2OqDtp8mQt1IA5RxgOkn3tEcGWQxb5K2g0oqqHDcrJUVlwlT9T2k HmQobND1aJ27eOj5wgvfFSN6w+Si4KRck33l271DidERebd+Bs+zHa2R0ZN5TOGQ8W9Z BPCA== MIME-Version: 1.0 Received: by 10.220.220.76 with SMTP id hx12mr14408784vcb.9.1344440877118; Wed, 08 Aug 2012 08:47:57 -0700 (PDT) Received: by 10.58.79.34 with HTTP; Wed, 8 Aug 2012 08:47:57 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> Date: Wed, 8 Aug 2012 23:47:57 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:48:03 -0000 2012/8/8, R=E9mi Despr=E9s : >> =3D=3D=3D> Proposed texts >> >> This BCP is applied because 464xlat leverages available host/router >> implementations by combining existing and well-known stateful protocol >> translation [RFC6146] and stateless protocol translation [RFC6145]. >> It's helpful to promote the mechanism introduction as an immediate >> instantiation, which is justified as a good applicability to BCP >> status [RFC2026]. On the other hand, it's worth to be noted that the >> processing involved in the framework may not achieve fully reversible >> translations, e.g. packets sourced with DF=3D1 and MF=3D1 and/or Offset>= 0 >> become MF=3D0 after 464 translation. The fact that IPv4 packets that are >> fragmented by sources, and not fragmentable in the network as >> recommended by [RFC4821], become fragmentable again is considered of >> limited enough consequence and rare enough and to be consciously >> accepted. >> >> In regards to above observation, this BCP can be applied when the >> following two criteria are present: >> >> 1. There is an IPv6-only access network that uses stateful >> translation [RFC6146] >> >> 2. There are IPv4-only applications or hosts that must communicat= e >> across the IPv6-only access network to reach the IPv4 Internet > > a. Concerning DF bit, this works for me, thanks. > > b. As also discussed, the applicability statement should clarify that, in > access networks where both NAT64 and DS-Lite are available, using DS-Lite > should be recommended (better IPv4 transparency). > For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would b= e > enough for me. > Accepted? The comment in this applicability statement is only regarding 464xlat. As commented earlier "There is no reason to go into what the other options the operator might have chosen might be. " IMHO, the proposed statement above already covered your needs. As a contributor to this work, this is only my personal view on that. I guess authors can use at the discretion in order to make a rigorous statement. Many thanks Gang From brian.e.carpenter@gmail.com Wed Aug 8 08:48:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B41711E80FE for ; Wed, 8 Aug 2012 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.73 X-Spam-Level: X-Spam-Status: No, score=-100.73 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfO9hwCaAJ8F for ; Wed, 8 Aug 2012 08:48:12 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8BE11E80FB for ; Wed, 8 Aug 2012 08:48:11 -0700 (PDT) Received: by eaai11 with SMTP id i11so290908eaa.31 for ; Wed, 08 Aug 2012 08:48:11 -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=qX6T+jJpggD0Gtb/ust/QXtZyePvCbwGqmS1aSi5uQE=; b=l2acK6Tyajug+nyz4CpzwUx6t1nCAc5uHRz4kuXbZQAZ+sb02eV8k2w/Z5gzVDmJyU yvfuka7d93A9SRRnSZvRmLT5eesi7uJvi3xhl96JmwfM7ObXMTx3HhLRO1uhnGr0Ovju isrEmd3hXpLyP2gle5Bsr2k92pE7G3HKDbahqDEnAl3utc5JOHI01Vg1jhDrZp4TQZ1o PJyehJYq3Vyd49KjZv7rbbaaX2hMfH33x3oYR4be81fgKn4WTJqm19hfqUEH4melNDTv 4qViTpQo1tfxe+n5t6ZBrg/FJpVuu0dePQeyNcG9RHTrAJd0qGjNUKxFEEPUWXKZvJGB n7Qw== Received: by 10.14.0.198 with SMTP id 46mr2142754eeb.30.1344440891248; Wed, 08 Aug 2012 08:48:11 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-169.as13285.net. [2.102.217.169]) by mx.google.com with ESMTPS id q3sm62467103eeo.4.2012.08.08.08.48.08 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 08:48:09 -0700 (PDT) Message-ID: <50228A3D.901@gmail.com> Date: Wed, 08 Aug 2012 16:48:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arturo Servin References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> <5020DEC0.1090601@gmail.com> <1344332397.93146.YahooMailNeo@web32504.mail.mud.yahoo.com> <50211B63.3020203@gmail.com> <502257A7.7080208@gmail.com> <4E118319-8D7F-40FC-B966-C7F44963A2F2@lacnic.net> <502282E7.3050502@gmail.com> <49BE778F-5C3C-4BA6-8E2C-AC068EA68943@gmail.com> In-Reply-To: <49BE778F-5C3C-4BA6-8E2C-AC068EA68943@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , "v6ops@ietf.org" , V6ops Chairs Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:48:13 -0000 Arturo, On 08/08/2012 16:28, Arturo Servin wrote: > No, I didn't say that. > > 1) if you are small, multi-homed you should use BGP+PI. > > > 2) if you are small and uni-home use PA. > > > If 1 does not scale (I would question that), it is a problem that we should solve elsewhere. Yes, of course, and that was the main focus of the Routing Research Group for a couple of years (see RFC 6115). It's pretty clear that it doesn't scale to millions of sites with currently deployable technology. That being so, IMHO v6ops has to be cautious about encouraging widespread usage. (This applies generally, not just to ICPs, of course.) Brian > There are other solutions for 1, but I would not recommend them as a best practice, just like workarounds to use PA and avoid BGP. > > 1 and 2 are orthogonal to the fact that the ICP is as well an enterprise or not. > > Regards, > as > > On 8 Aug 2012, at 12:16, Brian E Carpenter wrote: > >> On 08/08/2012 15:59, Arturo Servin wrote: >>> Brian, >>> >>> But we are not talking about enterprises, we are talking about ICPs, which IMHO are two different problems and advices. >> To be clear, I intended to talk about either pure specialised ICPs, or an enterprise that >> wishes to behave as an ICP for its own content. >> >>> For Enterprises, yes PA and PI are debatable (as discussed in many places, many times) and more dependent on the size and type of enterprise, for ICPs I think we are more or less in consensus that PI is more much common (and IMO the recommendation). >>> >>> Perhaps, the corner case are "small ICPs" which if they are uni-homed, then PA is fine, if they are multi-homed then BGP+PI should be the recommendation no matter if they are small or large. >> But that's the case that doesn't scale to millions. Are you suggesting that >> we have to tell them "you can't serve your own content reliably, because >> you're too small"? >> >> Brian >> >>> Regards, >>> as >>> >>> On 8 Aug 2012, at 09:12, Brian E Carpenter wrote: >>> >>>> My concern here, as I've already hinted, is publishing advice that is >>>> valid for the N thousand enterprises that can reasonably expect to get >>>> a PI prefix but nothing for the N million others that may wish to serve >>>> up content *and* be multihomed. >>> > > From fred@cisco.com Wed Aug 8 09:57:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E1121F86DC for ; Wed, 8 Aug 2012 09:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.341 X-Spam-Level: X-Spam-Status: No, score=-110.341 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKLMykpCTN-a for ; Wed, 8 Aug 2012 09:57:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 755F821F86D8 for ; Wed, 8 Aug 2012 09:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1769; q=dns/txt; s=iport; t=1344445067; x=1345654667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PbfwCAO6yRHUU3QSfPbtKEgpfMUpTp5IoPah/dLrqVE=; b=OETGagm6hNNomHH55jjqg+bJvqXNiJ5cv+/JwgzF2L0CQvCU7U5JvgGk FGf57HwlW7bt7nISgsol0DorZCEfKpPuchTDNArwbyNCGIQq6imjreTIE 92xysoM4r4TC/irybJq3IsuIPRjYAlvTNIbFUpfrKFKkFuOpuusJYTmGx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO6ZIlCtJXHA/2dsb2JhbABFuVyBB4IgAQEBAwESAWYFCwIBCEYyJQIEDiAHh2UGmwigPYsShgBgA4gZjTCOKYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208";a="109640397" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 08 Aug 2012 16:57:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q78GvkWW029706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 16:57:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 11:57:45 -0500 From: "Fred Baker (fred)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdYbuVoxwYpZrA0C9+mNRvxtYJg== Date: Wed, 8 Aug 2012 16:57:44 +0000 Message-ID: <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19094.000 x-tm-as-result: No--31.807600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <27FFA50295C93848B66682A055BE8FD9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:57:48 -0000 On Aug 8, 2012, at 3:29 AM, R=E9mi Despr=E9s wrote: > b. As also discussed, the applicability statement should clarify that, in= access networks where both NAT64 and DS-Lite are available, using DS-Lite = should be recommended (better IPv4 transparency). > For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would b= e enough for me. As I said earlier, it is beyond me why an applicability statement or a tech= nical description of one technology is constrained to discuss another. Let me repeat something that has been pointed out by others in this thread.= By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, ds-lite, = an MPLS LSP, or whatever other kind of tunnel might come to mind - one does= not provide an end to end IPv4 infrastructure. The solution can translate = to IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at one end of th= e tunnel or another, but one does not avoid translation of IPv4 packets. Th= e only way one avoids translation - at all - is to send native IPv6 packets= and deliver them to one's destination. That's kind of the point here, as C= ameron pointed out in the talk last week. For my money, this document should be constrained to talking about the 464X= LAT solution and the cases in which those providers using it find it useful= . Any other discussion, in my opinion, mostly confuses the discussion. At this point, in the opinion of this chair, any textual changes in the doc= ument should be for the purposes of clarifying the 464XLAT deployment strat= egy and its uses of the technologies it specifies, or the operational utili= ty of it. Discussion of technologies that would not be used in a 464XLAT ne= twork is out of place.= From sm@resistor.net Wed Aug 8 12:41:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A787711E80AD for ; Wed, 8 Aug 2012 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jUy3FnSMDXJ for ; Wed, 8 Aug 2012 12:41:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4211E8072 for ; Wed, 8 Aug 2012 12:41:17 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q78JfBs1025420; Wed, 8 Aug 2012 12:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344454875; bh=FmCzt42jZ9511NbuH6GsNCvKF0aRrHWiYrOHVC8Hh3Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TKD3s42RrGqwVD+rYgBztAvciNNmS5N+DxwECvUErSt9s7HIQvo/o8s1kksySZTpj xfKHeaXCILpmxtYg1R7EfE0B8jeKfvQZC0T6ua/SSt6lb5r+l4N2N3LOtJPoIh2Kfz WnTqsvXwsj4it/XeF4LDyiLnlgLb+FDPtZARpAZM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1344454875; i=@resistor.net; bh=FmCzt42jZ9511NbuH6GsNCvKF0aRrHWiYrOHVC8Hh3Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HDc4iMKwTtPBZB4tJLd0u2+sYqhSXRMq/2YoRGpSeFt17zjkNKGVzHK1/nDVUCThW HH/bLyfM4tTu5JVVXuBmJNEE+yEWDj9wsEOco+I/OfiE90S7QJseGAECLIM1cz70w2 z4lKuNaIzUZKsPjYsPcbFUHLt/Ir6QOatrwFcgSA= Message-Id: <6.2.5.6.2.20120808111904.0d7d0be8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Aug 2012 11:41:03 -0700 To: "Gunter Van de Velde (gvandeve)" From: SM In-Reply-To: <67832B1175062E48926BF3CB27C49B2406CB34@xmb-aln-x12.cisco.c om> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <6.2.5.6.2.20120807203008.0a6ca648@resistor.net> <67832B1175062E48926BF3CB27C49B2406CB34@xmb-aln-x12.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 19:41:22 -0000 Hi Gunter, At 02:35 08-08-2012, Gunter Van de Velde (gvandeve) wrote: >One of the most common questions people making NW design ask >themselves is: What for IPv6 prefix will I place on my p2p links. >Now exactly that is now wrong in the RFC5375. > >Maybe it is not an Errata as the RFC was correct at time of >publishing... it for sure is wrong right now. > >If possible I would like to see the rfc updated with this >significant address related change. You can submit a draft and see whether v6ops can adopt it. I suggest talking to the WG chairs first. The document can mark RFC 5375 as obsolete. The update would have to include other changes, e.g. RFC 3177 is obsolete. Regards, -sm From philip_matthews@magma.ca Wed Aug 8 13:57:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8430821F86F6 for ; Wed, 8 Aug 2012 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_ONLINE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulnLtEwo3YJy for ; Wed, 8 Aug 2012 13:57:28 -0700 (PDT) Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id A57B721F86DB for ; Wed, 8 Aug 2012 13:57:28 -0700 (PDT) Received: from [74.198.165.65] (helo=[172.20.10.2]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SzDJl-0001FI-37; Wed, 08 Aug 2012 16:57:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--1067461574 From: Philip Matthews In-Reply-To: Date: Wed, 8 Aug 2012 16:57:22 -0400 Message-Id: <3E813D19-C8DA-4C20-9A16-F4B3EC3E7FCD@magma.ca> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.65] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 20:57:29 -0000 --Apple-Mail-2--1067461574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-08-06, at 11:37 , Cameron Byrne wrote: >=20 > We have an addressing scheme that is based on the physical locations, > ULA allows us to express the physical location in the address, this > may also be possible in LLA ... but not meaningful in troubleshooting > since the packets cannot get off the link. >=20 > We like to troubleshoot routing based on 1 or 2 hops away, (i can ping > the local interface, but i can ping 1 router aways... somebody start > looking at L3 issues ...) >=20 > There is also the simplicity of using specifically assigned addresses, > if i am on blah:blah::1 i may know the other side of the link, by my > own convention, is blah:blah::2 without looking at a network map. >=20 > In short, the above 3 help us have a common operational practice with > IPv4. Common practices are good (i know ipv4 !=3D ipv6). >=20 > Here is something that is different between IPv4 and IPv4: >=20 > LLA is always present by default and auto configured. Global scope > addresses, like ULA show deliberate intention and configuration. > Meaning, when there is a global scope address like ULA / GUA, then you > know this link is supposed to be in service and somebody has decided > we are going to send packets over it. LLA just means the card is on > line. >=20 > ICMP redirects make my router CPU go high, i generally turn them off. >=20 > CB Cameron: Thanks for the input. It helps confirm for me that most operators = prefer GUA/ULA over just LLAs. Just a few comments on your reply. The inability to troubleshooting from 1 or 2 hops away is indeed a = limitation of LLAs. I am pretty sure this has already been captured in the I-D. Having explicitly assigned interface IDs is something one can do with = LLAs as well on our products -- I work for Alcatel-Lucent -- and I am pretty sure C = and J support it too. So I don't really see this as something I can put as a con for LLAs. At least on our products, and I am pretty sure on J as well, LLAs are = not assigned until one explicitly enables IPv6 on the interface. So I don't really = see the argument that a GUA/ULA means the link is "ready to go".=20 - Philip --Apple-Mail-2--1067461574 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

We have an = addressing scheme that is based on the physical locations,
ULA allows = us to express the physical location in the address, this
may also be = possible in LLA ... but not meaningful in troubleshooting
since the = packets cannot get off the link.

We like to troubleshoot routing = based on 1 or 2 hops away, (i can ping
the local interface, but i can = ping 1 router aways... somebody start
looking at L3 issues = ...)

There is also the simplicity of using specifically assigned = addresses,
if i am on blah:blah::1 i may know the other side of the = link, by my
own convention, is blah:blah::2 without looking at a = network map.

In short, the above 3 help us have a common = operational practice with
IPv4.  Common practices are good (i = know ipv4 !=3D ipv6).

Here is something that is different between = IPv4 and IPv4:

LLA is always present by default and auto = configured.  Global scope
addresses, like ULA show deliberate = intention and configuration.
Meaning, when there is a global scope = address like ULA / GUA, then you
know this link is supposed to be in = service and somebody has decided
we are going to send packets over = it.  LLA just means the card is on
line.

ICMP redirects = make my router CPU go high, i generally turn them off.

CB

Cameron:

Thanks for the input.  It helps confirm for = me that most operators prefer GUA/ULA
over just LLAs. =  Just a few comments on your reply.

The = inability to troubleshooting from 1 or 2 hops away is indeed a = limitation of LLAs.
I am pretty sure this has already been = captured in the I-D.

Having explicitly assigned = interface IDs is something one can do with LLAs as well
on our = products -- I work for Alcatel-Lucent -- and I am pretty sure C and J = support it too.
So I don't really see this as something I can = put as a con for LLAs.

At least on our = products, and I am pretty sure on J as well, LLAs are not = assigned
until one explicitly enables IPv6 on the interface. = So I don't really see the argument
that a GUA/ULA means the = link is "ready to go". 

- = Philip



= --Apple-Mail-2--1067461574-- From philip_matthews@magma.ca Wed Aug 8 14:26:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7111E811D for ; Wed, 8 Aug 2012 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q19WGE+lhfZF for ; Wed, 8 Aug 2012 14:26:53 -0700 (PDT) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65D11E8119 for ; Wed, 8 Aug 2012 14:26:53 -0700 (PDT) Received: from [74.198.165.0] (helo=[172.20.10.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SzDmD-00066Q-2W; Wed, 08 Aug 2012 17:26:50 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20120806191534.GY38127@Space.Net> Date: Wed, 8 Aug 2012 17:26:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> To: Gert Doering , sthaug@nethelp.no X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.0] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 21:26:54 -0000 Gert and Stiener: Thanks for your comments. Your messages, along with Cameron's, help re-confirm the assertion made = in the document that most operators prefer GUA/ULA addressing over pure LLA. I also appreciate the comments about redirects. I will strengthen the = language in the document around this. Thanks Gert for your comment about DNS. That is a new comment that I had = not previously captured. - Philip On 2012-08-06, at 15:15 , Gert Doering wrote: > Hi, >=20 > On Sat, Aug 04, 2012 at 11:40:36PM -0400, Philip Matthews wrote: >> Gert and Cameron: In your networks, what made you decide to use >> GUAs/ULAs as next hops? Was there some factor that I have not yet >> captured? Did you give serious consideration to using LLAs? Using >> GUAs/ULAs as the next-hop means that v6 redirects do not work -- >> are redirects simply unimportant to you? >=20 > I see no advantage to using LLAs. =20 >=20 > Besides having no advantage, they only complicate things due to=20 > aspects like not having a reverse DNS entry (so I can't easily find=20 > out "so which router should that route pointing to?" if things are=20 > not working). >=20 > We never point static routes to other routers *in* a network that > has end systems - so redirects just do no thappen (if the packet gets > send elsewhere, that's happening in backbone segments outside of the > end system LAN). =20 >=20 > End systems see a HSRP/VRRP default route, and send their packets = there,=20 > end of story (and redirects complicate trouble shooting at the end=20 > systems, as you can never be sure where packets are going, depending=20= > on the current expiry state of redirects, host implementation, etc). >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From internet-drafts@ietf.org Wed Aug 8 15:30:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268BB21F84F2; Wed, 8 Aug 2012 15:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcV3U7ELlD+0; Wed, 8 Aug 2012 15:30:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858C621F84EB; Wed, 8 Aug 2012 15:30:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808223009.7531.74467.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 15:30:09 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 22:30:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Enterprise Incremental IPv6 Author(s) : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-00.txt Pages : 27 Date : 2012-08-07 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Aug 8 15:30:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E9121F84FB; Wed, 8 Aug 2012 15:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVz0c1rumENG; Wed, 8 Aug 2012 15:30:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD0C21F84F6; Wed, 8 Aug 2012 15:30:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808223038.14338.63325.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 15:30:38 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 22:30:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Cameron Byrne Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-00.txt Pages : 16 Date : 2012-08-07 Abstract: This document summarizes stateful NAT64 deployment scenarios and operational experience with NAT64-CGN(NAT64 Carrier Grade NATs) and NAT64-CE (NAT64 Customer Edges). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Wed Aug 8 19:13:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8473211E815A for ; Wed, 8 Aug 2012 19:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDPBNjZc6xNC for ; Wed, 8 Aug 2012 19:13:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8002A11E8150 for ; Wed, 8 Aug 2012 19:13:49 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1549696vbb.31 for ; Wed, 08 Aug 2012 19:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UHQ3GaRkDgzNExlZkJNeVyi+NkALoIRF9OWqLCLIxzc=; b=zFge9UyDhWpWc3mCFZpKzS+Fp3Mxj3QNeukB2vyJxV1NKuwASpkv9/F05IAnffQgI1 rfmvQw6lRa/HJH8Iz2uRS5ucqGUczXj8qESuCO2ePHlu41ulyJLBOt6PQPhrV3bZLJnp tsu9E2ETn3QX4YnydsPpP9BN24EiF0jHOA3W4m/JlT8l+wnAZrsWSUi9k8Yhia7MMTj7 zLfmAJyUAYl+FyQVpK+zp3iOFXTbWvHajVnGoPvJJMgGLpVLNesRbqlX8jIyT7P9RTBm tNQD/gdbBROIgAH1b1O7IFVY+t26xLEbojFClxDte4mfudaRVuudV84gB5VylckcjlPj 8sCQ== MIME-Version: 1.0 Received: by 10.220.223.5 with SMTP id ii5mr15603414vcb.51.1344478428913; Wed, 08 Aug 2012 19:13:48 -0700 (PDT) Received: by 10.58.79.34 with HTTP; Wed, 8 Aug 2012 19:13:48 -0700 (PDT) In-Reply-To: <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Thu, 9 Aug 2012 10:13:48 +0800 Message-ID: From: GangChen To: mawatari@jpix.ad.jp, Masanobu Kawashima , Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:13:51 -0000 Hello authors, That is a tentative text proposal after several rounds of discussions. =3D=3D=3D> Proposed texts This BCP is applied because 464xlat leverages available host/router implementations by combining existing and well-known stateful protocol translation [RFC6146] and stateless protocol translation [RFC6145]. It's helpful to promote the mechanism introduction as an immediate instantiation, which is justified as a good applicability to BCP status [RFC2026]. On the other hand, it's worth to be noted that the processing involved in the framework may not achieve fully reversible translations, e.g. packets sourced with DF=3D1 and MF=3D1 and/or Offset>0 become DF=3D0 after 464 translation. The fact that IPv4 packets that are fragmented by sources, and not fragmentable in the network as recommended by [RFC4821], become fragmentable again is considered of limited enough consequence and rare enough and to be consciously accepted. In regards to above observation, this BCP can be applied when the following two criteria are present: 1. There is an IPv6-only access network that uses stateful translation [RFC6146] 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only access network to reach the IPv4 Internet =3D=3D=3D> the end Please kindly take that to your reference. Many thanks Gang 2012/8/9, Fred Baker (fred) : > > On Aug 8, 2012, at 3:29 AM, R=E9mi Despr=E9s wrote: > >> b. As also discussed, the applicability statement should clarify that, i= n >> access networks where both NAT64 and DS-Lite are available, using DS-Lit= e >> should be recommended (better IPv4 transparency). >> For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would = be >> enough for me. > > > As I said earlier, it is beyond me why an applicability statement or a > technical description of one technology is constrained to discuss another= . > > Let me repeat something that has been pointed out by others in this threa= d. > By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, ds-lite,= an > MPLS LSP, or whatever other kind of tunnel might come to mind - one does = not > provide an end to end IPv4 infrastructure. The solution can translate to > IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at one end of the > tunnel or another, but one does not avoid translation of IPv4 packets. Th= e > only way one avoids translation - at all - is to send native IPv6 packets > and deliver them to one's destination. That's kind of the point here, as > Cameron pointed out in the talk last week. > > For my money, this document should be constrained to talking about the > 464XLAT solution and the cases in which those providers using it find it > useful. Any other discussion, in my opinion, mostly confuses the > discussion. > > > At this point, in the opinion of this chair, any textual changes in the > document should be for the purposes of clarifying the 464XLAT deployment > strategy and its uses of the technologies it specifies, or the operationa= l > utility of it. Discussion of technologies that would not be used in a > 464XLAT network is out of place. From nygren@gmail.com Wed Aug 8 18:29:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6111E8156 for ; Wed, 8 Aug 2012 18:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmtyPeP7DvtX for ; Wed, 8 Aug 2012 18:29:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40D11E8151 for ; Wed, 8 Aug 2012 18:29:51 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1502326vcb.31 for ; Wed, 08 Aug 2012 18:29:50 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m+4l+MJ+8lOUoydoQR+ANyKQvFC9p+0d2ud5TrCoASI=; b=yxjFleFB++/Pv4Yjn+HhVe4Kn7HejH959pE+eKi5CaULe6eHL/0KlOSqqFMB11DLIQ M2WpJvlj4dq2lsq8SGLLGG8N0IMPo75ECX1Y8b8wIx7RQN3O382vc0qCRd/Ix/h0lTF+ q0NRjQVAOhxFcV5ZWBCrOdTFKXhiQ9Kap2Dud3MzTKgfb1HMlwvU+qA0tY6HU7rXINMs fEBv+ZeKVYaGjtn96ocFIy34m++OhIXseE/D6NEsc972neZa98v2qzsFU6Hxd02Ur/qZ ZNz7krcxEXIKOUJ2II5SFF2gK3v8U9fxfJvZ0WpTb2C45II/MvZh76e33P2xpQom/4IW yk0Q== MIME-Version: 1.0 Received: by 10.220.155.203 with SMTP id t11mr2174634vcw.36.1344475790461; Wed, 08 Aug 2012 18:29:50 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.58.207 with HTTP; Wed, 8 Aug 2012 18:29:50 -0700 (PDT) In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Date: Wed, 8 Aug 2012 20:29:50 -0500 X-Google-Sender-Auth: re7CHjm9DUfyEA8YYv7sunRDoYQ Message-ID: From: Erik Nygren To: "Fred Baker (fred)" , brian.e.carpenter@gmail.com, jiangsheng@huawei.com Content-Type: multipart/mixed; boundary=f46d04389099e6494004c6cb2942 Cc: "v6ops@ietf.org" , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 03:31:07 -0000 --f46d04389099e6494004c6cb2942 Content-Type: text/plain; charset=ISO-8859-1 I took a pass through this draft and had enough suggestions that it was easiest to just pass them along as a patch/diff against the -02.xml source (see attached). In general this feels like it will be very useful as a starting points for people at Internet content and application providers looking to kick off an IPv6 effort. As discussed on some of the other threads, I think its important that we keep this focused on recommendations that will be useful to people implementing IPv6 today, rather than on technologies that are still under development. Some of the proposed changes include: * Proposed some compromise text in the "IPv6 Infrastructure" section on the PI vs PA address space topic discussed in the other thread. It feels like we should be giving concrete recommendations that are useful to ICPs now, but while still leaving doors open for the future. * Add a note that support operations and support staff will generally also need to have IPv6 connectivity provisioned. (Outside of universities, external server and staff network connectivity and environments are often independent.) * Renamed the "Proxy" section to "Surrogate" as what is being described there is explicitly a reverse proxy (surrogate) setup. * Added more context and details and gotchas to the "DNS" section. This seems to be one of the top areas where ICPs seem to get themselves in trouble (perhaps because it seems like it's a "just do it"). * Added some notes on security (such as for host and network device firewalls) at appropriate points in the doc as ICPs especially shouldn't be thinking of these as an afterthought. * Added some more notes into the Application Layer section, such as some particular notes about logging and testing, as this seems to be another area where things are often missed. * Split up the CDN section into a broader section on "Complex Sites and Applications". About half of the existing CDN section was more generally applicable to ICPs with multiple POPs, so "Distributed Locations" got its own subsection here. I also added a subsection on "embeded resources" reminding ICPs to check that a rich site has more than just the base page available over IPv6. (I also took out the reference to my employer as that quote was from a few years ago and may not be generally helpful.) * Fixed some typos and made a few other edits, as well as some others that I may have missed in the summary above. I hope this is useful to folks. I'm happy to discuss any of my proposed changes in more detail. Erik --------------------- All opinions expressed herein are my own and my not reflect those of my employer. On Mon, Aug 6, 2012 at 12:29 AM, Fred Baker (fred) wrote: > This is to open a two week Working Group last Call on > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance > "IPv6 Guidance for Internet Content and Application Service Providers", > Brian Carpenter, Sheng Jiang, 10-Jul-12 > > Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d04389099e6494004c6cb2942 Content-Type: application/octet-stream; name="draft-ietf-v6ops-icp-guidance-02-nygren-feedback-2012-08-08.patch" Content-Disposition: attachment; filename="draft-ietf-v6ops-icp-guidance-02-nygren-feedback-2012-08-08.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5n61cqk0 LS0tIGRyYWZ0LWlldGYtdjZvcHMtaWNwLWd1aWRhbmNlLTAyLnhtbAkyMDEyLTA4LTA4IDE1OjAw OjIyLjAwMDAwMDAwMCAtMDQwMAorKysgZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFuY2UtMDIt bnlncmVuLWZlZWRiYWNrLnhtbAkyMDEyLTA4LTA4IDIxOjAzOjQzLjAwMDAwMDAwMCAtMDQwMApA QCAtMTAsMTIgKzEwLDE2IEBACiANCiA8IS0tIFlvdSBuZWVkIG9uZSBlbnRyeSBsaWtlIHRoZSBm b2xsb3dpbmcgZm9yIGVhY2ggUkZDIHJlZmVyZW5jZWQgLS0+DQogDQorPCFFTlRJVFkgUkZDMTkx MiBQVUJMSUMgJycNCisgICdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnht bC9yZWZlcmVuY2UuUkZDLjE5MTIueG1sJz4NCiA8IUVOVElUWSBSRkMyMTE5IFBVQkxJQyAnJw0K ICAgJ2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5S RkMuMjExOS54bWwnPg0KIDwhRU5USVRZIFJGQzI2MjkgUFVCTElDICcnDQogICAnaHR0cDovL3ht bC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yNjI5LnhtbCc+ DQogPCFFTlRJVFkgUkZDMjQ2MCBQVUJMSUMgJycNCiAgICdodHRwOi8veG1sLnJlc291cmNlLm9y Zy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjI0NjAueG1sJz4NCis8IUVOVElUWSBS RkMzMDQwIFBVQkxJQyAnJw0KKyAgJ2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMv YmlieG1sL3JlZmVyZW5jZS5SRkMuMzA0MC54bWwnPg0KIDwhRU5USVRZIFJGQzYxNDYgUFVCTElD ICcnDQogICAnaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy42MTQ2LnhtbCc+DQogPCFFTlRJVFkgUkZDNjM0MyBQVUJMSUMgJycNCkBAIC0xNjUs MTcgKzE2OSwyMCBAQAogPHNlY3Rpb24gYW5jaG9yPSJpbnRybyIgdGl0bGU9IkludHJvZHVjdGlv biI+DQogDQogPHQ+VGhlIGRlcGxveW1lbnQgb2YgSVB2NiA8eHJlZiB0YXJnZXQ9IlJGQzI0NjAi Lz4gaXMgbm93IGluIHByb2dyZXNzLCBhbmQgdXNlcnMgDQotd2l0aCBubyBJUHY0IGFjY2VzcyBh cmUgbGlrZWx5IHRvIGFwcGVhciBpbiBpbmNyZWFzaW5nDQord2l0aCBubyBkaXJlY3QgSVB2NCBh Y2Nlc3MgYXJlIGxpa2VseSB0byBhcHBlYXIgaW4gaW5jcmVhc2luZw0KIG51bWJlcnMgaW4gdGhl IGNvbWluZyB5ZWFycy4gQW55IHByb3ZpZGVyIG9mIGNvbnRlbnQgb3IgYXBwbGljYXRpb24gc2Vy dmljZXMgb3ZlciB0aGUgSW50ZXJuZXQgd2lsbCBuZWVkIHRvIGFycmFuZ2UgZm9yDQotSVB2NiBh Y2Nlc3Mgb3IgZWxzZSByaXNrIGxvc2luZyBsYXJnZSBudW1iZXJzIG9mIHBvdGVudGlhbCB1c2Vy cy4gSW4gdGhpcyBkb2N1bWVudCwgd2UgcmVmZXIgdG8gdGhlIHVzZXJzIG9mDQorSVB2NiBhY2Nl c3Mgb3IgZWxzZSByaXNrIGxvc2luZyBsYXJnZSBudW1iZXJzIG9mIHBvdGVudGlhbCB1c2Vycy4g RXZlbiBpbiB0aGUgY3VycmVudCB3b3JsZCB3aGVyZSBhbG1vc3QgDQorYWxsIHVzZXJzIHdpbGwg c3RpbGwgaGF2ZSBzb21lIGZvcm0gb2YgSVB2NCBhY2Nlc3MsIGVpdGhlciBkaXJlY3Qgb3IgdGhy b3VnaCBOQVQ0NCBvciBOQVQ2NCwgcHJvdmlkaW5nIGNvbnRlbnQgZGlyZWN0bHkNCitvdmVyIElQ djYgbWF5IGFsbG93IHNvbWUgdXNlcnMgdG8gYnlwYXNzIG9uZSBvZiB0aGVzZSBOQVQsIHBvdGVu dGlhbGx5IGltcHJvdmluZyBwZXJmb3JtYW5jZSBidXQgYWxzbyANCitwcmVzZXJ2aW5nIHZpc2li aWxpdHkgdGhhdCBtaWdodCBiZSBvYnNjdXJlZCBieSBhIE5BVC4gIEluIHRoaXMgZG9jdW1lbnQs IHdlIHJlZmVyIHRvIHRoZSB1c2VycyBvZg0KIGNvbnRlbnQgb3IgYXBwbGljYXRpb24gc2Vydmlj ZXMgYXMgImN1c3RvbWVycyIgdG8gY2xhcmlmeSB0aGUgcGFydCB0aGV5IHBsYXksIGJ1dCB0aGlz IGlzIG5vdCBpbnRlbmRlZCB0byBsaW1pdA0KIHRoZSBzY29wZSB0byBjb21tZXJjaWFsIHNpdGVz LiA8L3Q+DQogDQogPHQ+VGhlIHRpbWUgZm9yIGFjdGlvbiBpcyBub3csIHdoaWxlDQotdGhlIG51 bWJlciBvZiBJUHY2LW9ubHkgY3VzdG9tZXJzIGlzIHNtYWxsLCBzbyB0aGF0IGFwcHJvcHJpYXRl IHNraWxscywgc29mdHdhcmUgYW5kIGVxdWlwbWVudCBjYW4gYmUgYWNxdWlyZWQNCit0aGUgbnVt YmVyIG9mIElQdjYgY3VzdG9tZXJzIGlzIHJlbGF0aXZlbHkgc21hbGwgKGJ1dCBncm93aW5nKSwg c28gdGhhdCBhcHByb3ByaWF0ZSBza2lsbHMsIHNvZnR3YXJlIGFuZCBlcXVpcG1lbnQgY2FuIGJl IGFjcXVpcmVkDQogaW4gZ29vZCB0aW1lIHRvIHNjYWxlIHVwIHRoZSBJUHY2IHNlcnZpY2UgYXMg ZGVtYW5kIGluY3JlYXNlcy4gQW4gYWRkaXRpb25hbCBhZHZhbnRhZ2Ugb2YgZWFybHkgc3VwcG9y dCBmb3INCiBJUHY2IGN1c3RvbWVycyBpcyB0aGF0IGl0IHdpbGwgcmVkdWNlIHRoZSBudW1iZXIg b2YgY3VzdG9tZXJzIGNvbm5lY3RpbmcgbGF0ZXIgdmlhIElQdjQgImV4dGVuc2lvbiIgc29sdXRp b25zDQotc3VjaCBhcyBkb3VibGUgTkFULCB3aGljaCB3aWxsIG90aGVyd2lzZSBkZWdyYWRlIHRo ZSB1c2VyIGV4cGVyaWVuY2UuIDwvdD4NCitzdWNoIGFzIGRvdWJsZSBOQVQgb3IgTkFUNjQgPHhy ZWYgdGFyZ2V0PSJSRkM2MTQ2Ii8+LCB3aGljaCB3aWxsIG90aGVyd2lzZSBkZWdyYWRlIHRoZSB1 c2VyIGV4cGVyaWVuY2UuIDwvdD4NCiANCiA8dD5OZXZlcnRoZWxlc3MsIGl0IGlzIGltcG9ydGFu dCB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgSVB2NiBzZXJ2aWNlIHNob3VsZCBub3QgbWFrZSBz ZXJ2aWNlIGZvciBJUHY0DQogY3VzdG9tZXJzIHdvcnNlLiBJbiBzb21lIGNpcmN1bXN0YW5jZXMs IHRlY2hub2xvZ2llcyBpbnRlbmRlZCB0byBhc3Npc3QgaW4gdGhlIHRyYW5zaXRpb24gZnJvbSBJ UHY0IHRvIElQdjYNCkBAIC0yMTgsNyArMjI1LDcgQEAKIG9uIGFuIGVxdWFsIGJhc2lzIC0gdG8g Y292ZXIgYm90aCBleGlzdGluZyBhbmQgZnV0dXJlIGN1c3RvbWVycy4gVGhpcyBpcyB0aGUgcmVj b21tZW5kZWQNCiBzdHJhdGVneSBpbiA8eHJlZiB0YXJnZXQ9IlJGQzYxODAiLz4gZm9yIHN0cmFp Z2h0Zm9yd2FyZCBzaXR1YXRpb25zLiBTb21lIElDUHMgd2hvIGFscmVhZHkgaGF2ZQ0KIHNhdGlz ZmFjdG9yeSBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggSVB2NiBtaWdodCBjb25zaWRlciBh biBJUHY2LW9ubHkgc3RyYXRlZ3ksIHdpdGggSVB2NA0KLWNsaWVudHMgYmVpbmcgc3VwcG9ydGVk IGJ5IHRyYW5zbGF0aW9uIG9yIHByb3h5IGluIGZyb250IG9mIHRoZWlyIElQdjYgY29udGVudCBz ZXJ2ZXJzLiBIb3dldmVyLCB0aGUgcHJlc2VudCBkb2N1bWVudA0KK2NsaWVudHMgYmVpbmcgc3Vw cG9ydGVkIGJ5IHRyYW5zbGF0aW9uIG9yIHJldmVyc2UgcHJveHkgaW4gZnJvbnQgb2YgdGhlaXIg SVB2NiBjb250ZW50IHNlcnZlcnMuIEhvd2V2ZXIsIHRoZSBwcmVzZW50IGRvY3VtZW50DQogaXMg YWRkcmVzc2VkIHRvIElDUHMgd2l0aG91dCBJUHY2IGV4cGVyaWVuY2UsIHdobyBhcmUgbGlrZWx5 IHRvIHByZWZlciB0aGUgZHVhbCBzdGFjayBtb2RlbCB0byBidWlsZA0KIG9uIHRoZWlyIGV4aXN0 aW5nIElQdjQgc2VydmljZS4gPC90Pg0KIA0KQEAgLTIyNiw3ICsyMzMsNyBAQAogdHdvIGFwcHJv YWNoZXMgY291bGQgYmUgYWRvcHRlZCwgc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzICJvdXRzaWRl IGluIiBhbmQgImluc2lkZSBvdXQiOjwvdD4NCiAgIDx0PjxsaXN0IHN0eWxlID0gInN5bWJvbHMi Pg0KICAgICA8dD5PdXRzaWRlIGluOiBzdGFydCBieSBwcm92aWRpbmcgZXh0ZXJuYWwgdXNlcnMg d2l0aCBhbiBJUHY2IHB1YmxpYyBhY2Nlc3MgdG8geW91ciBzZXJ2aWNlcywNCi0gICAgICAgZm9y IGV4YW1wbGUgYnkgcnVubmluZyBhIHJldmVyc2UgcHJveHkgdGhhdCBoYW5kbGVzIElQdjYgY3Vz dG9tZXJzIChzZWUgPHhyZWYgdGFyZ2V0PSJwcm94eSIvPiBmb3IgZGV0YWlscykuDQorICAgICAg IGZvciBleGFtcGxlIGJ5IHJ1bm5pbmcgYSBzdXJyb2dhdGUgKGUuZy4sIHJldmVyc2UgcHJveHkp IHRoYXQgaGFuZGxlcyBJUHY2IGN1c3RvbWVycyAoc2VlIDx4cmVmIHRhcmdldD0icHJveHkiLz4g Zm9yIGRldGFpbHMpLg0KICAgICAgICBQcm9ncmVzc2l2ZWx5IGVuYWJsZSBJUHY2IGludGVybmFs bHkuIDwvdD4NCiAgICAgPHQ+SW5zaWRlIG91dDogc3RhcnQgYnkgZW5hYmxpbmcgaW50ZXJuYWwg bmV0d29ya2luZyBpbmZyYXN0cnVjdHVyZSwgaG9zdHMsIGFuZCBhcHBsaWNhdGlvbnMNCiAgICAg ICAgdG8gc3VwcG9ydCBJUHY2LiBQcm9ncmVzc2l2ZWx5IHJldmVhbCBJUHY2IGFjY2VzcyB0byBl eHRlcm5hbCBjdXN0b21lcnMuIDwvdD4NCkBAIC0yNDAsMTYgKzI0NywyMSBAQAogSVB2NiBhcyBh IHNpbmdsZSBwcm9qZWN0LiBBbnkgSUNQIGNvdWxkIGNob29zZSB0aGlzIGFwcHJvYWNoLCBidXQg aXQgbWlnaHQgYmUgbW9zdCBhcHByb3ByaWF0ZQ0KIGZvciBhIHNtYWxsIElDUCB3aXRob3V0IGNv bXBsZXggYmFjay1lbmQgc3lzdGVtcy4gPC90Pg0KIA0KKzx0PkR1ZSB0byB0aGUgcG90ZW50aWFs bHkgbGFyZ2Ugc2NvcGUgb2Ygc3VwcG9ydGluZyBJUHY2IGV2ZXJ5d2hlcmUgd2l0aGluIGFuIGVu dmlyb25tZW50LA0KK2l0IGlzIG9mdGVuIGltcG9ydGFudCB0byBzZWxlY3QgYW4gYXBwcm9hY2gg YmFzZWQgb24gYnVzaW5lc3MgbmVlZHMgYW5kIHRlY2huaWNhbA0KK2RlcGVuZGVuY2llcy4gIEEg Zm9jdXNlZCBpbml0aWFsIGFwcHJvYWNoIGNhbiBoZWxwIG1ha2UgcHJvZ3Jlc3Mgb24gdGhlIG1v c3QgaW1wb3J0YW50DQorYXJlYXMgd2hpbGUgYXZvaWRpbmcgcGFyYWx5c2lzIGZyb20gYSB2YXN0 IGFuZCBvdmVyd2hlbG1pbmcgcG90ZW50aWFsIHNjb3BlLjwvdD4NCisNCiA8dD5BIHBvaW50IHRo YXQgbXVzdCBiZSBjb25zaWRlcmVkIGluIHRoZSBzdHJhdGVneSBpcyB0aGF0IHNvbWUgY3VzdG9t ZXJzIHdpbGwgcmVtYWluIElQdjQtb25seSBmb3INCiBtYW55IHllYXJzLCBvdGhlcnMgd2lsbCBo YXZlIGJvdGggSVB2NCBhbmQgSVB2NiBhY2Nlc3MsIGFuZCB5ZXQgb3RoZXJzIHdpbGwgaGF2ZSBv bmx5IElQdjYuIEFkZGl0aW9uYWxseSwNCiBtb2JpbGUgY3VzdG9tZXJzIG1heSBmaW5kIHRoZW1z ZWx2ZXMgc3dpdGNoaW5nIGJldHdlZW4gSVB2NCBhbmQgSVB2NiBhY2Nlc3MgYXMgdGhleSB0cmF2 ZWwsIGV2ZW4gd2l0aGluDQogYSBzaW5nbGUgc2Vzc2lvbi4gU2VydmljZXMgYW5kIGFwcGxpY2F0 aW9ucyBtdXN0IGJlIGFibGUgdG8gZGVhbCB3aXRoIHRoaXMsIGp1c3QgYXMgZWFzaWx5IGFzIHRo ZXkNCiBkZWFsIHRvZGF5IHdpdGggYSB1c2VyIHdob3NlIElQdjQgYWRkcmVzcyBjaGFuZ2VzIChz ZWUgdGhlIGRpc2N1c3Npb24gb2YgY29va2llcyBpbiA8eHJlZiB0YXJnZXQ9ImFwcGwiLz4pLiA8 L3Q+DQogDQotPHQ+TmV2ZXJ0aGxlc3MsIHRoZSBlbmQgZ29hbCBpcyB0byBoYXZlIGEgbmV0d29y ayB0aGF0IGRvZXMgbm90IG5lZWQgbWFqb3IgY2hhbmdlcyB3aGVuIGF0IHNvbWUgcG9pbnQNCis8 dD5OZXZlcnRoZWxlc3MsIHRoZSBlbmQgZ29hbCBpcyB0byBoYXZlIGEgbmV0d29yayB0aGF0IGRv ZXMgbm90IG5lZWQgbWFqb3IgY2hhbmdlcyB3aGVuIGF0IHNvbWUgcG9pbnQNCiBpbiB0aGUgZnV0 dXJlIGl0IGJlY29tZXMgcG9zc2libGUgdG8gdHJhbnNpdGlvbiB0byBJUHY2LW9ubHksIGV2ZW4g aWYgb25seSBmb3Igc29tZSBwYXJ0cyBvZiB0aGUgbmV0d29yay4NCiBUaGF0IGlzLCB0aGUgSVB2 NiBkZXBsb3ltZW50IHNob3VsZCBiZSBkZXNpZ25lZCBpbiBzdWNoIGEgd2F5IGFzIHRvIG1vcmUg b3IgbGVzcyBhc3N1bWUgdGhhdCBJUHY0IGlzDQotYWJzZW50LCBzbyB0aGUgbmV0d29yayB3aWxs IGZ1bmN0aW9uIHNlYW1sZXNzbHkgd2hlbiBpdCBpcyBpbmRlZWQgbm8gbG9uZ2VyIHRoZXJlLiA8 L3Q+DQorYWJzZW50IGluIHRoZSBlbmQtZ2FtZSwgc28gdGhlIG5ldHdvcmsgd2lsbCBmdW5jdGlv biBzZWFtbGVzc2x5IHdoZW4gaXQgaXMgaW5kZWVkIG5vIGxvbmdlciB0aGVyZS4gPC90Pg0KIA0K IDx0PkFuIGltcG9ydGFudCBzdGVwIGluIHRoZSBzdHJhdGVneSBpcyB0byBkZXRlcm1pbmUgZnJv bSBoYXJkd2FyZSBhbmQgc29mdHdhcmUNCiBzdXBwbGllcnMgZGV0YWlscyBvZiB0aGVpciBwbGFu bmVkIGRhdGVzIGZvciBwcm92aWRpbmcgc3VmZmljaWVudCBJUHY2IHN1cHBvcnQsIHdpdGggcGVy Zm9ybWFuY2UNCkBAIC0yOTEsNiArMzAzLDEyIEBACiBUcmFpbmluZywgbGFiIGV4cGVyaWVuY2Us IGFuZCBhY3R1YWwgZGVwbG95bWVudCBzaG91bGQgdGhlcmVmb3JlIGZvbGxvdyBlYWNoIG90aGVy IGltbWVkaWF0ZWx5Lg0KIElmIHBvc3NpYmxlLCB0cmFpbmluZyBzaG91bGQgZXZlbiBiZSBjb21i aW5lZCB3aXRoIGFjdHVhbCBvcGVyYXRpb25hbCBleHBlcmllbmNlLiA8L3Q+DQogDQorPHQ+T25j ZSBzdGFmZiBhcmUgdHJhaW5lZCwgdGhleSB3aWxsIGxpa2VseSBuZWVkIHRvIHN1cHBvcnQgYm90 aCBJUHY0LCBJUHY2LCBhbmQgZHVhbC1zdGFjayBjdXN0b21lcnMuDQorUmF0aGVyIHRoYW4gaGF2 aW5nIHNlcGFyYXRlIGludGVybmFsIGVzY2FsYXRpb24gcGF0aHMgZm9yIElQdjYsIGl0IGdlbmVy YWxseSBtYWtlcyBzZW5zZSBmb3INCitxdWVzdGlvbnMgdGhhdCBtYXkgaGF2ZSBhbiBJUHY2IGVs ZW1lbnQgdG8gZm9sbG93IG5vcm1hbCBlc2NhbGF0aW9uIHBhdGhzIHdpdGggU3ViamVjdCBNYXR0 ZXINCitFeHBlcnRzIGJlaW5nIGF2YWlsYWJsZSBmb3Igc3VwcG9ydCBpbiB0aGUgY29ybmVyLWNh c2VzLjwvdD4NCisNCisNCiA8L3NlY3Rpb24+IDwhLS0gZWR1IC0tPg0KIA0KIDxzZWN0aW9uIGFu Y2hvcj0iaXNwIiB0aXRsZT0iQXJyYW5naW5nIElQdjYgQ29ubmVjdGl2aXR5Ij4NCkBAIC0zMDUs MTMgKzMyMywxMyBAQAogICAgICAgIGZpbmFuY2lhbCBpbXBsaWNhdGlvbnMsIGFuZCB3aGV0aGVy IHRoZSBzYW1lIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IHdpbGwNCiAgICAgICAgYXBwbHkgYXMg Zm9yIElQdjQuIEFueSBJU1AgdGhhdCBoYXMgbm8gZGVmaW5pdGUgcGxhbiB0byBvZmZlciBuYXRp dmUgSVB2NiBzZXJ2aWNlDQogICAgICAgIHNob3VsZCBiZSBhdm9pZGVkLiA8L3Q+DQotICAgIDx0 PlR1bm5lbC4gSXQgaXMgcG9zc2libGUgdG8gY29uZmlndXJlIGFuIElQdjYtaW4tSVB2NCB0dW5u ZWwgdG8gYSByZW1vdGUgSVNQDQorICAgIDx0Pk1hbmFnZWQgVHVubmVsLiBJdCBpcyBwb3NzaWJs ZSB0byBjb25maWd1cmUgYW4gSVB2Ni1pbi1JUHY0IHR1bm5lbCB0byBhIHJlbW90ZSBJU1ANCiAg ICAgICAgdGhhdCBvZmZlcnMgc3VjaCBhIHNlcnZpY2UuIEEgZHVhbC1zdGFjayByb3V0ZXIgaW4g dGhlIElDUCdzIG5ldHdvcmsgd2lsbCBhY3QNCiAgICAgICAgYXMgYSB0dW5uZWwgZW5kLXBvaW50 LCBvciB0aGlzIGZ1bmN0aW9uIGNvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBJQ1AncyBib3JkZXIg cm91dGVyLg0KICAgICA8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQotICAgICAgIEEgdHVubmVs IGlzIGEgcmVhc29uYWJsZSB3YXkgdG8gb2J0YWluIElQdjYgY29ubmVjdGl2aXR5IGZvciBpbml0 aWFsIHRlc3RpbmcgYW5kDQorICAgICAgIEEgbWFuYWdlZCB0dW5uZWwgaXMgYSByZWFzb25hYmxl IHdheSB0byBvYnRhaW4gSVB2NiBjb25uZWN0aXZpdHkgZm9yIGluaXRpYWwgdGVzdGluZyBhbmQN CiAgICAgICAgc2tpbGxzIGFjcXVpc2l0aW9uLiBIb3dldmVyLCBpdCBpbnRyb2R1Y2VzIGFuIGlu ZXZpdGFibGUgZXh0cmEgbGF0ZW5jeSBjb21wYXJlZA0KLSAgICAgICB0byBuYXRpdmUgSVB2Niwg Z2l2aW5nIHVzZXJzIGEgbm90aWNlYWJseSB3b3JzZSByZXNwb25zZSB0aW1lIGZvciBjb21wbGV4 IHdlYiBwYWdlcy4NCisgICAgICAgdG8gbmF0aXZlIElQdjYsIGdpdmluZyBjdXN0b21lcnMgYSBu b3RpY2VhYmx5IHdvcnNlIHJlc3BvbnNlIHRpbWUgZm9yIGNvbXBsZXggd2ViIHBhZ2VzLg0KICAg ICAgICBBIHR1bm5lbCBtYXkgYmVjb21lIGEgcGVyZm9ybWFuY2UgYm90dGxlbmVjayAoZXNwZWNp YWxseSBpZiBvZmZlcmVkIGFzIGEgZnJlZQ0KICAgICAgICBzZXJ2aWNlKSBvciBhIHRhcmdldCBm b3IgbWFsaWNpb3VzIGF0dGFjay4NCiAgICAgICAgSXQgaXMgYWxzbyBsaWtlbHkgdG8gbGltaXQg dGhlIElQdjYgTVRVIHNpemUuIEluIG5vcm1hbCBjaXJjdW1zdGFuY2VzLCBuYXRpdmUgSVB2Ng0K QEAgLTMyMyw0NCArMzQxLDcyIEBACiAgICAgPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KICAg ICAgICBGb3IgdGhlc2UgcmVhc29ucywNCiAgICAgICAgSUNQcyBhcmUgc3Ryb25nbHkgcmVjb21t ZW5kZWQgdG8gb2J0YWluIG5hdGl2ZSBJUHY2IHNlcnZpY2UgYmVmb3JlIGF0dGVtcHRpbmcNCi0g ICAgICAgdG8gb2ZmZXIgYSBwcm9kdWN0aW9uLXF1YWxpdHkgc2VydmljZSB0byB0aGVpciB1c2Vy cy4gPC90Pg0KKyAgICAgICB0byBvZmZlciBhIHByb2R1Y3Rpb24tcXVhbGl0eSBzZXJ2aWNlIHRv IHRoZWlyIGN1c3RvbWVycy4gQWRkaXRpb25hbGx5LCANCisgICAgICAgdW5tYW5hZ2VkIHR1bm5l bHMgKHN1Y2ggYXMgNnRvNCkgc2hvdWxkIGFsbW9zdCBuZXZlciBiZSB1c2VkIGZvciBjb25uZWN0 aXZpdHkNCisgICAgICAgd2hlbiBwcm92aWRpbmcgc2VydmljZXMgdG8gY3VzdG9tZXJzLjwvdD4N CiAgICA8L2xpc3Q+PC90Pg0KKw0KKzx0PlNvbWUgbGFyZ2VyIG9yZ2FuaXphdGlvbnMgbWF5IGZp bmQgdGhlbXNlbHZlcyBuZWVkaW5nIG11bHRpcGxlDQorZm9ybXMgb2YgSVB2NiBjb25uZWN0aXZp dHksIHN1Y2ggYXMgdG8gdGhlaXIgZGF0YSBjZW50ZXJzICh3aGljaCBtYXkNCitjb250YWluIElD UCBzZXJ2ZXJzKSBhbmQgdG8gdGhlaXIgc3RhZmYuICBJdCBpcyBpbXBvcnRhbnQgdG8gbG9vaw0K K2F0IG9idGFpbmluZyBJUHY2IGNvbm5lY3Rpdml0eSBmb3IgYm90aCBvZiB0aGVzZSwgYXMgdGVz dGluZw0KK2FuZCBzdXBwb3J0aW5nIGFuIElQdjYtZW5hYmxlZCBzZXJ2aWNlIGlzIGNoYWxsZW5n aW5nIHdpdGhvdXQNCitoYXZpbmcgSVB2NiBjb25uZWN0aXZpdHkuPC90Pg0KKw0KKzx0Pk9uZSBv cHRpb24gbWF5IGJlIHRvIHVzZSBuYXRpdmUgSVB2NiBjb25uZWN0aXZpdHkgZm9yIElDUCBzZXJ2 ZXJzDQorYnV0IHRvIGZpbmQgc2hvcnQtdGVybSBhbHRlcm5hdGl2ZXMgdG8gcHJvdmlkZSBJUHY2 IGNvbm5lY3Rpdml0eSB0bw0KK29wZXJhdGlvbnMgYW5kIHN1cHBvcnQgc3RhZmYsIHN1Y2ggYXMg YSBtYW5hZ2VkIHR1bm5lbCBvciBIVFRQIHByb3h5DQorc2VydmVyIHdpdGggSVB2NiBjb25uZWN0 aXZpdHkuICBOb3RlIHRoYXQgdW5tYW5hZ2VkIHR1bm5lbHMgKHN1Y2ggYXQgNnRvNCBhbmQgVGVy ZWRvKSANCithcmUgZ2VuZXJhbGx5IG5vdCB1c2VmdWwgdG8gc3VwcG9ydCBzdGFmZiBmb3IgdGVz dGluZyBwdXJwb3NlcyBhcw0KK3JlY2VudCBjbGllbnQgc29mdHdhcmUgd2lsbCBkaXNwcmVmZXIg d2hlbiBhY2Nlc3NpbmcgZHVhbC1zdGFjayBzaXRlcy48L3Q+DQorDQogPC9zZWN0aW9uPiA8IS0t IGlzcCAtLT4NCiANCiA8c2VjdGlvbiBhbmNob3I9InNpdGUiIHRpdGxlPSJJUHY2IEluZnJhc3Ry dWN0dXJlIj4NCiAgPHNlY3Rpb24gYW5jaG9yPSJhZGRyIiB0aXRsZT0iQWRkcmVzcyBhbmQgc3Vi bmV0IGFzc2lnbm1lbnQiPg0KICA8dD5BbiBJQ1AgbXVzdCBmaXJzdCBkZWNpZGUgd2hldGhlciB0 byBhcHBseSBmb3IgaXRzIG93biBQcm92aWRlciBJbmRlcGVuZGVudCAoUEkpIGFkZHJlc3MgcHJl Zml4IGZvcg0KLSBJUHY2LiBUaGUgZGVmYXVsdCBpcyB0byBvYnRhaW4gYSBQcm92aWRlciBBZ2dy ZWdhdGVkIChQQSkgcHJlZml4IGZyb20gZWFjaCBvZiBpdHMgSVNQcywgYW5kIG9wZXJhdGUNCi0g dGhlbSBpbiBwYXJhbGxlbC4gQm90aCBzb2x1dGlvbnMgYXJlIHZpYWJsZSBpbiBJUHY2LiBIb3dl dmVyLCBzY2FsaW5nIHByb3BlcnRpZXMgb2YgdGhlIHdpZGUgYXJlYQ0KKyBJUHY2IHNvIHRoYXQg aXQgY2FuIHVzZSBCR1AgdG8gbXVsdGktaG9tZSBpdHMgY29ubmVjdGl2aXR5IGFuZCBjb250cm9s IGl0cyBvd24gYWRkcmVzcyBzcGFjZS4NCisgVGhpcyBjYW4gaGF2ZSBzb21lIG1hbmFnZW1lbnQg b3ZlcmhlYWQsIGFuZCBzY2FsaW5nIHByb3BlcnRpZXMgb2YgdGhlIHdpZGUgYXJlYQ0KICByb3V0 aW5nIHN5c3RlbSAoQkdQNCkgbGltaXQgdGhlIHJvdXRpbmcgb2YgUEkgcHJlZml4ZXMsIHNvIG9u bHkgbGFyZ2UgY29udGVudCBwcm92aWRlcnMgY2FuDQogIGp1c3RpZnkgdGhlIGJvdGhlciBhbmQg ZXhwZW5zZSBvZiBvYnRhaW5pbmcgYSBQSSBwcmVmaXggYW5kIGNvbnZpbmNpbmcgdGhlaXIgSVNQ cyB0byByb3V0ZSBpdC4NCi0gTWlsbGlvbnMgb2YgZW50ZXJwcmlzZSBuZXR3b3JrcywgaW5jbHVk aW5nIHNtYWxsZXIgY29udGVudCBwcm92aWRlcnMsIHdpbGwgdXNlIFBBIHByZWZpeGVzLg0KLSBJ biB0aGlzIGNhc2UsIGEgY2hhbmdlIG9mIElTUCB3b3VsZCBuZWNlc3NpdGF0ZSBhIGNoYW5nZSBv ZiB0aGUgY29ycmVzcG9uZGluZyBQQSBwcmVmaXgsIHVzaW5nDQotIHRoZSBwcm9jZWR1cmUgb3V0 bGluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM0MTkyIi8+LiANCisgPC90Pg0KKw0KKyA8dD5UaGUg YWx0ZXJuYXRpdmUgaXMgZm9yIHRoZSBJQ1AgdG8gb2J0YWluIGEgUHJvdmlkZXIgQWdncmVnYXRl ZA0KKyAoUEEpIHByZWZpeCBmcm9tIGl0cyBJU1Agb3IgaG9zdGluZyBwcm92aWRlci4gIFRoaXMg bWF5IHNjYWxlIGJldHRlcg0KKyBmb3Igc21hbGxlciBJQ1BzLCBidXQgaGFzIHRoZSBkb3duc2lk ZSB0aGF0IGEgY2hhbmdlIG9mIElTUCB3b3VsZCBuZWNlc3NpdGF0ZSBhIGNoYW5nZSANCisgb2Yg dGhlIGNvcnJlc3BvbmRpbmcgUEEgcHJlZml4LCB1c2luZyB0aGUgcHJvY2VkdXJlIG91dGxpbmVk IGluIDx4cmVmIHRhcmdldD0iUkZDNDE5MiIvPi4gDQogIDx2c3BhY2UgYmxhbmtMaW5lcz0iMSIg Lz4NCi0gQW4gSUNQIHRoYXQgaGFzIG11bHRpcGxlIGNvbm5lY3Rpb25zIHZpYSBtdWx0aXBsZSBJ U1BzIHdpbGwgaGF2ZSBtdWx0aXBsZSBQQSBwcmVmaXhlcy4gVGhpcyByZXN1bHRzIGluDQotIG11 bHRpcGxlIFBBLWJhc2VkIGFkZHJlc3NlcyBmb3IgdGhlIHNlcnZlcnMsIG9yIGZvciBsb2FkIGJh bGFuY2VycyBpZiB0aGV5IGFyZSBpbiB1c2UuDQorIEl0IG1heSBiZSBwb3NzaWJsZSBmb3IgYW4g SUNQIHRvIGhhdmUgbXVsdGlwbGUgUEEgcHJlZml4ZXMgZnJvbSBtdWx0aXBsZSANCisgcHJvdmlk ZXJzIChlaXRoZXIgaW4gdGhlIHNhbWUgbG9jYXRpb24gb3IgbXVsdGlwbGUgbG9jYXRpb25zKSwg cmVzdWx0aW5nIGluDQorIG11bHRpcGxlIFBBLWJhc2VkIGFkZHJlc3NlcyBmb3IgdGhlIHNlcnZl cnMuICBUaGlzIGNhbiBpbnRyb2R1Y2UgY2hhbGxlbmdlcw0KKyBmb3IgdGhlIElDUCB0aGF0IHdp bGwgYmUgbmVlZCB0byBhZGRyZXNzZWQsIHN1Y2ggYXMgZm9yIGxvYWQtYmFsYW5jaW5nIGFuZCBz b3VyY2UgYWRkcmVzcw0KKyBzZWxlY3Rpb24gdG8gYXZvaWQgaW5ncmVzcyBmaWx0ZXJpbmcuDQog IDwvdD4NCiANCiAgPHQ+QW4gSUNQIG1heSBhbHNvIGNob29zZSB0byBvcGVyYXRlIGEgVW5pcXVl IExvY2FsIEFkZHJlc3MgcHJlZml4IDx4cmVmIHRhcmdldD0iUkZDNDE5MyIvPiBmb3IgaW50ZXJu YWwNCi0gdHJhZmZpYyBvbmx5LCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM0ODY0 Ii8+LiA8L3Q+DQorIHRyYWZmaWMgb25seSwgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0i UkZDNDg2NCIvPi48L3Q+DQogDQogIDx0PkRlcGVuZGluZyBvbiBpdHMgcHJvamVjdGVkIGZ1dHVy ZSBzaXplLCBhbiBJQ1AgbWlnaHQgY2hvb3NlIHRvIG9idGFpbiAvNDggUEkgb3IgUEEgcHJlZml4 ZXMgKGFsbG93aW5nDQogIDE2IGJpdHMgb2Ygc3VibmV0IGFkZHJlc3MpIG9yIGxvbmdlciBQQSBw cmVmaXhlcywgZS5nLiAvNTYgKGFsbG93aW5nIDggYml0cyBvZiBzdWJuZXQgYWRkcmVzcykuIA0K ICBDbGVhcmx5IHRoZSBjaG9pY2Ugb2YgLzQ4IGlzIG1vcmUgZnV0dXJlLXByb29mLiBBZHZpY2UN Ci0gb24gdGhlIG51bWJlcmluZyBvZiBzdWJuZXRzIG1heSBiZSBmb3VuZCBpbiA8eHJlZiB0YXJn ZXQ9IlJGQzUzNzUiLz4uIDwvdD4gDQotDQorIG9uIHRoZSBudW1iZXJpbmcgb2Ygc3VibmV0cyBt YXkgYmUgZm91bmQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM1Mzc1Ii8+LiAgQW4gSUNQIHdpdGggbXVs dGlwbGUNCisgbG9jYXRpb25zIHdpbGwgbGlrZWx5IG5lZWQgYSBwcmVmaXggKGUuZy4sIGEgLzQ4 IFBJIHByZWZpeCBvciAvNTYgUEEgcHJlZml4KSBwZXIgbG9jYXRpb24uPC90PiANCiANCiAgPHQ+ U2luY2UgSVB2NiBwcm92aWRlcyBmb3Igb3BlcmF0aW5nIG11bHRpcGxlIHByZWZpeGVzIHNpbXVs dGFuZW91c2x5LCBpdCBpcyBpbXBvcnRhbnQgdG8gY2hlY2sgdGhhdA0KICBhbGwgcmVsZXZhbnQg dG9vbHMsIHN1Y2ggYXMgYWRkcmVzcyBtYW5hZ2VtZW50IHBhY2thZ2VzLCBjYW4gZGVhbCB3aXRo IHRoaXMuIEluIHBhcnRpY3VsYXIsIHRoZSBuZWVkIHRvDQogIGFsbG93IGZvciBtdWx0aXBsZSBQ QSBwcmVmaXhlcyB3aXRoIElQdjYsIGFuZCB0aGUgcG9zc2libGUgbmVlZCB0byByZW51bWJlciwg bWVhbnMgdGhhdCB1c2luZw0KLSBtYW51YWxseSBhc3NpZ25lZCBzdGF0aWMgYWRkcmVzc2VzIGZv ciBzZXJ2ZXJzIGlzIHByb2JsZW1hdGljIDx4cmVmIHRhcmdldD0iSS1ELmNhcnBlbnRlci02cmVu dW0tc3RhdGljLXByb2JsZW0iLz4uPC90Pg0KLQ0KLSA8dD5UaGVvcmV0aWNhbGx5LCBpdCB3b3Vs ZCBiZSBwb3NzaWJsZSB0byBvcGVyYXRlIGFuIElDUCdzIElQdjYgbmV0d29yayB1c2luZyBvbmx5 IFN0YXRlbGVzcyBBZGRyZXNzDQotIEF1dG9jb25maWd1cmF0aW9uIDx4cmVmIHRhcmdldD0iUkZD NDg2MiIvPiwgYW5kIER5bmFtaWMgRE5TIDx4cmVmIHRhcmdldD0iUkZDMzAwNyIvPiANCi1vciBN dWx0aWNhc3QgRE5TIDx4cmVmIHRhcmdldD0iUkZDNDc5NSIvPi4NCisgbWFudWFsbHkgYXNzaWdu ZWQgc3RhdGljIGFkZHJlc3NlcyBmb3Igc2VydmVycyBpcyBwcm9ibGVtYXRpYyA8eHJlZiB0YXJn ZXQ9IkktRC5jYXJwZW50ZXItNnJlbnVtLXN0YXRpYy1wcm9ibGVtIi8+Lg0KKyBBdCBhIG1pbmlt dW0sIGFuIElDUCBtdXN0IGhhdmUgYSB3YXkgdG8gb3BlcmF0aW9uYWxseSBtYW5hZ2UgaXRzIElQ djYgYXNzaWdubWVudHMNCisgdG8gc2VydmVycyBpbiBhIHdheSB0aGF0IGFsbG93cyByZW51bWJl cmluZyB0byBiZSBzYWZlbHkgcm9sbGVkIG91dCBhbmQgDQorIHByb3BhZ2F0ZWQgaW50byBETlMu PC90Pg0KKw0KKyA8dD5XaGlsZSB0aGVvcmV0aWNhbGx5LCBpdCBtaWdodCBiZSBwb3NzaWJsZSB0 byBvcGVyYXRlIGFuIElDUCdzIElQdjYgbmV0d29yayB1c2luZyBvbmx5IFN0YXRlbGVzcyBBZGRy ZXNzDQorIEF1dG9jb25maWd1cmF0aW9uIDx4cmVmIHRhcmdldD0iUkZDNDg2MiIvPiBpbiBjb25q dW5jdGlvbiB3aXRoIER5bmFtaWMgRE5TIDx4cmVmIHRhcmdldD0iUkZDMzAwNyIvPiwgY2FyZWZ1 bA0KKyBhdHRlbnRpb24gd2lsbCBuZWVkIHRvIGJlIHBhaWQgdG8gZW5zdXJpbmcgdGhhdCBzZXJ2 ZXJzIGhhdmUgYm90aCB0aGVpciBvbGQgYW5kIG5ldyBJUHY2IGFkZHJlc3NlcyBmb3IgdGhlDQor IFRUTCBkdXJhdGlvbiBvZiBhbnkgRE5TIHJlc3BvbnNlcyBjYWNoZWQgYnkgY2xpZW50cy4NCiAg SW4gcHJhY3RpY2UsIGFuIElDUCBvZiByZWFzb25hYmxlIHNpemUgd2lsbCBwcm9iYWJseSBjaG9v c2UgdG8gb3BlcmF0ZQ0KLSBESENQdjYgPHhyZWYgdGFyZ2V0PSJSRkMzMzE1Ii8+IHdpdGggc3Rh bmRhcmQgRE5TLCBhbmQgdXNlIGl0IHRvIHN1cHBvcnQgc3RhdGVmdWwgYW5kL29yIG9uLWRlbWFu ZCBhZGRyZXNzIGFzc2lnbm1lbnQuIDwvdD4NCisgREhDUHY2IDx4cmVmIHRhcmdldD0iUkZDMzMx NSIvPiB3aXRoIHN0YW5kYXJkIEROUywgb3IgdG8gbWFuYWdlIElQdjYgYWRkcmVzcyBhc3NpZ25t ZW50DQorIHRocm91Z2ggaXRzIGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBzeXN0ZW0sIGFuZCB1 c2UgaXQgdG8gc3VwcG9ydCBzdGF0ZWZ1bCBhbmQvb3Igb24tZGVtYW5kIGFkZHJlc3MgYXNzaWdu bWVudC4gPC90Pg0KICA8L3NlY3Rpb24+DQogDQogIDxzZWN0aW9uIGFuY2hvcj0icm91dCIgdGl0 bGU9IlJvdXRpbmciPg0KQEAgLTM3MSw5ICs0MTcsMTAgQEAKICBJUy1JUyBoYXMgdGhlIGFkdmFu dGFnZSBvZiBoYW5kbGluZyB0aGVtIGJvdGggaW4gYSBzaW5nbGUgaW5zdGFuY2Ugb2YgdGhlIHBy b3RvY29sLCB3aXRoIHRoZSBwb3RlbnRpYWwNCiAgZm9yIG9wZXJhdGlvbmFsICBzaW1wbGlmaWNh dGlvbiBpbiB0aGUgbG9uZyB0ZXJtLiBJbiBhbnkgY2FzZSwgZm9yDQogIHRyYWluZWQgc3RhZmYs IHRoZXJlIHNob3VsZCBiZSBubyBwYXJ0aWN1bGFyIGRpZmZpY3VsdHkgaW4gZGVwbG95aW5nIElQ djYgcm91dGluZyB3aXRob3V0DQotIGRpc3R1cmJhbmNlIHRvIElQdjQgc2VydmljZXMuIDwvdD4N CisgZGlzdHVyYmFuY2UgdG8gSVB2NCBzZXJ2aWNlcy4gIEluIHNvbWUgY2FzZXMsIGZpcm13YXJl IHVwZ3JhZGVzIG1heSBiZSBuZWVkZWQgb24NCisgc29tZSBuZXR3b3JrIGRldmljZXMgdG8gd29y ayBhcm91bmQgdmFyaW91cyBJUHY2IGVycmF0YSBmcm9tIG9sZGVyIHZlcnNpb25zLjwvdD4NCiAN Ci0gPHQ+VGhlIHBlcmZvcm1hbmNlIGltcGFjdCBvZiBkdWFsIHN0YWNrIHJvdXRpbmcgbmVlZHMg dG8gYmUgZXZhbHVhdGVkLiBJbiBwYXJ0aWN1bGFyLCB3aGF0DQorIDx0PlRoZSBwZXJmb3JtYW5j ZSBpbXBhY3Qgb2YgZHVhbC1zdGFjayByb3V0aW5nIG5lZWRzIHRvIGJlIGV2YWx1YXRlZC4gSW4g cGFydGljdWxhciwgd2hhdA0KICBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlIGRvZXMgdGhlIHJvdXRl ciB2ZW5kb3IgY2xhaW0gZm9yIElQdjY/IElmIHRoZSBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlIGlz IHNpZ25pZmljYW50bHkNCiAgaW5mZXJpb3IgY29tcGFyZWQgdG8gSVB2NCwgd2lsbCB0aGlzIGJl IGFuIG9wZXJhdGlvbmFsIHByb2JsZW0/IElzIGV4dHJhIG1lbW9yeSBvciBUQ0FNIHNwYWNlIG5l ZWRlZA0KICB0byBhY2NvbW1vZGF0ZSBib3RoIElQdjQgYW5kIElQdjYgdGFibGVzPyBUbyBhbnN3 ZXIgdGhlc2UgcXVlc3Rpb25zLCB0aGUgSUNQIHdpbGwNCkBAIC0zODUsNyArNDMyLDkgQEAKIHRv IGVuc3VyZSB0aGF0IG91dGdvaW5nIHBhY2tldHMgYXJlIHJvdXRlZCB0byB0aGUgYXBwcm9wcmlh dGUgYm9yZGVyIHJvdXRlciBhbmQgSVNQIGxpbmsuDQogTm9ybWFsbHksIGEgcGFja2V0IHNvdXJj ZWQgZnJvbSBhbiBhZGRyZXNzIGFzc2lnbmVkIGJ5IElTUCBYIHNob3VsZCBub3QgYmUgc2VudCB2 aWEgSVNQIFksDQogdG8gYXZvaWQgaW5ncmVzcyBmaWx0ZXJpbmcgYnkgWSA8eHJlZiB0YXJnZXQ9 IlJGQzI4MjciLz4gPHhyZWYgdGFyZ2V0PSJSRkMzNzA0Ii8+LiANCi1BZGRpdGlvbmFsIGNvbnNp ZGVyYXRpb25zIG1heSBiZSBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9IkktRC5pZXRmLXY2b3BzLWlw djYtbXVsdGlob21pbmctd2l0aG91dC1pcHY2bmF0Ii8+LiA8L3Q+DQorQWRkaXRpb25hbCBjb25z aWRlcmF0aW9ucyBtYXkgYmUgZm91bmQgaW4gPHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi12Nm9wcy1p cHY2LW11bHRpaG9taW5nLXdpdGhvdXQtaXB2Nm5hdCIvPi4gDQorVGhlIGNvbXBsZXhpdGllcyBp bnZvbHZlZCBoZXJlIG1heSBpbmNsaW5lIGFuIElDUCB0byB1c2luZyBlaXRoZXIgYSBzaW5nbGUg c2luZ2xlLWhvbWVkIFBBIHByZWZpeCANCitvciBzaW5nbGUgbXVsdGktaG9tZWQgUEkgcHJlZml4 IHBlciBsb2NhdGlvbi48L3Q+DQogDQogIDx0PkVhY2ggSVB2NiBzdWJuZXQgdGhhdCBzdXBwb3J0 cyBlbmQgaG9zdHMgbm9ybWFsbHkgaGFzIGEgLzY0IHByZWZpeCwgbGVhdmluZyBhbm90aGVyIDY0 IGJpdHMgZm9yIHRoZQ0KICBpbnRlcmZhY2UgaWRlbnRpZmllcnMgb2YgaW5kaXZpZHVhbCBob3N0 cy4gSW4gY29udHJhc3QsIGEgdHlwaWNhbCBJUHY0IHN1Ym5ldCB3aWxsIGhhdmUgbm8gbW9yZSB0 aGFuIDggYml0cw0KQEAgLTM5OCwxMiArNDQ3LDMzIEBACiAgPC9zZWN0aW9uPg0KIA0KICA8c2Vj dGlvbiB0aXRsZT0iRE5TIj4NCi0gPHQ+VGhpcyBpcyBsYXJnZWx5IGEgY2FzZSBvZiAianVzdCBk byBpdC4iIEVhY2ggZXh0ZXJuYWxseSB2aXNpYmxlIGhvc3QNCi0gKG9yIHZpcnR1YWwgaG9zdCkg dGhhdCBoYXMgYW4gQSByZWNvcmQgZm9yIGl0cyBJUHY0IGFkZHJlc3MgbmVlZHMgYW4gQUFBQQ0K LSByZWNvcmQgPHhyZWYgdGFyZ2V0PSJSRkMzNTk2Ii8+IGZvciBpdHMgSVB2NiBhZGRyZXNzLCBh bmQgYSByZXZlcnNlIGVudHJ5IGlmIGFwcGxpY2FibGUuIE9uZSBpbXBvcnRhbnQNCi0gZGV0YWls IGlzIHRoYXQgc29tZSBjbGllbnRzIChlc3BlY2lhbGx5IFdpbmRvd3MgWFApIGNhbiBvbmx5IHJl c29sdmUgRE5TIG5hbWVzDQotIHZpYSBJUHY0LCBldmVuIGlmIHRoZXkgY2FuIHVzZSBJUHY2IGZv ciBhcHBsaWNhdGlvbiB0cmFmZmljLiBJdCBpcyB0aGVyZWZvcmUNCi0gYWR2aXNhYmxlIGZvciBh bGwgRE5TIHNlcnZlcnMgdG8gcmVzcG9uZCB0byBxdWVyaWVzIHZpYSBib3RoIElQdjQgYW5kIElQ djYuIDwvdD4NCisgPHQ+VGhlIGF2YWlsYWJpbGl0eSBvZiBBQUFBIHJlY29yZHMgaW4gRE5TIChp biBhZGRpdGlvbiB0byBleGlzdGluZyBBIHJlY29yZHMpDQorIGlzIHdoYXQgd2lsbCBjYXVzZSBJ UHY2IGFuZCBkdWFsLXN0YWNrIGNsaWVudHMgdG8gc3RhcnQgY29udGFjdGluZyB0aGUgSUNQJ3Mg c2VydmVycw0KKyBvdmVyIElQdjYuICBBcyBzdWNoLCBpdCBpcyBjcnVjaWFsIGZvciBhbiBJQ1Ag dG8gdGVzdCB0aGF0IElQdjYgd29ya3Mgb24gaXRzIHNlcnZlcnMNCisgYmVmb3JlIGFkZGluZyBB QUFBIHJlY29yZHMgdG8gRE5TLiAgKFRoZXJlIGhhdmUgYmVlbiBudW1lcm91cyBjYXNlcyBvZiBJ Q1BzDQorIGJyZWFraW5nIHRoZWlyIHNpdGVzIGZvciBhbGwgSVB2NiB1c2VycyBkdXJpbmcgYSBy b2xsLW91dCBieSByZXR1cm5pbmcgQUFBQQ0KKyByZWNvcmRzIGZvciBzZXJ2ZXJzIGltcHJvcGVy bHkgY29uZmlndXJlZCBmb3IgSVB2Ni4pPC90Pg0KKw0KKyA8dD5UbyBkdWFsLXN0YWNrIGEgaG9z dCwgYW4gSUNQIHdpbGwgYWRkIGFuIEFBQUENCisgcmVjb3JkIDx4cmVmIHRhcmdldD0iUkZDMzU5 NiIvPiB3aXRoIHRoZSBJUHY2IGFkZHJlc3MgZm9yIGVhY2ggZXh0ZXJuYWxseSB2aXNpYmxlIGhv c3QNCisgKG9yIHZpcnR1YWwgaG9zdCkgdGhhdCBoYXMgYW4gQSByZWNvcmQgZm9yIGl0cyBJUHY0 IGFkZHJlc3MgbmVlZHMuICBTZXBhcmF0ZWx5LCB0aGUgSUNQIA0KKyBtYXkgd2lzaCB0byBhZGQg YSByZXZlcnNlIGVudHJ5IChpcDYuYXJwYSkgY29ycmVzcG9uZGluZyB0byBlYWNoIHNlcnZlciBJ UHY2IGFkZHJlc3MuDQorIE5vdGUgdGhhdCBpZiBDTkFNRSByZWNvcmRzIGFyZSBpbi11c2UsIHRo ZSBBQUFBIHJlY29yZCBtdXN0IGJlIGFkZGVkIGFsb25nc2lkZSB0aGUgQSByZWNvcmQNCisgYXQg dGhlIGVuZCBvZiB0aGUgQ05BTUUgY2hhaW4uICBJdCBpcyBub3QgcG9zc2libGUgdG8gaGF2ZSB0 aGUgQUFBQSByZWNvcmQgb24gdGhlIHNhbWUgDQorIG5hbWUgYXMgYSBDTkFNRSByZWNvcmQsIGFz IHBlciA8eHJlZiB0YXJnZXQ9IlJGQzE5MTIiLz4uIDwvdD4NCisNCisgPHQ+SXQgaXMgd29ydGgg YmVpbmcgYXdhcmUgdGhhdCB0aGUgSVAgdmVyc2lvbiB1c2VkIGFzIHRoZSB0cmFuc3BvcnQgYnkg RE5TIHRvIGxvb2t1cCBuYW1lcw0KKyBpcyBvcnRob2dvbmFsIGZyb20gdGhlIHR5cGVzIG9mIHJl Y29yZHMgYmVpbmcgbG9va2VkIHVwLiAgRm9yIGV4YW1wbGUsDQorIGEgRE5TIHJlc29sdmVyIHdp bGwgcmVndWxhcmx5IHVzZSBJUHY0IHRvIGxvb2t1cCBBQUFBIHJlY29yZHMsIGFuZCANCisgdGhl IElQdjYgdHJhbnNwb3J0IG1heSBiZSB1c2VkIGJ5IEROUyB0byBsb29rdXAgQSByZWNvcmRzLg0K KyBBZGRpdGlvbmFsbHksIG1hbnkgZGVwbG95bWVudHMgb2YgSVB2Ni1vbmx5IGNsaWVudHMgKHN1 Y2ggYXMgdGhvc2UgDQorIHVzaW5nIE5BVDY0IGZvciB0aGVpciBJUHY0IGNvbm5lY3Rpdml0eSkg d2lsbCBoYXZlIHRoZSBjbGllbnRzIA0KKyBjb21tdW5pY2F0aW5nIHdpdGggdGhlaXIgRE5TIHJl c29sdmVycyBvdmVyIElQdjYsIGFuZCB0aG9zZSBETlMgcmVzb2x2ZXJzDQorIG1heSBpbi10dXJu IGJlIGR1YWwtc3RhY2tlZCBvciBJUHY0LW9ubHkuICBJdCBpcyB0aGVyZWZvcmUNCisgYWR2aXNh YmxlIGZvciBhbGwgRE5TIGF1dGhvcml0aWVzIHRvIHJlc3BvbmQgdG8gcXVlcmllcyB2aWEgYm90 aCBJUHY0IGFuZCBJUHY2LA0KKyBhbHRob3VnaCBtYWtpbmcgRE5TIGF1dGhvcml0aWVzIGF2YWls YWJsZSBvdmVyIElQdjYgaGFzIHJlbGF0aXZlbHkgbG93ZXINCisgdXJnZW5jeSBmb3IgYSBJQ1Ag dGhhbiBtYWtpbmcgSFRUUChTKSBjb250ZW50IGF2YWlsYWJsZSBvdmVyIElQdjYuIDwvdD4NCisN CiAgPC9zZWN0aW9uPg0KIA0KIDwvc2VjdGlvbj4gPCEtLSBzaXRlIC0tPg0KQEAgLTQxNCwxOSAr NDg0LDM3IEBACiBhc3N1cmFuY2VzIGZyb20gdmVuZG9ycyBhYm91dCB0aGVpciBJUHY2IHN1cHBv cnQsIGluY2x1ZGluZyBwZXJmb3JtYW5jZSBhc3BlY3RzIChhcyBkaXNjdXNzZWQgZm9yIA0KIHJv dXRlcnMgaW4gPHhyZWYgdGFyZ2V0PSJyb3V0Ii8+KS4gVGhlIHVwZGF0ZSBuZWVkcyB0byBiZSBw bGFubmVkIGluIGFudGljaXBhdGlvbiBvZiBleHBlY3RlZCB0cmFmZmljDQogZ3Jvd3RoLiBJdCBp cyB0byBiZSBleHBlY3RlZCB0aGF0IElQdjYgdHJhZmZpYyB3aWxsIGluaXRpYWxseSBiZSBsb3cs IA0KLWkuZS4sIGEgc21hbGwgcGVyY2VudGFnZSBvZiBJUHY0IHRyYWZmaWMuIEZvciB0aGlzIHJl YXNvbiwgaXQgbWlnaHQgYmUgYWNjZXB0YWJsZSB0byBoYXZlIElQdjYNCitpLmUuLCBhIHJlbGF0 aXZlbHkgc21hbGwgYnV0IGdyb3dpbmcgcGVyY2VudGFnZSBvZiBJUHY0IHRyYWZmaWMuIEZvciB0 aGlzIHJlYXNvbiwgaXQgbWlnaHQgYmUgYWNjZXB0YWJsZSB0byBoYXZlIElQdjYNCiB0cmFmZmlj IGJ5cGFzcyBsb2FkIGJhbGFuY2luZyBpbml0aWFsbHksIGJ5IHB1Ymxpc2hpbmcgYW4gQUFBQSBy ZWNvcmQgZm9yIGEgc3BlY2lmaWMgc2VydmVyIGluc3RlYWQNCi1vZiB0aGUgbG9hZCBiYWxhbmNl ci4gSG93ZXZlciwgaXQgd291bGQgYmUgbW9yZSBzdHJhaWdodGZvcndhcmQgdG8gaW1wbGVtZW50 IElQdjYgbG9hZCBiYWxhbmNpbmcNCi1pbW1lZGlhdGVseSwgd2hpY2ggd291bGQgYWxzbyBwcm92 aWRlIHN1cHBvcnQgZm9yIElQdjYgc2VydmVyIGZhaWwtb3Zlci4gPC90Pg0KK29mIHRoZSBsb2Fk IGJhbGFuY2VyLiAgSG93ZXZlciwgbG9hZCBiYWxhbmNlcnMgYXJlIGFsc28gb2Z0ZW4gdXNlZCB0 byBwcm92aWRlIGZhdWx0IHJlc3BvbnNlIHdoaWNoIG1heQ0KK2JlIG5lZWRlZCBmcm9tIHRoZSB2 ZXJ5IGJlZ2lubmluZy4gIEFzIHN1Y2gsIGl0IGlzIG9mdGVuIG1vcmUgcm9idXN0IGFuZCBtb3Jl IHN0cmFpZ2h0Zm9yd2FyZCB0byBpbXBsZW1lbnQgSVB2NiBsb2FkIGJhbGFuY2luZw0KK2ltbWVk aWF0ZWx5LiA8L3Q+DQogDQogPHQ+VGhlIHNhbWUgd291bGQgYXBwbHkgdG8gVExTIG9yIEhUVFAg cHJveGllcyB1c2VkIGZvciBsb2FkIGJhbGFuY2luZyBwdXJwb3Nlcy4gPC90Pg0KIA0KKzx0PkJl Y2F1c2UgZHVhbC1zdGFja2VkIGNsaWVudHMgbWF5IHN3aXRjaCBiZXR3ZWVuIElQdjQgYW5kIElQ djYsIGFzIHdlbGwgYXMgc3dpdGNoaW5nIA0KK2JldHdlZW4gbXVsdGlwbGUgSVB2NiBhZGRyZXNz ZXMgd2hlbiBwcml2YWN5IGFkZHJlc3NpbmcgaXMgaW4tdXNlLCBzcGVjaWFsIGNhcmUgd2lsbA0K K25lZWQgdG8gYmUgdGFrZW4gd2l0aCBhbnkgbG9hZCBiYWxhbmNlcnMgdXNpbmcgSVAgYWRkcmVz c2VzIGZvciBzZXNzaW9uIGFmZmluaXR5IGFzDQordGhlIHNhbWUgY2xpZW50IG1pZ2h0IG90aGVy d2lzZSBnbyB0byBkaWZmZXJlbnQgc2VydmVycyBmb3Igc3Vic2VxdWVudCByZXF1ZXN0cy48L3Q+ DQorDQogPC9zZWN0aW9uPiA8IS0tIGxvYWQgLS0+DQogDQotPHNlY3Rpb24gYW5jaG9yPSJwcm94 eSIgdGl0bGU9IlByb3hpZXMiPg0KKzxzZWN0aW9uIGFuY2hvcj0iZmlyZXdhbGwiIHRpdGxlPSJG aXJld2FsbHMgYW5kIE5ldHdvcmsgU2VjdXJpdHkgQXBwbGlhbmNlcyI+DQorDQorPHQ+V2hpbGUg bWFueSBJQ1BzIG1heSBzdGlsbCBiZSBpbiB0aGUgcHJvY2VzcyBvZiBleHBlcmltZW50aW5nIHdp dGgNCithbmQgY29uZmlndXJpbmcgSVB2NiwgdGhlcmUgaXMgbWF0dXJlIG1hbHdhcmUgaW4gdGhl IHdpbGQgdGhhdCB3aWxsIGxhdW5jaA0KK2F0dGFja3Mgb3ZlciBJUHY2LiAgRm9yIGV4YW1wbGUs IGlmIGEgQUFBQSBETlMgcmVjb3JkIGlzIGFkZGVkIHRvIGZvciBhIGhvc3RuYW1lLCwNCittYWx3 YXJlIHVzaW5nIGNsaWVudCBPUyBsaWJyYXJpZXMgbWF5IHN3aXRjaCBmcm9tIGF0dGFja2luZyB0 aGF0IGhvc3RuYW1lIG92ZXIgSVB2NA0KK3RvIGF0dGFja2luZyB0aGF0IGhvc3RuYW1lIG92ZXIg SVB2Ni4gIEFzIGEgcmVzdWx0LCBpdCBpcyBjcnVjaWFsIHRoYXQgZmlyZXdhbGxzIGFuZCANCitv dGhlciBuZXR3b3JrIHNlY3VyaXR5IGFwcGxpYW5jZXMgcHJvdGVjdGluZyBzZXJ2ZXJzIHN1cHBv cnQgSVB2NiBhbmQgaGF2ZSBydWxlcw0KK3Rlc3RlZCBhbmQgY29uZmlndXJlZC4gIE1vcmUgaXMg ZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0ic2VjdXJpdHkiLz4uIDwvdD4NCisNCis8L3NlY3Rp b24+DQogDQotPHQ+QW4gSFRUUCBwcm94eSA8eHJlZiB0YXJnZXQ9IlJGQzI2MTYiLz4gY2FuIHJl YWRpbHkgYmUgY29uZmlndXJlZCB0byBoYW5kbGUgaW5jb21pbmcgY29ubmVjdGlvbnMgb3ZlciBJ UHY2IGFuZCB0byBwcm94eSB0aGVtDQotdG8gYSBzZXJ2ZXIgb3ZlciBJUHY0LiBUaGVyZWZvcmUs IGEgc2luZ2xlIHByb3h5IGNhbiBiZSB1c2VkIGFzIHRoZSBmaXJzdCBzdGVwIGluIGFuIG91dHNp ZGUtaW4gc3RyYXRlZ3ksIGFzDQorPHNlY3Rpb24gYW5jaG9yPSJwcm94eSIgdGl0bGU9IlN1cnJv Z2F0ZXMiPg0KKw0KKzx0PkEgc3Vycm9nYXRlIChzdWNoIGFzIGFuIEhUVFAgcmV2ZXJzZSBwcm94 eSkgPHhyZWYgdGFyZ2V0PSJSRkMzMDQwIi8+IGNhbiByZWFkaWx5IGJlIGNvbmZpZ3VyZWQgdG8g aGFuZGxlIGluY29taW5nIGNvbm5lY3Rpb25zIG92ZXIgSVB2NiBhbmQgdG8gcHJveHkgdGhlbQ0K K3RvIGEgc2VydmVyIG92ZXIgSVB2NC4gVGhlcmVmb3JlLCBhIHN1cnJvZ2F0ZSBjYW4gYmUgdXNl ZCBhcyB0aGUgZmlyc3Qgc3RlcCBpbiBhbiBvdXRzaWRlLWluIHN0cmF0ZWd5LCBhcw0KIHNob3du IGluIHRoZSBmb2xsb3dpbmcgZGlhZ3JhbTogPC90Pg0KIDxmaWd1cmU+PGFydHdvcms+DQogICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpAQCAtNDQwLDEz ICs1MjgsMTMgQEAKICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tDQogICAgICAgICAg ICAgIF9fX19fX19fX19fX3xfX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICANCi0gICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLQ0KLSAgICAg ICAgICAgICAgICAgICB8IElQdjYgc3RhY2t8DQotICAgICAgICAgICAgICAgICAgIHwtLS0tLS0t LS0tLXwNCi0gICAgICAgICAgICAgICAgICAgfCBIVFRQIHByb3h5fA0KLSAgICAgICAgICAgICAg ICAgICB8LS0tLS0tLS0tLS18DQotICAgICAgICAgICAgICAgICAgIHwgSVB2NCBzdGFja3wgDQot ICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0NCisgICAgICAgICAgICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tfA0KKyAgICAgICAgICAgICAgICAgfCBJUHY2IHN0YWNrICAgICB8DQorICAg ICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLXwNCisgICAgICAgICAgICAgICAgIHwgSFRU UCBTdXJyb2dhdGUgfA0KKyAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS18DQorICAg ICAgICAgICAgICAgICB8IElQdjQgc3RhY2sgICAgIHwgDQorICAgICAgICAgICAgICAgICAtLS0t LS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgX19fX19fX19fX19ffF9fX19fX19fX19fX18N CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAtLS0tLS0tLS0tLS0tDQpAQCAtNDU3LDkgKzU0NSwyNCBAQAogICAgICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0tLS0NCiANCiAgPC9hcnR3b3JrPiA8L2ZpZ3VyZT4gICAgICAgICAgICAg ICANCi08dD5JbiB0aGlzIGNhc2UsIHRoZSBBQUFBIHJlY29yZCBmb3IgdGhlIHNlcnZpY2Ugd291 bGQgcHJvdmlkZSB0aGUgSVB2NiBhZGRyZXNzIG9mIHRoZSBwcm94eS4NCis8dD5JbiB0aGlzIGNh c2UsIHRoZSBBQUFBIHJlY29yZCBmb3IgdGhlIHNlcnZpY2Ugd291bGQgcHJvdmlkZSB0aGUgSVB2 NiBhZGRyZXNzIG9mIHRoZSBzdXJyb2dhdGUuDQogVGhpcyBhcHByb2FjaCB3aWxsIHdvcmsgZm9y IGFueSBIVFRQIG9yIEhUVFBTIGFwcGxpY2F0aW9ucyB0aGF0IG9wZXJhdGUgc3VjY2Vzc2Z1bGx5 DQotdmlhIGEgcHJveHksIGFzIGxvbmcgYXMgSVB2NiBsb2FkIHJlbWFpbnMgbG93LiA8L3Q+DQor dmlhIGEgc3Vycm9nYXRlLiA8L3Q+DQorDQorPHQ+Rm9yIG11bHRpLXRpZXIgYXBwbGljYXRpb25z LCBpdCBtYXkgYmUgaW5pdGlhbGx5IHN1ZmZpY2llbnQgdG8gZHVhbC1zdGFjaw0KK3RoZSBXZWIg VGllciAob2Z0ZW4gb3BlcmF0aW5nIGFzIGFuIEhUVFAgc3Vycm9nYXRlKSBhbmQgdG8gcHJvdmlk ZSBJUHY2IA0KK2Nvbm5lY3Rpdml0eSB0byBiYWNrLWVuZCBhcHBsaWNhdGlvbiBsYXllcnMgaW4g YSBsYXRlciBwaGFzZS48L3Q+DQorDQorPHQ+U29tZSBzZXJ2aWNlcywgc3VjaCBhcyBBcHBsaWNh dGlvbiBhbmQgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrcyAoc2VlIDx4cmVmIHRhcmdldD0iY2Ru Ii8+LCANCittYXkgYWN0IGFzIEhUVFAgc3Vycm9nYXRlcyBmb3IgYW4gSUNQIGFuZCBjYW4gcHJv dmlkZSBhIHF1aWNrIHdheSB0byBtYWtlIA0KK2NvbnRlbnQgYXZhaWxhYmxlIHRvIGVuZC11c2Vy cyBvdmVyIElQdjYgd2l0aG91dCBhbiBJQ1AgbmVlZGluZyB0byBpbW1lZGlhdGVseQ0KK3Byb3Zp c2lvbiB0aGVpciBvd24gSVB2NiBjb25uZWN0aXZpdHkuPC90Pg0KKw0KKzx0Pk5vdGUgdGhhdCBp biBhbGwgb2YgdGhlc2Ugc3Vycm9nYXRlIHNjZW5hcmlvcywgYW4gSUNQIG1heSBzdGlsbCANCitu ZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IGJvdGggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMgYXJlIGJl aW5nIHByb3Blcmx5IHBhc3NlZA0KK3RvIGFwcGxpY2F0aW9uIHNlcnZlcnMgaW4gYW55IHJlbGV2 YW50IEhUVFAgaGVhZGVycywgYW5kIHRoYXQgdGhvc2UgYXBwbGljYXRpb24NCitzZXJ2ZXJzIGFy ZSBwcm9wZXJseSBoYW5kbGluZyB0aGUgSVB2NiBhZGRyZXNzZXMuPC90Pg0KKw0KIDwvc2VjdGlv bj4gPCEtLSBwcm94eSAtLT4NCiANCiA8c2VjdGlvbiBhbmNob3I9InNlcnYiIHRpdGxlPSJTZXJ2 ZXJzIj4NCkBAIC00NjksNiArNTcyLDExIEBACiAgY2FzZXMsIGl0IGlzIHN1ZmZpY2llbnQgdG8g ZW5hYmxlIElQdjYgYW5kIHBvc3NpYmx5IERIQ1B2NjsgdGhlIHJlc3Qgd2lsbCBmb2xsb3cuIFNl cnZlcnMgaW5zaWRlIGFuIElDUCBuZXR3b3JrIHdpbGwNCiAgbm90IG5lZWQgdG8gc3VwcG9ydCBh bnkgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgYmV5b25kIGEgc2ltcGxlIGR1YWwgc3RhY2ssIHdp dGggYSBwb3NzaWJsZSBleGNlcHRpb24NCiAgZm9yIDZ0bzQgbWl0aWdhdGlvbiBub3RlZCBiZWxv dyBpbiA8eHJlZiB0YXJnZXQ9InhpdGlvbiIvPi4gPC90Pg0KKw0KKyA8dD5BcyBzb21lIG9wZXJh dGluZyBzeXN0ZW1zIGhhdmUgc2VwYXJhdGUgZmlyZXdhbGwgcnVsZSBzZXRzIGZvciBJUHY0IGFu ZCBJUHY2LA0KKyBhbiBJQ1Agc2hvdWxkIGFsc28gZXZhbHVhdGUgdGhlIHJ1bGUgc2V0cyBhbmQg ZW5zdXJlIHRoYXQgYXBwcm9wcmlhdGUgZmlyZXdhbGwgcnVsZXMNCisgYXJlIGNvbmZpZ3VyZWQg Zm9yIElQdjYuICBNb3JlIGRldGFpbHMgYXJlIGRpc2N1c3NlZCBpbiA8eHJlZiB0YXJnZXQ9InNl Y3VyaXR5Ii8+PC90Pg0KKw0KICA8L3NlY3Rpb24+DQogDQogIDxzZWN0aW9uIGFuY2hvcj0iYXBw bCIgdGl0bGU9IkFwcGxpY2F0aW9uIExheWVyIj4NCkBAIC00NzYsMjQgKzU4NCw0NSBAQAogIDx0 PkJhc2ljIEhUVFAgc2VydmVycyBoYXZlIGJlZW4gYWJsZSB0byBoYW5kbGUgYW4gSVB2Ni1lbmFi bGVkIG5ldHdvcmsgc3RhY2sgZm9yIHNvbWUgeWVhcnMsIHNvIGF0IHRoZSBtb3N0DQogIGl0IHdp bGwgYmUgbmVjZXNzYXJ5IHRvIHVwZGF0ZSB0byBhIG1vcmUgcmVjZW50IHNvZnR3YXJlIHZlcnNp b24uIFRoZSBzYW1lIGlzIHRydWUgb2YgZ2VuZXJpYyBhcHBsaWNhdGlvbnMNCiAgc3VjaCBhcyBl bWFpbCBwcm90b2NvbHMuIE5vIGdlbmVyYWwgc3RhdGVtZW50IGNhbiBiZSBtYWRlIGFib3V0IG90 aGVyIGFwcGxpY2F0aW9ucywgZXNwZWNpYWxseSBwcm9wcmlldGFyeQ0KLSBvbmVzLCBzbyBlYWNo IEFTUCB3aWxsIG5lZWQgdG8gbWFrZSBpdHMgb3duIGRldGVybWluYXRpb24uIDwvdD4NCisgb25l cywgc28gZWFjaCBBU1Agd2lsbCBuZWVkIHRvIG1ha2UgaXRzIG93biBkZXRlcm1pbmF0aW9uLiAg QXMgY2hhbmdlcyB0byB0aGUgbmV0d29yayBsYXllciANCisgdG8gaW50cm9kdWNlIElQdjYgYWRk cmVzc2VzIGNhbiByaXBwbGUgdGhyb3VnaCBhcHBsaWNhdGlvbnMsIHRlc3Rpbmcgb2YgYm90aCBj bGllbnQgYW5kIHNlcnZlcg0KKyBhcHBsaWNhdGlvbnMgc2hvdWxkIGJlIHBlcmZvcm1lZCBpbiBi b3RoIElQdjQtb25seSwgSVB2Ni1vbmx5LCBhbmQgZHVhbC1zdGFjayBlbnZpcm9ubWVudHMNCisg cHJpb3IgdG8gYW4gSUNQIGR1YWwtc3RhY2tpbmcgYSBwcm9kdWN0aW9uIGVudmlyb25tZW50Ljwv dD4NCisNCisgPHQ+R2VuZXJpYyBjb25zaWRlcmF0aW9ucyBvbiBhcHBsaWNhdGlvbiB0cmFuc2l0 aW9uIGFyZSBkaXNjdXNzZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkM0MDM4Ii8+LCBidXQNCisgbWFu eSBvZiB0aGVtIHdpbGwgbm90IGFwcGx5IHRvIHRoZSBkdWFsLXN0YWNrIElDUCBzY2VuYXJpby4g QW4gSUNQIHRoYXQgY3JlYXRlcyBhbmQgbWFpbnRhaW5zIGl0cw0KKyBvd24gYXBwbGljYXRpb25z IHdpbGwgbmVlZCB0byByZXZpZXcgdGhlbSBmb3IgYW55IGRlcGVuZGVuY3kgb24gSVB2NC4gPC90 Pg0KIA0KKyA8c2VjdGlvbiBhbmNob3I9ImNsaWVudCIgdGl0bGU9IkNsaWVudCBTb2Z0d2FyZSI+ DQogICA8dD5PbmUgaW1wb3J0YW50IHJlY29tbWVuZGF0aW9uIGhlcmUgaXMgdGhhdCBhbGwgYXBw bGljYXRpb25zIHNob3VsZCB1c2UgZG9tYWluIG5hbWVzLCB3aGljaCBhcmUgSVAtdmVyc2lvbi1p bmRlcGVuZGVudCwgDQotIHJhdGhlciB0aGFuIElQIGFkZHJlc3Nlcy4gQXBwbGljYXRpb25zIGJh c2VkIG9uIG1pZGRsd2FyZSBwbGF0Zm9ybXMgd2hpY2ggaGF2ZSB1bmlmb3JtIHN1cHBvcnQgZm9y IElQdjQgYW5kIElQdjYsDQotICBmb3IgZXhhbXBsZSBKYXZhLCBtYXkgYmUgYWJsZSB0byBzdXBw b3J0IGJvdGggSVB2NCBhbmQgSVB2NiBuYXR1cmFsbHkgd2l0aG91dCBhZGRpdGlvbmFsIHdvcmsu IDwvdD4NCi0gDQorIHJhdGhlciB0aGFuIElQIGFkZHJlc3Nlcy4gQXBwbGljYXRpb25zIGJhc2Vk IG9uIG1pZGRsZXdhcmUgcGxhdGZvcm1zIHdoaWNoIGhhdmUgdW5pZm9ybSBzdXBwb3J0IGZvciBJ UHY0IGFuZCBJUHY2LA0KKyAgZm9yIGV4YW1wbGUgSmF2YSwgbWF5IGJlIGFibGUgdG8gc3VwcG9y dCBib3RoIElQdjQgYW5kIElQdjYgbmF0dXJhbGx5IHdpdGhvdXQgYWRkaXRpb25hbCB3b3JrLiAg Tm90ZSB0aGF0IA0KKyAgdGhlIGJlaGF2aW9yIG9mIGR1YWwtc3RhY2sgY2xpZW50cyB3aWxsIHZh cnkgYmV0d2VlbiBvcGVyYXRpbmcgc3lzdGVtcyBhbmQgYnJvd3NlcnMuICBGb3IgZXhhbXBsZSwg c29tZSBjbGllbnQNCisgIGltcGxlbWVudGF0aW9uIG9mICJoYXBweSBleWViYWxscyIgPHhyZWYg dGFyZ2V0PSJSRkM2NTU1Ii8+IG1heSByZXN1bHQgaW4gYSBkdWFsLXN0YWNrIGNsaWVudCBtYWtp bmcgDQorICBjb25uZWN0aW9ucyB0byB0aGUgc2FtZSBkb21haW4gbmFtZSBvdmVyIGJvdGggSVB2 NCBhbmQgSVB2NiBvdmVyIHRpbWUuPC90Pg0KKyA8L3NlY3Rpb24+IA0KKw0KKyA8c2VjdGlvbiBh bmNob3I9ImNvb2tpZXMiIHRpdGxlPSJJc3N1ZXMgd2l0aCBlbWJlZGRpbmcgSVAgYWRkcmVzc2Vz IGluIGNvb2tpZXMiPg0KIDx0PkEgc3BlY2lmaWMgaXNzdWUgZm9yIEhUVFAtYmFzZWQgc2Vydmlj ZXMgaXMgdGhhdCBJUCBhZGRyZXNzLWJhc2VkIGNvb2tpZSBhdXRoZW50aWNhdGlvbiBzY2hlbWVz DQogIHdpbGwgbmVlZCB0byBkZWFsIHdpdGggZHVhbC1zdGFjayBjbGllbnRzLiBTZXJ2ZXJzIG1p Z2h0IGNyZWF0ZSBhIGNvb2tpZSBmb3IgYW4NCiAgSVB2NCBjb25uZWN0aW9uIG9yIGFuIElQdjYg Y29ubmVjdGlvbiwgZGVwZW5kaW5nIG9uIHRoZSBzZXR1cCBhdCB0aGUgY2xpZW50IHNpdGUgYW5k DQogIG9uIHRoZSB3aGltcyBvZiB0aGUgY2xpZW50IG9wZXJhdGluZyBzeXN0ZW0uIFRoZXJlIGlz IG5vIGd1YXJhbnRlZSB0aGF0IGEgZ2l2ZW4gY2xpZW50DQogIHdpbGwgY29uc2lzdGVudGx5IHVz ZSB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSwgZXNwZWNpYWxseSB3aGVuIGFjY2Vzc2luZyBhIGNv bGxlY3Rpb24NCi0gb2Ygc2l0ZXMgcmF0aGVyIHRoYW4gYSBzaW5nbGUgc2l0ZS4gSWYgdGhlIGNs aWVudCBpcyB1c2luZyBwcml2YWN5IGFkZHJlc3NlcyA8eHJlZiB0YXJnZXQ9IlJGQzQ5NDEiLz4s DQorIG9mIHNpdGVzIHJhdGhlciB0aGFuIGEgc2luZ2xlIHNpdGUgKHN1Y2ggYXMgd2hlbiBjb29r aWVzIGFyZSB1c2VkIGZvciBmZWRlcmF0ZWQgYXV0aGVudGljYXRpb24pLg0KKy4gSWYgdGhlIGNs aWVudCBpcyB1c2luZyBwcml2YWN5IGFkZHJlc3NlcyA8eHJlZiB0YXJnZXQ9IlJGQzQ5NDEiLz4s DQogIHRoZSBJUHY2IGFkZHJlc3MgKGJ1dCB1c3VhbGx5IG5vdCBpdHMgLzY0IHByZWZpeCkgbWln aHQgY2hhbmdlIHF1aXRlIGZyZXF1ZW50bHkuIEFueSBjb29raWUgbWVjaGFuaXNtDQotIGJhc2Vk IG9uIDMyLWJpdCBJUHY0IGFkZHJlc3NlcyB3aWxsIG5lZWQgc2lnbmlmaWNhbnQgcmVtb2RlbGxp bmcuIDwvdD4NCisgYmFzZWQgb24gMzItYml0IElQdjQgYWRkcmVzc2VzIHdpbGwgbmVlZCBzaWdu aWZpY2FudCByZWRlc2lnbiwgYW5kIGVtYmVkZGluZyBJUCBhZGRyZXNzZXMgaW4gY29va2llcw0K KyBtYXkgbm8gbG9uZ2VyIGJlIGZlYXNpYmxlIGluIGEgZHVhbC1zdGFjayBlbnZpcm9ubWVudC4g PC90Pg0KKyA8L3NlY3Rpb24+DQogDQotIDx0PkdlbmVyaWMgY29uc2lkZXJhdGlvbnMgb24gYXBw bGljYXRpb24gdHJhbnNpdGlvbiBhcmUgZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0iUkZDNDAz OCIvPiwgYnV0DQotIG1hbnkgb2YgdGhlbSB3aWxsIG5vdCBhcHBseSB0byB0aGUgZHVhbC1zdGFj ayBJQ1Agc2NlbmFyaW8uIEFuIElDUCB0aGF0IGNyZWF0ZXMgYW5kIG1haW50YWlucyBpdHMNCi0g b3duIGFwcGxpY2F0aW9ucyB3aWxsIG5lZWQgdG8gcmV2aWV3IHRoZW0gZm9yIGFueSBkZXBlbmRl bmN5IG9uIElQdjQuIDwvdD4NCisgPHNlY3Rpb24gYW5jaG9yPSJsb2dzIiB0aXRsZT0iTG9nZ2lu ZyI+DQorICAgPHQ+VGhlIGludHJvZHVjdGlvbiBvZiBJUHY2IGNsaWVudHMgd2lsbCBnZW5lcmFs bHkgYWxzbyByZXN1bHQgaW4gSVB2NiBhZGRyZXNzZXMNCisgICBhcHBlYXJpbmcgaW4gdGhlICJj bGllbnQgaXAiIGZpZWxkIG9mIHNlcnZlciBsb2dzLiAgSXQgZ2VuZXJhbGx5IG1ha2VzIHNlbnNl IHRvIHVzZQ0KKyAgIHRoZSBzYW1lIGxvZyBmaWVsZCB0byBob2xkIGEgY2xpZW50J3MgSVAgYWRk cmVzcywgd2hldGhlciBpdCBpcyBJUHY0IG9yIElQdjYuDQorICAgRG93bnN0cmVhbSBzeXN0ZW1z IGxvb2tpbmcgYXQgbG9ncyBhbmQgY2xpZW50IElQIGFkZHJlc3NlcyBtYXkgYWxzbyBuZWVkDQor ICAgdGVzdGluZyB0byBlbnN1cmUgdGhhdCB0aGV5IGNhbiBwcm9wZXJseSBoYW5kbGUgSVB2NiBh ZGRyZXNzZXMuDQorICAgVGhpcyBpbmNsdWRlcyBhbnkgb2YgYW4gSUNQJ3MgZGF0YWJhc2VzIHJl Y29yZGluZyBjbGllbnQgSVAgYWRkcmVzc2VzLCBzdWNoDQorICAgYXMgZm9yIHJlY29yZGluZyBJ UCBhZGRyZXNzZXMgb2Ygb25saW5lIHB1cmNoYXNlcyBhbmQgY29tbWVudCBwb3N0ZXJzLjwvdD4N CiAgPC9zZWN0aW9uPg0KIA0KICA8c2VjdGlvbiB0aXRsZT0iR2VvbG9jYXRpb24iPg0KQEAgLTUw NCw2ICs2MzMsOCBAQAogIGFzIHRpbWUgZ29lcyBvbiwgc28gZ2VvbG9jYXRpb24gYmFzZWQgb24g SVAgYWRkcmVzc2VzIGFsb25lIG1heSBpbiBhbnkgY2FzZSBiZWNvbWUgcHJvYmxlbWF0aWMuIDwv dD4NCiAgPC9zZWN0aW9uPiANCiANCisgPC9zZWN0aW9uPiA8IS0tIGFwcGwgLS0+DQorDQogPC9z ZWN0aW9uPiA8IS0tIHNlcnYgLS0+DQogDQogPHNlY3Rpb24gYW5jaG9yPSJ4aXRpb24iIHRpdGxl PSJDb3Bpbmcgd2l0aCBUcmFuc2l0aW9uIFRlY2hub2xvZ2llcyI+DQpAQCAtNTE2LDcgKzY0Nyw3 IEBACiANCiA8dD5JbiBzb21lIGNhc2VzIG91dHNpZGUgdGhlIElDUCdzIGNvbnRyb2wsIGNsaWVu dHMgbWlnaHQgcmVhY2ggYSBjb250ZW50IHNlcnZlciB2aWEgYSBuZXR3b3JrLWxheWVyDQogdHJh bnNsYXRvciBmcm9tIElQdjYgdG8gSVB2NC4gSUNQcyB3aG8gYXJlIG9mZmVyaW5nIGEgZHVhbCBz dGFjayBzZXJ2aWNlIGFuZCBwcm92aWRpbmcgYm90aCBBDQotYW5kIEFBQUEgcmVjb3JkcywgYXMg cmVjb21tZW5kZWQgaW4gdGhpcyBkb2N1bWVudCwgc2hvdWxkIG5vdCBub3JtYWxseSByZWNlaXZl IHRyYWZmaWMgZnJvbSBOQVQ2NA0KK2FuZCBBQUFBIHJlY29yZHMsIGFzIHJlY29tbWVuZGVkIGlu IHRoaXMgZG9jdW1lbnQsIHNob3VsZCBub3Qgbm9ybWFsbHkgcmVjZWl2ZSBJUHY0IHRyYWZmaWMg ZnJvbSBOQVQ2NA0KIHRyYW5zbGF0b3JzIDx4cmVmIHRhcmdldD0iUkZDNjE0NiIvPi4gRXhjZXB0 aW9uYWxseSwgaG93ZXZlciwgc3VjaCB0cmFmZmljIGNvdWxkIGFycml2ZSB2aWEgSVB2NCANCiBm cm9tIGFuIElQdjYtb25seSBjbGllbnQgd2hvc2UgRE5TIHJlc29sdmVyIGZhaWxlZCB0byByZWNl aXZlIHRoZSBJQ1AncyBBQUFBIHJlY29yZCBmb3Igc29tZSByZWFzb24uDQogU3VjaCB0cmFmZmlj IHdvdWxkIGJlIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gcmVndWxhciBJUHY0LXZpYS1OQVQgdHJh ZmZpYy4gPC90Pg0KQEAgLTU0MCw4ICs2NzEsMTAgQEAKIGJ5IGxpbWl0aW5nIHRoZSB2aXNpYmls aXR5IG9mIHRoZWlyIEFBQUEgcmVjb3JkcyB0byB1c2VycyB3aXRoIHZhbGlkYXRlZCBJUHY2IA0K IGNvbm5lY3Rpdml0eSA8eHJlZiB0YXJnZXQ9IlJGQzY1ODkiLz4gKGtub3duIGFzICJETlMgd2hp dGVsaXN0aW5nIikuIEF0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZywNCiB0aGlzIHNvbHV0aW9u IHNlZW1zIHRvIGJlIHBhc3Npbmcgb3V0IG9mIHVzZSwgYmVpbmcgcmVwbGFjZWQgYnkgIkROUyBi bGFja2xpc3RpbmciIG9mDQotY3VzdG9tZXIgc2l0ZXMga25vd24gdG8gaGF2ZSBwcm9ibGVtcyB3 aXRoIElQdjYgY29ubmVjdGl2aXR5LiBOZWl0aGVyIG9mIHRoZXNlIHNvbHV0aW9ucw0KLWlzIGFw cHJvcHJpYXRlIGluIHRoZSBsb25nIHRlcm0uIDwvdD4NCitjdXN0b21lciBzaXRlcyBrbm93biB0 byBoYXZlIHByb2JsZW1zIHdpdGggSVB2NiBjb25uZWN0aXZpdHkuIE9uIHRoZSByZXZlcnNlIGRp cmVjdGlvbiwgaXQgaXMgd29ydGggYmVpbmcgDQorYXdhcmUgdGhhdCBzb21lIElTUHMgd2l0aCBz aWduaWZpY2FudCBwb3B1bGF0aW9ucyBvZiBjbGllbnRzIGJyb2tlbiBmb3IgSVB2NiBoYXZlIGJl Z3VuDQorZmlsdGVyaW5nIEFBQUEgcmVjb3JkIGxvb2t1cHMgYnkgdGhlaXIgY2xpZW50cy4gIE5v bmUgb2YgdGhlc2Ugc29sdXRpb25zDQorYXJlIGFwcHJvcHJpYXRlIGluIHRoZSBsb25nIHRlcm0u ICA8L3Q+DQogDQogPHQ+QW5vdGhlciBhcHByb2FjaCB0YWtlbiBieSBzb21lIElDUHMgaXMgdG8g b2ZmZXIgSVB2Ni1vbmx5IHN1cHBvcnQgdmlhIGEgc3BlY2lmaWMgRE5TDQogbmFtZSwgZS5nLiwg aXB2Ni5leGFtcGxlLmNvbSwgaWYgdGhlIHByaW1hcnkgc2VydmljZSBpcyB3d3cuZXhhbXBsZS5j b20uIEluIHRoaXMgY2FzZQ0KQEAgLTU1NSwzNyArNjg4LDY4IEBACiANCiA8L3NlY3Rpb24+IDwh LS0geGl0aW9uIC0tPg0KIA0KKzxzZWN0aW9uIGFuY2hvcj0iY29tcGxleCIgdGl0bGU9IkNvbXBs ZXggU2l0ZXMgYW5kIEFwcGxpY2F0aW9ucyI+DQorDQorPHQ+U29tZSBhZGRpdGlvbmFsIGNvbnNp ZGVyYXRpb25zIGNvbWUgaW50byBwbGF5IGZvciBzb21lIHR5cGVzIG9mIGNvbXBsZXgNCitzaXRl cyBhbmQgYXBwbGljYXRpb25zIHRoYXQgYW4gSUNQIG1heSBiZSBkZWxpdmVyaW5nLiAgRm9yIGV4 YW1wbGUsIGFuIElDUA0KK21heSBoYXZlIGEgc2l0ZSBzcHJlYWQgYWNyb3NzIG1hbnkgaG9zdG5h bWVzIChub3QgYWxsIHVuZGVyIHRoZWlyIGNvbnRyb2wpLiAgDQorT3RoZXIgSUNQcyBtYXkgaGF2 ZSB0aGVpciBzaXRlcyBvciBhcHBsaWNhdGlvbnMgZGlzdHJpYnV0ZWQgYWNyb3NzIG11bHRpcGxl IGxvY2F0aW9ucw0KK2ZvciBhdmFpbGFiaWxpdHksIHNjYWxlLCBvciBwZXJmb3JtYW5jZS48L3Q+ DQorDQorPHNlY3Rpb24gdGl0bGU9IkVtYmVkZGVkIFJlc291cmNlcyI+DQorPHQ+TWFueSBtb2Rl cm4gd2ViIHNpdGVzIGFuZCBhcHBsaWNhdGlvbnMgbm93IHVzZSBhIGNvbGxlY3Rpb24gb2YgcmVz b3VyY2VzDQorYW5kIGFwcGxpY2F0aW9ucywgc29tZSBvcGVyYXRlZCBieSB0aGUgSUNQIGFuZCBv dGhlciBieSB0aGlyZCBwYXJ0aWVzLg0KK1doaWxlIG1vc3QgY2xpZW50cyBzdXBwb3J0IHNpdGVz IGNvbnRhaW5pbmcgYSBtaXh0dXJlIG9mIElQdjQtb25seSBhbmQgZHVhbC1zdGFjaw0KK2VsZW1l bnRzLCBhbiBJQ1Agc2hvdWxkIHRyYWNrIHRoZSBJUHY2IGF2YWlsYWJpbGl0eSBvZiBlbWJlZGRl ZCByZXNvdXJjZXMgKHN1Y2ggDQorYXMgaW1hZ2VzKSBhcyBvdGhlcndpc2UgdGhlaXIgc2l0ZSBt YXkgb25seSBiZSBwYXJ0aWFsbHkgZnVuY3Rpb25hbCBvciBtYXkNCitoYXZlIGRlZ3JhZGVkIHBl cmZvcm1hbmNlIGZvciBJUHY2LW9ubHkgdXNlcnMuPC90Pg0KKzwvc2VjdGlvbj4NCisNCis8c2Vj dGlvbiBhbmNob3I9Im11bHRpc2l0ZSIgdGl0bGU9IkRpc3RyaWJ1dGVkIExvY2F0aW9ucyI+DQor DQorPHQ+RE5TLWJhc2VkIHRlY2huaXF1ZXMgZm9yIGRpdmVydGluZyB1c2VycyB0byBzZXJ2ZXJz IGluIG11bHRpcGxlIFBPUHMNCit3aWxsIHdvcmsgZm9yIElQdjYsIGlmIHRoZSBsb2FkIGJhbGFu Y2VyIHN1cHBvcnRzIElQdjYgYW5kIGlmIA0KK0FBQUEgcmVjb3JkcyBhcmUgcHJvdmlkZWQgYXMg d2VsbCBhcyBBIHJlY29yZHMuIA0KK0RlcGVuZGluZyBvbiB0aGUgYXJjaGl0ZWN0dXJlIG9mIHRo ZSBsb2FkIGJhbGFuY2VyLCBhbiBJQ1AgbWF5IG5lZWQNCit0byBvcGVyYXRlIGEgZnVsbCBkdWFs IHN0YWNrIHNlcnZpY2UNCithdCBlYWNoIFBPUC4gIFdpdGggb3RoZXIgYXJjaGl0ZWN0dXJlcywg aXQgbWF5IGJlIGFjY2VwdGFibGUgdG8gaW5pdGlhbGx5DQorb25seSBoYXZlIElQdjYgYXQgYSBz dWJzZXQgb2YgbG9jYXRpb25zLiAgIFNvbWUgYXJjaGl0ZWN0dXJlcyB3aWxsIG1ha2UgaXQgcHJl ZmVyYWJsZQ0KK2ZvciBJUHY2IHJvdXRpbmcgdG8gbWlycm9yIElQdjQgcm91dGluZyAoZm9yIGV4 YW1wbGUgcnVubmluZyBCR1A0KyA8eHJlZiB0YXJnZXQ9IlJGQzQ3NjAiLz4gaWYgYXBwcm9wcmlh dGUpDQorYnV0IHRoaXMgbWF5IG5vdCBhbHdheXMgYmUgcG9zc2libGUgYXMgSVB2NiBhbmQgSVB2 NCBjb25uZWN0aXZpdHkgYXJlIG9mdGVuIGluZGVwZW5kZW50LiA8L3Q+DQorDQorPHQ+U29tZSBj b21wbGV4aXRpZXMgbWF5IGFyaXNlIHdoZW4gYSBjbGllbnQgc3VwcG9ydGluZyBib3RoIElQdjQg YW5kIElQdjYgDQordXNlcyBkaWZmZXJlbnQgUE9QcyBmb3IgZWFjaCBJUCB2ZXJzaW9uIChzdWNo IGFzIHdoZW4gSVB2NiBpcyBvbmx5IGF2YWlsYWJsZQ0KK2luIGEgc3Vic2V0IG9mIGxvY2F0aW9u cykuIFRoZXJlIGFyZSBhbHNvIHNjZW5hcmlvcyB3aGVyZSBhIGR1YWwtc3RhY2sgY2xpZW50IHdv dWxkIGJlIGRpdmVydGVkDQordG8gYSBtaXh0dXJlIG9mIElQdjQgYW5kIElQdjYgUE9QcyBmb3Ig ZGlmZmVyZW50IFVSTHMsIGFjY29yZGluZyB0byB0aGUgQSBhbmQgQUFBQSByZWNvcmRzIHByb3Zp ZGVkDQorYW5kIHRoZSBhdmFpbGFiaWxpdHkgb2Ygb3B0aW1pc2F0aW9ucyBzdWNoIGFzICJoYXBw eSBleWViYWxscy4iIEEgcmVsYXRlZCBzaWRlIGVmZmVjdCBpcyB0aGF0DQorY29waWVzIG9mIHRo ZSBzYW1lIGNvbnRlbnQgdmlld2VkIGF0IHRoZSBzYW1lIHRpbWUgdmlhIElQdjQgYW5kIElQdjYg bWF5IGJlIGRpZmZlcmVudCwNCitkdWUgdG8gbGF0ZW5jeSBpbiB0aGUgdW5kZXJseWluZyBkYXRh IHN5bmNocm9uaXphdGlvbiBwcm9jZXNzIHVzZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiBU aGlzIGVmZmVjdCBoYXMNCitpbiBmYWN0IGJlZW4gb2JzZXJ2ZWQgaW4gdGhlIHdpbGQgZm9yIGEg bWFqb3Igc29jaWFsIG5ldHdvcmsgc3VwcG9ydGluZyBkdWFsLXN0YWNrLjwvdD4NCisNCis8L3Nl Y3Rpb24+DQorDQogPHNlY3Rpb24gYW5jaG9yPSJjZG4iIHRpdGxlPSJDb250ZW50IERlbGl2ZXJ5 IE5ldHdvcmtzIj4NCiANCiA8dD5ETlMtYmFzZWQgdGVjaG5pcXVlcyBmb3IgZGl2ZXJ0aW5nIHVz ZXJzIHRvIENvbnRlbnQgRGVsaXZlcnkgTmV0d29yayAoQ0ROKSBwb2ludHMgb2YgcHJlc2VuY2Ug KFBPUHMpDQotd2lsbCB3b3JrIGZvciBJUHY2LCBpZiBBQUFBIHJlY29yZHMgYXJlIHByb3ZpZGVk IGFzIHdlbGwgYXMgQSByZWNvcmRzLiBJbiBnZW5lcmFsIHRoZSBDRE4gc2hvdWxkIGZvbGxvdw0K LXRoZSByZWNvbW1lbmRhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCwgZXNwZWNpYWxseSBieSBvcGVy YXRpbmcgYSBmdWxsIGR1YWwgc3RhY2sgc2VydmljZQ0KLWF0IGVhY2ggUE9QLiBBZGRpdGlvbmFs bHksIGVhY2ggUE9QIHdpbGwgbmVlZCB0byBoYW5kbGUgSVB2NiByb3V0aW5nIGV4YWN0bHkgbGlr ZSBJUHY0LA0KLWZvciBleGFtcGxlIHJ1bm5pbmcgQkdQNCsgPHhyZWYgdGFyZ2V0PSJSRkM0NzYw Ii8+IGlmIGFwcHJvcHJpYXRlLiA8L3Q+DQord2lsbCB3b3JrIGZvciBJUHY2LCBpZiBBQUFBIHJl Y29yZHMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBDRE4gYXMgd2VsbCBhcyBBIHJlY29yZHMuIEluIGdl bmVyYWwgdGhlIENETiBzaG91bGQgZm9sbG93DQordGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlz IGRvY3VtZW50LCBlc3BlY2lhbGx5IHRob3NlIGNvbnNpZGVyYXRpb25zIGluIDx4cmVmIHRhcmdl dD0ibXVsdGlzaXRlIi8+Li48L3Q+DQogDQogPHQ+Tm90ZSB0aGF0IGlmIGFuIElDUCBzdXBwb3J0 cyBJUHY2IGJ1dCBpdHMgZXh0ZXJuYWwgQ0ROIHByb3ZpZGVyIGRvZXMgbm90LCBpdHMgY2xpZW50 cyB3aWxsIGNvbnRpbnVlIHRvIHVzZQ0KIElQdjQgYW5kIGFueSBJUHY2LW9ubHkgY2xpZW50cyB3 aWxsIGhhdmUgdG8gdXNlIGEgdHJhbnNpdGlvbiBzb2x1dGlvbiBvZiBzb21lIGtpbmQuIFRoaXMg aXMNCi1ub3QgYSBkZXNpcmFibGUgc2l0dWF0aW9uLCBzaW5jZSB0aGUgSUNQJ3Mgd29yayB0byBz dXBwb3J0IElQdjYgd2lsbCBiZSB3YXN0ZWQuIFRoZSBjb252ZXJzZSBpcyBub3QNCi10cnVlOiBp ZiB0aGUgQ0ROIHN1cHBvcnRzIElQdjYgYnV0IHRoZSBJQ1AgZG9lcyBub3QsIGR1YWwtc3RhY2sg YW5kIElQdjYtb25seSBjbGllbnRzIHdpbGwNCi1vYnRhaW4gSVB2NiBhY2Nlc3MsIGFzc3VtaW5n IHRoZSBDRE4gcHJvdmlkZXIgYW5ub3VuY2VzIEFBQUEgRE5TIFJlc291cmNlIFJlY29yZHMuIDwv dD4NCi0NCi08dD5BbiBJQ1AgbWlnaHQgZmFjZSBhIGNvbXBsZXggc2l0dWF0aW9uLCBpZiBpdHMg Q0ROIHByb3ZpZGVyDQotc3VwcG9ydHMgSVB2NiBhdCBzb21lIFBPUHMgYnV0IG5vdCBhdCBvdGhl cnMuIElQdjYtb25seSBjbGllbnRzIGNvdWxkIG9ubHkgYmUgZGl2ZXJ0ZWQNCi10byBhIFBPUCBz dXBwb3J0aW5nIElQdjYuIFRoZXJlIGFyZSBhbHNvIHNjZW5hcmlvcyB3aGVyZSBhIGR1YWwtc3Rh Y2sgY2xpZW50IHdvdWxkIGJlIGRpdmVydGVkDQotdG8gYSBtaXh0dXJlIG9mIElQdjQgYW5kIElQ djYgUE9QcyBmb3IgZGlmZmVyZW50IFVSTHMsIGFjY29yZGluZyB0byB0aGUgQSBhbmQgQUFBQSBy ZWNvcmRzIHByb3ZpZGVkDQotYW5kIHRoZSBhdmFpbGFiaWxpdHkgb2Ygb3B0aW1pc2F0aW9ucyBz dWNoIGFzICJoYXBweSBleWViYWxscy4iIEEgcmVsYXRlZCBzaWRlIGVmZmVjdCBpcyB0aGF0DQot Y29waWVzIG9mIHRoZSBzYW1lIGNvbnRlbnQgdmlld2VkIGF0IHRoZSBzYW1lIHRpbWUgdmlhIElQ djQgYW5kIElQdjYgbWF5IGJlIGRpZmZlcmVudCwNCi1kdWUgdG8gbGF0ZW5jeSBpbiB0aGUgdW5k ZXJseWluZyBkYXRhIHN5bmNocm9uaXNhdGlvbiBwcm9jZXNzIHVzZWQgYnkgdGhlIENETi4gVGhp cyBlZmZlY3QgaGFzDQotaW4gZmFjdCBiZWVuIG9ic2VydmVkIGluIHRoZSB3aWxkIGZvciBhIG1h am9yIHNvY2lhbCBuZXR3b3JrIHN1cHBvcnRpbmcgZHVhbCBzdGFjay4NCi1UaGVzZSBjb21wbGlj YXRpb25zIGRvIG5vdCBhZmZlY3QgdGhlIHZpYWJpbGl0eSBvZiByZWx5aW5nIG9uIGEgZHVhbC1z dGFjayBDRE4sIGhvd2V2ZXIuIDwvdD4NCi0NCi08dD5UaGUgQ0ROIGl0c2VsZiBmYWNlcyByZWxh dGVkIGNvbXBsZXhpdHk6ICJBcyBJUHY2IHJvbGxzIG91dCwgaXQncyBnb2luZyB0byByb2xsIA0K LW91dCBpbiBwb2NrZXRzLCBhbmQgdGhhdCdzIGdvaW5nIHRvIG1ha2UgdGhlIHJvdXRpbmcgYXJv dW5kIGNvbmdlc3Rpb24gcG9pbnRzIHRoYXQgbXVjaCBtb3JlIA0KLWltcG9ydGFudCBidXQgYWxz byB0aGF0IG11Y2ggaGFyZGVyLCIgc3RhdGVkIEpvaG4gU3VtbWVycyBvZiBBa2FtYWkgaW4gMjAx MC4gDQotPC90Pg0KK25vdCBhIGRlc2lyYWJsZSBzaXR1YXRpb24sIHNpbmNlIHRoZSBJQ1AncyB3 b3JrIHRvIHN1cHBvcnQgSVB2NiB3aWxsIGJlIHdhc3RlZC4gPC90Pg0KKw0KKzx0PlRoZSBjb252 ZXJzZSBpcyBub3QgdHJ1ZTogaWYgdGhlIENETiBzdXBwb3J0cyBJUHY2IGJ1dCB0aGUgSUNQIGRv ZXMgbm90LCBkdWFsLXN0YWNrIGFuZCBJUHY2LW9ubHkgY2xpZW50cyB3aWxsDQorb2J0YWluIElQ djYgYWNjZXNzLCBhc3N1bWluZyB0aGUgQ0ROIHByb3ZpZGVyIGFubm91bmNlcyBBQUFBIEROUyBS ZXNvdXJjZSBSZWNvcmRzIGZvciB0aGUgSUNQJ3MgcHJvcGVydHkuICBJbiBmYWN0LA0KK0NETnMg YW5kIHNpbWlsYXIgc2VydmljZXMgY2FuIGVuYWJsZSBhbiBJQ1AgdG8gbWFrZSBjb250ZW50IGF2 YWlsYWJsZSBvdmVyIElQdjYNCit1c2luZyB0aGUgYXBwcm9hY2ggZGVzY3JpYmVkIGluIDx4cmVm IHRhcmdldD0icHJveHkiLz4uICBTb21lIG9mIHRoZXNlIHNlcnZpY2VzIG1heSBhbHNvDQorYmUg YWJsZSB0byBwcm92aWRlIGltcHJvdmVkIHNjYWxlIGFuZCByZWxpYWJpbGl0eSBieSByb3V0aW5n IGNsaWVudHMgYXJvdW5kIG5ldHdvcmsgaXNzdWVzLjwvdD4NCiANCiA8L3NlY3Rpb24+IDwhLS0g Y2RuIC0tPg0KIA0KKzwvc2VjdGlvbj4gPCEtLSBjb21wbGV4IC0tPg0KKw0KKw0KKw0KIDxzZWN0 aW9uIGFuY2hvcj0icGFydG5lciIgdGl0bGU9IkJ1c2luZXNzIFBhcnRuZXJzIj4NCiA8dD5BcyBu b3RlZCBlYXJsaWVyLCBpdCBpcyBpbiBhbiBJQ1AncyBvciBBU1AncyBiZXN0IGludGVyZXN0cyB0 aGF0IHRoZWlyIHVzZXJzIGhhdmUgZGlyZWN0DQogSVB2NiBjb25uZWN0aXZpdHksIHJhdGhlciB0 aGFuIGluZGlyZWN0IElQdjQgY29ubmVjdGl2aXR5IHZpYSBkb3VibGUgTkFULiBJZiB0aGUgSUNQ IG9yIEFTUCANCkBAIC02MTYsNyArNzgwLDcgQEAKIGZvciBjcmVhdGluZyBESENQIGFuZCBETlMg Y29uZmlndXJhdGlvbnMuIFRoZXJlIGlzIHNpZ25pZmljYW50IG92ZXJsYXAgaGVyZSB3aXRoIHRo ZQ0KIHRvb2xzIGludm9sdmVkIGluIHNpdGUgcmVudW1iZXJpbmcgPHhyZWYgdGFyZ2V0PSJJLUQu amlhbmctNnJlbnVtLWVudGVycHJpc2UiLz4uIDwvdD4NCiANCi08dD5BcyBmYXIgYXMgcG9zc2li bGUsIGhvd2V2ZXIsIG11dHVhbCBkZXBlbmRlbmN5IGJldHdlZW4gSVB2NCBhbmQgSVB2NiBvcGVy YXRpb25zIHNob3VsZCBiZSBhdm9pZGVkLg0KKzx0PkFzIGZhciBhcyBwb3NzaWJsZSwgaG93ZXZl ciwgbXV0dWFsIGRlcGVuZGVuY3kgYmV0d2VlbiBJUHY0IGFuZCBJUHY2IGF2YWlsYWJpbGl0eSBz aG91bGQgYmUgYXZvaWRlZC4NCiBBIGZhaWx1cmUgb2Ygb25lIHNob3VsZCBub3QgY2F1c2UgYSBm YWlsdXJlIG9mIHRoZSBvdGhlci4gT25lIHByZWNhdXRpb24gdG8gYXZvaWQgdGhpcyB3b3VsZCBi ZSBmb3INCiBiYWNrLWVuZCBzeXN0ZW1zIHN1Y2ggYXMgbmV0d29yayBtYW5hZ2VtZW50IGRhdGFi YXNlcyB0byBiZSBkdWFsIHN0YWNrZWQgYXMgc29vbiBhcyBjb252ZW5pZW50Lg0KIEl0IHNob3Vs ZCBhbHNvIGJlIHBvc3NpYmxlIHRvIHVzZSBJUHY0IGNvbm5lY3Rpdml0eSB0byByZXBhaXIgSVB2 NiBjb25maWd1cmF0aW9ucywgYW5kIA0KQEAgLTYzMCw2ICs3OTQsMTYgQEAKIGEgbWFuYWdlbWVu dCB0b29sIHRoYXQgbWFuYWdlcyBJUHY2IGJ1dCBpdHNlbGYgcnVucyBvbmx5IG92ZXIgSVB2NCB3 b3VsZCBwcm92ZSBkaXNhc3Ryb3VzDQogb24gdGhlIGRheSB0aGF0IElQdjQgaXMgc3dpdGNoZWQg b2ZmLiA8L3Q+DQogDQorPHQ+QW4gSUNQIHNob3VsZCBlbnN1cmUgdGhhdCBhbnkgZW5kLXRvLWVu ZCBhdmFpbGFiaWxpdHkgbW9uaXRvcmluZyBzeXN0ZW1zIGFyZSB1cGRhdGVkDQordG8gbW9uaXRv ciBkdWFsLXN0YWNrZWQgc2VydmVycyBvdmVyIGJvdGggSVB2NCBhbmQgSVB2Ni4gIEEgcGFydGlj dWxhciBjaGFsbGVuZ2UgaGVyZSBtYXkgYmUgDQorbW9uaXRvcmluZyBzeXN0ZW1zIHJlbHlpbmcg b24gRE5TIG5hbWVzIGFzIHRoaXMgbWF5IHJlc3VsdCBpbiBtb25pdG9yaW5nIG9ubHkNCitvbmUg b2YgSVB2NCBvciBJUHY2LCByZXN1bHRpbmcgaW4gYSBsb3NzIG9mIHZpc2liaWxpdHkgdG8gZmFp bHVyZXMgaW4gDQorbmV0d29yayBjb25uZWN0aXZpdHkgb3ZlciBlaXRoZXIgYWRkcmVzcyBmYW1p bHkuPC90Pg0KKw0KKzx0PkFzIG1lbnRpb25lZCBhYm92ZSwgaXQgd2lsbCBhbHNvIGJlIG5lY2Vz c2FyeSBmb3IgYW4gSUNQIHRvIHByb3ZpZGUgSVB2NiBjb25uZWN0aXZpdHkNCitmb3IgaXRzIG9w ZXJhdGlvbnMgYW5kIHN1cHBvcnQgc3RhZmYsIGluIGFkZGl0aW9uIHRvIGl0cyBzZXJ2ZXJzLjwv dD4NCisNCisNCiA8L3NlY3Rpb24+IDwhLS0gb2FtIC0tPg0KIA0KIA0KQEAgLTY0MCw3ICs4MTQs OSBAQAogdGhhdCBjb3VsZCBleGlzdCBpbiBJUHY2LiBIb3dldmVyLCBlc3NlbnRpYWxseSBldmVy eSB0aHJlYXQgdGhhdCBleGlzdHMgZm9yIElQdjQgZXhpc3RzIG9yIHdpbGwNCiBleGlzdCBmb3Ig SVB2NiwgdG8gYSBncmVhdGVyIG9yIGxlc3NlciBleHRlbnQuIEl0IGlzIGVzc2VudGlhbCB0byB1 cGRhdGUgZmlyZXdhbGxzLCBpbnRydXNpb24gZGV0ZWN0aW9uDQogc3lzdGVtcywgZGVuaWFsIG9m IHNlcnZpY2UgcHJlY2F1dGlvbnMsIGFuZCBzZWN1cml0eSBhdWRpdGluZyB0ZWNobm9sb2d5IHRv IGZ1bGx5IHN1cHBvcnQgSVB2Ni4NCi1PdGhlcndpc2UsIElQdjYgd2lsbCBiZWNvbWUgYW4gYXR0 cmFjdGl2ZSB0YXJnZXQgZm9yIGF0dGFja2Vycy4gPC90Pg0KK090aGVyd2lzZSwgSVB2NiB3aWxs IGJlY29tZSBhbiBhdHRyYWN0aXZlIHRhcmdldCBmb3IgYXR0YWNrZXJzLiAgSVB2NiBtYWx3YXJl IGhhcyBiZWVuIG9ic2VydmVkIGluIA0KK3RoZSB3aWxkOiBmb3IgZXhhbXBsZSwgbWFsd2FyZSB0 aGF0IGZvbGxvd3MgRE5TIG5hbWVzIGFuZCB1c2VzIHNvbWUgY2xpZW50IE9TIEhUVFAgbGlicmFy aWVzIA0KK21heSBhdXRvbWF0aWNhbGx5IHN3aXRjaCB0byBhdHRhY2tpbmcgYW4gSUNQIG92ZXIg SVB2NiBhcyBzb29uIGFzIEFBQUEgcmVjb3JkcyBhcmUgYWRkZWQuPC90Pg0KIA0KIA0KIDx0Pldo ZW4gbXVsdGlwbGUgUEEgcHJlZml4ZXMgYXJlIGluIHVzZSBhcyBtZW50aW9uZWQgaW4gPHhyZWYg dGFyZ2V0PSJhZGRyIi8+LCBmaXJld2FsbCBydWxlcw0KQEAgLTY2MSwxMSArODM3LDE0IEBACiBp biBhY2NvcmRhbmNlIHdpdGggPHhyZWYgdGFyZ2V0PSJSRkM0ODkwIi8+OyBpbiBwYXJ0aWN1bGFy LCBQYWNrZXQgVG9vIEJpZyBtZXNzYWdlcywgd2hpY2ggYXJlDQogZXNzZW50aWFsIGZvciBQTVRV IGRpc2NvdmVyeSwgbXVzdCBub3QgYmUgYmxvY2tlZC4gPC90Pg0KIA0KLTx0PlNjYW5uaW5nIGF0 dGFja3MgdG8gZGlzY292ZXIgdGhlIGV4aXN0ZW5jZSBvZiBob3N0cyBhcmUgbXVjaCBsZXNzDQot bGlrZWx5IHRvIHN1Y2NlZWQgZm9yIElQdjYgdGhhbiBmb3IgSVB2NCA8eHJlZiB0YXJnZXQ9IlJG QzUxNTciLz4uIEhvd2V2ZXIsDQotdGhpcyBpcyBvbmx5IHRydWUgaWYgSVB2NiBob3N0cyBhcmUg Y29uZmlndXJlZCB3aXRoIGludGVyZmFjZSBpZGVudGlmaWVycw0KLXRoYXQgYXJlIGhhcmQgdG8g Z3Vlc3M7IGZvciBleGFtcGxlLCBpdCBpcyBub3QgYWR2aXNhYmxlIHRvIG1hbnVhbGx5IGNvbmZp Z3VyZSBob3N0cw0KLXdpdGggY29uc2VjdXRpdmUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIHN0YXJ0 aW5nIGZyb20gIjEiLiA8L3Q+DQorPHQ+QnJ1dGUtZm9yY2Ugc2Nhbm5pbmcgYXR0YWNrcyB0byBk aXNjb3ZlciB0aGUgZXhpc3RlbmNlIG9mIGhvc3RzIGFyZSBtdWNoIGxlc3MNCitsaWtlbHkgdG8g c3VjY2VlZCBmb3IgSVB2NiB0aGFuIGZvciBJUHY0IDx4cmVmIHRhcmdldD0iUkZDNTE1NyIvPi4g VGhpcyBzaG91bGQgbm90DQorbHVsbCBhbiBJQ1AgaW50byBhIGZhbGwgc2Vuc2Ugb2Ygc2VjdXJp dHksIGFzIHZhcmlvdXMgbmFtaW5nIGNvbnZlbnRpb25zIGNhbiByZXN1bHQNCitpbiBJUHY2IGFk ZHJlc3Mgc3BhY2UgYmVpbmcgcHJlZGljdGFibGUgb3IgdmlzaWJsZS4gIEluIHRoZSBleHRyZW1l IGNhc2UsIElQdjYgaG9zdHMNCittaWdodCBiZSBjb25maWd1cmVkIHdpdGggaW50ZXJmYWNlIGlk ZW50aWZpZXJzIHRoYXQgYXJlIGVhc3kgdG8gZ3Vlc3M7IGZvciBleGFtcGxlLCANCitob3N0cyBv ciBzdWJuZXRzIG51bWJlcmVkIHdpdGggY29uc2VjdXRpdmUgaW50ZXJmYWNlIGlkZW50aWZpZXJz IHN0YXJ0aW5nIGZyb20gIjEiDQorbWF5IGJlIG11Y2ggZWFzaWVyIHRvIGZpbmQuICBTaW1pbGFy bHksIGF0dGFja2VycyBtaWdodCBmaW5kIElQdjYgYWRkcmVzc2VzDQoraW4gbG9ncywgcGFja2V0 IHRyYWNlcywgRE5TIHJlY29yZHMsIG9yIGVsc2V3aGVyZS4gPC90Pg0KIA0KIDx0PlRyYW5zcG9y dCBMYXllciBTZWN1cml0eSB2ZXJzaW9uIDEuMiA8eHJlZiB0YXJnZXQ9IlJGQzUyNDYiLz4gYW5k IGl0cyBwcmVkZWNlc3NvcnMgd29yaw0KIGNvcnJlY3RseSB3aXRoIFRDUCBvdmVyIElQdjYsIG1l YW5pbmcgdGhhdCBIVFRQUy1iYXNlZCBzZWN1cml0eSBzb2x1dGlvbnMgYXJlIGltbWVkaWF0ZWx5 DQpAQCAtNzAxLDYgKzg4MCw3IEBACiBUcmVudCBMbG95ZCwNCiBKb2huIE1hbm4sDQogTWljaGFl bCBOZXdiZXJ5LA0KK0VyaWsgTnlncmVuLA0KIEFydHVybyBTZXJ2aW4sDQogTWFyayBTbWl0aCwN CiANCg== --f46d04389099e6494004c6cb2942-- From bzeeb-lists@lists.zabbadoz.net Wed Aug 8 23:23:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82F911E80E2 for ; Wed, 8 Aug 2012 23:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSi+CfR+v5jg for ; Wed, 8 Aug 2012 23:23:36 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 121D511E80DC for ; Wed, 8 Aug 2012 23:23:36 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 74BD825D39FD; Thu, 9 Aug 2012 06:23:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 97F31BE850B; Thu, 9 Aug 2012 06:23:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id vcKGH3yVmbzj; Thu, 9 Aug 2012 06:23:31 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BAD05BE850A; Thu, 9 Aug 2012 06:23:29 +0000 (UTC) Date: Thu, 9 Aug 2012 06:23:28 +0000 (UTC) From: "Bjoern A. Zeeb" To: v6ops WG In-Reply-To: <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 06:23:37 -0000 On Wed, 8 Aug 2012, Fred Baker (fred) wrote: > .... > For my money, this document should be constrained to talking about the 464XLAT solution and the cases in which those providers using it find it useful. Any other discussion, in my opinion, mostly confuses the discussion. s/providers/people/ I am not a provider, I still find it useful. > > At this point, in the opinion of this chair, any textual changes in the document should be for the purposes of clarifying the 464XLAT deployment strategy and its uses of the technologies it specifies, or the operational utility of it. Discussion of technologies that would not be used in a 464XLAT network is out of place. Let me add what might have been forwarded in some ways. Currently the BCP Scenario only talks about IPv6-only *access* networks. Now depending on how you define "access" this might be true. However running an application requiring IPv4 sockets on my IPv6-only desktop kernel does not mean that my local network might not otherwise be dual stacked but just that my end-node is IPv6-only transport and this technology should allow me to do the translation purely in user space. So another use case is There are IPv4-only applications running on a node with an IPv6-only kernel wanting to communicate with other (IPv4) nodes. IMHO this is currently the only transition technology allowing me to do this, thus helping to push the IPv6-only boundry further out without killing legacy applications. Now this is the developers point of view and not the operators point of view. I am not asking for a complete substitution of "access" in the draft;) I just want to kill any further tunneling discussions etc. They simply are not applicable/do not work in this case anymore. Once I can prove my point with a working implementation I'll be happy to update this one, but this needs to go out and we need to move on, so I'll postpone. /bz PS: I'll send a diff latest during the weekend as there are a couple of proof reading things and inconsistencies in exmaples as well as invalid IPv6 addresses but this is only editorial not functional changes. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From leo.liubing@huawei.com Wed Aug 8 23:55:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD63611E8163 for ; Wed, 8 Aug 2012 23:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEsoCNeu3YKy for ; Wed, 8 Aug 2012 23:55:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1D11E809C for ; Wed, 8 Aug 2012 23:55:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB34341; Wed, 08 Aug 2012 22:55:31 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 23:52:06 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 23:52:04 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 14:52:00 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNc5SEZaOo7GeIYE+zCAtJF8/cLJdQ3UmQ Date: Thu, 9 Aug 2012 06:52:00 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452932DA39@szxeml509-mbs> References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> In-Reply-To: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 06:55:33 -0000 Support this draft forward. Some comments: In section 4 "Arranging IPv6 Connectivity" > There are, in theory, two ways to obtain IPv6 connectivity to the Interne= t. ... Native...Tunnel... Although double translation doesn't concern ICPs, maybe it's better to ment= ion it ? Since there might be confusion that translation was just missed to= be considered. In section 5.1, the last paragraph We have two auto-config methods(DHCP/SLAAC) in IPv6, which is one of the mo= st significant differences between IPv4. So, it may be worth to mention the= DHCP/SLAAC co-existence issue. The issue has been documented by [RFC5887] = and [6reum-gap-analysis], which could be references. In section 12, second paragraph > There is significant overlap here with the tools involved in site renumbe= ring [I-D.jiang-6renum-enterprise]. [6renum-enterprise] only mentioned the tool, a brief detailed discussion ab= out IPAM tool was in [6renum-gap-analysis], however, it may not be sufficie= nt for OAM consideration. Maybe just simply deleting the reference is bette= r. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker (fred) Sent: Monday, August 06, 2012 1:30 PM To: v6ops@ietf.org Cc: V6ops Chairs; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-icp-guidance WGLC This is to open a two week Working Group last Call on=20 http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6 Guidance for Internet Content and Application Service Providers", Brian Carpenter, Sheng Jiang, 10-Jul-12 Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulness t= o its target audience. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Aug 9 01:23:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BA521F8769 for ; Thu, 9 Aug 2012 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.181 X-Spam-Level: X-Spam-Status: No, score=-101.181 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k6rv1Ce+HE6 for ; Thu, 9 Aug 2012 01:23:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 683BD21F8767 for ; Thu, 9 Aug 2012 01:23:13 -0700 (PDT) Received: by eaai11 with SMTP id i11so50648eaa.31 for ; Thu, 09 Aug 2012 01:23:13 -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=Dr3X5f3YjVKaOgi9A0OVm4j1hP/ZIGQeU0HkDG0aMfU=; b=BmwqRsCruyMK/rexRvhpl2+3fFDwlFuXC2raEWxxdO+MU4KKOk3peqkejTwiTaqBkB oUfJ8wyr8RVYOF20hcj5lrQHzeeNqgaHWrJP1RCtrLH//7scMyX1zQCrbfAiw33Mpat3 knjgnJ4UGWM6buQIgStXU1jK85MHKLnHQ4G/qjiprX1eMEEyGMGyIfHTHdx8bDcrEirZ gjRIZ5pQbbk1ek9bhE6ZaA1hVs0oGQNzv5gSZ1pd83vd0TqBATKDg/An09v1wcdLuWdx XiQ5g5JBW+KK7ku8GlqVebHDk4eQl4yBRUEvbE1SZEaK/IagXoXsmFQTKVr9kHzcGHbm ol7w== Received: by 10.14.213.137 with SMTP id a9mr3845625eep.38.1344500593078; Thu, 09 Aug 2012 01:23:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-33.as13285.net. [2.102.216.33]) by mx.google.com with ESMTPS id e7sm1437695eep.2.2012.08.09.01.23.10 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 01:23:11 -0700 (PDT) Message-ID: <50237375.8060702@gmail.com> Date: Thu, 09 Aug 2012 09:23:17 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Nygren References: <5F52A5BB-36F7-4CF9-9639-960C65ADFD4E@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , "v6ops@ietf.org" , V6ops Chairs Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 08:23:19 -0000 Erik, Thanks for the careful review. You raise some good points but we will have to analyse your proposed changes carefully before replying in detail. Regards Brian On 09/08/2012 02:29, Erik Nygren wrote: > I took a pass through this draft and had enough suggestions that > it was easiest to just pass them along as a patch/diff against the > -02.xml source > (see attached). > > In general this feels like it will be very useful as a starting points > for people > at Internet content and application providers looking to kick off an > IPv6 effort. > As discussed on some of the other threads, I think its important that we > keep this focused on recommendations that will be useful to people > implementing IPv6 today, rather than on technologies that are still > under development. > > Some of the proposed changes include: > > * Proposed some compromise text in the "IPv6 Infrastructure" section > on the PI vs PA address space topic discussed in the other thread. > It feels like we should be giving concrete recommendations that are > useful to ICPs now, but while still leaving doors open for the > future. > > * Add a note that support operations and support staff will generally > also need to have IPv6 connectivity provisioned. (Outside of universities, > external server and staff network connectivity and environments are > often independent.) > > * Renamed the "Proxy" section to "Surrogate" as what is being described > there is explicitly a reverse proxy (surrogate) setup. > > * Added more context and details and gotchas to the "DNS" section. > This seems to be one of the top areas where ICPs seem to get > themselves in trouble (perhaps because it seems like it's > a "just do it"). > > * Added some notes on security (such as for host and network device > firewalls) at appropriate points in the doc as ICPs especially > shouldn't be thinking of these as an afterthought. > > * Added some more notes into the Application Layer section, > such as some particular notes about logging and testing, > as this seems to be another area where things are often missed. > > * Split up the CDN section into a broader section on "Complex Sites > and Applications". About half of the existing CDN section was more generally > applicable to ICPs with multiple POPs, so "Distributed Locations" > got its own subsection here. I also added a subsection on > "embeded resources" reminding ICPs to check that a rich > site has more than just the base page available over IPv6. > (I also took out the reference to my employer > as that quote was from a few years ago and may not > be generally helpful.) > > * Fixed some typos and made a few other edits, as well as > some others that I may have missed in the summary above. > > I hope this is useful to folks. I'm happy to discuss any > of my proposed changes in more detail. > > Erik > > > --------------------- > > All opinions expressed herein are my own and my not reflect those of > my employer. > > > > > > On Mon, Aug 6, 2012 at 12:29 AM, Fred Baker (fred) wrote: >> This is to open a two week Working Group last Call on >> >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >> "IPv6 Guidance for Internet Content and Application Service Providers", >> Brian Carpenter, Sheng Jiang, 10-Jul-12 >> >> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Thu Aug 9 02:11:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856B521F8691 for ; Thu, 9 Aug 2012 02:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1ggbbAVe27W for ; Thu, 9 Aug 2012 02:11:45 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8190D21F8690 for ; Thu, 9 Aug 2012 02:11:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id A4A7D70000EF; Thu, 9 Aug 2012 11:11:43 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id 2324E70000E5; Thu, 9 Aug 2012 11:11:42 +0200 (CEST) X-SFR-UUID: 20120809091143144.2324E70000E5@msfrf2204.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Thu, 9 Aug 2012 11:11:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 09:11:48 -0000 2012-08-08 18:57, Fred Baker (fred) : >=20 > On Aug 8, 2012, at 3:29 AM, R=E9mi Despr=E9s wrote: >=20 >> b. As also discussed, the applicability statement should clarify = that, in access networks where both NAT64 and DS-Lite are available, = using DS-Lite should be recommended (better IPv4 transparency). >> For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 = would be enough for me. >=20 > > As I said earlier, it is beyond me why an applicability statement or a = technical description of one technology is constrained to discuss = another. >=20 > Let me repeat something that has been pointed out by others in this = thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, = ds-lite, an MPLS LSP, or whatever other kind of tunnel might come to = mind - one does not provide an end to end IPv4 infrastructure. The = solution can translate to IPv6 and back to IPv4, or it can translate = IPv4 to IPv4 at one end of the tunnel or another, but one does not avoid = translation of IPv4 packets. The only way one avoids translation - at = all - is to send native IPv6 packets and deliver them to one's = destination. That's kind of the point here, as Cameron pointed out in = the talk last week. Strictly speaking, the second sentence isn't accurate because a = stateless v4/v6 tunneling solution, e.g. that being currently specified = in Softwire, does provide e2e v4 service. (No e2e way to notice that = part of the path includes one or several IPv4 tunnels over IPv6.) OTOH, I agree that, in the limited context of STATEFUL solutions (i.e. = including port translation), e2e transparency is never complete, and = that DS-Lite is in this category.=20 The only point point here is that DS-Lite always preserves DF bits, and = thus maintains compatibility with RFC 4821, while 464XLAT doesn't.=20 > For my money, this document should be constrained to talking about the = 464XLAT solution and the cases in which those providers using it find it = useful. Any other discussion, in my opinion, mostly confuses the = discussion. Note that DNS64 is discussed in the draft although it isn't part of the = 464XLAT specification. The criterion to mention or not a different = technology seems therefore to be more "is it useful" than "should never = be done", which makes sense. Letting readers believe that 464XLAT is THE best choice even where = service providers choose to support not only NAT64 CGN but also DS-Lite = remains misleading AFAIK.=20 I can't understand why it would be such a big deal to clarify that, even = in the limited context of stateful solutions, it is only for networks = that don't support more transparent transition solutions that 464XLAT is = THE recommended solution.=20 Regards, RD >=20 > > At this point, in the opinion of this chair, any textual changes in = the document should be for the purposes of clarifying the 464XLAT = deployment strategy and its uses of the technologies it specifies, or = the operational utility of it. Discussion of technologies that would not = be used in a 464XLAT network is out of place. From phdgang@gmail.com Thu Aug 9 03:04:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2D21F86B5 for ; Thu, 9 Aug 2012 03:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWZzC8618W7j for ; Thu, 9 Aug 2012 03:04:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A750221F8683 for ; Thu, 9 Aug 2012 03:04:28 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so237897vcb.31 for ; Thu, 09 Aug 2012 03:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QXfvZxMiNEtfIZVPTWR4vU9WElhZ4TRBKMUpJHvMpB4=; b=AcdoClQuofa40L6y4YRiUnSI17ZK0zVYExpJITQrfGfOArT6Z18t+jV8tbIOdzi6si fKATJqe4+4ZzOsYht4BC5HDe3fg0mIRzd7o8JTHj3HP3F/IgCcti5zQie9bsceFnA2N9 idTia5VLA0GM2khD6K9mGfhE8tpCBbhwY/LVFRKa+cKx4940B6ZNjaWOauWLifH03cO+ lV9hboWwMENbe9tE/dZMRrQFwfRqCBos7LzsJTXe+FSYf4vjLASoOeDaU3598oX1bSNM K47bFei9J45E393VS3p06IYXXojOWCnxm/FQyoaiCH0CR7Y24tmgF01f5dihPjQxBzF/ Y+Rw== MIME-Version: 1.0 Received: by 10.52.22.50 with SMTP id a18mr14325342vdf.60.1344506668031; Thu, 09 Aug 2012 03:04:28 -0700 (PDT) Received: by 10.58.79.34 with HTTP; Thu, 9 Aug 2012 03:04:27 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Thu, 9 Aug 2012 18:04:27 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 10:04:29 -0000 Hello Remi, 2012/8/9, R=E9mi Despr=E9s : > > 2012-08-08 18:57, Fred Baker (fred) : > >> >> On Aug 8, 2012, at 3:29 AM, R=E9mi Despr=E9s wrote: >> >>> b. As also discussed, the applicability statement should clarify that, = in >>> access networks where both NAT64 and DS-Lite are available, using DS-Li= te >>> should be recommended (better IPv4 transparency). >>> For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would >>> be enough for me. >> >> >> As I said earlier, it is beyond me why an applicability statement or a >> technical description of one technology is constrained to discuss >> another. >> >> Let me repeat something that has been pointed out by others in this >> thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, >> ds-lite, an MPLS LSP, or whatever other kind of tunnel might come to min= d >> - one does not provide an end to end IPv4 infrastructure. The solution c= an >> translate to IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at >> one end of the tunnel or another, but one does not avoid translation of >> IPv4 packets. The only way one avoids translation - at all - is to send >> native IPv6 packets and deliver them to one's destination. That's kind o= f >> the point here, as Cameron pointed out in the talk last week. > > Strictly speaking, the second sentence isn't accurate because a stateless > v4/v6 tunneling solution, e.g. that being currently specified in Softwire= , > does provide e2e v4 service. (No e2e way to notice that part of the path > includes one or several IPv4 tunnels over IPv6.) I like the statement as you said earlier, that is "more transparent". NAT44 is still needed on CPE even in encapsulation case. > OTOH, I agree that, in the limited context of STATEFUL solutions (i.e. > including port translation), e2e transparency is never complete, and that > DS-Lite is in this category. > The only point point here is that DS-Lite always preserves DF bits, and t= hus > maintains compatibility with RFC 4821, while 464XLAT doesn't. RFC4821 argument was already documented in the proposal. I guess that is sufficient to signal the fact. Adding much may not help the discussion IMHO. > >> For my money, this document should be constrained to talking about the >> 464XLAT solution and the cases in which those providers using it find it >> useful. Any other discussion, in my opinion, mostly confuses the >> discussion. > > Note that DNS64 is discussed in the draft although it isn't part of the > 464XLAT specification. DNS64 is closely related to and discussed in RFC6146. Therefore, it can't be a justification we need to do more on different technology. >The criterion to mention or not a different > technology seems therefore to be more "is it useful" than "should never b= e > done", which makes sense. > > Letting readers believe that 464XLAT is THE best choice even where servic= e > providers choose to support not only NAT64 CGN but also DS-Lite remains > misleading AFAIK. How the misleading should be? We even do 4rd to overcome ACL incompatibilities in DS-Lite kind of solution. That is a trade-off actually, i.e. "more transparent" vs "more compabilities". It's worth another draft to argue that. I really want the draft focus specific discussion on 464xlat features. > I can't understand why it would be such a big deal to clarify that, even = in > the limited context of stateful solutions, it is only for networks that > don't support more transparent transition solutions that 464XLAT is THE > recommended solution. Considering above, I hope you could accept and let us move-on Many thanks Gang > Regards, > RD > > > >> >> >> At this point, in the opinion of this chair, any textual changes in the >> document should be for the purposes of clarifying the 464XLAT deployment >> strategy and its uses of the technologies it specifies, or the operation= al >> utility of it. Discussion of technologies that would not be used in a >> 464XLAT network is out of place. > From markzzzsmith@yahoo.com.au Thu Aug 9 03:10:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F1821F8683 for ; Thu, 9 Aug 2012 03:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7wnINZJujXn for ; Thu, 9 Aug 2012 03:10:11 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by ietfa.amsl.com (Postfix) with SMTP id AC5A321F85F4 for ; Thu, 9 Aug 2012 03:10:07 -0700 (PDT) Received: from [98.139.52.193] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 10:10:04 -0000 Received: from [98.139.52.170] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 10:10:04 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 10:10:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 773739.38350.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 19368 invoked by uid 60001); 9 Aug 2012 10:10:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344507004; bh=04hyRcqKTznCqkjMAU0O+Zt729xXPwM9sdBDmsG1rHU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Lz9GUhuzrNNGQSp8uTk6IyFlLu0nrH9TLzlJBJDq7unoCSSnZ9oGWS8PV/bQYY8eLIpJhXdkAHVhgcnxO5c6Ui4xVA3AhJLMfn4XJyYcXaducxuwnJSdQExh2AvbRcGGbFSEwNAIWbrAvIe18vC1bDR33pzBtj51yfOP2fyOUCE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z3wF7T/BGrn0GeIDHyJYf6DQD/Px5pezURLzkCY8p2jH86ipPesoss+s651QSDpzGDYLzSf3eEfmSbPwgcocCQ+VismVo/odga7BlRKJ9u2AfUkaelN2xhZ1FV3fRVrjAg4xPCwjt7LK+u7/LXcd58JEnjyUMks1iPSJ68FGoY4=; X-YMail-OSG: biPiwPMVM1lQr9zCjXoqorAOygwyKS.n3m0BeBYmqtve3hd LLAawt5FNN6HOg8GP64i6qsQBODJMCTfp7O10B.SqWBBB_wCTRH.FcR6aUmZ wIm5PLJWB1RorukdqPiLlwdGceubyxxdZR8a2RKpL1WDeE.O1EVyoiSh8ljX j25cC025XzUeHfGoP6JkewyLBNtWglB._nKlWA6ZMs79cK2K_SaFAErbD8tQ K6sMFTTR42FYxRTSDRZIi0Wxb9_b.tllS7hBjCWj..urjlB1GRDwqNXgWf9o 7qDCYhiOpd34Rz1Zo6OJFQdMtethl2gSxDSPXxcEwDceyXwu.FBJEiZ263UB wwfYEeigrAk2yaWCt4U62QUoMRMZBI0jJNXZoSQCOIsoDNebHafGBv7.VmgR b5f.Rz22M1_neMArSOtaEEmlAUtI3UgCJkKoA4yAtC92zBxQMzhjkWYVdkOs E.FGMj0AqlCDa1QnDVpa14nvd_oE0FVnm2mx8D_ehKyYtSmUAfpme6v4acwH SI4J5Y69kpN2lMy5LZrCIMPSLOnw3SDu1eLaAWd.eZnxXmN_IW17aQyEcxmw 1MafHymaW7ml2wnkmSzs5BxGPFf7Ob3ldKVs.Xvg0uAHFKhwxHggH5DM6TjN 9b6c- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 03:10:04 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> Message-ID: <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 03:10:04 -0700 (PDT) From: Mark ZZZ Smith To: Philip Matthews , Gert Doering , "sthaug@nethelp.no" , "mbehring@cisco.com" , "evyncke@cisco.com" In-Reply-To: <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 10:10:12 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Philip Matthews =0A> To: Gert Doering ; sthaug@nethelp.no= =0A> Cc: "v6ops@ietf.org list" =0A> Sent: Thursday, 9 Augus= t 2012 7:26 AM=0A> Subject: Re: [v6ops] about LLAs pros/cons static routing= - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidel= ines=0A> =0A>G ert and Stiener:=0A> =0A> =0A> Thanks Gert for your comment = about DNS. That is a new comment that I had not =0A> previously captured.= =0A>=A0=0A=0ADepending on how visible you want your traceroute information = to be one, one thing you could do would be use static link local addresses = that are unique across the whole of your local network, and then put them i= n your local 0.8.e.f.ip6.arpa. subdomain.=0A=0AFor example,=A0=0A=0A-----[f= e80::1][fe80::2]----[fe80::3][fe80::4]-----[fe80::5] X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40C621F86A0 for ; Thu, 9 Aug 2012 03:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.174 X-Spam-Level: X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbFuZhnVAciL for ; Thu, 9 Aug 2012 03:47:44 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4CA421F8687 for ; Thu, 9 Aug 2012 03:47:43 -0700 (PDT) Received: by eaai11 with SMTP id i11so98494eaa.31 for ; Thu, 09 Aug 2012 03:47:43 -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=/UVZTWbcxymrxIFD45fg3sXV7aGhVvfuVberK2YTiyM=; b=USM/q+xqqIBtMY/y00AqDceWzQHbMm37ZdlXLnOdGQECu7NlINycTd22F7T6ji5Hti qv7SMRN63FrP74V/Vj7Islt0Yfa8CXyvgcNXCRbdxcvs3oVa8y0nt8cl5EyK2XiAhJM7 t5QtBPQpF1wJUNPLnDFz2HqW65tqjqR0KPrARAzGiNw0ScxzDr2kswi7YYiRF79CbNHl 57bMmaiwcs4ilC8LHf77RuNnJvco1D/jRz1BhxO9SOEwf1Foj5YLU3Efk7u+NeVS/ndz rCPjjMPP68pvtimVBXeQoSTEpXjluZ0iNGxSViHUEH/ouFFzpQDPhRsIHkphoiOOLM+0 YeOQ== Received: by 10.14.179.71 with SMTP id g47mr26996329eem.21.1344509262977; Thu, 09 Aug 2012 03:47:42 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-33.as13285.net. [2.102.216.33]) by mx.google.com with ESMTPS id 45sm2401615eed.17.2012.08.09.03.47.40 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 03:47:42 -0700 (PDT) Message-ID: <50239553.3010206@gmail.com> Date: Thu, 09 Aug 2012 11:47:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org list" , "mbehring@cisco.com" , Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 10:47:44 -0000 On 09/08/2012 11:10, Mark ZZZ Smith wrote: > Hi, > > > ----- Original Message ----- >> From: Philip Matthews >> To: Gert Doering ; sthaug@nethelp.no >> Cc: "v6ops@ietf.org list" >> Sent: Thursday, 9 August 2012 7:26 AM >> Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines >> >> G ert and Stiener: >> >> >> Thanks Gert for your comment about DNS. That is a new comment that I had not >> previously captured. >> > > Depending on how visible you want your traceroute information to be one, one thing you could do would be use static link local addresses that are unique across the whole of your local network, and then put them in your local 0.8.e.f.ip6.arpa. subdomain. > > For example, > > -----[fe80::1][fe80::2]----[fe80::3][fe80::4]-----[fe80::5] > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e0.rtr1 > > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e1.rtr1 > > 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e0.rtr2 > > 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e3.rtr2 > > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e2.rtr3 > > 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR e0.rtr3 > > > With so many interface IDs available in fe80::/64, there'd be no need to even put any effort into recycling them should you decommission a router or link. Just keep using the next fe80::X address as you add router interfaces. > > Traceroute would work for you, It shouldn't, because intermediate routers should discard ICMPv6 packets with LL source addresses, according to RFC 4291 section 2.5.6. The fact that they don't is an implementation error, and we shouldn't rely on that. ICMPv6 should never be sourced from a LL address. Brian however outside of your network, other people would be querying their own version of 0.8.e.f.ip6.arpa., hiding your interface and router names. This idea might be useful to assist with troubleshooting for a "Using Only Link-Local Addressing Inside an IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01 scenario. > > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mbehring@cisco.com Thu Aug 9 04:08:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C0F21F865E for ; Thu, 9 Aug 2012 04:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cYAbhX3UtgQ for ; Thu, 9 Aug 2012 04:08:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4C21F8639 for ; Thu, 9 Aug 2012 04:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbehring@cisco.com; l=1716; q=dns/txt; s=iport; t=1344510492; x=1345720092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZSxCb1wn1uS3PRxKe1i79Ly2AFigPiaqNtW6E7rQ09Y=; b=H7iKfAqCGLX8g5xdAUC2TJa7JxsN+8/tBEhKhZofNn+unaU8Igq2YaWJ l4V+b+tokD8CFeFFhlIdx05PG7DElXrcwx/XnFNr4VJOMNue7kTlW8eNH iYSHQ3g/0vu4mxeQrF7DBrxqDD7A20wKDyG/hj1Nyl9I9cskQNF1XGZvl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADiZI1CtJXG+/2dsb2JhbABFhgGydmiBB4IgAQEBAwESARARRRACAQgaAgYZBwICAjAVEAIEAQ0NGodlBgubcY0Zk0mBIY9EMmADll2NFYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,739,1336348800"; d="scan'208";a="109939408" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2012 11:08:11 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79B8BMO004385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 11:08:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 06:08:11 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Mark ZZZ Smith Thread-Topic: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines Thread-Index: AQHNdhcoykYiOdcqbUOuG8cjgPyM7JdRoHaA//+vXaA= Date: Thu, 9 Aug 2012 11:08:10 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> In-Reply-To: <50239553.3010206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.194.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19096.006 x-tm-as-result: No--23.216400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org list" , Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 11:08:12 -0000 PiA+IFRyYWNlcm91dGUgd291bGQgd29yayBmb3IgeW91LA0KPiANCj4gSXQgc2hvdWxkbid0LCBi ZWNhdXNlIGludGVybWVkaWF0ZSByb3V0ZXJzIHNob3VsZCBkaXNjYXJkIElDTVB2NiBwYWNrZXRz DQo+IHdpdGggTEwgc291cmNlIGFkZHJlc3NlcywgYWNjb3JkaW5nIHRvIFJGQyA0MjkxIHNlY3Rp b24gMi41LjYuDQo+IA0KPiBUaGUgZmFjdCB0aGF0IHRoZXkgZG9uJ3QgaXMgYW4gaW1wbGVtZW50 YXRpb24gZXJyb3IsIGFuZCB3ZSBzaG91bGRuJ3QgcmVseQ0KPiBvbiB0aGF0LiBJQ01QdjYgc2hv dWxkIG5ldmVyIGJlIHNvdXJjZWQgZnJvbSBhIExMIGFkZHJlc3MuDQoNCkkgY2FuIGNvbmZpcm0g dGhhdCBhdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gKG91cnMpIHJlc3BvbmRzIHVzaW5nIGEg Z2xvYmFsIGFkZHJlc3MgKGZyb20gYSBsb29wYmFjayksIG5vdCB0aGUgbGluayBsb2NhbC4gDQoN Cj4gDQo+ICAgICBCcmlhbg0KPiANCj4gaG93ZXZlciBvdXRzaWRlIG9mIHlvdXIgbmV0d29yaywg b3RoZXIgcGVvcGxlIHdvdWxkIGJlIHF1ZXJ5aW5nIHRoZWlyDQo+IG93biB2ZXJzaW9uIG9mIDAu OC5lLmYuaXA2LmFycGEuLCBoaWRpbmcgeW91ciBpbnRlcmZhY2UgYW5kIHJvdXRlciBuYW1lcy4N Cj4gVGhpcyBpZGVhIG1pZ2h0IGJlIHVzZWZ1bCB0byBhc3Npc3Qgd2l0aCB0cm91Ymxlc2hvb3Rp bmcgZm9yIGEgIlVzaW5nIE9ubHkNCj4gTGluay1Mb2NhbCBBZGRyZXNzaW5nIEluc2lkZSBhbg0K PiBJUHY2IE5ldHdvcmsiIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlaHJpbmdl ci1sbGEtb25seS0wMQ0KPiBzY2VuYXJpby4NCg0KVGhlIGNvbmNlcm4gaXMgdGhhdCBmb3IgSUNN UCBlY2hvIHJlcGx5LCB0cmFjZXJvdXRlLCBldGMgdGhlIHJvdXRlciB3aWxsIHJlc3BvbmQgd2l0 aCBhIGdsb2JhbCBhZGRyZXNzLCB3aGljaCBpcyBhIGxvb3BiYWNrIGFkZHJlc3MgKGluIHRoZSBh YnNlbmNlIG9mIGdsb2JhbCBhZGRyZXNzZXMgb24gdGhlIGludGVyZmFjZSkuIFlvdSBjYW4gdGhl cmVmb3JlIHNlZSB0aGUgcm91dGVyLCBidXQgbm90IHRoZSBpbnRlcmZhY2UgKHVubGVzcyBSRkM1 ODM3IGlzIGltcGxlbWVudGVkLCB3aGljaCBpcyBnZW5lcmFsbHkgbm90IHRoZSBjYXNlIHRvZGF5 KS4gDQoNClNvIEkgY2FuJ3Qgc2VlIGhvdyB0aGlzIGhlbHBzIHRyb3VibGVzaG9vdGluZz8gKEkg bXVzdCBiZSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0aGluZyBoZXJlKQ0KDQpNaWNoYWVsDQoNCg== From fred@cisco.com Thu Aug 9 05:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2069021F8659 for ; Thu, 9 Aug 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.849 X-Spam-Level: X-Spam-Status: No, score=-110.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H7xIm8NmQ-d for ; Thu, 9 Aug 2012 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6472721F86D1 for ; Thu, 9 Aug 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=146; q=dns/txt; s=iport; t=1344516302; x=1345725902; h=date:from:message-id:to:subject:cc; bh=1M+i+Jy6xvh+KJCiQVDVuSZDtuIfHVgbYU7yookPhTs=; b=hr1xR+Y83YUoj9TsiSbuqejhP/yxLs9nLDgHjmDo83xQRmDVpGAvVu/j ENpEJWLZsCX8AgzFQkdLrzXRf3AIyLRVrqP+0KV/tv6pQtKdl64M2juBF 8yq2Cvyc34QeeyeBRaD9KtYlIiFD9uMuPWOhmKg+iDSTSq3gZH0lqBPGh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAC+wI1CrRDoI/2dsb2JhbABFhTqjMQGQdoEHgjkBZjwtgQqHagycEKBijleDHAOITo4PjRWBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,739,1336348800"; d="scan'208";a="54457218" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79Cj1lG026750; Thu, 9 Aug 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q79Cj1g08088; Thu, 9 Aug 2012 05:45:01 -0700 (PDT) Date: Thu, 9 Aug 2012 05:45:01 -0700 (PDT) From: Message-Id: <201208091245.q79Cj1g08088@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-enterprise-incremental-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-enterprise-incremental-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please take a look at it and comment. From fred@cisco.com Thu Aug 9 05:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B95B21F8665 for ; Thu, 9 Aug 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcviaFaAyyrK for ; Thu, 9 Aug 2012 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 513EF21F86C5 for ; Thu, 9 Aug 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=135; q=dns/txt; s=iport; t=1344516302; x=1345725902; h=date:from:message-id:to:subject:cc; bh=h4n/xh0ZO5seoewU9Gs21t7wNX4rqdFt5A7qwrK2cwQ=; b=cBE1z16zHKqNIm8ze4G7xof52i2V00mPWGkCwmfumSVK89TZAz3lDeZE mZ4vF7wBdv8BFd1v2d/6KQlYH4P8HdX3f9+ZvcbcmzF0I+15JtPJqDldf o8BfoSNh24/MqtBNdoBvO/xcIoVFy5TdMimKaDBNo81nxSantSIBaimE5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAC+wI1CrRDoI/2dsb2JhbABFhTqjMQGQdoEHgjkBZjwtgQqHagycEKBijleDHAOITo4PjRWBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,739,1336348800"; d="scan'208";a="54457217" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79Cj1bC026751; Thu, 9 Aug 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q79Cj1k08091; Thu, 9 Aug 2012 05:45:01 -0700 (PDT) Date: Thu, 9 Aug 2012 05:45:01 -0700 (PDT) From: Message-Id: <201208091245.q79Cj1k08091@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-nat64-experience@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-nat64-experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. Please take a look at it and comment. From despres.remi@laposte.net Thu Aug 9 06:11:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9CF21F8665 for ; Thu, 9 Aug 2012 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En7b+7xsqGLO for ; Thu, 9 Aug 2012 06:11:19 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4061321F85DD for ; Thu, 9 Aug 2012 06:11:16 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 75BC0700009D; Thu, 9 Aug 2012 15:11:15 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id D654F70000A1; Thu, 9 Aug 2012 15:11:12 +0200 (CEST) X-SFR-UUID: 20120809131112879.D654F70000A1@msfrf2411.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 9 Aug 2012 15:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5967F575-2C1E-45FB-AAC8-DCBE46DF0CBD@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:11:20 -0000 Dear Gang, None of what follows convinces me that the clarification I see as = necessary is against anyone's need. Besides, none of what I explained seems to convince any key supporter of = the 464XLAT proposal that this clarification is acceptable. How to proceed is, I suppose, a matter for chairs to decide. Having said what had IMHO to be said, I don't plan to add anything = unless some new statement is made that is AFAIK invalid.=20 Regards, RD Le 2012-08-09 =E0 12:04, GangChen a =E9crit : > Hello Remi, >=20 > 2012/8/9, R=E9mi Despr=E9s : >>=20 >> 2012-08-08 18:57, Fred Baker (fred) : >>=20 >>>=20 >>> On Aug 8, 2012, at 3:29 AM, R=E9mi Despr=E9s wrote: >>>=20 >>>> b. As also discussed, the applicability statement should clarify = that, in >>>> access networks where both NAT64 and DS-Lite are available, using = DS-Lite >>>> should be recommended (better IPv4 transparency). >>>> For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 = would >>>> be enough for me. >>>=20 >>> >>> As I said earlier, it is beyond me why an applicability statement or = a >>> technical description of one technology is constrained to discuss >>> another. >>>=20 >>> Let me repeat something that has been pointed out by others in this >>> thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, = 4rd, >>> ds-lite, an MPLS LSP, or whatever other kind of tunnel might come to = mind >>> - one does not provide an end to end IPv4 infrastructure. The = solution can >>> translate to IPv6 and back to IPv4, or it can translate IPv4 to IPv4 = at >>> one end of the tunnel or another, but one does not avoid translation = of >>> IPv4 packets. The only way one avoids translation - at all - is to = send >>> native IPv6 packets and deliver them to one's destination. That's = kind of >>> the point here, as Cameron pointed out in the talk last week. >>=20 >> Strictly speaking, the second sentence isn't accurate because a = stateless >> v4/v6 tunneling solution, e.g. that being currently specified in = Softwire, >> does provide e2e v4 service. (No e2e way to notice that part of the = path >> includes one or several IPv4 tunnels over IPv6.) >=20 > I like the statement as you said earlier, that is "more transparent". > NAT44 is still needed on CPE even in encapsulation case. >=20 >> OTOH, I agree that, in the limited context of STATEFUL solutions = (i.e. >> including port translation), e2e transparency is never complete, and = that >> DS-Lite is in this category. >> The only point point here is that DS-Lite always preserves DF bits, = and thus >> maintains compatibility with RFC 4821, while 464XLAT doesn't. >=20 > RFC4821 argument was already documented in the proposal. I guess that > is sufficient to signal the fact. Adding much may not help the > discussion IMHO. >=20 >>=20 >>> For my money, this document should be constrained to talking about = the >>> 464XLAT solution and the cases in which those providers using it = find it >>> useful. Any other discussion, in my opinion, mostly confuses the >>> discussion. >>=20 >> Note that DNS64 is discussed in the draft although it isn't part of = the >> 464XLAT specification. >=20 > DNS64 is closely related to and discussed in RFC6146. Therefore, it > can't be a justification we need to do more on different technology. >=20 >=20 >> The criterion to mention or not a different >> technology seems therefore to be more "is it useful" than "should = never be >> done", which makes sense. >>=20 >> Letting readers believe that 464XLAT is THE best choice even where = service >> providers choose to support not only NAT64 CGN but also DS-Lite = remains >> misleading AFAIK. >=20 > How the misleading should be? We even do 4rd to overcome ACL > incompatibilities in DS-Lite kind of solution. That is a trade-off > actually, i.e. "more transparent" vs "more compabilities". It's worth > another draft to argue that. I really want the draft focus specific > discussion on 464xlat features. >=20 >> I can't understand why it would be such a big deal to clarify that, = even in >> the limited context of stateful solutions, it is only for networks = that >> don't support more transparent transition solutions that 464XLAT is = THE >> recommended solution. >=20 > Considering above, I hope you could accept and let us move-on >=20 > Many thanks >=20 > Gang >=20 >=20 >=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>>=20 >>> >>> At this point, in the opinion of this chair, any textual changes in = the >>> document should be for the purposes of clarifying the 464XLAT = deployment >>> strategy and its uses of the technologies it specifies, or the = operational >>> utility of it. Discussion of technologies that would not be used in = a >>> 464XLAT network is out of place. >>=20 From markzzzsmith@yahoo.com.au Thu Aug 9 14:07:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2516621F86D1 for ; Thu, 9 Aug 2012 14:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u0JxD304LDV for ; Thu, 9 Aug 2012 14:07:04 -0700 (PDT) Received: from nm12.bullet.mail.ac4.yahoo.com (nm12.bullet.mail.ac4.yahoo.com [98.139.52.209]) by ietfa.amsl.com (Postfix) with SMTP id 454F521F86C4 for ; Thu, 9 Aug 2012 14:07:04 -0700 (PDT) Received: from [98.139.52.190] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 21:07:01 -0000 Received: from [98.139.52.131] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 21:07:01 -0000 Received: from [127.0.0.1] by omp1014.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 21:07:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 273071.48323.bm@omp1014.mail.ac4.yahoo.com Received: (qmail 81141 invoked by uid 60001); 9 Aug 2012 21:07:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344546420; bh=TfQ0UH0W+OEgEBNelkucW3W5n/F/wnQa0d9Wt4V23Rs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DLbUtaHX4DV5ue1vaSopJEw6rZaq9yaX7kr6O/Mxssf63vrTG69E4dWuV9muWmbZFLRz8Z/AQTVurWlReGo6BusSWRdfpeiS1brEyHJZHI8tmyOpe5zYHTkX0pzsRZtKQ/k/Yu4ajxVMXQGMaMk8j7rS0K52yVZUSY1KnGhDQxI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XCDvNrHmySARWt975jHFXjKDHFbl1xfwcia7GFufgGtgAnLxSgZlChjXClHzR9jk14JUGNy6KQL8k76rkanDF5UwHVzwFf+Etbffh2ObdeSBwNStAtEiIHntz0Z7xkO+vOjZrrrttNYcPeyrJWptjSk3kzQV50ClQTKB7V84cr4=; X-YMail-OSG: hcHiAwoVM1nZoZXj8PmfUZaDw6UG65L6fG_ZbVdqqE8QmTp zSdicqxZv_eSH0isWWOAoLHZQxiyLvE9VeGvROaLnqFnIbM0zH1FGsUhHXNv JfcI_oeAqPDp4uFzUJL5RZ0LHpD7MXoe1l5WVOnYFJc3ctNqs.xwRa1.dECW T26CIZ6h2kx0m6I7Ag4IiImxHwDgue19bn8vttS0U9MlQ7_QmFImbtfArjtc 3UAs4iin.GgVjj7TR4ghRI9h3kG62dbHGeuPARHFsu7kiziPMDOc.e7ernGc _T8v7jhP9SkI3jdfxRU1UMy3myBhiH.mHoRCMVary41sDTxtr3NGH3amuxpr WebD86CXZvBts7TaWaN3bUNSEgfuVIX_bmWSr0Pjml3AdV.TgjhCXMEhnkbJ dfEa1X8PHXWrMSIzIwAcap49kkNzr6gcky_sW5wtTiBQLnCB2zZY_kImz6Hy hSNl9Uv.Y8GkP4s936B69EcmG2gTdJ8PZHwVk8Atxs33q_g-- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 14:07:00 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> Message-ID: <1344546420.80494.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 14:07:00 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter In-Reply-To: <50239553.3010206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org list" , "mbehring@cisco.com" , Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:07:05 -0000 Hi Brian,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter = =0A> To: Mark ZZZ Smith =0A> Cc: Philip Matthews ; Gert Doering ; "sthaug@nethelp.no" ; "mbehring@cisco.com"= ; "evyncke@cisco.com" ; "v6ops@ietf= .org list" =0A> Sent: Thursday, 9 August 2012 8:47 PM=0A> S= ubject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configu= ration of addresses, draft-matthews-v6ops-design-guidelines=0A> =0A> On 09/= 08/2012 11:10, Mark ZZZ Smith wrote:=0A>> Hi,=0A>> =0A>> =0A>> ----- Orig= inal Message -----=0A>>> From: Philip Matthews = =0A>>> To: Gert Doering ; sthaug@nethelp.no=0A>>> Cc: "v6= ops@ietf.org list" =0A>>> Sent: Thursday, 9 August 2012 7:= 26 AM=0A>>> Subject: Re: [v6ops] about LLAs pros/cons static routing - =0A= > auto/self-configuration of addresses, draft-matthews-v6ops-design-guideli= nes=0A>>> =0A>>> G ert and Stiener:=0A>>> =0A>>>=A0=0A=0A=A0=0A=0A>>= With so many interface IDs available in fe80::/64, there'd be no need =0A= > to even put any effort into recycling them should you decommission a rout= er or =0A> link. Just keep using the next fe80::X address as you add router= interfaces.=0A>> =0A>> Traceroute would work for you, =0A> =0A> It should= n't, because intermediate routers should discard ICMPv6 packets =0A> with= =0A> LL source addresses, according to RFC 4291 section 2.5.6.=0A>=A0=0A=0A= Hmm, you're right.=0A=0ASo this idea would provide accurate reverse DNS nam= es for your static link local addresses because they're now unique within y= our network, however the collection of that information can't rely on link = local addressing as it would in traceroute, if the collection process needs= to traverse more than a single link.=0A=0ARegards,=0AMark.=0A=0A> The fact= that they don't is an implementation error, and we shouldn't=0A> rely on t= hat. ICMPv6 should never be sourced from a LL address.=0A> =0A> =A0 =A0 Bri= an=0A> =0A> however outside of your network, other people would be querying= their own =0A> version of 0.8.e.f.ip6.arpa., hiding your interface=0A> and= router names. This idea might be useful to assist with troubleshooting for= a =0A> "Using Only Link-Local Addressing Inside an=0A> IPv6 Network" http:= //tools.ietf.org/html/draft-behringer-lla-only-01 =0A> scenario.=0A>> =0A>>= Regards,=0A>> Mark.=0A>> ______________________________________________= _=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/= mailman/listinfo/v6ops=0A>> =0A> From markzzzsmith@yahoo.com.au Thu Aug 9 14:39:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695D721F86FF for ; Thu, 9 Aug 2012 14:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+0nw9iGICqL for ; Thu, 9 Aug 2012 14:39:19 -0700 (PDT) Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (nm5-vm2.bullet.mail.ne1.yahoo.com [98.138.90.153]) by ietfa.amsl.com (Postfix) with SMTP id 8217321F86F9 for ; Thu, 9 Aug 2012 14:39:19 -0700 (PDT) Received: from [98.138.90.52] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 21:39:15 -0000 Received: from [98.138.226.162] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 21:39:15 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 21:39:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 472860.70169.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 38743 invoked by uid 60001); 9 Aug 2012 21:39:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1344548354; bh=jUDQs8GqkMR/LYy7Aryjf8hM64LYgCIfSU5QLgIwTiQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JoStIXqNGPAdC2TZ3y1SMgvCBwBad1+eqbG7impP0ro30y92owaWfEz0SBCou5/LRvRqJCk6uRJQGOC4A6hLgllI+/s9p94+By5EOBOgHNPbU6U1tdHkpegf3UykM7oCFeGQJD8BdQPZk7v3TNCK5wf9yej7+8o0A58VxibBn5o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aPtLfQixsqxqrQtXg26zxboNWaHem902t73it/Q6VGBEB9z4d38vefD/wiufwwt5NpdN94L05LGB0AafRhrzvI2oocUd1cAHpyf2MvmKqB5D0oU3dIit24P69LnsfcV5VymjnVZSWTHZeSnFVMU6DjAlBNzrjxQ1vqtHgCfz7rI=; X-YMail-OSG: dKHHLaIVM1lXNUGmB2uvMryg.mSYL5hnUuKZ91v0pdGP1kW adi7UY5Vw0aZKEAf9L.IINZJx8KIMZfWk4Z0_XAmXou.FGBb66T6UY2M59Tu 7haITUG3_FHjg_yc7k7kNNmRlK8ZezGHQJpsaQEZW_6pAvFkqgkIRORPMOin ro.AZYO4z.ZgfpGMXeiB_F6gQs_F51.VBXSM0xQtsQwjfav3EPi8wCzvuYg7 cv_jc0r2Fo5EHAxOyazzTPO0ue.PcOSUSceWJb4fgQsBTKEVbuOnTzmiqSvx 60h7fFHo3aGeDq5E5Dh8.N9j.HdLIuE4xmikWP_nxoZArNl.lTdH192d06l4 hUaOKwBql5wiATbcwGA47DG19y3dy.BX.gYoZ17u2RVzAfaAm9Q2WPKF_0yE QnVpa6X37H7YbCScMIzxvzyzZNAqFOfcZ3cwJN3AyZJzvE2KC54P_.FCFT4R aPv7GGu2vyZVPE69PE3aLmrV9IXK5xsEOLGrmv0UoOrM3_dSeXZMkFrmXZ_N MiZ8- Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 14:39:14 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> Message-ID: <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 14:39:14 -0700 (PDT) From: Mark ZZZ Smith To: "Michael Behringer \(mbehring\)" , Brian E Carpenter In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org list" , Philip Matthews Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:39:20 -0000 Hi Michael,=0A=0A=0A----- Original Message -----=0A> From: Michael Behringe= r (mbehring) =0A> To: Brian E Carpenter ; Mark ZZZ Smith =0A> Cc: Philip M= atthews ; Gert Doering ; "sthaug@= nethelp.no" ; Eric Vyncke (evyncke) ;= "v6ops@ietf.org list" =0A> Sent: Thursday, 9 August 2012 9= :08 PM=0A> Subject: RE: [v6ops] about LLAs pros/cons static routing - auto/= self-configuration of addresses, draft-matthews-v6ops-design-guidelines=0A>= =0A>> > Traceroute would work for you,=0A>> =0A>> It shouldn't, because = intermediate routers should discard ICMPv6 =0A> packets=0A>> with LL sourc= e addresses, according to RFC 4291 section 2.5.6.=0A>> =0A>> The fact that= they don't is an implementation error, and we =0A> shouldn't rely=0A>> on= that. ICMPv6 should never be sourced from a LL address.=0A> =0A> I can con= firm that at least one implementation (ours) responds using a global =0A> a= ddress (from a loopback), not the link local. =0A> =0A>> =0A>> =A0 =A0 Bri= an=0A>> =0A>> however outside of your network, other people would be query= ing their=0A>> own version of 0.8.e.f.ip6.arpa., hiding your interface and= router names.=0A>> This idea might be useful to assist with troubleshooti= ng for a "Using =0A> Only=0A>> Link-Local Addressing Inside an=0A>> IPv6 = Network" http://tools.ietf.org/html/draft-behringer-lla-only-01 =0A>> scen= ario.=0A> =0A> The concern is that for ICMP echo reply, traceroute, etc the= router will respond =0A> with a global address, which is a loopback addres= s (in the absence of global =0A> addresses on the interface). You can there= fore see the router, but not the =0A> interface (unless RFC5837 is implemen= ted, which is generally not the case =0A> today). =0A> =0A> So I can't see = how this helps troubleshooting? (I must be misunderstanding =0A> something = here)=0A=0AAs Brian said, traceroute won't reliably work due to the LL sour= ce address issue, however having unique static LL addresses across your net= work's router interfaces, and then having a record of the static LL address= assignments in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for=A0supplemen= tary information) might still be a useful troubleshooting tool.=A0For examp= le, if you're on the CLI of one router, and want to find out the interface = name corresponding to an adjacent router's static LL address, a ping comman= d with a reverse resolve of the address far router's interface address woul= d return the result of the PTR and therefore the name of the remote interfa= ce and router.=0A=0ARegards,=0AMark. From philip_matthews@magma.ca Thu Aug 9 14:58:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B0E21F85F3 for ; Thu, 9 Aug 2012 14:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2LtVLz1huWT for ; Thu, 9 Aug 2012 14:58:29 -0700 (PDT) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57421F85DA for ; Thu, 9 Aug 2012 14:58:28 -0700 (PDT) Received: from [74.198.165.21] (helo=[172.20.10.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SzakH-0003jX-2z; Thu, 09 Aug 2012 17:58:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 17:58:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.21] Cc: "v6ops@ietf.org list" , "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:58:30 -0000 On 2012-08-09, at 17:39 , Mark ZZZ Smith wrote: > Hi Michael, >=20 >=20 > ----- Original Message ----- >> From: Michael Behringer (mbehring) >> To: Brian E Carpenter ; Mark ZZZ Smith = >> Cc: Philip Matthews ; Gert Doering = ; "sthaug@nethelp.no" ; Eric Vyncke = (evyncke) ; "v6ops@ietf.org list" >> Sent: Thursday, 9 August 2012 9:08 PM >> Subject: RE: [v6ops] about LLAs pros/cons static routing - = auto/self-configuration of addresses, = draft-matthews-v6ops-design-guidelines >>=20 >>>> Traceroute would work for you, >>>=20 >>> It shouldn't, because intermediate routers should discard ICMPv6=20 >> packets >>> with LL source addresses, according to RFC 4291 section 2.5.6. >>>=20 >>> The fact that they don't is an implementation error, and we=20 >> shouldn't rely >>> on that. ICMPv6 should never be sourced from a LL address. >>=20 >> I can confirm that at least one implementation (ours) responds using = a global=20 >> address (from a loopback), not the link local.=20 >>=20 >>>=20 >>> Brian >>>=20 >>> however outside of your network, other people would be querying = their >>> own version of 0.8.e.f.ip6.arpa., hiding your interface and router = names. >>> This idea might be useful to assist with troubleshooting for a = "Using=20 >> Only >>> Link-Local Addressing Inside an >>> IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01=20= >>> scenario. >>=20 >> The concern is that for ICMP echo reply, traceroute, etc the router = will respond=20 >> with a global address, which is a loopback address (in the absence of = global=20 >> addresses on the interface). You can therefore see the router, but = not the=20 >> interface (unless RFC5837 is implemented, which is generally not the = case=20 >> today).=20 >>=20 >> So I can't see how this helps troubleshooting? (I must be = misunderstanding=20 >> something here) >=20 > As Brian said, traceroute won't reliably work due to the LL source = address issue, however having unique static LL addresses across your = network's router interfaces, and then having a record of the static LL = address assignments in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for = supplementary information) might still be a useful troubleshooting tool. = For example, if you're on the CLI of one router, and want to find out = the interface name corresponding to an adjacent router's static LL = address, a ping command with a reverse resolve of the address far = router's interface address would return the result of the PTR and = therefore the name of the remote interface and router. I believe traceroute will work. As Michael said, at least some routers, = if there is no GUA/ULA configured on the interface, then the router = sends the ICMP reply using the IP address of the loopback or system = address as the source address. Michael confirmed that Cisco routers work = this way, and I can confirm that Alcatel-Lucent routers work this way.=20= If anyone knows of a router which behaves differently, I would be = interested in hearing of it. This would be a useful comment to put in my = I-D. - Philip From victor.kuarsingh@gmail.com Thu Aug 9 17:40:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE8221F8419 for ; Thu, 9 Aug 2012 17:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmojBRppzNru for ; Thu, 9 Aug 2012 17:40:33 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7232721F85A0 for ; Thu, 9 Aug 2012 17:40:33 -0700 (PDT) Received: by yenm5 with SMTP id m5so1189581yen.31 for ; Thu, 09 Aug 2012 17:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-transfer-encoding:content-type :in-reply-to:message-id:date:cc:to:mime-version:x-mailer; bh=AAwd1oIXs5MnZK0cZdCfu+rmJb73Fpz2jGOVmmks164=; b=YSbisSFr8C52hT7BwsBIpgNj8fKbjLbgUasQaJipOwPaOJOlcE8k9oUbZ8qaGaR2Q/ /X0lsLALyYsGvr/5uxM5tf1yn5HiJNqluGqiezNdAm2JKLjdJ0UAdQiPUGVY49Y+qX7R IaEbx4Xjtdl/LswMzwmQmH0Lx/R0BfJYvVn01u+yqtRMB5E9Iznn93ozaeqmMwkWvmyS amLtRSgvs1ci5fp5zFFViUOXElIDGa3pe2i11v/cBUlCtldcp1G1c9S4+5qjkjwqtGgL JbwJ8qVRW9Orb+medLkWE585eesFh7GgKFctAUaz9xn6b5c64HWpJOZv7s91SPfe+PlN ZKlA== Received: by 10.50.219.136 with SMTP id po8mr207491igc.70.1344559232643; Thu, 09 Aug 2012 17:40:32 -0700 (PDT) Received: from [192.168.1.11] ([74.198.164.85]) by mx.google.com with ESMTPS id mb9sm2076151igc.7.2012.08.09.17.40.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 17:40:31 -0700 (PDT) References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> From: Victor Kuarsingh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Thu, 9 Aug 2012 19:58:27 -0400 To: Philip Matthews Mime-Version: 1.0 (iPad Mail 8J2) X-Mailer: iPad Mail (8J2) Cc: "v6ops@ietf.org list" , "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:40:34 -0000 Sent from my iPad On 2012-08-09, at 5:58 PM, Philip Matthews wrote:= >=20 > On 2012-08-09, at 17:39 , Mark ZZZ Smith wrote: >=20 >> Hi Michael, >>=20 >>=20 >> ----- Original Message ----- >>> From: Michael Behringer (mbehring) >>> To: Brian E Carpenter ; Mark ZZZ Smith >>> Cc: Philip Matthews ; Gert Doering ; "sthaug@nethelp.no" ; Eric Vyncke (evyncke) ; "v6ops@ietf.org list" >>> Sent: Thursday, 9 August 2012 9:08 PM >>> Subject: RE: [v6ops] about LLAs pros/cons static routing - auto/self-con= figuration of addresses, draft-matthews-v6ops-design-guidelines >>>=20 >>>>> Traceroute would work for you, >>>>=20 >>>> It shouldn't, because intermediate routers should discard ICMPv6=20 >>> packets >>>> with LL source addresses, according to RFC 4291 section 2.5.6. >>>>=20 >>>> The fact that they don't is an implementation error, and we=20 >>> shouldn't rely >>>> on that. ICMPv6 should never be sourced from a LL address. >>>=20 >>> I can confirm that at least one implementation (ours) responds using a g= lobal=20 >>> address (from a loopback), not the link local.=20 >>>=20 >>>>=20 >>>> Brian >>>>=20 >>>> however outside of your network, other people would be querying their >>>> own version of 0.8.e.f.ip6.arpa., hiding your interface and router name= s. >>>> This idea might be useful to assist with troubleshooting for a "Using=20= >>> Only >>>> Link-Local Addressing Inside an >>>> IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01=20= >>>> scenario. >>>=20 >>> The concern is that for ICMP echo reply, traceroute, etc the router will= respond=20 >>> with a global address, which is a loopback address (in the absence of gl= obal=20 >>> addresses on the interface). You can therefore see the router, but not t= he=20 >>> interface (unless RFC5837 is implemented, which is generally not the cas= e=20 >>> today).=20 >>>=20 >>> So I can't see how this helps troubleshooting? (I must be misunderstandi= ng=20 >>> something here) >>=20 >> As Brian said, traceroute won't reliably work due to the LL source addres= s issue, however having unique static LL addresses across your network's rou= ter interfaces, and then having a record of the static LL address assignment= s in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for supplementary informati= on) might still be a useful troubleshooting tool. For example, if you're on t= he CLI of one router, and want to find out the interface name corresponding t= o an adjacent router's static LL address, a ping command with a reverse reso= lve of the address far router's interface address would return the result of= the PTR and therefore the name of the remote interface and router. >=20 > I believe traceroute will work. As Michael said, at least some routers, i= f there is no GUA/ULA configured on the interface, then the router sends the= ICMP reply using the IP address of the loopback or system address as the so= urce address. Michael confirmed that Cisco routers work this way, and I can c= onfirm that Alcatel-Lucent routers work this way.=20 >=20 > If anyone knows of a router which behaves differently, I would be interest= ed in hearing of it. This would be a useful comment to put in my I-D. If you do put that point in, should it be noted that it is a "de facto" beha= vior of [some] routers? ( I don't recall a rule suggesting this is the offi= cial behavior).=20 I guess it's possible to not configure a loopback on a router (although it w= ould seem strange not to have one). I guess it's also possible that the LB m= ay also not be in the same routing instance. Also, some operators limit the reachability of the LB from outside their adm= inistrative perimeter for security reasons since it's used for management an= d routing functions (which does not always apply to the interface IP address= es). Regards, Victor K >=20 > - Philip >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Aug 9 17:57:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8664311E80A4 for ; Thu, 9 Aug 2012 17:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.704 X-Spam-Level: X-Spam-Status: No, score=-102.704 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crr00Ileqz7e for ; Thu, 9 Aug 2012 17:57:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E47EF11E80A2 for ; Thu, 9 Aug 2012 17:57:36 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1654782obb.31 for ; Thu, 09 Aug 2012 17:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=PqvmAVqwMBDUQEnzUCz0l/mgmBi2+4Jh9HocpViO7mM=; b=hfDI/uDdZSogEomD/AXH36kARE3u6u7Jn1aQUBQsDzKFhGy1pn3oraTnFLbG/TelEf W/vlhEyNtnXuGZwM30P/aEFch8nPGHpRIaAZLoOx1LopP/1fP8gLnAyutuuDVrtjh+qZ OuC7k89VIcf6FIpZpBZ5pmevF2JVejfumlHre4HcAjjksSM6XuhNynaRfE6XzKJhIlB8 eKlE2LcSEwKXbXzX1VKZsa0o90rP1xyxgsIqcIwuXoknCgLAQMhlmiXrsM2wimK5P9nc FkbEBnV1jRqskMjCIXCcz41gRR40ki0KlzDU/hDo3q/9DS6OrB4xskx5qL78DdwnF9zK 3QyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=PqvmAVqwMBDUQEnzUCz0l/mgmBi2+4Jh9HocpViO7mM=; b=EdCk0219KtC58nVsnSADgfg4+sV++MOFzmhXJbmEIkGB/ceL9Is9Mm1+YblqB43A/s IL9T9JwDHwGK2bPWNv70cr7SkPMdUIieqaQ6/zthQh34i6ikMAklPWb4PR3dWfzXVKlo Yu38Vqo20ZbwBxGyqyXgmnduEnjLEXWnVTKEWhrdwzTY7ZiGwYM/5ankM7q4Q22izbnG RRMvZiD4fw6qMbimQpN0zP1aEyEHNn2mm1+ZBJRhZLiprDHOhjGDZaVTRORuJ+Zh0rEw gdmbphBRpEExchrl5anxH1MCW9h+K5j/AXn5e9o2jsI7/jbJN0PSF+xDxCIGlhFVzM2/ PTgg== Received: by 10.60.20.74 with SMTP id l10mr1895568oee.19.1344560256353; Thu, 09 Aug 2012 17:57:36 -0700 (PDT) Received: by 10.60.20.74 with SMTP id l10mr1895551oee.19.1344560256164; Thu, 09 Aug 2012 17:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Thu, 9 Aug 2012 17:57:15 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> From: Lorenzo Colitti Date: Fri, 10 Aug 2012 09:57:15 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f923f7c72a51104c6ded474 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQGfAXxS7pnsJ5+EggnKU0ziAZkYwriRK4cTQ1RI2LkYPTz8UzR0eAouh7yWb91rwgwRTWYpr8yA4DxkSLifMIdP0hRf+7jxVJe7bgnJcBUQ423t8Bkqevvnx1sZShD9v8Su0FgucZXrYm5RJpyKXUjzwDrK3mCTZTDs1ciNzcEyAQTRF552c3FNwnGDY8EO6uYivi Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:57:37 -0000 --e89a8f923f7c72a51104c6ded474 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s = wrote: > I can't understand why it would be such a big deal to clarify that, even > in the limited context of stateful solutions, it is only for networks tha= t > don't support more transparent transition solutions that 464XLAT is THE > recommended solution. > I believe we all agree that 464xlat is suboptimal in terms of transparency and that other technologies provide better transparency. I believe we also agree that this is not a strict requirement for 464xlat because many of the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent. The only thing we disagree on is what the "best" in "best practice" should refer to. Right? With that in mind - if we said that the "best" in "best" practice refers to "the best way of running IPv4 over IPv6 when combining stateful and stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks that cannot support encapsulation"? Could we agree on that? Cheers, Lorenzo --e89a8f923f7c72a51104c6ded474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s= <despres.remi@laposte.net> wrote:
I can't understand why it would be such a big deal to clarify that, eve= n in the limited context of stateful solutions, it is only for networks tha= t don't support more transparent transition solutions that 464XLAT is T= HE recommended solution.

I believe we all agree that 464xlat is sub= optimal in terms of transparency and that other technologies provide better= transparency. I believe we also agree that this is not a strict requiremen= t for 464xlat because many of the target scenarios are networks that alread= y run carrier-operated NAT, which of course is not transparent. The only th= ing we disagree on is what the "best" in "best practice"= ; should refer to. Right?

With that in mind - if we said that the "best"= ; in "best" practice refers to "the best way of running IPv4= over IPv6 when combining stateful and stateless NAT64?", or "the= best way of running IPv4 over IPv6 in networks that cannot support encapsu= lation"?

Could we agree on that?

Cheers= ,
Lorenzo
--e89a8f923f7c72a51104c6ded474-- From cb.list6@gmail.com Thu Aug 9 19:09:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890521F85E1 for ; Thu, 9 Aug 2012 19:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+P8OI89B+3b for ; Thu, 9 Aug 2012 19:09:54 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9134521F85D8 for ; Thu, 9 Aug 2012 19:09:53 -0700 (PDT) Received: by lahm15 with SMTP id m15so626864lah.31 for ; Thu, 09 Aug 2012 19:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lMc/I4jSUr6Bfqm7WM1G6p6vu0luHKDcTRXWN88jMJk=; b=Gj1NS5z+1Vq4fNcxb0gnx+tYh0kn6HSuLq4bDNvCLU0RFRwEXlrQ0lYhtKrulNEExr +/UMk4lSQrmmQJCvF5vvYyTHlQZEpWd6d7U4jTO+Xo/7FWfcnsi+T8tOYZwdw8vcvuVX n67Udz/2SmISvcObE2ZEs8nzoqt5jqLYCNqh01Fg9jLLuHRRAs7BS5s+5o1dYZ4TIiEl 6kGGGJfaBTlpN/LCsCzhb+LI1o3kQSQKHPveJTSIFIEeQpPlSLCLbIMrloM1J0d7OPxB mR+D4x9pq+3jE38/Uq3AfAcUyjAusvPJJ4BrptXxdH24wi9InIlM7TbKU9llpmSfQ3w/ EjsQ== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr1181059lab.51.1344564592401; Thu, 09 Aug 2012 19:09:52 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Thu, 9 Aug 2012 19:09:52 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Thu, 9 Aug 2012 19:09:52 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Thu, 9 Aug 2012 19:09:52 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=e89a8f22bfb1e85e5504c6dfd6dc Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 02:09:54 -0000 --e89a8f22bfb1e85e5504c6dfd6dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" wrote: > > On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s wrote: >> >> I can't understand why it would be such a big deal to clarify that, even in the limited context of stateful solutions, it is only for networks that don't support more transparent transition solutions that 464XLAT is THE recommended solution. > > > I believe we all agree that 464xlat is suboptimal in terms of transparency and that other technologies provide better transparency. I believe we also agree that this is not a strict requirement for 464xlat because many of the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent. The only thing we disagree on is what the "best" in "best practice" should refer to. Right? > > With that in mind - if we said that the "best" in "best" practice refers to "the best way of running IPv4 over IPv6 when combining stateful and stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks that cannot support encapsulation"? > > Could we agree on that? > Afaik, the draft says that in section 2. The current text in the draft is very concise and exact about where the bcp applies. I see no need for any change. If somebody wants to write different draft that establishes a pecking order such as DS > MAP-E > ds-lite > 464xlat. .... They may do that. 464xlat is not the place for establishing that context for the global set of solutions. The current scope of the bcp is only networks that have stateful nat64 and is very clear in several places that this is a "limited" ipv4 service CB > Cheers, > Lorenzo > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f22bfb1e85e5504c6dfd6dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>
>> I can't understand why it would be such a big deal to clarify = that, even in the limited context of stateful solutions, it is only for net= works that don't support more transparent transition solutions that 464= XLAT is THE recommended solution.
>
>
> I believe we all agree that 464xlat is suboptimal in terms of transpar= ency and that other technologies provide better transparency. I believe we = also agree that this is not a strict requirement for 464xlat because many o= f the target scenarios are networks that already run carrier-operated NAT, = which of course is not transparent. The only thing we disagree on is what t= he "best" in "best practice" should refer to. Right? >
> With that in mind - if we said that the "best" in "best= " practice refers to "the best way of running IPv4 over IPv6 when= combining stateful and stateless NAT64?", or "the best way of ru= nning IPv4 over IPv6 in networks that cannot support encapsulation"? >
> Could we agree on that?
>

Afaik, the draft says=A0 that in section 2.

The current text in the draft is very concise and exact about where the = bcp applies. I see no need for any change.

If somebody wants to write different draft that establishes a pecking or= der such as DS > MAP-E=A0 > ds-lite >=A0 464xlat. ....

They may do that.=A0 464xlat is not the place for establishing that cont= ext for the global set of solutions.

The current scope of the bcp is only networks that have stateful nat64 a= nd=A0 is very clear in several places that this is a "limited" ip= v4 service

CB

> Cheers,
> Lorenzo
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--e89a8f22bfb1e85e5504c6dfd6dc-- From despres.remi@laposte.net Thu Aug 9 23:19:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E3021F861B for ; Thu, 9 Aug 2012 23:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-KVFgDXtLDZ for ; Thu, 9 Aug 2012 23:19:14 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 669BA21F8618 for ; Thu, 9 Aug 2012 23:19:13 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id B7D65700005B; Fri, 10 Aug 2012 08:19:12 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 0EA9B700004A; Fri, 10 Aug 2012 08:19:09 +0200 (CEST) X-SFR-UUID: 20120810061910601.0EA9B700004A@msfrf2217.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--947353704 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 10 Aug 2012 08:19:09 +0200 Message-Id: <73D8BFC0-42F5-4B41-BE33-B5337F4998D1@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 06:19:15 -0000 --Apple-Mail-2--947353704 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-10 =E0 02:57, Lorenzo Colitti a =E9crit : > On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s = wrote: > I can't understand why it would be such a big deal to clarify that, = even in the limited context of stateful solutions, it is only for = networks that don't support more transparent transition solutions that = 464XLAT is THE recommended solution. >=20 > I believe we all agree that 464xlat is suboptimal in terms of = transparency and that other technologies provide better transparency. I = believe we also agree that this is not a strict requirement for 464xlat = because many of the target scenarios are networks that already run = carrier-operated NAT, which of course is not transparent. The only thing = we disagree on is what the "best" in "best practice" should refer to. = Right? >=20 > With that in mind - if we said that the "best" in "best" practice = refers to "the best way of running IPv4 over IPv6 when combining = stateful and stateless NAT64?", or "the best way of running IPv4 over = IPv6 in networks that cannot support encapsulation"? The second one does cover my point. > Could we agree on that? Yes, AFAIAC. Could be improved IMHO with "does not support" instead "cannot support", = but acceptable as is. Thanks, RD >=20 > Cheers, > Lorenzo --Apple-Mail-2--947353704 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Thu, Aug 9, 2012 at 6:11 PM, = R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
I can't understand why it would be such a big deal to clarify that, even = in the limited context of stateful solutions, it is only for networks = that don't support more transparent transition solutions that 464XLAT is = THE recommended solution.

I believe we all agree that 464xlat is = suboptimal in terms of transparency and that other technologies provide = better transparency. I believe we also agree that this is not a strict = requirement for 464xlat because many of the target scenarios are = networks that already run carrier-operated NAT, which of course is not = transparent. The only thing we disagree on is what the "best" in "best = practice" should refer to. Right?

With that in mind - if we said that the "best" in = "best" practice refers to "the best way of running IPv4 over IPv6 when = combining stateful and stateless NAT64?", or "the best way of running = IPv4 over IPv6 in networks that cannot support = encapsulation"?

The second one = does cover my point.

Could we agree on that?

Yes, = AFAIAC.
Could be improved IMHO with "does not support" = instead "cannot support", but acceptable as = is.

Thanks,
RD


Cheers,
Lorenzo

= --Apple-Mail-2--947353704-- From despres.remi@laposte.net Thu Aug 9 23:22:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0FD21F84F6 for ; Thu, 9 Aug 2012 23:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjCEIGbF+rjT for ; Thu, 9 Aug 2012 23:22:24 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9A21F84F5 for ; Thu, 9 Aug 2012 23:22:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 5A44D70000B8; Fri, 10 Aug 2012 08:22:23 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id E73C770000B6; Fri, 10 Aug 2012 08:22:22 +0200 (CEST) X-SFR-UUID: 20120810062222947.E73C770000B6@msfrf2217.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--947160736 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 10 Aug 2012 08:22:22 +0200 Message-Id: <442B3481-A7C7-4409-9CC6-31A3B73288FE@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 06:22:25 -0000 --Apple-Mail-3--947160736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-10 =E0 04:09, Cameron Byrne a =E9crit : >=20 > On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" wrote: > > > > On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s = wrote: > >> > >> I can't understand why it would be such a big deal to clarify that, = even in the limited context of stateful solutions, it is only for = networks that don't support more transparent transition solutions that = 464XLAT is THE recommended solution. > > > > > > I believe we all agree that 464xlat is suboptimal in terms of = transparency and that other technologies provide better transparency. I = believe we also agree that this is not a strict requirement for 464xlat = because many of the target scenarios are networks that already run = carrier-operated NAT, which of course is not transparent. The only thing = we disagree on is what the "best" in "best practice" should refer to. = Right? > > > > With that in mind - if we said that the "best" in "best" practice = refers to "the best way of running IPv4 over IPv6 when combining = stateful and stateless NAT64?", or "the best way of running IPv4 over = IPv6 in networks that cannot support encapsulation"? > > > > Could we agree on that? > > >=20 > Afaik, the draft says that in section 2. >=20 > The current text in the draft is very concise and exact about where = the bcp applies. I see no need for any change. >=20 > If somebody wants to write different draft that establishes a pecking = order such as DS > MAP-E > ds-lite > 464xlat. .... >=20 Did anyone suggested to include MAP-E??? Lorenzo's proposal Nb 2 is OK. RD =20 > They may do that. 464xlat is not the place for establishing that = context for the global set of solutions. >=20 > The current scope of the bcp is only networks that have stateful nat64 = and is very clear in several places that this is a "limited" ipv4 = service >=20 > CB >=20 > > Cheers, > > Lorenzo > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --Apple-Mail-3--947160736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
>>
>> I can't understand why it would be such a big deal to clarify = that, even in the limited context of stateful solutions, it is only for = networks that don't support more transparent transition solutions that = 464XLAT is THE recommended solution.
>
>
> I believe we all agree that 464xlat is suboptimal in terms of = transparency and that other technologies provide better transparency. I = believe we also agree that this is not a strict requirement for 464xlat = because many of the target scenarios are networks that already run = carrier-operated NAT, which of course is not transparent. The only thing = we disagree on is what the "best" in "best practice" should refer to. = Right?
>
> With that in mind - if we said that the "best" in "best" practice = refers to "the best way of running IPv4 over IPv6 when combining = stateful and stateless NAT64?", or "the best way of running IPv4 over = IPv6 in networks that cannot support encapsulation"?
>
> Could we agree on that?
>

Afaik, the draft says  that in section 2.

The = current text in the draft is very concise and exact about where the bcp = applies. I see no need for any change.

If somebody wants to write = different draft that establishes a pecking order such as DS > = MAP-E  > ds-lite >  464xlat. .... =


Did anyone suggested to include = MAP-E???
Lorenzo's proposal Nb 2 is = OK.
RD
 

They = may do that.  464xlat is not the place for establishing that = context for the global set of solutions.

The current scope of the = bcp is only networks that have stateful nat64 and  is very clear in = several places that this is a "limited" ipv4 service

CB

> = Cheers,
> Lorenzo
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/= mailman/listinfo/v6ops
>


= --Apple-Mail-3--947160736-- From brian.e.carpenter@gmail.com Fri Aug 10 00:16:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0011E8102 for ; Fri, 10 Aug 2012 00:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.475 X-Spam-Level: X-Spam-Status: No, score=-101.475 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HhIcEK1-S2W for ; Fri, 10 Aug 2012 00:16:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05521F85B4 for ; Fri, 10 Aug 2012 00:16:58 -0700 (PDT) Received: by weyu54 with SMTP id u54so924469wey.31 for ; Fri, 10 Aug 2012 00:16:57 -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=anGDhrIlm6ga3HKxqqEV+SYYc/1xRga3JOwpifFgUws=; b=AO6azDA3wJ4Ri3bQcvFgDlS7g44opl1c1DgCtlyVo+2RjQeLM1nJBKd9Ds1Oza+XgY hnnkmc29ABfgO/RFxNljAJRM9SC0YwJmaAgrMeIHW4RQY4N1K3HUNjZz8VE8it4FdNBN K4R148DcCb6PfazrSkHbjuZIsFXku0JFJqNhttaoaeApYLC7JC8QAaKfetbf36a2O2zB QsPhpd6UGf+UJxjUd0SKWk58ulYmyBr64sISAy0GP9VlQu7JcmPwY/1ZZM6u8B1bwp0s eHOUfcJ/tfv9UiHyTFDd6pdNOK6k984KoAIvXWZwOaaYlChHnOOSn+IvyJW8EbZM+3QL GghQ== Received: by 10.180.81.66 with SMTP id y2mr3614663wix.22.1344583017443; Fri, 10 Aug 2012 00:16:57 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-58.as13285.net. [2.102.218.58]) by mx.google.com with ESMTPS id o2sm9189350wiz.11.2012.08.10.00.16.54 (version=SSLv3 cipher=OTHER); Fri, 10 Aug 2012 00:16:56 -0700 (PDT) Message-ID: <5024B571.7090907@gmail.com> Date: Fri, 10 Aug 2012 08:17:05 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org list" , "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:16:59 -0000 On 09/08/2012 22:58, Philip Matthews wrote: > On 2012-08-09, at 17:39 , Mark ZZZ Smith wrote: ... >> As Brian said, traceroute won't reliably work due to the LL source address issue, however having unique static LL addresses across your network's router interfaces, and then having a record of the static LL address assignments in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for supplementary information) might still be a useful troubleshooting tool. For example, if you're on the CLI of one router, and want to find out the interface name corresponding to an adjacent router's static LL address, a ping command with a reverse resolve of the address far router's interface address would return the result of the PTR and therefore the name of the remote interface and router. > > I believe traceroute will work. As Michael said, at least some routers, if there is no GUA/ULA configured on the interface, then the router sends the ICMP reply using the IP address of the loopback or system address as the source address. Michael confirmed that Cisco routers work this way, and I can confirm that Alcatel-Lucent routers work this way. > > If anyone knows of a router which behaves differently, I would be interested in hearing of it. This would be a useful comment to put in my I-D. See http://www.ietf.org/mail-archive/web/v6ops/current/msg11277.html Brian From ietfc@btconnect.com Fri Aug 10 04:34:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FFA21F8629 for ; Fri, 10 Aug 2012 04:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK4P4iEhipoY for ; Fri, 10 Aug 2012 04:34:00 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id EBCF321F8627 for ; Fri, 10 Aug 2012 04:33:59 -0700 (PDT) Received: from mail87-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Aug 2012 11:33:58 +0000 Received: from mail87-db3 (localhost [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id 9CC8C260363; Fri, 10 Aug 2012 11:33:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I542M1452I1432Izz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1344598436919612_1337; Fri, 10 Aug 2012 11:33:56 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.248]) by mail87-db3.bigfish.com (Postfix) with ESMTP id D4CF52A003F; Fri, 10 Aug 2012 11:33:56 +0000 (UTC) Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Aug 2012 11:33:56 +0000 Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.108.4; Fri, 10 Aug 2012 11:33:55 +0000 Message-ID: <021501cd76eb$65d0fe80$4001a8c0@gateway.2wire.net> From: t.petch To: "Bjoern A. Zeeb" , v6ops WG References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com><20120807133908kawashimam@mail.jp.nec.com><7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net><90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net><992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net><841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Fri, 10 Aug 2012 12:28:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.37] X-OriginatorOrg: btconnect.com Cc: V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 11:34:01 -0000 ----- Original Message ----- From: "Bjoern A. Zeeb" To: "v6ops WG" Cc: "V6ops Chairs" Sent: Thursday, August 09, 2012 7:23 AM > On Wed, 8 Aug 2012, Fred Baker (fred) wrote: > .... > > For my money, this document should be constrained to talking about the 464XLAT solution and the cases in which those providers using it find it useful. Any other discussion, in my opinion, mostly confuses the discussion. > > s/providers/people/ I am not a provider, I still find it useful. > > > > > At this point, in the opinion of this chair, any textual changes in the document should be for the purposes of clarifying the 464XLAT deployment strategy and its uses of the technologies it specifies, or the operational utility of it. Discussion of technologies that would not be used in a 464XLAT network is out of place. > > Let me add what might have been forwarded in some ways. Currently the BCP > Scenario only talks about IPv6-only *access* networks. Now depending > on how you define "access" this might be true. For me, and how I see "access" used, access is clearly the wrong term:-( I see access networks as giving access to the Internet, at either end, so in this I-D it is the v4p and v4g networks that are access (although access networks could of course be v6 instead). The use of "access" here gives me the flavour that I am sitting in a Data Centre, viewing the world from there, and the access network is providing access to the Data Centre from the world at large; and that seems wrong. Tom Petch > However running an application requiring IPv4 sockets on my IPv6-only > desktop kernel does not mean that my local network might not otherwise > be dual stacked but just that my end-node is IPv6-only transport and this > technology should allow me to do the translation purely in user space. > > So another use case is > > There are IPv4-only applications running on a node with an IPv6-only > kernel wanting to communicate with other (IPv4) nodes. > > > IMHO this is currently the only transition technology allowing me to > do this, thus helping to push the IPv6-only boundry further out without > killing legacy applications. Now this is the developers point of view > and not the operators point of view. I am not asking for a complete > substitution of "access" in the draft;) I just want to kill any > further tunneling discussions etc. They simply are not applicable/do > not work in this case anymore. Once I can prove my point with a > working implementation I'll be happy to update this one, but this > needs to go out and we need to move on, so I'll postpone. > > /bz > > PS: I'll send a diff latest during the weekend as there are a couple > of proof reading things and inconsistencies in exmaples as well as > invalid IPv6 addresses but this is only editorial not functional > changes. > -- > Bjoern A. Zeeb From rajiva@cisco.com Fri Aug 10 04:53:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F421F8585 for ; Fri, 10 Aug 2012 04:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArSmAg5k1W35 for ; Fri, 10 Aug 2012 04:53:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D39BF21F8613 for ; Fri, 10 Aug 2012 04:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5969; q=dns/txt; s=iport; t=1344599619; x=1345809219; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sQQaUo+PdNx0N/LQlwzGQWhF13rcKFqJ6bR5zIH8UGA=; b=CiKA9nthtC15X353ocKFQXYQtLpu3QAevvAxPDz4M8aaqHR6CbChzj94 DUsBVJBAL9B9OeP6L5fFZvVZt4jnEXEavg9cdgOV3Zbam71s72lvIsfSb sUd8I2LLBr3bXZIEUz6+LktNj5TiQr0UKZCUF5mlWuBGaKkMrheZKxx7f Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIzgI1CtJV2d/2dsb2JhbABFuWKBB4IgAQEBAwEBAQEPAVQHCwULAgEIDgonByEGCxQRAgQOBRsHh1wDBgYLmnuXEg0GiUQEiiplFIVwYAOIGYtdgVOLCoMfgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,745,1336348800"; d="scan'208,217";a="110289261" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 10 Aug 2012 11:53:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7ABrcVa013621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 11:53:38 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 06:53:37 -0500 From: "Rajiv Asati (rajiva)" To: Cameron Byrne Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdg79+XACQkbPc0aEIk8gtnL9iJdSjd2AgAAUSgCAAE9HDA== Date: Fri, 10 Aug 2012 11:53:36 +0000 Message-ID: <2010A36F-8B6E-41AE-95AC-6A7E7B638AAA@cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003 x-tm-as-result: No--26.836500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2010A36F8B6E41AE95AC6A7E7B638AAAciscocom_" MIME-Version: 1.0 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 11:53:40 -0000 --_000_2010A36F8B6E41AE95AC6A7E7B638AAAciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Cameron. Cheers, Rajiv Sent from my Phone On Aug 9, 2012, at 10:10 PM, "Cameron Byrne" > wrote: On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" > wrote: > > On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s > wrote: >> >> I can't understand why it would be such a big deal to clarify that, even= in the limited context of stateful solutions, it is only for networks that= don't support more transparent transition solutions that 464XLAT is THE re= commended solution. > > > I believe we all agree that 464xlat is suboptimal in terms of transparenc= y and that other technologies provide better transparency. I believe we als= o agree that this is not a strict requirement for 464xlat because many of t= he target scenarios are networks that already run carrier-operated NAT, whi= ch of course is not transparent. The only thing we disagree on is what the = "best" in "best practice" should refer to. Right? > > With that in mind - if we said that the "best" in "best" practice refers = to "the best way of running IPv4 over IPv6 when combining stateful and stat= eless NAT64?", or "the best way of running IPv4 over IPv6 in networks that = cannot support encapsulation"? > > Could we agree on that? > Afaik, the draft says that in section 2. The current text in the draft is very concise and exact about where the bcp= applies. I see no need for any change. If somebody wants to write different draft that establishes a pecking order= such as DS > MAP-E > ds-lite > 464xlat. .... They may do that. 464xlat is not the place for establishing that context f= or the global set of solutions. The current scope of the bcp is only networks that have stateful nat64 and = is very clear in several places that this is a "limited" ipv4 service CB > Cheers, > Lorenzo > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_2010A36F8B6E41AE95AC6A7E7B638AAAciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Cameron.

Cheers,
Rajiv

Sent from my Phone

On Aug 9, 2012, at 10:10 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:


On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>
>> I can't understand why it would be such a big deal to clarify that= , even in the limited context of stateful solutions, it is only for network= s that don't support more transparent transition solutions that 464XLAT is = THE recommended solution.
>
>
> I believe we all agree that 464xlat is suboptimal in terms of transpar= ency and that other technologies provide better transparency. I believe we = also agree that this is not a strict requirement for 464xlat because many o= f the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent.= The only thing we disagree on is what the "best" in "best p= ractice" should refer to. Right?
>
> With that in mind - if we said that the "best" in "best= " practice refers to "the best way of running IPv4 over IPv6 when= combining stateful and stateless NAT64?", or "the best way of ru= nning IPv4 over IPv6 in networks that cannot support encapsulation"? >
> Could we agree on that?
>

Afaik, the draft says  that in section 2.

The current text in the draft is very concise and exact about where the = bcp applies. I see no need for any change.

If somebody wants to write different draft that establishes a pecking or= der such as DS > MAP-E  > ds-lite >  464xlat. ....

They may do that.  464xlat is not the place for establishing that c= ontext for the global set of solutions.

The current scope of the bcp is only networks that have stateful nat64 a= nd  is very clear in several places that this is a "limited"= ipv4 service

CB

> Cheers,
> Lorenzo
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_2010A36F8B6E41AE95AC6A7E7B638AAAciscocom_-- From rajiva@cisco.com Fri Aug 10 05:15:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581521F84F6 for ; Fri, 10 Aug 2012 05:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rIZn+dtM08m for ; Fri, 10 Aug 2012 05:15:58 -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 558E321F84F9 for ; Fri, 10 Aug 2012 05:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4444; q=dns/txt; s=iport; t=1344600958; x=1345810558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D0hXPDmcFVDGpcLpE72T/iYOnqqwFtNaDXHWV1XJDTE=; b=i0qZfixXJEzagBirxRtnGlsWjNcIDz8mZVsMpHBsFmLNtpLIcfWSyn5b DrTr9lNsMlkFp99eZuV2MT6bRiaEvZs7+1CK46TbOfubYXwXMhzxzekGR PvPQUnipzb3WwAEo3DONlCzb48eFsoHQzDGHg8l8bU+IY9L9IUkpYIxM9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIzgI1CtJXHB/2dsb2JhbABFuWKBB4IhAQEEAQEBDwFUBwsQAgEIBDsHJwsUEQIEDgUbB4dcAwwLmnuXEhOJRASLDxSFcGADiBmNMI4pgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,745,1336348800"; d="scan'208,217";a="110306726" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 10 Aug 2012 12:15:58 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7ACFvHF022385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 12:15:57 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 07:15:57 -0500 From: "Rajiv Asati (rajiva)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdg79+XACQkbPc0aEIk8gtnL9iJdSjd2AgABpz+M= Date: Fri, 10 Aug 2012 12:15:56 +0000 Message-ID: <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003 x-tm-as-result: No--31.569700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2231CCD286F640B79EFCA7F9C8E06BA1ciscocom_" MIME-Version: 1.0 Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:15:59 -0000 --_000_2231CCD286F640B79EFCA7F9C8E06BA1ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Did we already conclude that this is a BCP and not Informational? We should= just put it in the latter category and move on/progress. Cheers, Rajiv Sent from my Phone On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" > wrote: On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s > wrote: I can't understand why it would be such a big deal to clarify that, even in= the limited context of stateful solutions, it is only for networks that do= n't support more transparent transition solutions that 464XLAT is THE recom= mended solution. I believe we all agree that 464xlat is suboptimal in terms of transparency = and that other technologies provide better transparency. I believe we also = agree that this is not a strict requirement for 464xlat because many of the= target scenarios are networks that already run carrier-operated NAT, which= of course is not transparent. The only thing we disagree on is what the "b= est" in "best practice" should refer to. Right? With that in mind - if we said that the "best" in "best" practice refers to= "the best way of running IPv4 over IPv6 when combining stateful and statel= ess NAT64?", or "the best way of running IPv4 over IPv6 in networks that ca= nnot support encapsulation"? Could we agree on that? Cheers, Lorenzo _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_2231CCD286F640B79EFCA7F9C8E06BA1ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Did we already conclude that this is a BCP and not Informational? We s= hould just put it in the latter category and move on/progress.

Cheers,
Rajiv

Sent from my Phone

On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s= <despres.r= emi@laposte.net> wrote:
I can't understand why it would be such a big deal to clarify that, even in= the limited context of stateful solutions, it is only for networks that do= n't support more transparent transition solutions that 464XLAT is THE recom= mended solution.

I believe we all agree that 464xlat is suboptimal in terms of transpar= ency and that other technologies provide better transparency. I believe we = also agree that this is not a strict requirement for 464xlat because many o= f the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent.= The only thing we disagree on is what the "best" in "best p= ractice" should refer to. Right?

With that in mind - if we said that the "best" in "best= " practice refers to "the best way of running IPv4 over IPv6 when= combining stateful and stateless NAT64?", or "the best way of ru= nning IPv4 over IPv6 in networks that cannot support encapsulation"?

Could we agree on that?

Cheers,
Lorenzo
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_2231CCD286F640B79EFCA7F9C8E06BA1ciscocom_-- From cb.list6@gmail.com Fri Aug 10 07:25:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3983721F84F4 for ; Fri, 10 Aug 2012 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsy9oKTrcZeg for ; Fri, 10 Aug 2012 07:25:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16D21F84DA for ; Fri, 10 Aug 2012 07:25:54 -0700 (PDT) Received: by lahm15 with SMTP id m15so946544lah.31 for ; Fri, 10 Aug 2012 07:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EYalsfn/dk4lvINEYsEWS8nxqyoowuxr6TKOjgGcc9A=; b=HZVFt/ox4pEFsOFOz+eM1mMqCKPToifOAObDYTMT0heHZlqhH1GJk14kCyTmPEhNgD fZGqiVjGg//fFxR7vhYuo1gS8GoH+ayedSJRiHg8YYUsOzhjsJtwnJf750gFp3E+UjyG k/9XPSOzLREwMuvbcEsaMEX0gMNcR2bNKOUBZLBJYqNJXC+0qyhihz2zU7SjujoYhiKy /4bJlF/mpTLuuIIgUg1mU28PDfc2LD/yezQ7Lda5S/OsUkqHbG3vxyquPSM1FKG/Q8KQ DVYncqpbGjgVqw3jtH4eZm3K/+KD81CvrUyC6QcYVP/WlQytlu2cAtOSl2dObwh1fjCt XWuw== MIME-Version: 1.0 Received: by 10.112.84.39 with SMTP id v7mr2557897lby.15.1344608753955; Fri, 10 Aug 2012 07:25:53 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 10 Aug 2012 07:25:53 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 10 Aug 2012 07:25:53 -0700 (PDT) In-Reply-To: <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> Date: Fri, 10 Aug 2012 07:25:53 -0700 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=f46d04016d5d24329004c6ea1f95 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:25:56 -0000 --f46d04016d5d24329004c6ea1f95 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" wrote: > > Did we already conclude that this is a BCP and not Informational? We should just put it in the latter category and move on/progress. > > Yes, afaik, the chairs have accepted bcp status and have accepted the bcp scenario text. The chairs also direct the WG to move on to any remainig technical issuess. http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html CB > Cheers, > Rajiv > > Sent from my Phone > > On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" wrote: > >> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s wrote: >>> >>> I can't understand why it would be such a big deal to clarify that, even in the limited context of stateful solutions, it is only for networks that don't support more transparent transition solutions that 464XLAT is THE recommended solution. >> >> >> I believe we all agree that 464xlat is suboptimal in terms of transparency and that other technologies provide better transparency. I believe we also agree that this is not a strict requirement for 464xlat because many of the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent. The only thing we disagree on is what the "best" in "best practice" should refer to. Right? >> >> With that in mind - if we said that the "best" in "best" practice refers to "the best way of running IPv4 over IPv6 when combining stateful and stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks that cannot support encapsulation"? >> >> Could we agree on that? >> >> Cheers, >> Lorenzo >> >> _______________________________________________ >> >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04016d5d24329004c6ea1f95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
>
> Did we already conclude that this is a BCP and not Informational? We s= hould just put it in the latter category and move on/progress.
>
>

Yes, afaik, the chairs have accepted bcp status and have accepted the bc= p scenario text.

The chairs also direct the WG to move on to any remainig technical issue= ss.

http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html

CB

> Cheers,
> Rajiv
>
> Sent from my Phone
>
> On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
>> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>
>>> I can't understand why it would be such a big deal to clar= ify that, even in the limited context of stateful solutions, it is only for= networks that don't support more transparent transition solutions that= 464XLAT is THE recommended solution.
>>
>>
>> I believe we all agree that 464xlat is suboptimal in terms of tran= sparency and that other technologies provide better transparency. I believe= we also agree that this is not a strict requirement for 464xlat because ma= ny of the target scenarios are networks that already run carrier-operated N= AT, which of course is not transparent. The only thing we disagree on is wh= at the "best" in "best practice" should refer to. Right= ?
>>
>> With that in mind - if we said that the "best" in "= best" practice refers to "the best way of running IPv4 over IPv6 = when combining stateful and stateless NAT64?", or "the best way o= f running IPv4 over IPv6 in networks that cannot support encapsulation"= ;?
>>
>> Could we agree on that?
>>
>> Cheers,
>> Lorenzo
>>
>> _______________________________________________
>>
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--f46d04016d5d24329004c6ea1f95-- From livio.zanol.puppim@gmail.com Wed Aug 8 09:46:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7127C21F8629 for ; Wed, 8 Aug 2012 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+kfaODDHEpO for ; Wed, 8 Aug 2012 09:46:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C45FC21F8622 for ; Wed, 8 Aug 2012 09:46:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1631574obb.31 for ; Wed, 08 Aug 2012 09:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MSCjrmc/mZCNkfzlfdUcz56zEtl5K6FWHLdMEH+ls2s=; b=S0LJUBnysIDadbhX/kMY27kH8u4PgrqLYwxk7nf61kypbp8Z5H4UBYi+26pd8VODLI LpYdFWOnqWwLFe1YJxx4YH37/fGB4F+Po7cVf1YNprW4WHiBQZ4tGpUz0WKuusfUbhrk hUPYZKGWU4O72rRb8QEagcvpld68odqP+Xb8SYR8vrutUz0bOtPPLvJNw1KF0i91vunl EYzZvkEkJVYhWkJU9+/svOVYeGTJuBZMSkEUzn/SnBZ9gmFhVYCF6w5QnYHLKIGpsUDe SrnPmgc17uRatJZ+/cp6ws8gaB7KLfJg3bDR3hECERQ/HZIlLtNAVBq8HQR3ad9oeX9h Obkw== MIME-Version: 1.0 Received: by 10.182.167.101 with SMTP id zn5mr31371664obb.60.1344444387309; Wed, 08 Aug 2012 09:46:27 -0700 (PDT) Received: by 10.76.22.230 with HTTP; Wed, 8 Aug 2012 09:46:27 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> Date: Wed, 8 Aug 2012 13:46:27 -0300 Message-ID: From: Livio Zanol Puppim To: Ronald Bonica Content-Type: multipart/alternative; boundary=e89a8f83a703203a1104c6c3da67 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:28:59 -0700 Cc: "" , "" , Alice Russo , "" , RFC Errata System , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:46:29 -0000 --e89a8f83a703203a1104c6c3da67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ronald, As gunter, I also do not know enough about the IETF processing methodologies, but, as long as there is an update reference in RFC 5375 linking to RFC 6164, I think this will do the job. Reading the "IESG Processing of RFC Errata for the IETF Stream" ( http://www.ietf.org/iesg/statement/errata-processing.html) I have encountered some information that could guide the group decision: "(...) Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC ... Guidelines for review are: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. (...)" So, in my understanding: - This does not fix a 'bug' in the RFC, since it was published correctly as said by Brain. - The /127 information in section B.2.2 of RFC 5375 is wrong and definatelly causes *significant confusion* as stated in the guideline 1 above. I think that the best solution for this situation is what you're proposing. May I do something now? Do I need to submit a new errata to RFC 6164? Best Regards, Livio Zanol Puppim 2012/8/8 Ronald Bonica > Livo,**** > > ** ** > > RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 should > have updated 5375. If we issue an errata against 6164 that causes 6164 to > update 5375, would that fix the problem?**** > > ** ** > > > = Ron > **** > > ** ** > > ** ** > > *From:* Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] > *Sent:* Tuesday, August 07, 2012 7:08 PM > *To:* Ronald Bonica > *Cc:* Alice Russo; Brian E Carpenter; Fred Baker (fred); = ; > ; ; ; > ; RFC Errata System > > *Subject:* Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)**** > > ** ** > > Hello guys.**** > > ** ** > > Just to give you more information:**** > > - RFC 5375 state that you should not use /127 address and makes a > reference to RFC 3627.**** > > ** ** > > - RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 > and 5375 are potentially wrong, but did not make any recommendation about > it.**** > > ** ** > > - RFC 6547 was published to overcome this error, and proposes that RFC > 3627 should move to historic status, updating the RFC 6177, but again, di= d > not mention RFC 5375.**** > > ** ** > > - An e-mail has been sent to the WG of the RFC 6547, but no answers were > given. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html)*= * > ** > > ** ** > > - I've sent an erratum to RFC 5375 about this, which you guys are > discussing.**** > > ** ** > > So, what to do next?**** > > Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update > to RFC 5375?**** > > ** ** > > I really don't know. As I've stated in an e-mail to rfc-interest mailing > list, I'm just a reader and saw this /127 text while reading RFC 5375.***= * > > ** ** > > The only thing that I'm sure, is that other readers of RFC 5375 would not > want to know that the recommendation about /127, at B.2.2 sector is > misguided after they have elaborated an address assignment project. > Sometimes, you only read the text, and do not click on every RFC linked i= n > it.**** > > ** ** > > I have full confidence in the WG, and I'm sure you will find the right > solution.**** > > ** ** > > Thank you for your time. Best regards,**** > > ** ** > > L=EDvio Zanol Puppim**** > > ** ** > > 2012/8/7 Ronald Bonica **** > > Hi Alice, > > Thanks for this reminder! I will consult with the WG and IESG to make sur= e > that nobody objects. > > Ron**** > > > > -----Original Message----- > > From: Alice Russo [mailto:arusso@amsl.com] > > Sent: Tuesday, August 07, 2012 3:55 PM > > To: Ronald Bonica > > Cc: Brian E Carpenter; Fred Baker (fred); ; > > ; ; > > ; ; ; > > RFC Errata System > > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > >**** > > > Ron, > > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > > in an errata. > > > > > > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > > metadata-errata.html. If there is an errata report regarding the > > metadata of an RFC *and* the verifying party marks it as Verified, the > > RFC Editor will update the RFC's metadata accordingly (which appears in > > the RFC Index, info page, etc.). > > > > Thank you. > > RFC Editor/ar > > > > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > > > > > Brian, > > > > > > I agree that Errata 3309 should be put into the "hold for update" > > state, because RFC 5375 was not wrong when it was published. > > > > > > However, we need to figure out what to do about RFC 6164. I dimly > > recall a conversation about this when RFC 6164 was published. The > > consensus was that RFC 6164 trumps RFC 5375 because the former is on > > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > > doesn't need to update RFC 5375. > > > > > > Looking back on it, this argument is weak. How would the reader of > > 5375 know that RFC 6164 exists if it weren't for the update information > > in the metadata? > > > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > > in an errata. > > > > > > Ron > > > > > > > > >> -----Original Message----- > > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > >> Behalf Of Brian E Carpenter > > >> Sent: Tuesday, August 07, 2012 1:59 PM > > >> To: Fred Baker (fred) > > >> Cc: ; ; > > >> ; ; > > >> ; ; RFC Errata System > > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > >> > > >> Wait a minute. > > >> > > >> How can this be described as an error in 5375? 5375 was not wrong > > >> when published. > > >> > > >> The error was in 6164, which failed to formally update 5375. > > >> > > >> Surely this is a "hold for update" not "verified". > > >> > > >> Regards > > >> Brian > > >> > > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > > >>> We agree that this erratum is valid. > > >>> > > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > > >>> > > >>>> The following errata report has been submitted for RFC5375, > > >>>> "IPv6 Unicast Address Assignment Considerations". > > >>>> > > >>>> -------------------------------------- > > >>>> You may review the report below and at: > > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > > >>>> > > >>>> -------------------------------------- > > >>>> Type: Technical > > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > > >>>> > > >>>> > > >>>> Section: B.2.2 > > >>>> > > >>>> Original Text > > >>>> ------------- > > >>>> B.2.2. /127 Addresses > > >>>> > > >>>> > > >>>> > > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > > 3021 > > >>>> > > >>>> [RFC3021], is not valid and should be strongly discouraged as > > >>>> > > >>>> documented in RFC 3627 [RFC3627]. > > >>>> > > >>>> Corrected Text > > >>>> -------------- > > >>>> B.2.2. /127 Addresses > > >>>> > > >>>> > > >>>> > > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > > 3021 > > >>>> > > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > > >>>> > > >>>> Notes > > >>>> ----- > > >>>> Maybe just remove the section B.2.2? > > >>>> > > >>>> Instructions: > > >>>> ------------- > > >>>> This errata is currently posted as "Reported". If necessary, > > please > > >>>> use "Reply All" to discuss whether it should be verified or > > >> rejected. > > >>>> When a decision is reached, the verifying party (IESG) can log in > > >>>> to change the status and edit the report, if necessary. > > >>>> > > >>>> -------------------------------------- > > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > > >>>> -------------------------------------- > > >>>> Title : IPv6 Unicast Address Assignment > > Considerations > > >>>> Publication Date : December 2008 > > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > > >> Bonness, C. Hahn > > >>>> Category : INFORMATIONAL > > >>>> Source : IPv6 Operations > > >>>> Area : Operations and Management > > >>>> Stream : IETF > > >>>> Verifying Party : IESG > > >>> > > >>> ---------------------------------------------------- > > >>> The ignorance of how to use new knowledge stockpiles exponentially. > > >>> - Marshall McLuhan > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------------------- > > - > > >>> - > > >> - > > >>> -- > > >>> > > >>> _______________________________________________ > > >>> v6ops mailing list > > >>> v6ops@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/v6ops > > >> > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops**** > > > > **** > > ** ** > > -- **** > --=20 []'s L=EDvio Zanol Puppim --e89a8f83a703203a1104c6c3da67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ronald,

As gunter, I also do not know enough about the IETF processi= ng methodologies, but, as long as there is an update reference in RFC 5375 = linking to RFC 6164, I think this will do the job.

Reading the "= ;IESG Processing of RFC Errata for the IETF Stream" (http://www.ietf.org/ie= sg/statement/errata-processing.html) I have encountered some informatio= n that could guide the group decision:

"(...) Errata are meant to f= ix "bugs" in the specification and should not be used to change what the commu= nity meant when it approved the RFC

...
Guidelines for review are:
  1. Only errors that could= cause implementation or deployment problems or significant confusion should be Approved.
    2. =
(...)"

So, in my understanding:
- This does not fix a &= #39;bug' in=A0 the RFC, since it was published correctly as said by Bra= in.
- The /127 information in section B.2.2 of RFC 5375 is wrong and definatell= y causes significant confusion as stated in the guideline 1 above.
I think that the best solution for this situation is what you're = proposing. May I do something now? Do I need to submit a new errata to RFC = 6164?

Best Regards,
Livio Zanol Puppim

2= 012/8/8 Ronald Bonica <rbonica@juniper.net>

Livo,

=A0

RFC 6164 speaks directly to the /127 issue. S= o, it seems that 6164 should have updated 5375. If we issue an errata again= st 6164 that causes 6164 to update 5375, would that fix the problem?=

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0Ron

=A0<= /p>

=A0

From:= Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com]
Sent: Tuesday, August 07, 2012 7:08 PM
To: Ronald BonicaCc: Alice Russo; Brian E Carpenter; Fred Baker (fred); <v6ops@ietf.org>; <fred.baker@cisco.co= m>; <Olaf.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>; RFC Errata Sy= stem


Subject: Re: [v6ops] [Technical Errata Re= ported] RFC5375 (3309)

=A0

Hello guys.

=A0

Just to give you more informatio= n:

- RFC 5375 state that= you should not use /127 address and makes a reference to RFC 3627.<= u>

=A0

- RFC 6177 came out as a standard, and in section 4 states t= hat RFCs 3627 and 5375 are potentially wrong, but did not make any recommen= dation about it.

=A0

- RFC 6547 was published to overcome this error, and propose= s that RFC 3627 should move to historic status, updating the RFC 6177, but = again, did not mention RFC 5375.

=A0

- An e-mail has been sent to the WG of the RFC 6547, but no = answers were given. (http://www.ietf.org/mail-archive/we= b/ipv6/current/msg16203.html)

=A0

- I've sent an erratum to RFC 5375 about this, which you= guys are discussing.

=A0

So, what to do next?

Publish an erratum in RFC 5375? Publish a RF= C 6547-bis? Publish an update to RFC 5375?

=A0

I really don't k= now. As I've stated in an e-mail to rfc-interest mailing list, I'm = just a reader and saw this /127 text while reading RFC 5375.<= /p>

=A0

The only thing that I'm sure, is that other readers of R= FC 5375 would not want to know that the recommendation about /127, at B.2.2= sector is misguided after they have elaborated an address assignment proje= ct. Sometimes, you only read the text, and do not click on every RFC linked= in it.

=A0

I have full confidence in the WG, and I'm sure you will = find the right solution.

=A0

Thank you for your time. Best regards,=

=A0

L=EDvio Zanol Puppim

=A0

2012/8/7 Ronald Bonica <= ;rbonica@juniper.n= et>

Hi Alice,

Thanks = for this reminder! I will consult with the WG and IESG to make sure that no= body objects.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ron


> -----Original Message-----
> From: Alice Ru= sso [mailto:arusso@ams= l.com]
> Sent: Tuesday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Carpenter; Fred Baker (fred); &l= t;v6ops@ietf.org>= ;;
> <livio.zanol.puppim@gmail.com>; <fred.baker@cisco.com>;
> <Ol= af.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>;
> RFC Errata System
> Subject: Re: [v6ops] [Technical Errata Repor= ted] RFC5375 (3309)
>

> Ron,
>
> > I wi= ll check with the RFC editor to see if it is OK to add an UPDATE
> in an errata.
>
>
> Please see this IESG statement: = http:= //www.ietf.org/iesg/statement/rfc-
> metadata-errata.html. =A0If = there is an errata report regarding the
> metadata of an RFC *and* the verifying party marks it as Verified, the=
> RFC Editor will update the RFC's metadata accordingly (which a= ppears in
> the RFC Index, info page, etc.).
>
> Thank yo= u.
> RFC Editor/ar
>
> On Aug 7, 2012, at 11:36 AM, Ronald Boni= ca wrote:
>
> > Brian,
> >
> > I agree tha= t Errata 3309 should be put into the "hold for update"
> st= ate, because RFC 5375 was not wrong when it was published.
> >
> > However, we need to figure out what to do about RFC = 6164. I dimly
> recall a conversation about this when RFC 6164 was pu= blished. The
> consensus was that RFC 6164 trumps RFC 5375 because th= e former is on
> the Standards Track while the later is only INFORMATIONAL. So, RFC 616= 4
> doesn't need to update RFC 5375.
> >
> > Lo= oking back on it, this argument is weak. How would the reader of
> 53= 75 know that RFC 6164 exists if it weren't for the update information > in the metadata?
> >
> > I will check with the RFC e= ditor to see if it is OK to add an UPDATE
> in an errata.
> >= ;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron
> >
> >
> >> -----Original Message-----
> >> From= : v6ops-bounces= @ietf.org [mailto:v6ops-bounces@ietf.org] On
> >> Behalf Of Brian E Carpenter
> >> Sent: Tuesday, A= ugust 07, 2012 1:59 PM
> >> To: Fred Baker (fred)
> >&= gt; Cc: <v6ops@ietf.= org>; <livio.zanol.puppim@gmail.com>;
> >> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems.com>;
> >>= ; <cpopovic@cisc= o.com>; <gu= nter@cisco.com>; RFC Errata System
> >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (330= 9)
> >>
> >> Wait a minute.
> >>
>= ; >> How can this be described as an error in 5375? 5375 was not wron= g
> >> when published.
> >>
> >> The error w= as in 6164, which failed to formally update 5375.
> >>
> = >> Surely this is a "hold for update" not "verified&qu= ot;.
> >>
> >> Regards
> >> =A0 Brian
> &= gt;>
> >> On 07/08/2012 16:23, Fred Baker (fred) wrote:
&= gt; >>> We agree that this erratum is valid.
> >>><= br> > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote:
&= gt; >>>
> >>>> The following errata report has b= een submitted for RFC5375,
> >>>> "IPv6 Unicast Addr= ess Assignment Considerations".
> >>>>
> >>>> ----------------------------= ----------
> >>>> You may review the report below and at:=
> >>>> http://www.rfc-editor.or= g/errata_search.php?rfc=3D5375&eid=3D3309
> >>>>
> >>>> ----------------------------= ----------
> >>>> Type: Technical
> >>>>= ; Reported by: L=EDvio Zanol Pereira de Souza Puppim
> >>>&g= t; <li= vio.zanol.puppim@gmail.com>
> >>>>
> >>>> Section: B.2.2
> >&= gt;>>
> >>>> Original Text
> >>>>= -------------
> >>>> B.2.2. /127 Addresses
> >&= gt;>>
> >>>>
> >>>>
> >>>> =A0= The usage of the /127 addresses, the equivalent of IPv4's RFC
> 3= 021
> >>>>
> >>>> =A0[RFC3021], is not = valid and should be strongly discouraged as
> >>>>
> >>>> =A0documented in RFC 3627 [R= FC3627].
> >>>>
> >>>> Corrected Text> >>>> --------------
> >>>> B.2.2. /127= Addresses
> >>>>
> >>>>
> >>>>
= > >>>> =A0The usage of the /127 addresses, the equivalent of= IPv4's RFC
> 3021
> >>>>
> >>>&= gt; =A0[RFC3021], is valid as stated in RFC 6164 [RFC 6164].
> >>>>
> >>>> Notes
> >>>&g= t; -----
> >>>> Maybe just remove the section B.2.2?
&= gt; >>>>
> >>>> Instructions:
> >>= ;>> -------------
> >>>> This errata is currently posted as "Reported&quo= t;. If necessary,
> please
> >>>> use "Reply A= ll" to discuss whether it should be verified or
> >> rejec= ted.
> >>>> When a decision is reached, the verifying party (IESG= ) can log in
> >>>> to change the status and edit the rep= ort, if necessary.
> >>>>
> >>>> ------= --------------------------------
> >>>> RFC5375 (draft-ietf-v6ops-addcon-10)
> >>= >> --------------------------------------
> >>>> Ti= tle =A0 =A0 =A0 =A0 =A0 =A0 =A0 : IPv6 Unicast Address Assignment
> C= onsiderations
> >>>> Publication Date =A0 =A0: December 2008
> >&= gt;>> Author(s) =A0 =A0 =A0 =A0 =A0 : G. Van de Velde, C. Popoviciu, = T. Chown, O.
> >> Bonness, C. Hahn
> >>>> Cat= egory =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL
> >>>> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: IPv6 Operations> >>>> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations an= d Management
> >>>> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: I= ETF
> >>>> Verifying Party =A0 =A0 : IESG
> >>>
> >>> ------------------------------------= ----------------
> >>> The ignorance of how to use new knowl= edge stockpiles exponentially.
> >>> =A0 - Marshall McLuhan<= br> > >>>
> >>>
> >>>
> >>= ;> -------------------------------------------------------------------> -
> >>> -
> >> -
> >>> --<= br> > >>>
> >>> ____________________________________= ___________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
>= ; >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >> ____________________________________________= ___
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https:= //www.ietf.org/mailman/listinfo/v6ops



=A0

--




--
[]'s
L=EDvio Zanol Puppim
--e89a8f83a703203a1104c6c3da67-- From gvandeve@cisco.com Wed Aug 8 02:36:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF01111E80D5 for ; Wed, 8 Aug 2012 02:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V9xX4MOGJtn for ; Wed, 8 Aug 2012 02:36:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96D21F856D for ; Wed, 8 Aug 2012 02:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1438; q=dns/txt; s=iport; t=1344418560; x=1345628160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GuGQeEhpFWGETJRb8p4Xu2OdXU6MjHrrpLvttPo6wDg=; b=giEhaSzFynTUB1QCBgeGF9j2HQNajSHnGX5jlWORyATvNVF3j2qHZrdA EKhofiFnv5WFbvVWNSqh73NRnWGWKpLH9wyrXXamv5dTzyGDlTLl7feSW mKZ7cLqz7E9TF0RTNVnzhatcsVtFnTnh8jXRfPZyyovFkYyL/9BtId94l M=; X-IronPort-AV: E=Sophos;i="4.77,732,1336348800"; d="scan'208";a="109536172" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 08 Aug 2012 09:36:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q789Zx2o026776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 09:35:59 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.122]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 04:35:59 -0500 From: "Gunter Van de Velde (gvandeve)" To: SM , Brian E Carpenter , "Fred Baker (fred)" Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNc9/hDzwzSeK+NE2Vr68ZU+v1+JdOzViAgAArYICAAKLLgIAADdiA Date: Wed, 8 Aug 2012 09:35:59 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2406CB34@xmb-aln-x12.cisco.com> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <6.2.5.6.2.20120807203008.0a6ca648@resistor.net> In-Reply-To: <6.2.5.6.2.20120807203008.0a6ca648@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.103] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19094.000 x-tm-as-result: No--42.573300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:29:17 -0700 Cc: "" , "" , "" , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 09:36:00 -0000 One of the most common questions people making NW design ask themselves is:= What for IPv6 prefix will I place on my p2p links. Now exactly that is now wrong in the RFC5375. Maybe it is not an Errata as the RFC was correct at time of publishing... i= t for sure is wrong right now. If possible I would like to see the rfc updated with this significant addre= ss related change. Unfortunately I do not know enough about IETF'ology to identify the best wa= y to get this done. (Errata, RFC update, new RFC?, RFC5375bis?) G/ -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: 08 August 2012 05:42 To: Brian E Carpenter; Fred Baker (fred) Cc: ; ; ; ; ; ; = RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) At 10:59 07-08-2012, Brian E Carpenter wrote: >Wait a minute. > >How can this be described as an error in 5375? 5375 was not wrong when=20 >published. > >The error was in 6164, which failed to formally update 5375. > >Surely this is a "hold for update" not "verified". I don't think that the erratum fits as verified. RFC 5375 was published in= December 2008. RFC 6164 was published in April 2011. RFC 5375 was correc= t at the time of publication. I suggest leaving it as is. Regards, -sm=20 From bclaise@cisco.com Wed Aug 8 04:01:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A6C21F86D4 for ; Wed, 8 Aug 2012 04:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isBc667O5CpG for ; Wed, 8 Aug 2012 04:01:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4AC21F858E for ; Wed, 8 Aug 2012 04:01:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q78B0vLq016311; Wed, 8 Aug 2012 13:00:57 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q78B0txL007929; Wed, 8 Aug 2012 13:00:55 +0200 (CEST) Message-ID: <502246E7.1010900@cisco.com> Date: Wed, 08 Aug 2012 13:00:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20120806142829.81256B1E003@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 10 Aug 2012 08:29:17 -0700 Cc: "" , "" , "" , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 11:01:31 -0000 I just "verified" this one. Regards, Benoit. > We agree that this erratum is valid. > > On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5375, >> "IPv6 Unicast Address Assignment Considerations". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309 >> >> -------------------------------------- >> Type: Technical >> Reported by: Lívio Zanol Pereira de Souza Puppim >> >> Section: B.2.2 >> >> Original Text >> ------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is not valid and should be strongly discouraged as >> >> documented in RFC 3627 [RFC3627]. >> >> Corrected Text >> -------------- >> B.2.2. /127 Addresses >> >> >> >> The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 >> >> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. >> >> Notes >> ----- >> Maybe just remove the section B.2.2? >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5375 (draft-ietf-v6ops-addcon-10) >> -------------------------------------- >> Title : IPv6 Unicast Address Assignment Considerations >> Publication Date : December 2008 >> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > From rbonica@juniper.net Wed Aug 8 06:44:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B41A21F85DA for ; Wed, 8 Aug 2012 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.27 X-Spam-Level: X-Spam-Status: No, score=-106.27 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPbHpMN6nUTT for ; Wed, 8 Aug 2012 06:44:51 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49021F85D8 for ; Wed, 8 Aug 2012 06:44:45 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUCJtSXDMxvtCKFaKJ7aPNl8MLGhWEowM@postini.com; Wed, 08 Aug 2012 06:44:50 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Aug 2012 06:44:01 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Aug 2012 06:44:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 8 Aug 2012 09:44:00 -0400 From: Ronald Bonica To: Livio Zanol Puppim Date: Wed, 8 Aug 2012 09:43:58 -0400 Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: Ac108W7zRSWHe6UqSq+gTNrNvlyZfAAehoiw Message-ID: <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D77189AD37EMBX01WFjnprn_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:29:17 -0700 Cc: "" , "" , Alice Russo , "" , RFC Errata System , "" , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 13:44:52 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D77189AD37EMBX01WFjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Livo, RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 should h= ave updated 5375. If we issue an errata against 6164 that causes 6164 to up= date 5375, would that fix the problem? = Ron From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] Sent: Tuesday, August 07, 2012 7:08 PM To: Ronald Bonica Cc: Alice Russo; Brian E Carpenter; Fred Baker (fred); ; ; ; ; <= gunter@cisco.com>; RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) Hello guys. Just to give you more information: - RFC 5375 state that you should not use /127 address and makes a reference= to RFC 3627. - RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 a= nd 5375 are potentially wrong, but did not make any recommendation about it= . - RFC 6547 was published to overcome this error, and proposes that RFC 3627= should move to historic status, updating the RFC 6177, but again, did not = mention RFC 5375. - An e-mail has been sent to the WG of the RFC 6547, but no answers were gi= ven. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html) - I've sent an erratum to RFC 5375 about this, which you guys are discussin= g. So, what to do next? Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update t= o RFC 5375? I really don't know. As I've stated in an e-mail to rfc-interest mailing li= st, I'm just a reader and saw this /127 text while reading RFC 5375. The only thing that I'm sure, is that other readers of RFC 5375 would not w= ant to know that the recommendation about /127, at B.2.2 sector is misguide= d after they have elaborated an address assignment project. Sometimes, you = only read the text, and do not click on every RFC linked in it. I have full confidence in the WG, and I'm sure you will find the right solu= tion. Thank you for your time. Best regards, L=EDvio Zanol Puppim 2012/8/7 Ronald Bonica > Hi Alice, Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects. Ron > -----Original Message----- > From: Alice Russo [mailto:arusso@amsl.com] > Sent: Tuesday, August 07, 2012 3:55 PM > To: Ronald Bonica > Cc: Brian E Carpenter; Fred Baker (fred); >; > >; >; > >; >; >; > RFC Errata System > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > Ron, > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > metadata-errata.html. If there is an errata report regarding the > metadata of an RFC *and* the verifying party marks it as Verified, the > RFC Editor will update the RFC's metadata accordingly (which appears in > the RFC Index, info page, etc.). > > Thank you. > RFC Editor/ar > > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > > > Brian, > > > > I agree that Errata 3309 should be put into the "hold for update" > state, because RFC 5375 was not wrong when it was published. > > > > However, we need to figure out what to do about RFC 6164. I dimly > recall a conversation about this when RFC 6164 was published. The > consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > doesn't need to update RFC 5375. > > > > Looking back on it, this argument is weak. How would the reader of > 5375 know that RFC 6164 exists if it weren't for the update information > in the metadata? > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > > Ron > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6= ops-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Tuesday, August 07, 2012 1:59 PM > >> To: Fred Baker (fred) > >> Cc: >; >; > >> >; >; > >> >; >; RFC Errata System > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > >> > >> Wait a minute. > >> > >> How can this be described as an error in 5375? 5375 was not wrong > >> when published. > >> > >> The error was in 6164, which failed to formally update 5375. > >> > >> Surely this is a "hold for update" not "verified". > >> > >> Regards > >> Brian > >> > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > >>> We agree that this erratum is valid. > >>> > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >>> > >>>> The following errata report has been submitted for RFC5375, > >>>> "IPv6 Unicast Address Assignment Considerations". > >>>> > >>>> -------------------------------------- > >>>> You may review the report below and at: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > >>>> > >>>> -------------------------------------- > >>>> Type: Technical > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> > > >>>> > >>>> Section: B.2.2 > >>>> > >>>> Original Text > >>>> ------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is not valid and should be strongly discouraged as > >>>> > >>>> documented in RFC 3627 [RFC3627]. > >>>> > >>>> Corrected Text > >>>> -------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > >>>> > >>>> Notes > >>>> ----- > >>>> Maybe just remove the section B.2.2? > >>>> > >>>> Instructions: > >>>> ------------- > >>>> This errata is currently posted as "Reported". If necessary, > please > >>>> use "Reply All" to discuss whether it should be verified or > >> rejected. > >>>> When a decision is reached, the verifying party (IESG) can log in > >>>> to change the status and edit the report, if necessary. > >>>> > >>>> -------------------------------------- > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > >>>> -------------------------------------- > >>>> Title : IPv6 Unicast Address Assignment > Considerations > >>>> Publication Date : December 2008 > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > >> Bonness, C. Hahn > >>>> Category : INFORMATIONAL > >>>> Source : IPv6 Operations > >>>> Area : Operations and Management > >>>> Stream : IETF > >>>> Verifying Party : IESG > >>> > >>> ---------------------------------------------------- > >>> The ignorance of how to use new knowledge stockpiles exponentially. > >>> - Marshall McLuhan > >>> > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> - > >> - > >>> -- > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops -- --_000_13205C286662DE4387D9AF3AC30EF456D77189AD37EMBX01WFjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Livo,

 

<= p class=3DMsoNormal>RFC 6164 speaks directly to the /127 issue. So, = it seems that 6164 should have updated 5375. If we issue an errata against = 6164 that causes 6164 to update 5375, would that fix the problem?

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Ron

 

=

 

From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gm= ail.com]
Sent: Tuesday, August 07, 2012 7:08 PM
To: Ro= nald Bonica
Cc: Alice Russo; Brian E Carpenter; Fred Baker (fred)= ; <v6ops@ietf.org>; <fred.baker@cisco.com>; <Olaf.Bonness@t-= systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>; RFC = Errata System
Subject: Re: [v6ops] [Technical Errata Reported] RF= C5375 (3309)

&nb= sp;

Hello guys.

 

= Just to give you more information:

- RFC 5375 state that you should not use /127 address and makes a ref= erence to RFC 3627.

&nbs= p;

- RFC 6177 came out as a standa= rd, and in section 4 states that RFCs 3627 and 5375 are potentially wrong, = but did not make any recommendation about it.

 

- RFC= 6547 was published to overcome this error, and proposes that RFC 3627 shou= ld move to historic status, updating the RFC 6177, but again, did not menti= on RFC 5375.

 

- An e-mail has been sent to the WG of= the RFC 6547, but no answers were given. (http://www.ietf.org/mail-archiv= e/web/ipv6/current/msg16203.html)

 

- I've sent a= n erratum to RFC 5375 about this, which you guys are discussing.=

 

So, what to do next?

Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an up= date to RFC 5375?

 =

I really don't know. As I've stat= ed in an e-mail to rfc-interest mailing list, I'm just a reader and saw thi= s /127 text while reading RFC 5375.

 

The only thing = that I'm sure, is that other readers of RFC 5375 would not want to know tha= t the recommendation about /127, at B.2.2 sector is misguided after they ha= ve elaborated an address assignment project. Sometimes, you only read the t= ext, and do not click on every RFC linked in it.

<= p class=3DMsoNormal> 

I = have full confidence in the WG, and I'm sure you will find the right soluti= on.

 

Thank you for your time. Best regards,

 

L=EDvio Zanol Puppim

 

2012/8/7 Ronald Boni= ca <rbonica@jun= iper.net>

Hi Alice,

Thanks= for this reminder! I will consult with the WG and IESG to make sure that n= obody objects.

              &nbs= p;    Ron


> -----O= riginal Message-----
> From: Alice Russo [mailto:arusso@amsl.com]
> Sent: Tuesday= , August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Car= penter; Fred Baker (fred); <v6ops@ietf.org>;
> <livio.zanol.puppim@gmail.com>; &l= t;fred.baker@cisc= o.com>;
> <Olaf.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>;> RFC Errata System
> Subject: Re: [v6ops] [Technical Errata Rep= orted] RFC5375 (3309)
>

> Ron,
>
> > I will = check with the RFC editor to see if it is OK to add an UPDATE
> in an= errata.
>
>
> Please see this IESG statement: http://www.ietf= .org/iesg/statement/rfc-
> metadata-errata.html.  If there i= s an errata report regarding the
> metadata of an RFC *and* the verif= ying party marks it as Verified, the
> RFC Editor will update the RFC= 's metadata accordingly (which appears in
> the RFC Index, info page,= etc.).
>
> Thank you.
> RFC Editor/ar
>
> On= Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote:
>
> > Brian,=
> >
> > I agree that Errata 3309 should be put into the = "hold for update"
> state, because RFC 5375 was not wrong w= hen it was published.
> >
> > However, we need to figure = out what to do about RFC 6164. I dimly
> recall a conversation about = this when RFC 6164 was published. The
> consensus was that RFC 6164 t= rumps RFC 5375 because the former is on
> the Standards Track while t= he later is only INFORMATIONAL. So, RFC 6164
> doesn't need to update= RFC 5375.
> >
> > Looking back on it, this argument is w= eak. How would the reader of
> 5375 know that RFC 6164 exists if it w= eren't for the update information
> in the metadata?
> >
= > > I will check with the RFC editor to see if it is OK to add an UPD= ATE
> in an errata.
> >
> >       &n= bsp;                     =                   Ron
> = >
> >
> >> -----Original Message-----
> >&= gt; From: v6ops= -bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> >> Behalf Of Br= ian E Carpenter
> >> Sent: Tuesday, August 07, 2012 1:59 PM
= > >> To: Fred Baker (fred)
> >> Cc: <v6ops@ietf.org>; <livio.zanol.pupp= im@gmail.com>;
> >> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems.com= >;
> >> <cpopovic@cisco.com>; <gunter@cisco.com>; RFC Errata System
> = >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)> >>
> >> Wait a minute.
> >>
> >= ;> How can this be described as an error in 5375? 5375 was not wrong
= > >> when published.
> >>
> >> The error w= as in 6164, which failed to formally update 5375.
> >>
> = >> Surely this is a "hold for update" not "verified&qu= ot;.
> >>
> >> Regards
> >>   Bria= n
> >>
> >> On 07/08/2012 16:23, Fred Baker (fred) = wrote:
> >>> We agree that this erratum is valid.
> &g= t;>>
> >>> On Aug 6, 2012, at 7:28 AM, RFC Errata Syst= em wrote:
> >>>
> >>>> The following errat= a report has been submitted for RFC5375,
> >>>> "IPv= 6 Unicast Address Assignment Considerations".
> >>>>=
> >>>> --------------------------------------
> &g= t;>>> You may review the report below and at:
> >>>= > http://www.rfc-editor.org/errata_search.php?r= fc=3D5375&eid=3D3309
> >>>>
> >>>&= gt; --------------------------------------
> >>>> Type: T= echnical
> >>>> Reported by: L=EDvio Zanol Pereira de Sou= za Puppim
> >>>> <livio.zanol.puppim@gmail.com>
> = >>>>
> >>>> Section: B.2.2
> >>&g= t;>
> >>>> Original Text
> >>>> ----= ---------
> >>>> B.2.2. /127 Addresses
> >>&g= t;>
> >>>>
> >>>>
> >>&g= t;>  The usage of the /127 addresses, the equivalent of IPv4's RFC<= br>> 3021
> >>>>
> >>>>  [RFC30= 21], is not valid and should be strongly discouraged as
> >>>= ;>
> >>>>  documented in RFC 3627 [RFC3627].
&= gt; >>>>
> >>>> Corrected Text
> >&g= t;>> --------------
> >>>> B.2.2. /127 Addresses> >>>>
> >>>>
> >>>>> >>>>  The usage of the /127 addresses, the equivalen= t of IPv4's RFC
> 3021
> >>>>
> >>>&= gt;  [RFC3021], is valid as stated in RFC 6164 [RFC 6164].
> >= ;>>>
> >>>> Notes
> >>>> -----=
> >>>> Maybe just remove the section B.2.2?
> >= >>>
> >>>> Instructions:
> >>>>= ; -------------
> >>>> This errata is currently posted as= "Reported". If necessary,
> please
> >>>>= ; use "Reply All" to discuss whether it should be verified or
= > >> rejected.
> >>>> When a decision is reached= , the verifying party (IESG) can log in
> >>>> to change = the status and edit the report, if necessary.
> >>>>
&= gt; >>>> --------------------------------------
> >>= ;>> RFC5375 (draft-ietf-v6ops-addcon-10)
> >>>> ---= -----------------------------------
> >>>> Title   &= nbsp;           : IPv6 Unicast Address Assignment<= br>> Considerations
> >>>> Publication Date   &nb= sp;: December 2008
> >>>> Author(s)       =     : G. Van de Velde, C. Popoviciu, T. Chown, O.
> >>= ; Bonness, C. Hahn
> >>>> Category       &= nbsp;    : INFORMATIONAL
> >>>> Source   &= nbsp;          : IPv6 Operations
> >>&= gt;> Area                : Opera= tions and Management
> >>>> Stream       &= nbsp;      : IETF
> >>>> Verifying Party &= nbsp;   : IESG
> >>>
> >>> -------------= ---------------------------------------
> >>> The ignorance = of how to use new knowledge stockpiles exponentially.
> >>> =   - Marshall McLuhan
> >>>
> >>>
>= >>>
> >>> ----------------------------------------= ---------------------------
> -
> >>> -
> >&g= t; -
> >>> --
> >>>
> >>> ____= ___________________________________________
> >>> v6ops mail= ing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/= listinfo/v6ops
> >>
> >> ______________________= _________________________
> >> v6ops mailing list
> >&= gt; v6ops@ietf.org<= br>> >> https://www.ietf.org/mailman/listinfo/v6ops<= /p>



 

--

= = --_000_13205C286662DE4387D9AF3AC30EF456D77189AD37EMBX01WFjnprn_-- From fred@cisco.com Wed Aug 8 09:05:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16D721F86BB for ; Wed, 8 Aug 2012 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.99 X-Spam-Level: X-Spam-Status: No, score=-109.99 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cmy4ggbtgur for ; Wed, 8 Aug 2012 09:05:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2517121F857D for ; Wed, 8 Aug 2012 09:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=37432; q=dns/txt; s=iport; t=1344441933; x=1345651533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YMDyZZwFuVM9EPEOIuXiAsB+Sjyi+O1v1014LVMeGNA=; b=MgdTpeJ5/z2ue41QXmuwB7yw6rBkE2CoOxIIni7bvcsxVhBNAtXoN6ZA EnbbQPkRBpTRw/qfcawsW9EDOit2qn9uOJeT/6TzEHwUcKPyPZbuqDKoq 9LdqREjU+2681ph797tqETCfhZ3OAQcn+qxuL0LaizYTwkNGEd0mhtHdg c=; X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208,217";a="109412558" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2012 16:05:32 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q78G5WPx009757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 16:05:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 11:05:32 -0500 From: "Fred Baker (fred)" To: Ronald Bonica Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNdX+jFXBggWswrE2BV8Ybtajh/w== Date: Wed, 8 Aug 2012 16:05:32 +0000 Message-ID: References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--50.330500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A6FEBEE1D81B48319779561E0DC873ABciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:29:17 -0700 Cc: "" , Livio Zanol Puppim , "" , Alice Russo , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:05:54 -0000 --_000_A6FEBEE1D81B48319779561E0DC873ABciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That seems to be a reasonable solution. On Aug 8, 2012, at 6:43 AM, Ronald Bonica wrote: Livo, RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 should h= ave updated 5375. If we issue an errata against 6164 that causes 6164 to up= date 5375, would that fix the problem? = Ron From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] Sent: Tuesday, August 07, 2012 7:08 PM To: Ronald Bonica Cc: Alice Russo; Brian E Carpenter; Fred Baker (fred); >; >; <= Olaf.Bonness@t-systems.com>; >; >; RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) Hello guys. Just to give you more information: - RFC 5375 state that you should not use /127 address and makes a reference= to RFC 3627. - RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 a= nd 5375 are potentially wrong, but did not make any recommendation about it= . - RFC 6547 was published to overcome this error, and proposes that RFC 3627= should move to historic status, updating the RFC 6177, but again, did not = mention RFC 5375. - An e-mail has been sent to the WG of the RFC 6547, but no answers were gi= ven. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html) - I've sent an erratum to RFC 5375 about this, which you guys are discussin= g. So, what to do next? Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update t= o RFC 5375? I really don't know. As I've stated in an e-mail to rfc-interest mailing li= st, I'm just a reader and saw this /127 text while reading RFC 5375. The only thing that I'm sure, is that other readers of RFC 5375 would not w= ant to know that the recommendation about /127, at B.2.2 sector is misguide= d after they have elaborated an address assignment project. Sometimes, you = only read the text, and do not click on every RFC linked in it. I have full confidence in the WG, and I'm sure you will find the right solu= tion. Thank you for your time. Best regards, L=EDvio Zanol Puppim 2012/8/7 Ronald Bonica > Hi Alice, Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects. Ron > -----Original Message----- > From: Alice Russo [mailto:arusso@amsl.com] > Sent: Tuesday, August 07, 2012 3:55 PM > To: Ronald Bonica > Cc: Brian E Carpenter; Fred Baker (fred); >; > >; >; > >; >; >; > RFC Errata System > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > Ron, > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > metadata-errata.html. If there is an errata report regarding the > metadata of an RFC *and* the verifying party marks it as Verified, the > RFC Editor will update the RFC's metadata accordingly (which appears in > the RFC Index, info page, etc.). > > Thank you. > RFC Editor/ar > > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > > > Brian, > > > > I agree that Errata 3309 should be put into the "hold for update" > state, because RFC 5375 was not wrong when it was published. > > > > However, we need to figure out what to do about RFC 6164. I dimly > recall a conversation about this when RFC 6164 was published. The > consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > doesn't need to update RFC 5375. > > > > Looking back on it, this argument is weak. How would the reader of > 5375 know that RFC 6164 exists if it weren't for the update information > in the metadata? > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > > Ron > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6= ops-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Tuesday, August 07, 2012 1:59 PM > >> To: Fred Baker (fred) > >> Cc: >; >; > >> >; >; > >> >; >; RFC Errata System > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > >> > >> Wait a minute. > >> > >> How can this be described as an error in 5375? 5375 was not wrong > >> when published. > >> > >> The error was in 6164, which failed to formally update 5375. > >> > >> Surely this is a "hold for update" not "verified". > >> > >> Regards > >> Brian > >> > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > >>> We agree that this erratum is valid. > >>> > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >>> > >>>> The following errata report has been submitted for RFC5375, > >>>> "IPv6 Unicast Address Assignment Considerations". > >>>> > >>>> -------------------------------------- > >>>> You may review the report below and at: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > >>>> > >>>> -------------------------------------- > >>>> Type: Technical > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> > > >>>> > >>>> Section: B.2.2 > >>>> > >>>> Original Text > >>>> ------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is not valid and should be strongly discouraged as > >>>> > >>>> documented in RFC 3627 [RFC3627]. > >>>> > >>>> Corrected Text > >>>> -------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > >>>> > >>>> Notes > >>>> ----- > >>>> Maybe just remove the section B.2.2? > >>>> > >>>> Instructions: > >>>> ------------- > >>>> This errata is currently posted as "Reported". If necessary, > please > >>>> use "Reply All" to discuss whether it should be verified or > >> rejected. > >>>> When a decision is reached, the verifying party (IESG) can log in > >>>> to change the status and edit the report, if necessary. > >>>> > >>>> -------------------------------------- > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > >>>> -------------------------------------- > >>>> Title : IPv6 Unicast Address Assignment > Considerations > >>>> Publication Date : December 2008 > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > >> Bonness, C. Hahn > >>>> Category : INFORMATIONAL > >>>> Source : IPv6 Operations > >>>> Area : Operations and Management > >>>> Stream : IETF > >>>> Verifying Party : IESG > >>> > >>> ---------------------------------------------------- > >>> The ignorance of how to use new knowledge stockpiles exponentially. > >>> - Marshall McLuhan > >>> > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> - > >> - > >>> -- > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops -- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --_000_A6FEBEE1D81B48319779561E0DC873ABciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <146DA12C0B3B60459FD357D009047461@cisco.com> Content-Transfer-Encoding: quoted-printable That seems to be a reasonable solution.

On Aug 8, 2012, at 6:43 AM, Ronald Bonica wrote:

Livo,
 
RFC 6164 speaks directly to the /127 issue. So, it seems = that 6164 should have updated 5375. If we issue an errata against 6164 that= causes 6164 to update 5375, would that fix the problem?
 
         &nb= sp;            =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     Ron
 
 
From:=  Livio Zanol Puppim [m= ailto:livio.zanol.puppim@gmail.com]&n= bsp;
Sent: Tuesday, Aug= ust 07, 2012 7:08 PM
To: Ronald Bonica<= br> Cc: Alice Russo; B= rian E Carpenter; Fred Baker (fred); <= v6ops@ietf.org>; <fred.ba= ker@cisco.com>; <Ol= af.Bonness@t-systems.com>; <cpopovic@cisco.com>; <= gunter@cisco.com>; RFC Errata Sy= stem
Subject: Re: [v6op= s] [Technical Errata Reported] RFC5375 (3309)
 
Hello guys.
 
Just to give you more information:
- RFC 5375 state that you should not use /127 address and makes a reference= to RFC 3627.
 
- RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 a= nd 5375 are potentially wrong, but did not make any recommendation about it= .
 
- RFC 6547 was published to overcome this error, and proposes that RFC 3627= should move to historic status, updating the RFC 6177, but again, did not = mention RFC 5375.
 
- An e-mail has been sent to the WG of the RFC 6547, but no answers were gi= ven. (http://www.ietf.= org/mail-archive/web/ipv6/current/msg16203.html)
 
- I've sent an erratum to RFC 5375 about this, which you guys are discussin= g.
 
So, what to do next?
Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update t= o RFC 5375?
 
I really don't know. As I've stated in an e-mail to rfc-interest mailing li= st, I'm just a reader and saw this /127 text while reading RFC 5375.
 
The only thing that I'm sure, is that other readers of RFC 5375 would not w= ant to know that the recommendation about /127, at B.2.2 sector is misguide= d after they have elaborated an address assignment project. Sometimes, you = only read the text, and do not click on every RFC linked in it.
 
I have full confidence in the WG, and I'm sure you will find the right solu= tion.
 
Thank you for your time. Best regards,
 
L=EDvio Zanol Puppim
 
2012/8/7 Ronald Bonica <rbonica@junipe= r.net>
Hi Alice,

Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects.

                   Ron

> -----Original Message-----
> From: Alice Russo [mailto:arusso@amsl.co= m]
> Sent: Tuesday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Carpenter; Fred Baker (fred); <v6ops@ietf.org>;
> <livio.zanol.puppim@gmai= l.com>; <fred.baker@cisco.com<= /a>>;
> <Olaf.Bonness@t-systems.co= m>; <cpopovic@cisco.com>; <gunter@cisco.com>;
> RFC Errata System
> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)
>

> Ron,
>
> > I will check with the RFC editor to see if it is OK to add an UPD= ATE
> in an errata.
>
>
> Please see this IESG statement:&= nbsp;http://www.ietf.= org/iesg/statement/rfc-
> metadata-errata.html.  If there is an errata report regarding the=
> metadata of an RFC *and* the verifying party marks it as Verified, the=
> RFC Editor will update the RFC's metadata accordingly (which appears i= n
> the RFC Index, info page, etc.).
>
> Thank you.
> RFC Editor/ar
>
> On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote:
>
> > Brian,
> >
> > I agree that Errata 3309 should be put into the "hold for up= date"
> state, because RFC 5375 was not wrong when it was published.
> >
> > However, we need to figure out what to do about RFC 6164. I dimly=
> recall a conversation about this when RFC 6164 was published. The
> consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 616= 4
> doesn't need to update RFC 5375.
> >
> > Looking back on it, this argument is weak. How would the reader o= f
> 5375 know that RFC 6164 exists if it weren't for the update informatio= n
> in the metadata?
> >
> > I will check with the RFC editor to see if it is OK to add an UPD= ATE
> in an errata.
> >
> >                   &n= bsp;                     =       Ron
> >
> >
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> >> Behalf Of Brian E Carpenter
> >> Sent: Tuesday, August 07, 2012 1:59 PM
> >> To: Fred Baker (fred)
> >> Cc: <v6ops@ietf.org>; = <livio.zanol.puppim@gmail.com= >;
> >> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems= .com>;
> >> <cpopovic@cisco.com&g= t;; <gunter@cisco.com>; RFC Errata System
> >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (330= 9)
> >>
> >> Wait a minute.
> >>
> >> How can this be described as an error in 5375? 5375 was not w= rong
> >> when published.
> >>
> >> The error was in 6164, which failed to formally update 5375.<= br> > >>
> >> Surely this is a "hold for update" not "verifi= ed".
> >>
> >> Regards
> >>   Brian
> >>
> >> On 07/08/2012 16:23, Fred Baker (fred) wrote:
> >>> We agree that this erratum is valid.
> >>>
> >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote:
> >>>
> >>>> The following errata report has been submitted for RF= C5375,
> >>>> "IPv6 Unicast Address Assignment Considerations&= quot;.
> >>>>
> >>>> --------------------------------------
> >>>> You may review the report below and at:
> >>>> h= ttp://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > >>>>
> >>>> --------------------------------------
> >>>> Type: Technical
> >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> <livio.= zanol.puppim@gmail.com>
> >>>>
> >>>> Section: B.2.2
> >>>>
> >>>> Original Text
> >>>> -------------
> >>>> B.2.2. /127 Addresses
> >>>>
> >>>>
> >>>>
> >>>>  The usage of the /127 addresses, the equivalent= of IPv4's RFC
> 3021
> >>>>
> >>>>  [RFC3021], is not valid and should be strongly = discouraged as
> >>>>
> >>>>  documented in RFC 3627 [RFC3627].
> >>>>
> >>>> Corrected Text
> >>>> --------------
> >>>> B.2.2. /127 Addresses
> >>>>
> >>>>
> >>>>
> >>>>  The usage of the /127 addresses, the equivalent= of IPv4's RFC
> 3021
> >>>>
> >>>>  [RFC3021], is valid as stated in RFC 6164 [RFC = 6164].
> >>>>
> >>>> Notes
> >>>> -----
> >>>> Maybe just remove the section B.2.2?
> >>>>
> >>>> Instructions:
> >>>> -------------
> >>>> This errata is currently posted as "Reported&quo= t;. If necessary,
> please
> >>>> use "Reply All" to discuss whether it shoul= d be verified or
> >> rejected.
> >>>> When a decision is reached, the verifying party (IESG= ) can log in
> >>>> to change the status and edit the report, if necessar= y.
> >>>>
> >>>> --------------------------------------
> >>>> RFC5375 (draft-ietf-v6ops-addcon-10)
> >>>> --------------------------------------
> >>>> Title              = ; : IPv6 Unicast Address Assignment
> Considerations
> >>>> Publication Date    : December 2008
> >>>> Author(s)           : G. Van= de Velde, C. Popoviciu, T. Chown, O.
> >> Bonness, C. Hahn
> >>>> Category            : I= NFORMATIONAL
> >>>> Source             &nbs= p;: IPv6 Operations
> >>>> Area              =  : Operations and Management
> >>>> Stream             &nbs= p;: IETF
> >>>> Verifying Party     : IESG
> >>>
> >>> ----------------------------------------------------
> >>> The ignorance of how to use new knowledge stockpiles expo= nentially.
> >>>   - Marshall McLuhan
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------= ----------
> -
> >>> -
> >> -
> >>> --
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/li= stinfo/v6ops
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listin= fo/v6ops



 

--


----------------------------------------------------
The = ;ignorance of how to use new=  = knowledge stockpiles exponentially. 
   - Marshall McLuhan

--_000_A6FEBEE1D81B48319779561E0DC873ABciscocom_-- From rbonica@juniper.net Wed Aug 8 09:44:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D04E11E8108 for ; Wed, 8 Aug 2012 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.26 X-Spam-Level: X-Spam-Status: No, score=-106.26 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0RrsXNI62Ev for ; Wed, 8 Aug 2012 09:44:43 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4434211E8097 for ; Wed, 8 Aug 2012 09:44:42 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUCKXdLPIubso/Tmv97IStLf4Tm1wFzhT@postini.com; Wed, 08 Aug 2012 09:44:42 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Aug 2012 09:31:52 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 8 Aug 2012 12:31:19 -0400 From: Ronald Bonica To: "Fred Baker (fred)" Date: Wed, 8 Aug 2012 12:31:18 -0400 Thread-Topic: [v6ops] [Technical Errata Reported] RFC5375 (3309) Thread-Index: AQHNdX+jFXBggWswrE2BV8Ybtajh/5dQGyPA Message-ID: <13205C286662DE4387D9AF3AC30EF456D77189B066@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D77189B066EMBX01WFjnprn_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:29:17 -0700 Cc: "" , Livio Zanol Puppim , "" , Alice Russo , "" , "" , RFC Errata System , "" Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:44:44 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D77189B066EMBX01WFjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Livo, If you file that Errata, and there are no objections from the WG before Fri= day, I will verify it. = Ron From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: Wednesday, August 08, 2012 12:06 PM To: Ronald Bonica Cc: Livio Zanol Puppim; Alice Russo; Brian E Carpenter; ; <= fred.baker@cisco.com>; ; ; = ; RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) That seems to be a reasonable solution. On Aug 8, 2012, at 6:43 AM, Ronald Bonica wrote: Livo, RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 should h= ave updated 5375. If we issue an errata against 6164 that causes 6164 to up= date 5375, would that fix the problem? = Ron From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] Sent: Tuesday, August 07, 2012 7:08 PM To: Ronald Bonica Cc: Alice Russo; Brian E Carpenter; Fred Baker (fred); >; >; <= Olaf.Bonness@t-systems.com>; >; >; RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) Hello guys. Just to give you more information: - RFC 5375 state that you should not use /127 address and makes a reference= to RFC 3627. - RFC 6177 came out as a standard, and in section 4 states that RFCs 3627 a= nd 5375 are potentially wrong, but did not make any recommendation about it= . - RFC 6547 was published to overcome this error, and proposes that RFC 3627= should move to historic status, updating the RFC 6177, but again, did not = mention RFC 5375. - An e-mail has been sent to the WG of the RFC 6547, but no answers were gi= ven. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html) - I've sent an erratum to RFC 5375 about this, which you guys are discussin= g. So, what to do next? Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update t= o RFC 5375? I really don't know. As I've stated in an e-mail to rfc-interest mailing li= st, I'm just a reader and saw this /127 text while reading RFC 5375. The only thing that I'm sure, is that other readers of RFC 5375 would not w= ant to know that the recommendation about /127, at B.2.2 sector is misguide= d after they have elaborated an address assignment project. Sometimes, you = only read the text, and do not click on every RFC linked in it. I have full confidence in the WG, and I'm sure you will find the right solu= tion. Thank you for your time. Best regards, L=EDvio Zanol Puppim 2012/8/7 Ronald Bonica > Hi Alice, Thanks for this reminder! I will consult with the WG and IESG to make sure = that nobody objects. Ron > -----Original Message----- > From: Alice Russo [mailto:arusso@amsl.com] > Sent: Tuesday, August 07, 2012 3:55 PM > To: Ronald Bonica > Cc: Brian E Carpenter; Fred Baker (fred); >; > >; >; > >; >; >; > RFC Errata System > Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > > Ron, > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc- > metadata-errata.html. If there is an errata report regarding the > metadata of an RFC *and* the verifying party marks it as Verified, the > RFC Editor will update the RFC's metadata accordingly (which appears in > the RFC Index, info page, etc.). > > Thank you. > RFC Editor/ar > > On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote: > > > Brian, > > > > I agree that Errata 3309 should be put into the "hold for update" > state, because RFC 5375 was not wrong when it was published. > > > > However, we need to figure out what to do about RFC 6164. I dimly > recall a conversation about this when RFC 6164 was published. The > consensus was that RFC 6164 trumps RFC 5375 because the former is on > the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 > doesn't need to update RFC 5375. > > > > Looking back on it, this argument is weak. How would the reader of > 5375 know that RFC 6164 exists if it weren't for the update information > in the metadata? > > > > I will check with the RFC editor to see if it is OK to add an UPDATE > in an errata. > > > > Ron > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6= ops-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Tuesday, August 07, 2012 1:59 PM > >> To: Fred Baker (fred) > >> Cc: >; >; > >> >; >; > >> >; >; RFC Errata System > >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) > >> > >> Wait a minute. > >> > >> How can this be described as an error in 5375? 5375 was not wrong > >> when published. > >> > >> The error was in 6164, which failed to formally update 5375. > >> > >> Surely this is a "hold for update" not "verified". > >> > >> Regards > >> Brian > >> > >> On 07/08/2012 16:23, Fred Baker (fred) wrote: > >>> We agree that this erratum is valid. > >>> > >>> On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote: > >>> > >>>> The following errata report has been submitted for RFC5375, > >>>> "IPv6 Unicast Address Assignment Considerations". > >>>> > >>>> -------------------------------------- > >>>> You may review the report below and at: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309 > >>>> > >>>> -------------------------------------- > >>>> Type: Technical > >>>> Reported by: L=EDvio Zanol Pereira de Souza Puppim > >>>> > > >>>> > >>>> Section: B.2.2 > >>>> > >>>> Original Text > >>>> ------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is not valid and should be strongly discouraged as > >>>> > >>>> documented in RFC 3627 [RFC3627]. > >>>> > >>>> Corrected Text > >>>> -------------- > >>>> B.2.2. /127 Addresses > >>>> > >>>> > >>>> > >>>> The usage of the /127 addresses, the equivalent of IPv4's RFC > 3021 > >>>> > >>>> [RFC3021], is valid as stated in RFC 6164 [RFC 6164]. > >>>> > >>>> Notes > >>>> ----- > >>>> Maybe just remove the section B.2.2? > >>>> > >>>> Instructions: > >>>> ------------- > >>>> This errata is currently posted as "Reported". If necessary, > please > >>>> use "Reply All" to discuss whether it should be verified or > >> rejected. > >>>> When a decision is reached, the verifying party (IESG) can log in > >>>> to change the status and edit the report, if necessary. > >>>> > >>>> -------------------------------------- > >>>> RFC5375 (draft-ietf-v6ops-addcon-10) > >>>> -------------------------------------- > >>>> Title : IPv6 Unicast Address Assignment > Considerations > >>>> Publication Date : December 2008 > >>>> Author(s) : G. Van de Velde, C. Popoviciu, T. Chown, O. > >> Bonness, C. Hahn > >>>> Category : INFORMATIONAL > >>>> Source : IPv6 Operations > >>>> Area : Operations and Management > >>>> Stream : IETF > >>>> Verifying Party : IESG > >>> > >>> ---------------------------------------------------- > >>> The ignorance of how to use new knowledge stockpiles exponentially. > >>> - Marshall McLuhan > >>> > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> - > >> - > >>> -- > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops -- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --_000_13205C286662DE4387D9AF3AC30EF456D77189B066EMBX01WFjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Livo,

 

<= p class=3DMsoNormal>If you file that Errata, and there are no object= ions from the WG before Friday, I will verify it.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 =A0Ron

 

 

From: Fred Baker (fred) [mailt= o:fred@cisco.com]
Sent: Wednesday, August 08, 2012 12:06 PM
<= b>To: Ronald Bonica
Cc: Livio Zanol Puppim; Alice Russo; Bria= n E Carpenter; <v6ops@ietf.org>; <fred.baker@cisco.com>; <Ol= af.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.= com>; RFC Errata System
Subject: Re: [v6ops] [Technical Errata= Reported] RFC5375 (3309)

 

That seems to be a reasonabl= e solution.

 

<= div>

On Aug 8, 2012, at 6:43 AM, Ronald Bonica wro= te:



Livo,

 

RFC 6164 speaks directly to the /127 issue. So, it seems that= 6164 should have updated 5375. If we issue an errata against 6164 that cau= ses 6164 to update 5375, would that fix the problem?

<= /div>

 

       &nb= sp;            =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       Ron

 

<= p class=3DMsoNormal> 

From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] 
Sent: Tuesday, August 07, 2012 7:08 PM
To: Ronald Bonica
Cc: Alice Russo; Brian E Carpenter; Fred = Baker (fred); <v6ops@ietf.org>;= <fred.baker@cisco.com>; = <Olaf.Bonness@t-systems.co= m>; <cpopovic@cisco.com= >; <gunter@cisco.com>; RFC= Errata System
Subject: = Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)

 

Hello guys.

 

Just to give you more information:

- RFC 5375 state that you should not use= /127 address and makes a reference to RFC 3627.

=

 

<= p class=3DMsoNormal>- RFC 6177 came out as a standard, and in section 4 sta= tes that RFCs 3627 and 5375 are potentially wrong, but did not make any rec= ommendation about it.

 

- RFC 6= 547 was published to overcome this error, and proposes that RFC 3627 should= move to historic status, updating the RFC 6177, but again, did not mention= RFC 5375.

 <= o:p>

- An e-mail has be= en sent to the WG of the RFC 6547, but no answers were given. (http://www.= ietf.org/mail-archive/web/ipv6/current/msg16203.html)

 

- I've sent an erratum to RFC 5375 about this,= which you guys are discussing.

 

So, what to do next?

Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an up= date to RFC 5375?

=  

I really do= n't know. As I've stated in an e-mail to rfc-interest mailing list, I'm jus= t a reader and saw this /127 text while reading RFC 5375.

 

The only thing that I'm sure, is that other re= aders of RFC 5375 would not want to know that the recommendation about /127= , at B.2.2 sector is misguided after they have elaborated an address assign= ment project. Sometimes, you only read the text, and do not click on every = RFC linked in it.

=  

I have full= confidence in the WG, and I'm sure you will find the right solution.<= /o:p>

 

Thank you for your time. Best rega= rds,

 

L=EDvio Zanol Puppim

 

=

2012/8/7 Ronald Bonica <rbonica@juniper.net>

Hi Alice,

Thanks for th= is reminder! I will consult with the WG and IESG to make sure that nobody o= bjects.

                &nbs= p;  Ron


> --= ---Original Message-----
> From: Alice Russo [mailto:arusso@amsl.com]
> Sent: Tue= sday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E= Carpenter; Fred Baker (fred); <v6ops@ietf.org>;
> <livio.zanol.puppim@gmail.com>= ; <fred.baker@= cisco.com>;
> <Olaf.Bonness@t-systems.com>; <cpopovic@cisco.com>; <gunter@cisco.com>= ;;
> RFC Errata System
> Subject: Re: [v6ops] [Technical Errata= Reported] RFC5375 (3309)
>

> Ron,
>
> &g= t; I will check with the RFC editor to see if it is OK to add an UPDATE
= > in an errata.
>
>
> Please see this IESG statement:<= span class=3Dapple-converted-space> http://www.ietf.org/iesg/stateme= nt/rfc-
> metadata-errata.html.  If there is an errata repor= t regarding the
> metadata of an RFC *and* the verifying party marks = it as Verified, the
> RFC Editor will update the RFC's metadata accor= dingly (which appears in
> the RFC Index, info page, etc.).
>> Thank you.
> RFC Editor/ar
>
> On Aug 7, 2012, at = 11:36 AM, Ronald Bonica wrote:
>
> > Brian,
> >
= > > I agree that Errata 3309 should be put into the "hold for up= date"
> state, because RFC 5375 was not wrong when it was publis= hed.
> >
> > However, we need to figure out what to do ab= out RFC 6164. I dimly
> recall a conversation about this when RFC 616= 4 was published. The
> consensus was that RFC 6164 trumps RFC 5375 be= cause the former is on
> the Standards Track while the later is only = INFORMATIONAL. So, RFC 6164
> doesn't need to update RFC 5375.
>= ; >
> > Looking back on it, this argument is weak. How would th= e reader of
> 5375 know that RFC 6164 exists if it weren't for the up= date information
> in the metadata?
> >
> > I will = check with the RFC editor to see if it is OK to add an UPDATE
> in an= errata.
> >
> >            = ;                     &nb= sp;             Ron
> >
> >=
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> >> Behalf O= f Brian E Carpenter
> >> Sent: Tuesday, August 07, 2012 1:59 PM=
> >> To: Fred Baker (fred)
> >> Cc: <v6ops@ietf.org>; <livio.zanol.pu= ppim@gmail.com>;
> >> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems.c= om>;
> >> <cpopovic@cisco.com>; <gunter@cisco.com>; RFC Errata System
>= ; >> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)<= br>> >>
> >> Wait a minute.
> >>
> &= gt;> How can this be described as an error in 5375? 5375 was not wrong> >> when published.
> >>
> >> The error= was in 6164, which failed to formally update 5375.
> >>
>= ; >> Surely this is a "hold for update" not "verified&= quot;.
> >>
> >> Regards
> >>   Br= ian
> >>
> >> On 07/08/2012 16:23, Fred Baker (fred= ) wrote:
> >>> We agree that this erratum is valid.
> = >>>
> >>> On Aug 6, 2012, at 7:28 AM, RFC Errata Sy= stem wrote:
> >>>
> >>>> The following err= ata report has been submitted for RFC5375,
> >>>> "I= Pv6 Unicast Address Assignment Considerations".
> >>>&g= t;
> >>>> --------------------------------------
> = >>>> You may review the report below and at:
> >>&g= t;> http://www.rfc-editor.org/errata_search.php?rfc=3D5375&eid=3D3309<= /a>
> >>>>
> >>>> ---------------------= -----------------
> >>>> Type: Technical
> >>= >> Reported by: L=EDvio Zanol Pereira de Souza Puppim
> >>= ;>> <livio.zanol.puppim@gmail.com>
> >>>>
> = >>>> Section: B.2.2
> >>>>
> >>&g= t;> Original Text
> >>>> -------------
> >>= ;>> B.2.2. /127 Addresses
> >>>>
> >>&g= t;>
> >>>>
> >>>>  The usage of= the /127 addresses, the equivalent of IPv4's RFC
> 3021
> >= >>>
> >>>>  [RFC3021], is not valid and sho= uld be strongly discouraged as
> >>>>
> >>>= ;>  documented in RFC 3627 [RFC3627].
> >>>>
&= gt; >>>> Corrected Text
> >>>> --------------=
> >>>> B.2.2. /127 Addresses
> >>>>> >>>>
> >>>>
> >>>> &n= bsp;The usage of the /127 addresses, the equivalent of IPv4's RFC
> 3= 021
> >>>>
> >>>>  [RFC3021], is v= alid as stated in RFC 6164 [RFC 6164].
> >>>>
> >= ;>>> Notes
> >>>> -----
> >>>>= Maybe just remove the section B.2.2?
> >>>>
> >= >>> Instructions:
> >>>> -------------
> &= gt;>>> This errata is currently posted as "Reported". If= necessary,
> please
> >>>> use "Reply All&quo= t; to discuss whether it should be verified or
> >> rejected.> >>>> When a decision is reached, the verifying party (IE= SG) can log in
> >>>> to change the status and edit the r= eport, if necessary.
> >>>>
> >>>> ----= ----------------------------------
> >>>> RFC5375 (draft-= ietf-v6ops-addcon-10)
> >>>> ----------------------------= ----------
> >>>> Title          = ;     : IPv6 Unicast Address Assignment
> Considerations> >>>> Publication Date    : December 2008
>= ; >>>> Author(s)           : G. Van de= Velde, C. Popoviciu, T. Chown, O.
> >> Bonness, C. Hahn
>= ; >>>> Category            : INFO= RMATIONAL
> >>>> Source          = ;    : IPv6 Operations
> >>>> Area    = ;            : Operations and Management
&= gt; >>>> Stream              = ;: IETF
> >>>> Verifying Party     : IESG
&g= t; >>>
> >>> --------------------------------------= --------------
> >>> The ignorance of how to use new knowled= ge stockpiles exponentially.
> >>>   - Marshall McLuhan=
> >>>
> >>>
> >>>
> >= ;>> -----------------------------------------------------------------= --
> -
> >>> -
> >> -
> >>>= --
> >>>
> >>> _____________________________= __________________
> >>> v6ops mailing list
> >>= > v6ops@ietf.org
> >>> https://www.ietf.org/mailman/list= info/v6ops
> >>
> >> __________________________= _____________________
> >> v6ops mailing list
> >><= span class=3Dapple-converted-space> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6op= s



 

--

 =

----------------------------= ------------------------

The ignorance<= span class=3Dapple-style-span> of how to use new=  knowledge stockpi= les exponentially.&nbs= p;

  = - Marshall McLuhan

 

= --_000_13205C286662DE4387D9AF3AC30EF456D77189B066EMBX01WFjnprn_-- From despres.remi@laposte.net Fri Aug 10 09:00:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9821F87CD for ; Fri, 10 Aug 2012 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmW8PkYPihPb for ; Fri, 10 Aug 2012 09:00:14 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFCE21F87CB for ; Fri, 10 Aug 2012 09:00:13 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id 802B770000AF; Fri, 10 Aug 2012 18:00:12 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id 32D84700009D; Fri, 10 Aug 2012 18:00:10 +0200 (CEST) X-SFR-UUID: 20120810160010208.32D84700009D@msfrf2407.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12--912497678 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 10 Aug 2012 18:00:05 +0200 Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:00:15 -0000 --Apple-Mail-12--912497678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >=20 > On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" = wrote: > > > > Did we already conclude that this is a BCP and not Informational? We = should just put it in the latter category and move on/progress. > > > > >=20 > Yes, afaik, the chairs have accepted bcp status and have accepted the = bcp scenario text. >=20 > The chairs also direct the WG to move on to any remainig technical = issuess. >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >=20 After that, Lorenzo proposed an approach, which I approved, to resolve = the last issue I had raised. If the chairs also agree, all is AFAIK OK for the draft to proceed = without objection as BCP. Regards,` RD >=20 > CB >=20 > > Cheers, > > Rajiv > > > > Sent from my Phone > > > > On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" = wrote: > > > >> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s = wrote: > >>> > >>> I can't understand why it would be such a big deal to clarify = that, even in the limited context of stateful solutions, it is only for = networks that don't support more transparent transition solutions that = 464XLAT is THE recommended solution. > >> > >> > >> I believe we all agree that 464xlat is suboptimal in terms of = transparency and that other technologies provide better transparency. I = believe we also agree that this is not a strict requirement for 464xlat = because many of the target scenarios are networks that already run = carrier-operated NAT, which of course is not transparent. The only thing = we disagree on is what the "best" in "best practice" should refer to. = Right? > >> > >> With that in mind - if we said that the "best" in "best" practice = refers to "the best way of running IPv4 over IPv6 when combining = stateful and stateless NAT64?", or "the best way of running IPv4 over = IPv6 in networks that cannot support encapsulation"? > >> > >> Could we agree on that? > >> > >> Cheers, > >> Lorenzo > >> > >> _______________________________________________ > >> > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-12--912497678 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
>
> Did we already conclude that this is a BCP and not Informational? = We should just put it in the latter category and move on/progress.
>
>

Yes, afaik, the chairs have accepted bcp status and have = accepted the bcp scenario text.

The chairs also direct the WG to = move on to any remainig technical issuess.

= http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html


After that, Lorenzo proposed an approach, = which I approved, to resolve the last issue I had raised.
If = the chairs also agree, all is AFAIK OK for the draft to proceed without = objection as = BCP.
Regards,`
RD



CB

> Cheers,
> Rajiv
>
> Sent from my Phone
>
> On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
>> On Thu, Aug 9, 2012 at 6:11 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
>>>
>>> I can't understand why it would be such a big deal to = clarify that, even in the limited context of stateful solutions, it is = only for networks that don't support more transparent transition = solutions that 464XLAT is THE recommended solution.
>>
>>
>> I believe we all agree that 464xlat is suboptimal in terms of = transparency and that other technologies provide better transparency. I = believe we also agree that this is not a strict requirement for 464xlat = because many of the target scenarios are networks that already run = carrier-operated NAT, which of course is not transparent. The only thing = we disagree on is what the "best" in "best practice" should refer to. = Right?
>>
>> With that in mind - if we said that the "best" in "best" = practice refers to "the best way of running IPv4 over IPv6 when = combining stateful and stateless NAT64?", or "the best way of running = IPv4 over IPv6 in networks that cannot support encapsulation"?
>>
>> Could we agree on that?
>>
>> Cheers,
>> Lorenzo
>>
>> _______________________________________________
>>
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/= mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/= mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-12--912497678-- From cb.list6@gmail.com Fri Aug 10 09:39:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60921F8758 for ; Fri, 10 Aug 2012 09:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SY4hcNvIFW2 for ; Fri, 10 Aug 2012 09:39:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D086D21F874A for ; Fri, 10 Aug 2012 09:39:39 -0700 (PDT) Received: by lahm15 with SMTP id m15so1018899lah.31 for ; Fri, 10 Aug 2012 09:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QfH0O37XQhnTGwLCFIGWKDddxQ3x529CaJDCunIC2n0=; b=tTWJEoCMHYvqlUdQ7jLtFJplfuCjtYmt4HO6MV6O/nsBYQX3toLXLa6F7ij+sg+dAj J+zcJR1lywDc8LIgyg/yHR9DaxiwkT9cwW6G8DEKJBBbQTTb7ONf6n2IJzc4H6QwmpiQ jvlSEVce58J9jjULAdN5xrfjwUgAqITXdCyCR9tAHhgtwZeEONNSL2YiN8YakQ1eeGZg ubmhelf647oVV3nGrJHUxN5ugU/1Px7Opook4yvyGbQ7GPFhHWSLaK4RUoQ3sZF6TYMl xVd3cCOVnx/vYuOZWXN7uy9CRFWYTZL8uU6m0Q5afbg+ojlmRWfsuPSEuPilY3SLEy4L sLQg== MIME-Version: 1.0 Received: by 10.112.23.40 with SMTP id j8mr2702852lbf.31.1344616778654; Fri, 10 Aug 2012 09:39:38 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 10 Aug 2012 09:39:38 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> Date: Fri, 10 Aug 2012 09:39:38 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:39:41 -0000 On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s wrote: > > Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : > > > On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" wrote: >> >> Did we already conclude that this is a BCP and not Informational? We >> should just put it in the latter category and move on/progress. >> >> > > Yes, afaik, the chairs have accepted bcp status and have accepted the bcp > scenario text. > > The chairs also direct the WG to move on to any remainig technical issues= s. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > > > After that, Lorenzo proposed an approach, which I approved, to resolve th= e > last issue I had raised. > If the chairs also agree, all is AFAIK OK for the draft to proceed withou= t > objection as BCP. > Regards,` > RD > R=E9mi, It sounds like you are deferring to the chairs. I too will defer to the chairs, since my focus is moving forward. The chairs have already made their position known, and they may re-open this issue. You and Lorenzo have supplied input to the chairs. My input to the chairs is that there should be no changes required of the current text. In very basic logical terms the text currently says X =3D RFC 6146 IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only hosts and apps on an IPv6-only access network. Your original proposal and more or less Lorenzo's proposal Y =3D DS-lite IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only hosts and apps on an IPv6-only access network The difference between "only X" and "X and not Y" is that there must be a scenario where X and Y both occur. I do not believe that is the case that X and Y will occur together so there is no need to complicated the document with this. And, your meaning, which i believe is to say that tunneling is better than translation, is already documented in the IETF (RFC 4213, others?) As i said before, it seems like the aim is to create a pecking order of transition solutions. If you want to do that, that is the scope of a different draft. CB From ichiroumakino@gmail.com Fri Aug 10 10:00:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601B521F87ED for ; Fri, 10 Aug 2012 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTQPtyH+5B8Y for ; Fri, 10 Aug 2012 10:00:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7739C21F87F4 for ; Fri, 10 Aug 2012 10:00:19 -0700 (PDT) Received: by eaai11 with SMTP id i11so487574eaa.31 for ; Fri, 10 Aug 2012 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UpiJI/uCzubBHKf0nvxGC5QFgp7+tsp40tfgoPGm1vM=; b=0/F/aSsLvV+nnJSsdADbc8/n1oSMtAJmqEnbFGuo4IXDlS9uaFichm/llMPFhf1GgA EVPaf5inMjcz9MDdES8n5jNzACWqqZWfUIB2WNSfisUeV5NEl70UTqy367MqYukTEG4S NG6suXvpi0KBbewcZuNSbbp0TpPLMIrFOhUOMC3VejSQLuEs7rLQcxQ6oYCAADNVEy6J fLtbO82/ZeCiXz3YpbCLhr//O23PDrjngdB+wUtNHsbd1loChuOII+8gaICJtBZ1pQV4 cMXayUQLMu0F+9iXO1tT5pC+89v5bjRYOhbAtR5g90oVSCHy5LKrDYoEpPkvopRfsdxY UJyQ== Received: by 10.14.182.134 with SMTP id o6mr4016038eem.26.1344618017333; Fri, 10 Aug 2012 10:00:17 -0700 (PDT) Received: from dhcp-10-61-99-14.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d48sm12743052eeo.10.2012.08.10.10.00.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 10:00:16 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_08784E4B-1E7C-40C5-AAA5-4D3433421C97"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 10 Aug 2012 19:00:11 +0200 Message-Id: <3BC2ABD9-4D04-4903-BBCA-F9EA59DB40C4@employees.org> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1278) Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:00:20 -0000 --Apple-Mail=_08784E4B-1E7C-40C5-AAA5-4D3433421C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cameron, > I too will defer to the chairs, since my focus is moving forward. >=20 > The chairs have already made their position known, and they may > re-open this issue. >=20 > You and Lorenzo have supplied input to the chairs. >=20 > My input to the chairs is that there should be no changes required of > the current text. In very basic logical terms the text currently says >=20 > X =3D RFC 6146 >=20 > IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network. >=20 > Your original proposal and more or less Lorenzo's proposal >=20 > Y =3D DS-lite >=20 > IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network >=20 > The difference between "only X" and "X and not Y" is that there must > be a scenario where X and Y both occur. I do not believe that is the > case that X and Y will occur together so there is no need to > complicated the document with this. And, your meaning, which i > believe is to say that tunneling is better than translation, is > already documented in the IETF (RFC 4213, others?) >=20 > As i said before, it seems like the aim is to create a pecking order > of transition solutions. If you want to do that, that is the scope of > a different draft. +1. I think 464XLAT should be standing on its own, and given the plethora of = IPv4 life extension mechanisms then it is quite unlikely that we'll = reach consensus on that pecking order any time soon. I know I disagree = with Y above at least. ;-) cheers, Ole= --Apple-Mail=_08784E4B-1E7C-40C5-AAA5-4D3433421C97 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODEwMTcwMDEyWjAjBgkqhkiG9w0BCQQxFgQUoxih7/idapNQZPAs +nwCxg7Ig80wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAiLqQvezDCKSqcAUdqZt5 +t2YpUrBZmSlUj+exLx7sEy2yBdSV0Bb0/E/YsGX/dnFh5SePUgJ4yHkqWo+dW/0PFmcL+J+q9k3 e0XGO5RcX6nYgNv7w6RzA65XY3ppshgvkI3/CnLkI6280MW6U9bqF0HHCJH7n0iFesnO4Kounihp 3TY/BG51bS/ObQY1Xb9ij56nlxjoX3eTxwo9Y7tt59fNDyR+TI8K8Bw8xT69HBvIgFOifDcPpAnw nYgvvj+Z0iahvZCDXxWlicBOdvtZz36RW/6+KDSShsm4yxGTBc7aJL3HYddu+FdnrSBvQm7/Eakw nz7O36WEuZ6elxYo8wAAAAAAAA== --Apple-Mail=_08784E4B-1E7C-40C5-AAA5-4D3433421C97-- From joelja@bogus.com Fri Aug 10 10:05:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C3C21F8609 for ; Fri, 10 Aug 2012 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liuDNA2cWXLh for ; Fri, 10 Aug 2012 10:05:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DD31E21F8569 for ; Fri, 10 Aug 2012 10:05:46 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7AH5i09091498 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 10 Aug 2012 17:05:44 GMT (envelope-from joelja@bogus.com) Message-ID: <50253F63.10106@bogus.com> Date: Fri, 10 Aug 2012 10:05:39 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Cameron Byrne References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 10 Aug 2012 17:05:44 +0000 (UTC) Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:05:47 -0000 On 8/10/12 9:39 AM, Cameron Byrne wrote: > On Fri, Aug 10, 2012 at 9:00 AM, Rémi Després wrote: >> Le 2012-08-10 à 16:25, Cameron Byrne a écrit : >> >> >> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" wrote: >>> Did we already conclude that this is a BCP and not Informational? We >>> should just put it in the latter category and move on/progress. We did, there were opinions voiced in the meeting and on the mailing list. A raising of hands was taken. In conjunction with the area director, we requested that the draft be resubmitted with an applicability statement that made it clear when it was expected to be appropiate and an intended status of BCP. >>> Yes, afaik, the chairs have accepted bcp status and have accepted the bcp >>> scenario text. >>> >>> The chairs also direct the WG to move on to any remainig technical issuess. >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>> >>> >>> After that, Lorenzo proposed an approach, which I approved, to resolve the >>> last issue I had raised. >>> If the chairs also agree, all is AFAIK OK for the draft to proceed without >>> objection as BCP. >>> Regards,` >>> RD >>> > Rémi, > > It sounds like you are deferring to the chairs. > > I too will defer to the chairs, since my focus is moving forward. > > The chairs have already made their position known, and they may > re-open this issue. > > You and Lorenzo have supplied input to the chairs. > > My input to the chairs is that there should be no changes required of > the current text. In very basic logical terms the text currently says > > X = RFC 6146 > > IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network. > > Your original proposal and more or less Lorenzo's proposal > > Y = DS-lite > > IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network > > The difference between "only X" and "X and not Y" is that there must > be a scenario where X and Y both occur. I do not believe that is the > case that X and Y will occur together so there is no need to > complicated the document with this. And, your meaning, which i > believe is to say that tunneling is better than translation, is > already documented in the IETF (RFC 4213, others?) > > As i said before, it seems like the aim is to create a pecking order > of transition solutions. If you want to do that, that is the scope of > a different draft. > > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From rajiva@cisco.com Fri Aug 10 10:43:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6521F870F for ; Fri, 10 Aug 2012 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8Hs5JKWygW2 for ; Fri, 10 Aug 2012 10:43:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6521F8707 for ; Fri, 10 Aug 2012 10:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3507; q=dns/txt; s=iport; t=1344620588; x=1345830188; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Kl6UuEQJO/PdA/PW/jGqsRNkx30ZZ8r2Z+ufy2kk7so=; b=gNNcy2kKZrggqYEV3kv4sxR1JU4Hn1QhWI/MrNcS3IrBM9sS94a5q9mF H6ZfWgQO9N52QNvxpJw8asb/iew7UwkzSFf8LODoMKwtmb51+pJTBKLKc 1qfLtDQXM9foBYmZ8gr1PVJ2f+7aXM72oIFVquqaKcJNpw0kKLgdne7Mj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJFHJVCtJV2b/2dsb2JhbABEuWyBB4IgAQEBBAEBAQ8BWwsMBgEIEQMBAgFPBgsdCAIEAQ0FCRIHh1wDDAuYApYyDQaJSIoqZRqGSgOIGYtdgVOBFIl2gx+BZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,747,1336348800"; d="scan'208";a="110431397" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Aug 2012 17:43:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7AHh7gl008808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 17:43:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 12:43:07 -0500 From: "Rajiv Asati (rajiva)" To: joel jaeggli , Cameron Byrne Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNdg79+XACQkbPc0aEIk8gtnL9iJdSjd2AgABpz+OAAHgfgIAAGlKAgAALDQCAAAdFgP//x2QA Date: Fri, 10 Aug 2012 17:43:05 +0000 Message-ID: In-Reply-To: <50253F63.10106@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [64.102.38.125] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003 x-tm-as-result: No--52.408100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <65D31D461A72404490D49C9D580F5918@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:43:09 -0000 Got it. Thanks. And assuming that this is the applicability statement, I am ok with it to move forward. http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06#section-2 Cheers, Rajiv -----Original Message----- From: Joel jaeggli Date: Friday, August 10, 2012 1:05 PM To: Cameron Byrne Cc: "v6ops-chairs@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt >On 8/10/12 9:39 AM, Cameron Byrne wrote: >> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s >> wrote: >>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>> >>> >>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" >>>wrote: >>>> Did we already conclude that this is a BCP and not Informational? We >>>> should just put it in the latter category and move on/progress. >We did, there were opinions voiced in the meeting and on the mailing list. > > A raising of hands was taken. > >In conjunction with the area director, we requested that the draft be >resubmitted with an applicability statement that made it clear when it >was expected to be appropiate and an intended status of BCP. >>>> Yes, afaik, the chairs have accepted bcp status and have accepted the >>>>bcp >>>> scenario text. >>>> >>>> The chairs also direct the WG to move on to any remainig technical >>>>issuess. >>>> >>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>>> >>>> >>>> After that, Lorenzo proposed an approach, which I approved, to >>>>resolve the >>>> last issue I had raised. >>>> If the chairs also agree, all is AFAIK OK for the draft to proceed >>>>without >>>> objection as BCP. >>>> Regards,` >>>> RD >>>> >> R=E9mi, >> >> It sounds like you are deferring to the chairs. >> >> I too will defer to the chairs, since my focus is moving forward. >> >> The chairs have already made their position known, and they may >> re-open this issue. >> >> You and Lorenzo have supplied input to the chairs. >> >> My input to the chairs is that there should be no changes required of >> the current text. In very basic logical terms the text currently says >> >> X =3D RFC 6146 >> >> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only >> hosts and apps on an IPv6-only access network. >> >> Your original proposal and more or less Lorenzo's proposal >> >> Y =3D DS-lite >> >> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only >> hosts and apps on an IPv6-only access network >> >> The difference between "only X" and "X and not Y" is that there must >> be a scenario where X and Y both occur. I do not believe that is the >> case that X and Y will occur together so there is no need to >> complicated the document with this. And, your meaning, which i >> believe is to say that tunneling is better than translation, is >> already documented in the IETF (RFC 4213, others?) >> >> As i said before, it seems like the aim is to create a pecking order >> of transition solutions. If you want to do that, that is the scope of >> a different draft. >> >> >> CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From ietfc@btconnect.com Fri Aug 10 11:43:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8968D21F851C for ; Fri, 10 Aug 2012 11:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Atun2-oksxN for ; Fri, 10 Aug 2012 11:43:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCD21F8501 for ; Fri, 10 Aug 2012 11:43:08 -0700 (PDT) Received: from mail64-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Aug 2012 18:43:08 +0000 Received: from mail64-am1 (localhost [127.0.0.1]) by mail64-am1-R.bigfish.com (Postfix) with ESMTP id 08DB3802AB; Fri, 10 Aug 2012 18:43:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: PS-30(zz98dI9371Ic89bh936eI542M1432Ic1dMzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail64-am1 (localhost.localdomain [127.0.0.1]) by mail64-am1 (MessageSwitch) id 1344624186480062_26229; Fri, 10 Aug 2012 18:43:06 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.231]) by mail64-am1.bigfish.com (Postfix) with ESMTP id 738AB60238; Fri, 10 Aug 2012 18:43:06 +0000 (UTC) Received: from DB3PRD0702HT002.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Aug 2012 18:43:01 +0000 Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.3.4.146) with Microsoft SMTP Server (TLS) id 14.15.108.4; Fri, 10 Aug 2012 18:43:00 +0000 Message-ID: <006a01cd7727$56837ca0$4001a8c0@gateway.2wire.net> From: t.petch To: Cameron Byrne References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com><20120807133908kawashimam@mail.jp.nec.com><7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net><90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net><992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net><841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com><2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> Date: Fri, 10 Aug 2012 19:38:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:43:10 -0000 Something different and a bit lighter:-) s.4 "PLAT: PLAT is Provider side translator(XLAT) that complies with [RFC6146]. It translates N:1 global IPv6 packets to global IPv4 packets, and vice versa." Is that really N:1 packets? s.6.1 "The private IPv4 host on this diagram " which is the private host? OK I worked out that the host on the left had the private addresses, but this could be clearer 'The private IPv4 host on the left hand side of this diagram ' or 'The host on this diagram with the private IPv4 addresses ' and the first occurrences of PLAT, CLAT and UE I would like to see expanded. Tom Petch ----- Original Message ----- From: "Cameron Byrne" To: "R=E9mi Despr=E9s" Cc: "v6ops WG" ; "V6ops Chairs" Sent: Friday, August 10, 2012 5:39 PM Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s wrote: > > Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : > > > On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" wrote: >> >> Did we already conclude that this is a BCP and not Informational? We >> should just put it in the latter category and move on/progress. >> >> > > Yes, afaik, the chairs have accepted bcp status and have accepted the bcp > scenario text. > > The chairs also direct the WG to move on to any remainig technical issuess. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > > > After that, Lorenzo proposed an approach, which I approved, to resolve the > last issue I had raised. > If the chairs also agree, all is AFAIK OK for the draft to proceed without > objection as BCP. > Regards,` > RD > R=E9mi, It sounds like you are deferring to the chairs. I too will defer to the chairs, since my focus is moving forward. The chairs have already made their position known, and they may re-open this issue. You and Lorenzo have supplied input to the chairs. My input to the chairs is that there should be no changes required of the current text. In very basic logical terms the text currently says X =3D RFC 6146 IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only hosts and apps on an IPv6-only access network. Your original proposal and more or less Lorenzo's proposal Y =3D DS-lite IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only hosts and apps on an IPv6-only access network The difference between "only X" and "X and not Y" is that there must be a scenario where X and Y both occur. I do not believe that is the case that X and Y will occur together so there is no need to complicated the document with this. And, your meaning, which i believe is to say that tunneling is better than translation, is already documented in the IETF (RFC 4213, others?) As i said before, it seems like the aim is to create a pecking order of transition solutions. If you want to do that, that is the scope of a different draft. CB _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Fri Aug 10 13:13:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780CC21F869F for ; Fri, 10 Aug 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrTZcux28wKT for ; Fri, 10 Aug 2012 13:13:03 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD421F86AA for ; Fri, 10 Aug 2012 13:13:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so1114007lah.31 for ; Fri, 10 Aug 2012 13:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4tV2Cohzq9nnb3YEnxjVfl6Y77+e/4Ih8zLVtYFD5Jw=; b=mMTZG3o8XV/rcMzawo91uE5/8llu/2fq4fT+GNtq7suB31VDzayKrLT+hCbpJiiUxK J6caADadsXNdLpm7FPGO1it7vnB7hZrY4vNQqiuQ8RkGs6eIX3qkq1b30fqvXzkKukzr YfTFSSOr7r5uAynEGU2ZUlvZyekAlKb4Wke+vp8VIkETvqYvVmyhiyowxCftwEJpSzyL 6VCU6yt68PTgMkgEKrFBsQhwzU+1WfdMkd0cmeJktCET2JIWxcZNJQ9ywGqEcSM4kbbq /fNs+alvcSHglNeQye3E+COusiO0DErCRqgGzkuYnnyfUyLJDPGWXKj5+dHYTbBWAweq BijQ== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr4020509lab.31.1344629582195; Fri, 10 Aug 2012 13:13:02 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 10 Aug 2012 13:13:02 -0700 (PDT) In-Reply-To: <006a01cd7727$56837ca0$4001a8c0@gateway.2wire.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> <006a01cd7727$56837ca0$4001a8c0@gateway.2wire.net> Date: Fri, 10 Aug 2012 13:13:02 -0700 Message-ID: From: Cameron Byrne To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , draft-ietf-v6ops-464xlat Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:13:04 -0000 Thanks Tom, we will make these updates On Fri, Aug 10, 2012 at 11:38 AM, t.petch wrote: > Something different and a bit lighter:-) > > s.4 "PLAT: PLAT is Provider side translator(XLAT) that complies with > [RFC6146]. It translates N:1 global IPv6 packets to global > IPv4 packets, and vice versa." > Is that really N:1 packets? > s/packets/addresses > s.6.1 "The private IPv4 host on this diagram " > which is the private host? OK I worked out that the host on the left > had the private addresses, but this could be clearer > 'The private IPv4 host on the left hand side of this diagram ' > or > 'The host on this diagram with the private IPv4 addresses ' > We will change it to 'The host on this diagram with the private IPv4 addres= ses ' > and the first occurrences of PLAT, CLAT and UE I would like to see > expanded. > Good idea, will do. CB > Tom Petch > > > ----- Original Message ----- > From: "Cameron Byrne" > To: "R=E9mi Despr=E9s" > Cc: "v6ops WG" ; "V6ops Chairs" > > Sent: Friday, August 10, 2012 5:39 PM > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt > > > On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s > wrote: >> >> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >> >> >> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" > wrote: >>> >>> Did we already conclude that this is a BCP and not Informational? We >>> should just put it in the latter category and move on/progress. >>> >>> >> >> Yes, afaik, the chairs have accepted bcp status and have accepted the > bcp >> scenario text. >> >> The chairs also direct the WG to move on to any remainig technical > issuess. >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >> >> >> After that, Lorenzo proposed an approach, which I approved, to resolve > the >> last issue I had raised. >> If the chairs also agree, all is AFAIK OK for the draft to proceed > without >> objection as BCP. >> Regards,` >> RD >> > > R=E9mi, > > It sounds like you are deferring to the chairs. > > I too will defer to the chairs, since my focus is moving forward. > > The chairs have already made their position known, and they may > re-open this issue. > > You and Lorenzo have supplied input to the chairs. > > My input to the chairs is that there should be no changes required of > the current text. In very basic logical terms the text currently says > > X =3D RFC 6146 > > IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network. > > Your original proposal and more or less Lorenzo's proposal > > Y =3D DS-lite > > IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network > > The difference between "only X" and "X and not Y" is that there must > be a scenario where X and Y both occur. I do not believe that is the > case that X and Y will occur together so there is no need to > complicated the document with this. And, your meaning, which i > believe is to say that tunneling is better than translation, is > already documented in the IETF (RFC 4213, others?) > > As i said before, it seems like the aim is to create a pecking order > of transition solutions. If you want to do that, that is the scope of > a different draft. > > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From despres.remi@laposte.net Sat Aug 11 00:15:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADF211E80D9 for ; Sat, 11 Aug 2012 00:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0rPUA-EWmxo for ; Sat, 11 Aug 2012 00:14:59 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8D11E80A3 for ; Sat, 11 Aug 2012 00:14:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id D76C770000A9; Sat, 11 Aug 2012 09:14:57 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 53915700008D; Sat, 11 Aug 2012 09:14:55 +0200 (CEST) X-SFR-UUID: 20120811071455342.53915700008D@msfrf2206.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 11 Aug 2012 09:14:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D9B9695-E937-475A-9479-CD66A0F97B50@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 07:15:00 -0000 Cameron,=20 Since the point made doesn't seem clear enough, here is another try. - 464XLAT as best practice where providers offer NAT64 as their ONLY = IPv4 support across their access networks: agreed.=20 - 464XLAT declared best practice independently of OTHER IPv4 support = providers may offer across their access networks, in addition to = NAT64-CGN: disagreed. If a rough consensus is nevertheless declared that ignores this, = whatever the reasons, I want to be clearly out of it. Your key argument below is that no provider would realistically support = both 464-CGN and DS-Lite, but this isn't right AFAIK.=20 NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" = [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs = across IPv6-only access networks such that "communications between = end-nodes stay within their address family" [RFC6333]. Satisfying both = needs does make sense.=20 You object to what you see as a pecking order if, for example, 464XLAT = is said to be "the best way of running IPv4 over IPv6 in networks that = cannot support encapsulation". But the word "best" in "BCP" is per se = expressing some order. Current text implicitly asserts that using = 464XLAT IS better than using DS-Lite where both are available. This = isn't acceptable AFAIAC.=20 Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, = explicitly or implicitly, which one is best practice where 464XLAT = coexists with DS-Lite: it can be left unspecified.=20 FWIW, =20 RD Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : > On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>=20 >>=20 >> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" = wrote: >>>=20 >>> Did we already conclude that this is a BCP and not Informational? We >>> should just put it in the latter category and move on/progress. >>>=20 >>>=20 >>=20 >> Yes, afaik, the chairs have accepted bcp status and have accepted the = bcp >> scenario text. >>=20 >> The chairs also direct the WG to move on to any remainig technical = issuess. >>=20 >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>=20 >>=20 >> After that, Lorenzo proposed an approach, which I approved, to = resolve the >> last issue I had raised. >> If the chairs also agree, all is AFAIK OK for the draft to proceed = without >> objection as BCP. >> Regards,` >> RD >>=20 >=20 > R=E9mi, >=20 > It sounds like you are deferring to the chairs. >=20 > I too will defer to the chairs, since my focus is moving forward. >=20 > The chairs have already made their position known, and they may > re-open this issue. >=20 > You and Lorenzo have supplied input to the chairs. >=20 > My input to the chairs is that there should be no changes required of > the current text. In very basic logical terms the text currently says >=20 > X =3D RFC 6146 >=20 > IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network. >=20 > Your original proposal and more or less Lorenzo's proposal >=20 > Y =3D DS-lite >=20 > IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only > hosts and apps on an IPv6-only access network >=20 > The difference between "only X" and "X and not Y" is that there must > be a scenario where X and Y both occur. I do not believe that is the > case that X and Y will occur together so there is no need to > complicated the document with this. And, your meaning, which i > believe is to say that tunneling is better than translation, is > already documented in the IETF (RFC 4213, others?) >=20 > As i said before, it seems like the aim is to create a pecking order > of transition solutions. If you want to do that, that is the scope of > a different draft. >=20 >=20 > CB From randy@psg.com Sat Aug 11 05:51:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAF121F8516 for ; Sat, 11 Aug 2012 05:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpAOTvD1LZus for ; Sat, 11 Aug 2012 05:51:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 55BEB21F85BB for ; Sat, 11 Aug 2012 05:51:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T0BAF-000AMR-AT; Sat, 11 Aug 2012 12:51:35 +0000 Date: Sat, 11 Aug 2012 08:51:47 -0400 Message-ID: From: Randy Bush To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 12:51:37 -0000 > RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 > should have updated 5375. updating the status of a number of RFCs was 'discussed' extensively at the time of 6164's process. what stands is a compromise with all the warts that come with most compromises. the astute rfc reader can find the status/recommendation, but it's not pretty. it would be interesting if the community has moved forward enough to be more realistic about ipv6 addressing. randy, who still has scars from the TLA wars From phdgang@gmail.com Sat Aug 11 08:59:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4321F8628 for ; Sat, 11 Aug 2012 08:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFgw9qX+boIm for ; Sat, 11 Aug 2012 08:59:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E01821F8627 for ; Sat, 11 Aug 2012 08:59:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2624938vbb.31 for ; Sat, 11 Aug 2012 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bSCaJvv0LPAeYkNETwWGVAc+APpqivJ14qxlhfbT9EU=; b=pLCpzgVryEXWL6jM3UweljFCYynbdIooMb9NqrDTwniRY6Pz7JtBN+6XzcRDIMegaD tMT05deLp+iqoWPSl5gmyGhNDDzGO8XCghVlnySwVdDOqVZOh86Y6h1snneI70k+a8RU b1UMMOsmqEhZ0xl/BYa3DEuQebc00wNiD07DKc9CGCh6uJ9Jp5a29mhrdKe5y1+nzBbP MjXsxwpaAw0pPtHEgVYILeCDczsrF31y6sg2U6iiQw6oarXDds4XAp2lQ+lW969TeXyH g7TGo54FCbVhNDqozI/tPq7suB8QZjeuYLXyZNKX1PSTk3OXgqunatC4TDi5mv4iu4M2 NzJw== MIME-Version: 1.0 Received: by 10.58.33.234 with SMTP id u10mr3967095vei.49.1344700792806; Sat, 11 Aug 2012 08:59:52 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Sat, 11 Aug 2012 08:59:52 -0700 (PDT) In-Reply-To: <2D9B9695-E937-475A-9479-CD66A0F97B50@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> <2D9B9695-E937-475A-9479-CD66A0F97B50@laposte.net> Date: Sat, 11 Aug 2012 23:59:52 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:59:54 -0000 2012/8/11, R=E9mi Despr=E9s : > Cameron, > > Since the point made doesn't seem clear enough, here is another try. > > - 464XLAT as best practice where providers offer NAT64 as their ONLY IPv4 > support across their access networks: agreed. > - 464XLAT declared best practice independently of OTHER IPv4 support > providers may offer across their access networks, in addition to NAT64-CG= N: > disagreed. > > If a rough consensus is nevertheless declared that ignores this, whatever > the reasons, I want to be clearly out of it. > > Your key argument below is that no provider would realistically support b= oth > 464-CGN and DS-Lite, but this isn't right AFAIK. > NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" > [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs > across IPv6-only access networks such that "communications between end-no= des > stay within their address family" [RFC6333]. Satisfying both needs does m= ake > sense. The communication model is similar but incentive is different I guess. DS-Lite is built on the dual-stack model. The target is to guarantee communication experiences within same address family across different family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 service. RFC6180 made really clear statements for each model (see section 4.3 and 4.4), I guess we don't need to argue that here. So, why not use it to get rid of confusions. Item 1 could be clearer as 1. There is an IPv6-only Deployment [RFC6180] that uses stateful translation [RFC6146] > You object to what you see as a pecking order if, for example, 464XLAT is > said to be "the best way of running IPv4 over IPv6 in networks that canno= t > support encapsulation". But the word "best" in "BCP" is per se expressing > some order. Current text implicitly asserts that using 464XLAT IS better > than using DS-Lite where both are available. This isn't acceptable AFAIAC= . > Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, > explicitly or implicitly, which one is best practice where 464XLAT coexis= ts > with DS-Lite: it can be left unspecified. > > FWIW, > RD > > > Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : > >> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s >> wrote: >>> >>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>> >>> >>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" >>> wrote: >>>> >>>> Did we already conclude that this is a BCP and not Informational? We >>>> should just put it in the latter category and move on/progress. >>>> >>>> >>> >>> Yes, afaik, the chairs have accepted bcp status and have accepted the >>> bcp >>> scenario text. >>> >>> The chairs also direct the WG to move on to any remainig technical >>> issuess. >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>> >>> >>> After that, Lorenzo proposed an approach, which I approved, to resolve >>> the >>> last issue I had raised. >>> If the chairs also agree, all is AFAIK OK for the draft to proceed >>> without >>> objection as BCP. >>> Regards,` >>> RD >>> >> >> R=E9mi, >> >> It sounds like you are deferring to the chairs. >> >> I too will defer to the chairs, since my focus is moving forward. >> >> The chairs have already made their position known, and they may >> re-open this issue. >> >> You and Lorenzo have supplied input to the chairs. >> >> My input to the chairs is that there should be no changes required of >> the current text. In very basic logical terms the text currently says >> >> X =3D RFC 6146 >> >> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only >> hosts and apps on an IPv6-only access network. >> >> Your original proposal and more or less Lorenzo's proposal >> >> Y =3D DS-lite >> >> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only >> hosts and apps on an IPv6-only access network >> >> The difference between "only X" and "X and not Y" is that there must >> be a scenario where X and Y both occur. I do not believe that is the >> case that X and Y will occur together so there is no need to >> complicated the document with this. And, your meaning, which i >> believe is to say that tunneling is better than translation, is >> already documented in the IETF (RFC 4213, others?) >> >> As i said before, it seems like the aim is to create a pecking order >> of transition solutions. If you want to do that, that is the scope of >> a different draft. >> >> >> CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sat Aug 11 11:03:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399321F8630 for ; Sat, 11 Aug 2012 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Q7fQBX8JYU for ; Sat, 11 Aug 2012 11:03:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8716B21F862A for ; Sat, 11 Aug 2012 11:03:15 -0700 (PDT) Received: from joels-MacBook-Air.local (66.sub-166-250-37.myvzw.com [166.250.37.66]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7BI3ECh099761 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 11 Aug 2012 18:03:15 GMT (envelope-from joelja@bogus.com) Message-ID: <50269E5D.7040500@bogus.com> Date: Sat, 11 Aug 2012 11:03:09 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 11 Aug 2012 18:03:15 +0000 (UTC) Subject: [v6ops] draft minutes, ietf84 thursday 0900. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 18:03:16 -0000 Draft Minutes IETF 84 Thursday August 2nd - Agenda Discussion - Sept 29th interim meeting dicussion. Q - how many folks would be at ripe anyway A - order of a dozen Ron Bonica - Q - asking question of are there drafts that we would want to discuss with a larger community 20-25ish hands Date is noted as Saturday, September 29th - 1. Design Guidelines for IPv6 Networks 29-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf Tim C - As one of the authors of 5375 there's a been a lot of deplyment since then Fred B - with respect to 5375 should people who want make changes to it file erratum on it? Dan Y - this document would be worthwhile - security considerations should be infilled. Brian H (jabber) - Is someone proposing to use the errata system as an issue tracker? Joel J (fred)- @brian - fred, but not exactly Joel J (mic) - Is this a style guide from one person's view or a survey of existing design styles? fred B - icp guidance - is it time to last call it? Supported additional work on the document - Eric Kline, Eric Nygren, Dan York 2. IPv6 Guidance for Internet Content and Application Service Providers 10-Jul-12, (no slides required) Fred - (discussion of last call on mailing list after the meeting) 3. Service Provider Wi-Fi Services Over Residential Architectures 29-Apr-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-7.pdf dan y - it's in interesting draft - is this a v6ops doc ? Fred - does this document belong here ? (poll) we don't really have a viewpoint in paris there was some interest. continue to work it with interested parties and we'll see where that goes. 4. Enterprise Incremental IPv6 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-0.pdf Fred - most recent guidance in this area is rfc 4852 historically what the ietf has recomeded a pa prefix you recomended pi I take it you have an opinion Number of people at mic - Tim C, Lorenzo C, Bob H, Fred - document should talk about different options Lorenzo C - Using two prefixes is not multihoming ... NPT in Japan is a use case of how a pig can fly if there are enough economics behind it Eric K - disable security extentions - disagree as phrased Tim C - - reviewing where we are in current practice allows us to idenitfy shortcomings Merike k - I like this work. there's probably other general guidelines that you can point out differing opinions on. Philip M - second bullet question about isis vs ospf Lorenzo C - ospfv3 is a similar protocol not the same. point-3 I don't agree with - there are other ways in v6. no comfortable making a recomnedation feels - like it started a here's what we did morphed into here's how we did it Mark A - Lots of enterprises knock out icmp completely, just doesn't work completely Tim C - 4860 talks about filtering policy K K - is the document too ambitious> Fred B - Perception is that a document of this class is desired Want three operators who have deployed ipv6 to review and comment on the draft. Those who want it to become a working group draft hum (some in favor) (none opposed) 5. A Reference Framework for DC Migration to IPv6 19-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-1.pdf Dan Y - I think it's another good one. Make a comment to the chairs - that this is a package of a documents. we should harmonize some names Philip M - jsut a question - does that apply to wireline incremental? Lorenzo C - Full disclusre wee did do this (nat64) but it was 2008 and our own infrastrucure - in a multitenetant there's no way to pipe this in. joel j - we shouldn't say that it's a sustainable solution. Diego L - this is certainly switchable warren k - This doesn't work for use but does that mean it doesn't work for anyone. Lorenzo - we should talk about what wording we can use to to gain consensus on it. place mautrity level on non—equal footing with 2 and 3 Fred B - hum for wg acceptance (some in favor), (none opposed.0 Return to discussion of: - 1. Design Guidelines for IPv6 Networks 29-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf due to remaining time. Discussion of dedicated v6 vs v4/v6 circuits/vlans/pseudowires boris y (telus) - consistency of quos control (by address family) lorenzo C- Option b only exists because of bad job a specifiy per interface protocol counters. Tim C - Just another example when mentioning that tradeoff (vendor gap) Bill F - Hardware issue, it's in the 2006 spec discussion of link local addressing: Lorenzo C- a breaks traceroute - e.g. when there are multiple links. (e.g. because you don't see the hashingtake place. Marc blanchett - would be great to have one but I doubt the level of consensus will reise to than inclusive of nanog/ fred B - expect to see ongoing work - should we be adopting this? hum? (more in favor than opposed) not strog though. lets continue working it From fred@cisco.com Sat Aug 11 13:33:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0754F21F853C for ; Sat, 11 Aug 2012 13:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.32 X-Spam-Level: X-Spam-Status: No, score=-110.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VBsHR0io5e7 for ; Sat, 11 Aug 2012 13:33:31 -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 5E5E221F8517 for ; Sat, 11 Aug 2012 13:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=66; q=dns/txt; s=iport; t=1344717211; x=1345926811; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bha2TeunExssx7kNU5xFMeRYERFR3nbJlI5fiHowgyI=; b=KmDdrdoyxqGr8QlgqS25+20l/RdjwOmMfxEJi7an4a737I2y2rg2ZTxP xUD/94OxCvQtthLN9WoU/euuRlo84O016u1F+bOxlP7RRleA3OPxKgySg E9cN7sdBzhr0bZDBd+nOxuSAHCP3B6fFruW11kkLsWNbNeGclCquh1ZNt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPvAJlCtJXG9/2dsb2JhbABEuXuBB4InEgEnPxIBPkInBA4nh2uYap9dkGNgA5VLjiqBZoJf X-IronPort-AV: E=Sophos;i="4.77,752,1336348800"; d="scan'208";a="110664970" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 11 Aug 2012 20:33:31 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7BKXU1T004820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Aug 2012 20:33:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Sat, 11 Aug 2012 15:33:30 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Reminder: draft-ietf-v6ops-icp-guidance WGLC Thread-Index: AQHNeACR5/nIOofjKUyaPbCdZ+YMjQ== Date: Sat, 11 Aug 2012 20:33:30 +0000 Message-ID: <540B9CF3-746C-45D0-8BDE-1734EC179C32@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19102.006 x-tm-as-result: No--25.318800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <24A4084B0083E044B81ACB5432233F0A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: V6ops Chairs , Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-icp-guidance WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 20:33:32 -0000 We have another week for WGLC for draft-ietf-v6ops-icp-guidance. From joelja@bogus.com Sun Aug 12 14:53:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29B021F85ED for ; Sun, 12 Aug 2012 14:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvICyBGoz6Kc for ; Sun, 12 Aug 2012 14:53:29 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 400CD21F85E4 for ; Sun, 12 Aug 2012 14:53:29 -0700 (PDT) Received: from joels-MacBook-Air.local (2.sub-166-250-33.myvzw.com [166.250.33.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7CLrKYs007690 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 12 Aug 2012 21:53:21 GMT (envelope-from joelja@bogus.com) Message-ID: <50282231.3000307@bogus.com> Date: Sun, 12 Aug 2012 14:37:53 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 12 Aug 2012 21:53:21 +0000 (UTC) Subject: [v6ops] draft minutes, ietf84 friday 0900 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 21:53:30 -0000 Friday August 3nd Semantic IPv6 Prefix 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-4.pdf George M - outside of your locous of control it can't be trusted - fred - help me understand the semantics of ip addressing at a car manufacturer, they want to embedd the vin number or building number they don't seem to have the same problems as you're looking at. Give me a use case Jaing - they have a different understanding of use case George M- a pragmatic dicision was made to walk from the tla model. there was an architure that put proscriptive labels on addresses Wes G - Renumbering is not an easy thing difficulty of merging two addressing planes Dan Y - You have a security section with no security considerations. Tim C - at the heart of it an address planning issue. pros/cons for this sort of approach. kk - Implied suggestion that applications become aware of address semantics. Seem like a really bad idea. fred - As soon sa you put semantics in an address by defintion you're revealing information. NAT64 Operational Experiences 4-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-2.pdf Cameron Byrne presenting Dan Y - thinks it's goo to have a document like this we know this in operational use Wes george - would I recomend it? compared to nat444 absolutely inherent mistrust of things that don't perpetuate what we've already done yes this does work. it's not a corner case. cb - 6145 46 44 great for box builders this doc sets this in context for an operational network dan york - I think it's exactly the sort of doc we should have Fred B - right now not a wg document do we want to do that hum (many in favor) (none opposed.) Cameron B - I'd say it needs more work prioro to last call 464XLAT: Combination of Stateful and Stateless Translation 2-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-5.pdf lorenzo c- didn't understand the distinction can you explain the clat is assigned a real v6 address where the dest is synthesized fred b - as one of the authors of 6052 - I might have to do a stateful thing or I imght have an embdded v4 address there's a neccestiy packets go to the service to which they are intended Remi D - Question on the iana section Ron B - It's fine lorenzo c - it's fine and it came from your request for a special interface id if it's a procedural problem then we can not do it. Remi D - keeping it simlifies the design. On the question of bcp vs informational Lorenzo C - You don't have to do dap?(DAD) for those address because they're reserved. I don't have strong opinion. Remi D - double translation loses transparency. Cameron B- We have taken care in the document that this is not the greatest solution but it fills the gap. This is a way to operationalize nat64 dns64 to meet our customers needs. Lorenzo C - The work in softwire is higher quality but it's signficantly harder to deploy. lets unblock turning on v6 in the network. Lorenzo C- It is the best current practice within a narrow usage case - dave thayler - Nothing new to speficy new or algorythms. do this, bcp Fred B - if it goes bcp it's bcp in a use case. applicabiltiy statement. Ron B - put the statement in the bcp Fred - we did adopt this as a wg document. hum we'll take this to wg last call (some in favor none opposed.) hum in favor of bcp/informational/experimental some for bcp some for informational none for experimental IPv6 over ATM Interworking Function 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-3.pdf Fred B - question - internet architecturel has a defined internetworking function (a router) which you didn't use. Zhang - don't know how to answer this Wes G - Where did you find a dslam that does atm but speaks ipv6 Zhang - Came from from china telecom Lorenzo C - A large number of these devices are doing ipoe which doesn't support v6. I think you might be willing to replace the bng and do you want. Fred B - I will invite you to discuss it on the list. From joelja@bogus.com Sun Aug 12 14:58:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D521F8605 for ; Sun, 12 Aug 2012 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8z8OXefieZc for ; Sun, 12 Aug 2012 14:58:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 467E221F85E1 for ; Sun, 12 Aug 2012 14:58:43 -0700 (PDT) Received: from joels-MacBook-Air.local (2.sub-166-250-33.myvzw.com [166.250.33.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7CLwfBD007740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 12 Aug 2012 21:58:42 GMT (envelope-from joelja@bogus.com) Message-ID: <5028270F.3060204@bogus.com> Date: Sun, 12 Aug 2012 14:58:39 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: V6ops Chairs , IPv6 Ops WG , "ops-ads@tools.ietf.org" Content-Type: multipart/mixed; boundary="------------030201020806030907020206" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 12 Aug 2012 21:58:43 +0000 (UTC) Subject: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 21:58:44 -0000 This is a multi-part message in MIME format. --------------030201020806030907020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While there are some details still to be worked out it's time to get the framework in place for the interim to coincide with the end of RIPE 65, Amsterdam, 24 - 28 September 2012. We believe that the location will be: Hotel Okura Ferdinand Bolstraat 333 1072 LH Amsterdam +31 (0) 20 678 7493 however that is not yet gospel I am told. The plan as it stands know is to attempt to time the meeting to accommodate remote participants in North American I have requested that it start at 1600cest. that said there are still a lot of details to be worked out. and and time one a Saturday is going to be an inconvenience to some (sorry) who might otherwise make it in the flesh or online. Things we can plan for however are an interim document submission deadline two weeks out from the meeting itself. Too be considered for inclusion in the interim agenda new or revised documented should be submitted to the IETF document system by 23:59 UTC on Sept 14th. more details will follow as we get them. --------------030201020806030907020206 Content-Type: text/calendar; name="iCal-20120812-145046.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iCal-20120812-145046.ics" BEGIN:VCALENDAR CALSCALE:GREGORIAN VERSION:2.0 X-WR-CALNAME:V6ops Interim Meeting document submission deadline METHOD:PUBLISH PRODID:-//Apple Inc.//Mac OS X 10.8//EN BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU DTSTART:20070311T020000 TZNAME:PDT TZOFFSETTO:-0700 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0700 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU DTSTART:20071104T020000 TZNAME:PST TZOFFSETTO:-0800 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20120812T214712Z UID:A784AB91-4382-4D39-93C4-2B30B887CD7D DTEND;TZID=America/Los_Angeles:20120914T170000 TRANSP:OPAQUE SUMMARY:V6ops Interim Meeting document submission deadline DTSTART;TZID=America/Los_Angeles:20120914T165900 DTSTAMP:20120812T214906Z SEQUENCE:9 BEGIN:VALARM X-WR-ALARMUID:2E53CB93-179D-41F3-AC53-E77FB035A12D UID:2E53CB93-179D-41F3-AC53-E77FB035A12D TRIGGER:-PT15S X-APPLE-DEFAULT-ALARM:TRUE ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR --------------030201020806030907020206-- From lorenzo@google.com Sun Aug 12 20:20:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209A321F8668 for ; Sun, 12 Aug 2012 20:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9beEtVubUvsM for ; Sun, 12 Aug 2012 20:20:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 116C921F860B for ; Sun, 12 Aug 2012 20:20:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7307546obb.31 for ; Sun, 12 Aug 2012 20:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=S4SKdDbF3J3ACMAfwSWfGzzXefjWUT3ailOoDaI6ow0=; b=cwmBf4d4oONM3gtWq8VOG4njdd/p3uULVWj5YlqYk7Lb4HmtW3QLoFuQa7VMZvbw/b Pjjn09jWItZDOA+9Z0cCDCKTw4SwORNnLUtPRThrnn+4cSvKQdKXaw1amnGoPp253EPt MAa8MliGK4Phu35ob/Rvc5jsIbyq4/t4LyFCqBWFGhC/cXXpmDatN495V5/fd+83r482 Y7Z7pwJNsPLP6IJrhtd+kBGlDtLyYXvHYEC29sY58ZvulUqxC8qi4hzsjlVDO9sb17w4 QlcCoisiIZKGd9w9RSjUX7QMzhNh27u+KU9C8R91OBywGQlAyvrENlwhpFVBul6Buw9O 2cGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=S4SKdDbF3J3ACMAfwSWfGzzXefjWUT3ailOoDaI6ow0=; b=bCD+Flcyi+xc7KJW/mSvmyM53ggtfoNvM6QzSi3EBAl1lslWY3qOSPd+joLk/9sLnh Lf8qqnkFzOAC6/IBLWr8ld2HCb0P5Q/nR42EME9WedZ5JOVOuZTqoPlCPmmhIksU8w95 tEif2Wn6+zUrX6PP5XNaX/NFH2DO/9H4dh4axvJMm/vNWoEk339r8QKo7jqPVGrkOurq 1QIW4M+kFgOLHQ+taBQaDTMrA0cvfuhf1WDD6vovUeGucCNjIMdiEl0SBO60BEIMbd73 Dv5Wta7v5g9ar9LDgA6eU2Yx9wl0yzYGgT+4uNgotWIKJFsHzh39zds3/1CwcTDhLLj+ VMaQ== Received: by 10.182.169.40 with SMTP id ab8mr9098424obc.34.1344828043475; Sun, 12 Aug 2012 20:20:43 -0700 (PDT) Received: by 10.182.169.40 with SMTP id ab8mr9098409obc.34.1344828043289; Sun, 12 Aug 2012 20:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Sun, 12 Aug 2012 20:20:23 -0700 (PDT) In-Reply-To: References: <20120806142829.81256B1E003@rfc-editor.org> <50215765.7060406@gmail.com> <13205C286662DE4387D9AF3AC30EF456D77178C049@EMBX01-WF.jnpr.net> <7AF2B382-0B88-4171-BBDA-3CF0807C1DAB@amsl.com> <13205C286662DE4387D9AF3AC30EF456D77178C212@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D77189AD37@EMBX01-WF.jnpr.net> From: Lorenzo Colitti Date: Mon, 13 Aug 2012 12:20:23 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=e89a8f6434eccde2af04c71d2d8c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkWpq4Wbn898BgbztZCOxstJH+zoYbPMk1dJiiu5/CsFR+XUgiz6M1g+A4i/XNQ/ff+TtCRhh0NgyxwtCgxB65OxrfejZnWYXVHH6WXJpnDmG9gRXjs1TDkR/LZvyVax25CAo5iZGf7a8dQcGD9BCDWBBrrUXWfmDjW4NYGR1rGad6EzS5XgSIYQ+Drc/4V5mpXUcge Cc: IETF v6ops list Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 03:20:45 -0000 --e89a8f6434eccde2af04c71d2d8c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 11, 2012 at 9:51 PM, Randy Bush wrote: > > RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 > > should have updated 5375. > > updating the status of a number of RFCs was 'discussed' extensively at > the time of 6164's process. what stands is a compromise with all the > warts that come with most compromises. the astute rfc reader can find > the status/recommendation, but it's not pretty. it would be interesting > if the community has moved forward enough to be more realistic about > ipv6 addressing. > Speaking as one of the authors of RFC6164 - I can't remember considering updating RFC 5375, as I was not aware of any conflict with it. So, at least on my part, that was an oversight. Filing an erratum saying "RFC 6164 should have updated RFC 5375, but didn't" seems like a fine plan to me. --e89a8f6434eccde2af04c71d2d8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 11, 2012 at 9:51 PM, Randy Bush= <r= andy@psg.com> wrote:
> RFC 6164 speaks directly to the /127 issue. So, it seems that 616= 4
> should have updated 5375.

updating the status of a number of RFCs was 'discussed' exten= sively at
the time of 6164's process. =A0what stands is a compromise with all the=
warts that come with most compromises. =A0the astute rfc reader can find the status/recommendation, but it's not pretty. =A0it would be interest= ing
if the community has moved forward enough to be more realistic about
ipv6 addressing.

Speaking as one of the auth= ors of RFC6164 - I can't remember considering updating RFC=A05375, as I= was not aware of any conflict with it. So, at least on my part, that was a= n oversight.

Filing an erratum saying "RFC 6164 should have updated = RFC 5375, but didn't" seems like a fine plan to me.
--e89a8f6434eccde2af04c71d2d8c-- From despres.remi@laposte.net Mon Aug 13 00:41:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54521F84F6 for ; Mon, 13 Aug 2012 00:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJmP6eX-gZ+o for ; Mon, 13 Aug 2012 00:41:44 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5874221F84F2 for ; Mon, 13 Aug 2012 00:41:43 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2406.sfr.fr (SMTP Server) with ESMTP id A4FBA70000B9; Mon, 13 Aug 2012 09:41:42 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2406.sfr.fr (SMTP Server) with ESMTP id 368C770000A3; Mon, 13 Aug 2012 09:41:40 +0200 (CEST) X-SFR-UUID: 20120813074140223.368C770000A3@msfrf2406.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 13 Aug 2012 09:41:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> <2D9B9695-E937-475A-9479-CD66A0F97 B50@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 07:41:45 -0000 Le 2012-08-11 =E0 17:59, GangChen a =E9crit : > 2012/8/11, R=E9mi Despr=E9s : >> Cameron, >>=20 >> Since the point made doesn't seem clear enough, here is another try. >>=20 (*) >> - 464XLAT as best practice where providers offer NAT64 as their ONLY = IPv4 >> support across their access networks: agreed. >> - 464XLAT declared best practice independently of OTHER IPv4 support >> providers may offer across their access networks, in addition to = NAT64-CGN: >> disagreed. >>=20 >> If a rough consensus is nevertheless declared that ignores this, = whatever >> the reasons, I want to be clearly out of it. >> Your key argument below is that no provider would realistically = support both >> 464-CGN and DS-Lite, but this isn't right AFAIK. (**) >> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" >> [RFC6146], and DS-Lite a solution for IPv4 clients to reach = NAT44-CGNs >> across IPv6-only access networks such that "communications between = end-nodes >> stay within their address family" [RFC6333]. Satisfying both needs = does make >> sense. > The communication model is similar but incentive is different I guess. > DS-Lite is built on the dual-stack model. The target is to guarantee > communication experiences within same address family across different > family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 > service. RFC6180 made really clear statements for each model (see > section 4.3 and 4.4), I guess we don't need to argue that here. So, > why not use it to get rid of confusions. >=20 > Item 1 could be clearer as >=20 > 1. There is an IPv6-only Deployment [RFC6180] that uses stateful > translation [RFC6146] The point is that an IPv6-only deployment with both a NAT-64-CGN and a = DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable = deployment (see (**) above). It is inappropriate, in this case, to = write that using NAT64 is necessarily best. - This point isn't covered by words you propose. - I can't see what would be wrong (besides NIH) in something like: "1. There is an IPv6-only access network that uses stateful translation = [RFC6146] as its sole transition solution for IPv4 via IPv6." =3D> (*) above is confirmed. Regards, RD >=20 >=20 >=20 >> You object to what you see as a pecking order if, for example, = 464XLAT is >> said to be "the best way of running IPv4 over IPv6 in networks that = cannot >> support encapsulation". But the word "best" in "BCP" is per se = expressing >> some order. Current text implicitly asserts that using 464XLAT IS = better >> than using DS-Lite where both are available. This isn't acceptable = AFAIAC. >> Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, >> explicitly or implicitly, which one is best practice where 464XLAT = coexists >> with DS-Lite: it can be left unspecified. >>=20 >> FWIW, >> RD >>=20 >>=20 >> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : >>=20 >>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s = >>> wrote: >>>>=20 >>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>>>=20 >>>>=20 >>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" >>>> wrote: >>>>>=20 >>>>> Did we already conclude that this is a BCP and not Informational? = We >>>>> should just put it in the latter category and move on/progress. >>>>>=20 >>>>>=20 >>>>=20 >>>> Yes, afaik, the chairs have accepted bcp status and have accepted = the >>>> bcp >>>> scenario text. >>>>=20 >>>> The chairs also direct the WG to move on to any remainig technical >>>> issuess. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>>>=20 >>>>=20 >>>> After that, Lorenzo proposed an approach, which I approved, to = resolve >>>> the >>>> last issue I had raised. >>>> If the chairs also agree, all is AFAIK OK for the draft to proceed >>>> without >>>> objection as BCP. >>>> Regards,` >>>> RD >>>>=20 >>>=20 >>> R=E9mi, >>>=20 >>> It sounds like you are deferring to the chairs. >>>=20 >>> I too will defer to the chairs, since my focus is moving forward. >>>=20 >>> The chairs have already made their position known, and they may >>> re-open this issue. >>>=20 >>> You and Lorenzo have supplied input to the chairs. >>>=20 >>> My input to the chairs is that there should be no changes required = of >>> the current text. In very basic logical terms the text currently = says >>>=20 >>> X =3D RFC 6146 >>>=20 >>> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only >>> hosts and apps on an IPv6-only access network. >>>=20 >>> Your original proposal and more or less Lorenzo's proposal >>>=20 >>> Y =3D DS-lite >>>=20 >>> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only >>> hosts and apps on an IPv6-only access network >>>=20 >>> The difference between "only X" and "X and not Y" is that there must >>> be a scenario where X and Y both occur. I do not believe that is = the >>> case that X and Y will occur together so there is no need to >>> complicated the document with this. And, your meaning, which i >>> believe is to say that tunneling is better than translation, is >>> already documented in the IETF (RFC 4213, others?) >>>=20 >>> As i said before, it seems like the aim is to create a pecking order >>> of transition solutions. If you want to do that, that is the scope = of >>> a different draft. >>>=20 >>>=20 >>> CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From phdgang@gmail.com Mon Aug 13 01:39:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930CD21F86E3 for ; Mon, 13 Aug 2012 01:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8xPtCrlCAH1 for ; Mon, 13 Aug 2012 01:39:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9014721F86DF for ; Mon, 13 Aug 2012 01:39:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3516467vbb.31 for ; Mon, 13 Aug 2012 01:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4WM+ZkvpJLqPiugcXfxCf7c9DWaed5pp5HJRsngaZg4=; b=l/EZ1YoGQjFSzlWnja0/WVq+/OWJ1dQyUI7B4Vjky9ewjW/mpMNsaCyB1HI3nOq96D Fe5YUq4pKwqyrIu+CrdF/trsvt/bUiG2cy6IdmIsu49Weiczu1uBkmnA3JNFUh5c3Vt3 +Lib4c4v7CVBy/0R9ITD4Nq6dKuDovKNuGXgQJ+akuJVyaY/heaiF+DbgsFfvvKaV4mx KhJS+uhj6C9Ki5Ut4EKGfoABrETaO47IUejcqne9VYUfC7J2Zgfcxekj2fFUQrG+A2X/ B9eb8KzInGiCICnarSi1PalC5yeRV4euIYNeXk0S95RKRrnSE3uK58ERFyassUlKqBGq UaYw== MIME-Version: 1.0 Received: by 10.58.102.83 with SMTP id fm19mr8923857veb.24.1344847154979; Mon, 13 Aug 2012 01:39:14 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Mon, 13 Aug 2012 01:39:14 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> Date: Mon, 13 Aug 2012 16:39:14 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 08:39:16 -0000 2012/8/13, R=E9mi Despr=E9s : > > Le 2012-08-11 =E0 17:59, GangChen a =E9crit : > >> 2012/8/11, R=E9mi Despr=E9s : >>> Cameron, >>> >>> Since the point made doesn't seem clear enough, here is another try. >>> > > (*) >>> - 464XLAT as best practice where providers offer NAT64 as their ONLY >>> IPv4 >>> support across their access networks: agreed. >>> - 464XLAT declared best practice independently of OTHER IPv4 support >>> providers may offer across their access networks, in addition to >>> NAT64-CGN: >>> disagreed. >>> >>> If a rough consensus is nevertheless declared that ignores this, >>> whatever >>> the reasons, I want to be clearly out of it. > > > >>> Your key argument below is that no provider would realistically support >>> both >>> 464-CGN and DS-Lite, but this isn't right AFAIK. > > (**) >>> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" >>> [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs >>> across IPv6-only access networks such that "communications between >>> end-nodes >>> stay within their address family" [RFC6333]. Satisfying both needs does >>> make >>> sense. > > >> The communication model is similar but incentive is different I guess. >> DS-Lite is built on the dual-stack model. The target is to guarantee >> communication experiences within same address family across different >> family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 >> service. RFC6180 made really clear statements for each model (see >> section 4.3 and 4.4), I guess we don't need to argue that here. So, >> why not use it to get rid of confusions. >> >> Item 1 could be clearer as >> >> 1. There is an IPv6-only Deployment [RFC6180] that uses stateful >> translation [RFC6146] > > The point is that an IPv6-only deployment with both a NAT-64-CGN and a > DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable > deployment (see (**) above). It is inappropriate, in this case, to write > that using NAT64 is necessarily best. > - This point isn't covered by words you propose. Hope you may consider it again. My point here is - The reference of RFC6180 gives audients a very clear context, in which NAT64 is the major transition solution (That was already documented section 4.4 in RFC6180; OTOH, DS-lite was described in section 4.3. Very explicit: two different cases here) =3D>I guess that covers your needs - IPv6-only deployment in RFC6180 perfectly matches 464xlat target scenarios. This would not complicate the document with additional scenario justification, but help the clarification. =3D>I guess that covers author needs So why not adopt RFC6180? > - I can't see what would be wrong (besides NIH) in something like: > "1. There is an IPv6-only access network that uses stateful translation > [RFC6146] as its sole transition solution for IPv4 via IPv6." > =3D> (*) above is confirmed. The logic seems to me you are using one technology to pick BCP. I guess we are discussing the scenario picking BCP BRs Gang > Regards, > RD > > > >> >> >> >>> You object to what you see as a pecking order if, for example, 464XLAT >>> is >>> said to be "the best way of running IPv4 over IPv6 in networks that >>> cannot >>> support encapsulation". But the word "best" in "BCP" is per se >>> expressing >>> some order. Current text implicitly asserts that using 464XLAT IS bette= r >>> than using DS-Lite where both are available. This isn't acceptable >>> AFAIAC. >>> Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, >>> explicitly or implicitly, which one is best practice where 464XLAT >>> coexists >>> with DS-Lite: it can be left unspecified. >>> >>> FWIW, >>> RD >>> >>> >>> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : >>> >>>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s >>>> >>>> wrote: >>>>> >>>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>>>> >>>>> >>>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" >>>>> wrote: >>>>>> >>>>>> Did we already conclude that this is a BCP and not Informational? We >>>>>> should just put it in the latter category and move on/progress. >>>>>> >>>>>> >>>>> >>>>> Yes, afaik, the chairs have accepted bcp status and have accepted the >>>>> bcp >>>>> scenario text. >>>>> >>>>> The chairs also direct the WG to move on to any remainig technical >>>>> issuess. >>>>> >>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>>>> >>>>> >>>>> After that, Lorenzo proposed an approach, which I approved, to resolv= e >>>>> the >>>>> last issue I had raised. >>>>> If the chairs also agree, all is AFAIK OK for the draft to proceed >>>>> without >>>>> objection as BCP. >>>>> Regards,` >>>>> RD >>>>> >>>> >>>> R=E9mi, >>>> >>>> It sounds like you are deferring to the chairs. >>>> >>>> I too will defer to the chairs, since my focus is moving forward. >>>> >>>> The chairs have already made their position known, and they may >>>> re-open this issue. >>>> >>>> You and Lorenzo have supplied input to the chairs. >>>> >>>> My input to the chairs is that there should be no changes required of >>>> the current text. In very basic logical terms the text currently says >>>> >>>> X =3D RFC 6146 >>>> >>>> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only >>>> hosts and apps on an IPv6-only access network. >>>> >>>> Your original proposal and more or less Lorenzo's proposal >>>> >>>> Y =3D DS-lite >>>> >>>> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only >>>> hosts and apps on an IPv6-only access network >>>> >>>> The difference between "only X" and "X and not Y" is that there must >>>> be a scenario where X and Y both occur. I do not believe that is the >>>> case that X and Y will occur together so there is no need to >>>> complicated the document with this. And, your meaning, which i >>>> believe is to say that tunneling is better than translation, is >>>> already documented in the IETF (RFC 4213, others?) >>>> >>>> As i said before, it seems like the aim is to create a pecking order >>>> of transition solutions. If you want to do that, that is the scope of >>>> a different draft. >>>> >>>> >>>> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From despres.remi@laposte.net Mon Aug 13 02:37:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6A21F8508 for ; Mon, 13 Aug 2012 02:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Nh3SggoZQr9 for ; Mon, 13 Aug 2012 02:37:28 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 21F7821F870E for ; Mon, 13 Aug 2012 02:37:25 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id D02B9700009B; Mon, 13 Aug 2012 11:37:24 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 09CB970000A4; Mon, 13 Aug 2012 11:37:22 +0200 (CEST) X-SFR-UUID: 20120813093722402.09CB970000A4@msfrf2114.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 13 Aug 2012 11:37:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32B857FD-016B-435E-B83D-3BF603BDEEB3@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:37:29 -0000 Le 2012-08-13 =E0 10:39, GangChen a =E9crit : > 2012/8/13, R=E9mi Despr=E9s : >>=20 >> Le 2012-08-11 =E0 17:59, GangChen a =E9crit : >>=20 >>> 2012/8/11, R=E9mi Despr=E9s : >>>> Cameron, >>>>=20 >>>> Since the point made doesn't seem clear enough, here is another = try. >>>>=20 >>=20 >> (*) >>>> - 464XLAT as best practice where providers offer NAT64 as their = ONLY >>>> IPv4 >>>> support across their access networks: agreed. >>>> - 464XLAT declared best practice independently of OTHER IPv4 = support >>>> providers may offer across their access networks, in addition to >>>> NAT64-CGN: >>>> disagreed. >>>>=20 >>>> If a rough consensus is nevertheless declared that ignores this, >>>> whatever >>>> the reasons, I want to be clearly out of it. >>=20 >>=20 >>=20 >>>> Your key argument below is that no provider would realistically = support >>>> both >>>> 464-CGN and DS-Lite, but this isn't right AFAIK. >>=20 >> (**) >>>> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" >>>> [RFC6146], and DS-Lite a solution for IPv4 clients to reach = NAT44-CGNs >>>> across IPv6-only access networks such that "communications between >>>> end-nodes >>>> stay within their address family" [RFC6333]. Satisfying both needs = does >>>> make >>>> sense. >>=20 >>=20 >>> The communication model is similar but incentive is different I = guess. >>> DS-Lite is built on the dual-stack model. The target is to guarantee >>> communication experiences within same address family across = different >>> family. 464xlat adopts IPv6-only model. It aims to serve LIMITED = ipv4 >>> service. RFC6180 made really clear statements for each model (see >>> section 4.3 and 4.4), I guess we don't need to argue that here. So, >>> why not use it to get rid of confusions. >>>=20 >>> Item 1 could be clearer as >>>=20 >>> 1. There is an IPv6-only Deployment [RFC6180] that uses = stateful >>> translation [RFC6146] >>=20 >> The point is that an IPv6-only deployment with both a NAT-64-CGN and = a >> DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable >> deployment (see (**) above). It is inappropriate, in this case, to = write >> that using NAT64 is necessarily best. >> - This point isn't covered by words you propose. >=20 > Hope you may consider it again. >=20 > My point here is > - The reference of RFC6180 gives audients a very clear context, in > which NAT64 is the major transition solution (That was already > documented section 4.4 in RFC6180; OTOH, DS-lite was described in > section 4.3. Very explicit: two different cases here) > =3D>I guess that covers your needs >=20 > - IPv6-only deployment in RFC6180 perfectly matches 464xlat target > scenarios. This would not complicate the document with additional > scenario justification, but help the clarification. > =3D>I guess that covers author needs >=20 > So why not adopt RFC6180? "IPv6-only deployment" as defined in RFC6180 shouldn't be taken IMHO as = a clarifying term for 464XLAT because section 4.4 of this RFC is = particularly hard to decode. It can be understood that, in one of its = IPv6-only domains, all applications are IPv6-only, so that 464XLAT = support of IPv4-only applications is out of scope. >> - I can't see what would be wrong (besides NIH) in something like: >> "1. There is an IPv6-only access network that uses stateful = translation >> [RFC6146] as its sole transition solution for IPv4 via IPv6." >> =3D> (*) above is confirmed. >=20 > The logic seems to me you are using one technology to pick BCP. I > guess we are discussing the scenario picking BCP Not understood. RD >=20 > BRs >=20 > Gang >=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>> You object to what you see as a pecking order if, for example, = 464XLAT >>>> is >>>> said to be "the best way of running IPv4 over IPv6 in networks that >>>> cannot >>>> support encapsulation". But the word "best" in "BCP" is per se >>>> expressing >>>> some order. Current text implicitly asserts that using 464XLAT IS = better >>>> than using DS-Lite where both are available. This isn't acceptable >>>> AFAIAC. >>>> Note that I agree that it isn't necessary, in a 464XLAT RFC, to = tell, >>>> explicitly or implicitly, which one is best practice where 464XLAT >>>> coexists >>>> with DS-Lite: it can be left unspecified. >>>>=20 >>>> FWIW, >>>> RD >>>>=20 >>>>=20 >>>> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : >>>>=20 >>>>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s >>>>> >>>>> wrote: >>>>>>=20 >>>>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>>>>>=20 >>>>>>=20 >>>>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" = >>>>>> wrote: >>>>>>>=20 >>>>>>> Did we already conclude that this is a BCP and not = Informational? We >>>>>>> should just put it in the latter category and move on/progress. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> Yes, afaik, the chairs have accepted bcp status and have accepted = the >>>>>> bcp >>>>>> scenario text. >>>>>>=20 >>>>>> The chairs also direct the WG to move on to any remainig = technical >>>>>> issuess. >>>>>>=20 >>>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>>>>>=20 >>>>>>=20 >>>>>> After that, Lorenzo proposed an approach, which I approved, to = resolve >>>>>> the >>>>>> last issue I had raised. >>>>>> If the chairs also agree, all is AFAIK OK for the draft to = proceed >>>>>> without >>>>>> objection as BCP. >>>>>> Regards,` >>>>>> RD >>>>>>=20 >>>>>=20 >>>>> R=E9mi, >>>>>=20 >>>>> It sounds like you are deferring to the chairs. >>>>>=20 >>>>> I too will defer to the chairs, since my focus is moving forward. >>>>>=20 >>>>> The chairs have already made their position known, and they may >>>>> re-open this issue. >>>>>=20 >>>>> You and Lorenzo have supplied input to the chairs. >>>>>=20 >>>>> My input to the chairs is that there should be no changes required = of >>>>> the current text. In very basic logical terms the text currently = says >>>>>=20 >>>>> X =3D RFC 6146 >>>>>=20 >>>>> IF (X) then 464XLAT is BCP for providing IPv4 service to = IPv4-only >>>>> hosts and apps on an IPv6-only access network. >>>>>=20 >>>>> Your original proposal and more or less Lorenzo's proposal >>>>>=20 >>>>> Y =3D DS-lite >>>>>=20 >>>>> IF (X and NOT Y) then BCP for providing IPv4 service to = IPv4-only >>>>> hosts and apps on an IPv6-only access network >>>>>=20 >>>>> The difference between "only X" and "X and not Y" is that there = must >>>>> be a scenario where X and Y both occur. I do not believe that is = the >>>>> case that X and Y will occur together so there is no need to >>>>> complicated the document with this. And, your meaning, which i >>>>> believe is to say that tunneling is better than translation, is >>>>> already documented in the IETF (RFC 4213, others?) >>>>>=20 >>>>> As i said before, it seems like the aim is to create a pecking = order >>>>> of transition solutions. If you want to do that, that is the = scope of >>>>> a different draft. >>>>>=20 >>>>>=20 >>>>> CB >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 From Niall.oReilly@ucd.ie Mon Aug 13 02:43:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE921F8722 for ; Mon, 13 Aug 2012 02:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eMaJrRutDnA for ; Mon, 13 Aug 2012 02:43:54 -0700 (PDT) Received: from mx4.ucd.ie (mx4.ucd.ie [137.43.231.112]) by ietfa.amsl.com (Postfix) with ESMTP id A492A21F8717 for ; Mon, 13 Aug 2012 02:43:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,759,1336345200"; d="scan'208";a="22823678" Received: from dhcp-c101a88b.ucd.ie ([193.1.168.139]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 13 Aug 2012 10:43:53 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <5028270F.3060204@bogus.com> Date: Mon, 13 Aug 2012 10:43:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5028270F.3060204@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , V6ops Chairs , "ops-ads@tools.ietf.org" Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:43:54 -0000 On 12 Aug 2012, at 22:58, joel jaeggli wrote: > The plan as it stands know is to attempt to time the meeting to = accommodate remote participants in North American I have requested that = it start at 1600cest. that said there are still a lot of details to be = worked out. and and time one a Saturday is going to be an inconvenience = to some (sorry) who might otherwise make it in the flesh or online. It may be worth noting that RIPE meetings usually finish before lunch on the Friday. Would 16:00 CEST on Friday 28 September be=20= worth considering instead of 24 hours later? 0,02 Niall From phdgang@gmail.com Mon Aug 13 03:31:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508BC21F86DE for ; Mon, 13 Aug 2012 03:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAskymMeTUHt for ; Mon, 13 Aug 2012 03:31:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89D6721F85F7 for ; Mon, 13 Aug 2012 03:31:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3612694vbb.31 for ; Mon, 13 Aug 2012 03:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NZRi+85gJNs0y7z2/4AHvdwEpPUVPh5uAExoV2NfXKs=; b=coLtO5MnPTiIV8cPqlppRCa/T7CZPSwMLl2dYXtsCggfQflWVK9b9melzIcIZ38gBU riP6cowKv7qhrMg88WKFNM8Qlzxmik3q2zpAtK7WpGv2efokzF+St7MIUFy5dvJ2Sz+i JzvEWU1ngS0HOV8OxXpD0V+N8x+PUHsReaX9BDifSiAxDn6s75u6LV+PsdemrF3O80Tc cCLylHrYEYsgmMZfKmKJYUdpM+3W2kHvmra11SlQ0zdejFxVyLn5kW3Is6x1B1k3r0jG JOzwNH+QAOsHUuW4iWmfD+G2wdhmmyNG9zPqDnQSDlcFxAmEj9/b5e0OPrcMQwKUqsVV M9Rw== MIME-Version: 1.0 Received: by 10.58.102.83 with SMTP id fm19mr9127830veb.24.1344853895876; Mon, 13 Aug 2012 03:31:35 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Mon, 13 Aug 2012 03:31:35 -0700 (PDT) In-Reply-To: <32B857FD-016B-435E-B83D-3BF603BDEEB3@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> <32B857FD-016B-435E-B83D-3BF603BDEEB3@laposte.net> Date: Mon, 13 Aug 2012 18:31:35 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 10:31:39 -0000 2012/8/13, R=E9mi Despr=E9s : > > Le 2012-08-13 =E0 10:39, GangChen a =E9crit : > >> 2012/8/13, R=E9mi Despr=E9s : >>> >>> Le 2012-08-11 =E0 17:59, GangChen a =E9crit : >>> >>>> 2012/8/11, R=E9mi Despr=E9s : >>>>> Cameron, >>>>> >>>>> Since the point made doesn't seem clear enough, here is another try. >>>>> >>> >>> (*) >>>>> - 464XLAT as best practice where providers offer NAT64 as their ONLY >>>>> IPv4 >>>>> support across their access networks: agreed. >>>>> - 464XLAT declared best practice independently of OTHER IPv4 support >>>>> providers may offer across their access networks, in addition to >>>>> NAT64-CGN: >>>>> disagreed. >>>>> >>>>> If a rough consensus is nevertheless declared that ignores this, >>>>> whatever >>>>> the reasons, I want to be clearly out of it. >>> >>> >>> >>>>> Your key argument below is that no provider would realistically >>>>> support >>>>> both >>>>> 464-CGN and DS-Lite, but this isn't right AFAIK. >>> >>> (**) >>>>> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" >>>>> [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGN= s >>>>> across IPv6-only access networks such that "communications between >>>>> end-nodes >>>>> stay within their address family" [RFC6333]. Satisfying both needs >>>>> does >>>>> make >>>>> sense. >>> >>> >>>> The communication model is similar but incentive is different I guess. >>>> DS-Lite is built on the dual-stack model. The target is to guarantee >>>> communication experiences within same address family across different >>>> family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 >>>> service. RFC6180 made really clear statements for each model (see >>>> section 4.3 and 4.4), I guess we don't need to argue that here. So, >>>> why not use it to get rid of confusions. >>>> >>>> Item 1 could be clearer as >>>> >>>> 1. There is an IPv6-only Deployment [RFC6180] that uses stateful >>>> translation [RFC6146] >>> >>> The point is that an IPv6-only deployment with both a NAT-64-CGN and a >>> DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable >>> deployment (see (**) above). It is inappropriate, in this case, to >>> write >>> that using NAT64 is necessarily best. >>> - This point isn't covered by words you propose. >> >> Hope you may consider it again. >> >> My point here is >> - The reference of RFC6180 gives audients a very clear context, in >> which NAT64 is the major transition solution (That was already >> documented section 4.4 in RFC6180; OTOH, DS-lite was described in >> section 4.3. Very explicit: two different cases here) >> =3D>I guess that covers your needs >> >> - IPv6-only deployment in RFC6180 perfectly matches 464xlat target >> scenarios. This would not complicate the document with additional >> scenario justification, but help the clarification. >> =3D>I guess that covers author needs >> >> So why not adopt RFC6180? > > "IPv6-only deployment" as defined in RFC6180 shouldn't be taken IMHO as a > clarifying term for 464XLAT because section 4.4 of this RFC is particula= rly > hard to decode. IMHO, RFC6180 is well documented. But I would like to hear other opinions. >It can be understood that, in one of its IPv6-only domains, > all applications are IPv6-only, so that 464XLAT support of IPv4-only > applications is out of scope. No. The last paragraph of RFC6180 section 4.4 explicitly described the challenge how to support "IPv4 referrals", which makes application is IPv6-incapable. Especially, linking to [IPv6-only-experience] even highlights the significance. 464XLAT is indeed in the scope. > >>> - I can't see what would be wrong (besides NIH) in something like: >>> "1. There is an IPv6-only access network that uses stateful translation >>> [RFC6146] as its sole transition solution for IPv4 via IPv6." >>> =3D> (*) above is confirmed. >> >> The logic seems to me you are using one technology to pick BCP. I >> guess we are discussing the scenario picking BCP > > Not understood. The section 2 supposed to make applicability statement to the scenario which gives operational guidance. The scenario to me is a term independent with a particular technology, like RFC6180 documented "Native Dual Stack", "IPv6-Only Core Network", "IPv6-Only Deployment" and etc. Those terms is well understood in the operational context. Adding second half of texts give an impression we do 464xlat because of one particular technology. The sense of operational guidance is somehow weakening imho. But I'm open to hear other opinions as well. BRs Gang > RD > > >> >> BRs >> >> Gang >> >>> Regards, >>> RD >>> >>> >>> >>>> >>>> >>>> >>>>> You object to what you see as a pecking order if, for example, 464XLA= T >>>>> is >>>>> said to be "the best way of running IPv4 over IPv6 in networks that >>>>> cannot >>>>> support encapsulation". But the word "best" in "BCP" is per se >>>>> expressing >>>>> some order. Current text implicitly asserts that using 464XLAT IS >>>>> better >>>>> than using DS-Lite where both are available. This isn't acceptable >>>>> AFAIAC. >>>>> Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, >>>>> explicitly or implicitly, which one is best practice where 464XLAT >>>>> coexists >>>>> with DS-Lite: it can be left unspecified. >>>>> >>>>> FWIW, >>>>> RD >>>>> >>>>> >>>>> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : >>>>> >>>>>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : >>>>>>> >>>>>>> >>>>>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" >>>>>>> wrote: >>>>>>>> >>>>>>>> Did we already conclude that this is a BCP and not Informational? >>>>>>>> We >>>>>>>> should just put it in the latter category and move on/progress. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, afaik, the chairs have accepted bcp status and have accepted >>>>>>> the >>>>>>> bcp >>>>>>> scenario text. >>>>>>> >>>>>>> The chairs also direct the WG to move on to any remainig technical >>>>>>> issuess. >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html >>>>>>> >>>>>>> >>>>>>> After that, Lorenzo proposed an approach, which I approved, to >>>>>>> resolve >>>>>>> the >>>>>>> last issue I had raised. >>>>>>> If the chairs also agree, all is AFAIK OK for the draft to proceed >>>>>>> without >>>>>>> objection as BCP. >>>>>>> Regards,` >>>>>>> RD >>>>>>> >>>>>> >>>>>> R=E9mi, >>>>>> >>>>>> It sounds like you are deferring to the chairs. >>>>>> >>>>>> I too will defer to the chairs, since my focus is moving forward. >>>>>> >>>>>> The chairs have already made their position known, and they may >>>>>> re-open this issue. >>>>>> >>>>>> You and Lorenzo have supplied input to the chairs. >>>>>> >>>>>> My input to the chairs is that there should be no changes required o= f >>>>>> the current text. In very basic logical terms the text currently >>>>>> says >>>>>> >>>>>> X =3D RFC 6146 >>>>>> >>>>>> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only >>>>>> hosts and apps on an IPv6-only access network. >>>>>> >>>>>> Your original proposal and more or less Lorenzo's proposal >>>>>> >>>>>> Y =3D DS-lite >>>>>> >>>>>> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only >>>>>> hosts and apps on an IPv6-only access network >>>>>> >>>>>> The difference between "only X" and "X and not Y" is that there must >>>>>> be a scenario where X and Y both occur. I do not believe that is >>>>>> the >>>>>> case that X and Y will occur together so there is no need to >>>>>> complicated the document with this. And, your meaning, which i >>>>>> believe is to say that tunneling is better than translation, is >>>>>> already documented in the IETF (RFC 4213, others?) >>>>>> >>>>>> As i said before, it seems like the aim is to create a pecking order >>>>>> of transition solutions. If you want to do that, that is the scope >>>>>> of >>>>>> a different draft. >>>>>> >>>>>> >>>>>> CB >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>> > From rajiva@cisco.com Mon Aug 13 05:42:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB421F870E for ; Mon, 13 Aug 2012 05:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSFCz+ZZZ1HC for ; Mon, 13 Aug 2012 05:42:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B028721F870A for ; Mon, 13 Aug 2012 05:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4222; q=dns/txt; s=iport; t=1344861746; x=1346071346; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4DPnsF1R8Bu3QHfpxFI/RDw4lQCbPoQ1omdzWrd4mEI=; b=DYlm/FfEMKUAb41aXDU5lpSIVEVZjNRmQxubrHkmB+MjI9Wkr4KCDlCg ypGGsl78N0SOprwPucf6mOhUOhPwqy2gdKcfxsqnClzirBwWgzSUIycDS u74R9d4K4cBnLbhvEGwPd7TkYGsGORf5YgDvBGNpK9mMT2zAlh4PniiLj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANX1KFCtJXG//2dsb2JhbABFugSBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBECAgEBAQoUBQQHIQYLFAkIAgQBDQUIGodcAwYGC5dflhwNiU6KLGaFUWADk3gDgmSJdoMggWaCXw X-IronPort-AV: E=Sophos;i="4.77,759,1336348800"; d="scan'208";a="110985137" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2012 12:42:26 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7DCgQaE012164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 12:42:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 07:42:25 -0500 From: "Rajiv Asati (rajiva)" To: Philip Matthews , Mark ZZZ Smith Thread-Topic: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines Thread-Index: AQHNdnd2JQ+QwBCNH0aENwRIzVj0+pdSWwmAgAU8TpA= Date: Mon, 13 Aug 2012 12:42:25 +0000 Message-ID: References: <501AB97A.7060202@gmail.com> <33FE6FAB-E7D8-4CA7-8C94-933D1BA1DE2F@magma.ca> <501AEB86.5080808@gmail.com> <20120803135243.GU38127@Space.Net> <20120806191534.GY38127@Space.Net> <5D908C2E-DC1D-4268-83ED-E9F23A51514F@magma.ca> <1344507004.18219.YahooMailNeo@web32504.mail.mud.yahoo.com> <50239553.3010206@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4E5159@xmb-rcd-x14.cisco.com> <1344548354.85419.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.004 x-tm-as-result: No--47.154800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org list" , "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self-configuration of addresses, draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 12:42:27 -0000 > there is no GUA/ULA configured on the interface, then the router sends th= e > ICMP reply using the IP address of the loopback or system address as the > source address.=20 Stating the obvious assumption - Loopback interface is configured with GUA/= ULA. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Philip Matthews > Sent: Thursday, August 09, 2012 5:58 PM > To: Mark ZZZ Smith > Cc: v6ops@ietf.org list; Michael Behringer (mbehring) > Subject: Re: [v6ops] about LLAs pros/cons static routing - auto/self- > configuration of addresses, draft-matthews-v6ops-design-guidelines >=20 >=20 > On 2012-08-09, at 17:39 , Mark ZZZ Smith wrote: >=20 > > Hi Michael, > > > > > > ----- Original Message ----- > >> From: Michael Behringer (mbehring) > >> To: Brian E Carpenter ; Mark ZZZ Smith > >> > >> Cc: Philip Matthews ; Gert Doering > >> ; "sthaug@nethelp.no" ; Eric > >> Vyncke (evyncke) ; "v6ops@ietf.org list" > >> > >> Sent: Thursday, 9 August 2012 9:08 PM > >> Subject: RE: [v6ops] about LLAs pros/cons static routing - > >> auto/self-configuration of addresses, > >> draft-matthews-v6ops-design-guidelines > >> > >>>> Traceroute would work for you, > >>> > >>> It shouldn't, because intermediate routers should discard ICMPv6 > >> packets > >>> with LL source addresses, according to RFC 4291 section 2.5.6. > >>> > >>> The fact that they don't is an implementation error, and we > >> shouldn't rely > >>> on that. ICMPv6 should never be sourced from a LL address. > >> > >> I can confirm that at least one implementation (ours) responds using > >> a global address (from a loopback), not the link local. > >> > >>> > >>> Brian > >>> > >>> however outside of your network, other people would be querying > >>> their own version of 0.8.e.f.ip6.arpa., hiding your interface and rou= ter > names. > >>> This idea might be useful to assist with troubleshooting for a > >>> "Using > >> Only > >>> Link-Local Addressing Inside an > >>> IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01 > >>> scenario. > >> > >> The concern is that for ICMP echo reply, traceroute, etc the router > >> will respond with a global address, which is a loopback address (in > >> the absence of global addresses on the interface). You can therefore > >> see the router, but not the interface (unless RFC5837 is implemented, > >> which is generally not the case today). > >> > >> So I can't see how this helps troubleshooting? (I must be > >> misunderstanding something here) > > > > As Brian said, traceroute won't reliably work due to the LL source addr= ess > issue, however having unique static LL addresses across your network's > router interfaces, and then having a record of the static LL address > assignments in 0.8.e.f.ip6.arpa via PTRs (and perhaps TXTs for > supplementary information) might still be a useful troubleshooting tool. = For > example, if you're on the CLI of one router, and want to find out the > interface name corresponding to an adjacent router's static LL address, a > ping command with a reverse resolve of the address far router's interface > address would return the result of the PTR and therefore the name of the > remote interface and router. >=20 > I believe traceroute will work. As Michael said, at least some routers, = if > there is no GUA/ULA configured on the interface, then the router sends th= e > ICMP reply using the IP address of the loopback or system address as the > source address. Michael confirmed that Cisco routers work this way, and I > can confirm that Alcatel-Lucent routers work this way. >=20 > If anyone knows of a router which behaves differently, I would be > interested in hearing of it. This would be a useful comment to put in my = I-D. >=20 > - Philip >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From iesg-secretary@ietf.org Mon Aug 13 07:49:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C608321F8773; Mon, 13 Aug 2012 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3QGoOKgqF+g; Mon, 13 Aug 2012 07:49:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B39D21F85A5; Mon, 13 Aug 2012 07:49:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120813144910.23720.48772.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 07:49:10 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Wireline Incremental IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:49:11 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Wireline Incremental IPv6' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ballot/ No IPR declarations have been submitted directly on this I-D. From joelja@bogus.com Mon Aug 13 08:09:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB621F8751 for ; Mon, 13 Aug 2012 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UeXMudI78JF for ; Mon, 13 Aug 2012 08:09:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8802B21F8731 for ; Mon, 13 Aug 2012 08:09:18 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7DF9EF5013192 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 13 Aug 2012 15:09:14 GMT (envelope-from joelja@bogus.com) Message-ID: <50291894.2000806@bogus.com> Date: Mon, 13 Aug 2012 08:09:08 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: GangChen References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 13 Aug 2012 15:09:15 +0000 (UTC) Cc: V6ops Chairs , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 15:09:19 -0000 On 8/13/12 1:39 AM, GangChen wrote: > 2012/8/13, Rémi Després : >> Le 2012-08-11 à 17:59, GangChen a écrit : >> >>> 2012/8/11, Rémi Després : >>>> Cameron, >>>> >>>> Since the point made doesn't seem clear enough, here is another try. >>>> >> (*) >>>> - 464XLAT as best practice where providers offer NAT64 as their ONLY >>>> IPv4 >>>> support across their access networks: agreed. >>>> - 464XLAT declared best practice independently of OTHER IPv4 support >>>> providers may offer across their access networks, in addition to >>>> NAT64-CGN: >>>> disagreed. >>>> >>>> If a rough consensus is nevertheless declared that ignores this, >>>> whatever >>>> the reasons, I want to be clearly out of it. >> >> >>>> Your key argument below is that no provider would realistically support >>>> both >>>> 464-CGN and DS-Lite, but this isn't right AFAIK. >> (**) >>>> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" >>>> [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs >>>> across IPv6-only access networks such that "communications between >>>> end-nodes >>>> stay within their address family" [RFC6333]. Satisfying both needs does >>>> make >>>> sense. >> >>> The communication model is similar but incentive is different I guess. >>> DS-Lite is built on the dual-stack model. The target is to guarantee >>> communication experiences within same address family across different >>> family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 >>> service. RFC6180 made really clear statements for each model (see >>> section 4.3 and 4.4), I guess we don't need to argue that here. So, >>> why not use it to get rid of confusions. >>> >>> Item 1 could be clearer as >>> >>> 1. There is an IPv6-only Deployment [RFC6180] that uses stateful >>> translation [RFC6146] >> If you eliminate having an ipv4 stack present or active as I think Bjoern noted at the mic, I'm pretty sure encapsulation ceases to be feasible path. ds-lite for all it's benefits doesn't allow for that. While I am happy to stipulate that ds-lite provides the potential for a better experience, if v6only is your goal from the host vantage-point it's a non-starter. From evyncke@cisco.com Mon Aug 13 09:11:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E321F86E1; Mon, 13 Aug 2012 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYwPhQv0FD7u; Mon, 13 Aug 2012 09:11:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3221821F86DC; Mon, 13 Aug 2012 09:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=8872; q=dns/txt; s=iport; t=1344874292; x=1346083892; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tWEaruPxZ5ZCWJr5u3bHIbrvi3Kqea38zCs5Mhu6tU4=; b=k96qV502cPWP30jl0IXJPmx41tLLXNCmfrATAYY9l/gaM8vP2f+TA3rE Jv+OcdEdwHWNUKp/PsohPe3xiLDzl92uiorbwxO00wBTBrTUwiYMHhs6d NNrd6StYAGDr3OH2Dq9L0RnBe9wk5+VpB9i8Ji5uzyqS1SPrImxY6pDTU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPQmKVCtJV2Z/2dsb2JhbAA7CoJKtzuBB4IgAQEBBBIBGlwCAQgRBAEBCx0HMhQJCAEBBAESCAwOh2uYJKAoixIQhUFgA4gZm1yBZoJf X-IronPort-AV: E=Sophos;i="4.77,761,1336348800"; d="scan'208,217";a="111063676" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 13 Aug 2012 16:11:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7DGBTbQ021398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 16:11:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 11:11:28 -0500 From: "Eric Vyncke (evyncke)" To: "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" , "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71ApgFv8/bw Date: Mon, 13 Aug 2012 16:11:28 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.006 x-tm-as-result: No--37.783500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E10C2DE3xmbalnx02ciscocom_" MIME-Version: 1.0 Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:11:33 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E10C2DE3xmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Count me in From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: lundi 6 ao=FBt 2012 10:43 To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implica= tions-on-ipv4-nets Dear all, Can I request the WG members for 3 volunteers to read the draft draft-gont-= opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list? This will help the OPSEC chairs to identify if the work is ready for WG ado= ption or not. The work targets are within charter of the WG, and seems to b= e interesting work for the community. Questions we are looking answers for: 1) Should it be targeted BCP or Informational? 2) Is the work quality ok to be accepted as WG document? 3) Is the topic inline with the OPSEC charter? 4) Any missing or over-described points? Many thanks in advance, Kind Regards, OPSEC Chairs, (G/, KK, Warren) --_000_97EB7536A2B2C549846804BBF3FD47E10C2DE3xmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Count me in

 

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org= ] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: lundi 6 ao=FBt 2012 10:43
To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org)
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-= implications-on-ipv4-nets

 

Dear all,

 

Can I request the WG members fo= r 3 volunteers to read the draft draft-gont-opsec-ipv6-implications-on-ipv4= -nets and provide feedback to the list?

 

This will help the OPSEC chairs= to identify if the work is ready for WG adoption or not. The work targets = are within charter of the WG, and seems to be interesting work for the comm= unity.

 

Questions we are looking answer= s for:

 

1) &nbs= p;    Should it be targeted B= CP or Informational?

2) &nbs= p;    Is the work quality ok = to be accepted as WG document?

3) &nbs= p;    Is the topic inline wit= h the OPSEC charter?

4) &nbs= p;    Any missing or over-des= cribed points?

 

Many thanks in advance,

 

Kind Regards,=

OPSEC Chairs,=

(G/, KK, Warren)

--_000_97EB7536A2B2C549846804BBF3FD47E10C2DE3xmbalnx02ciscocom_-- From fgont@si6networks.com Mon Aug 13 12:58:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D355C21F8629; Mon, 13 Aug 2012 12:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYLklb+9a4wb; Mon, 13 Aug 2012 12:58:39 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFFF21F8627; Mon, 13 Aug 2012 12:58:39 -0700 (PDT) Received: from [190.245.182.195] (helo=[192.168.1.128]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T10mY-0001u5-RI; Mon, 13 Aug 2012 21:58:35 +0200 Message-ID: <50295C33.7070606@si6networks.com> Date: Mon, 13 Aug 2012 16:57:39 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 19:58:39 -0000 On 08/13/2012 01:11 PM, Eric Vyncke (evyncke) wrote: > Count me in Great! -- Thanks so much for volunteering.. I look forward to your feedback! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Donald.Smith@CenturyLink.com Mon Aug 13 13:57:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892FB21F866B; Mon, 13 Aug 2012 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iufhXqAtWTFU; Mon, 13 Aug 2012 13:57:43 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9221F865F; Mon, 13 Aug 2012 13:57:42 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q7DKvfBP003236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 15:57:41 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 28F621E0053; Mon, 13 Aug 2012 15:57:36 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id EC9C21E0086; Mon, 13 Aug 2012 15:57:35 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q7DKvZLl015559; Mon, 13 Aug 2012 14:57:35 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q7DKvZg9015556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 14:57:35 -0600 (MDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Mon, 13 Aug 2012 14:57:35 -0600 From: "Smith, Donald" To: Fernando Gont , "Eric Vyncke (evyncke)" Thread-Topic: [OPSEC] [v6ops] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: AQHNeY4L0zidHynrsUS/d4UYUcJKBJdYNfPC Date: Mon, 13 Aug 2012 20:57:34 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0832E8D2@PDDCWMBXEX501.ctl.intranet> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com>, <50295C33.7070606@si6networks.com> In-Reply-To: <50295C33.7070606@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 20:57:43 -0000 In 3.1 Grammer nit this: As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 that contain their Protocol field set to 41. This is the most effective way of filtering such traffic. Should be this: As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 that has the Protocol field set to 41. This is the most effective way of filtering such traffic. in 3.1 you state: Filter incoming IPv4 packets that have their Source Address set to an address that belongs to the prefix 192.88.99.0/24. It has been suggested that 6to4 relays send their packets with their IPv4 Source Address set to 192.88.99.1. So should the blocking recommendation be 192.88.99.0/24 or the .1/32? Other than that this looks pretty good. Thanks. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Fernando= Gont [fgont@si6networks.com] Sent: Monday, August 13, 2012 1:57 PM To: Eric Vyncke (evyncke) Cc: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] [v6ops] 3 Volunteers wanted - Draft: draft-gont-= opsec-ipv6-implications-on-ipv4-nets On 08/13/2012 01:11 PM, Eric Vyncke (evyncke) wrote: > Count me in Great! -- Thanks so much for volunteering.. I look forward to your feedback! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From randy@psg.com Mon Aug 13 14:23:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09A21F8686 for ; Mon, 13 Aug 2012 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPLiNxloC9ER for ; Mon, 13 Aug 2012 14:23:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 260F621F8650 for ; Mon, 13 Aug 2012 14:23:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T126l-000GWy-Ij; Mon, 13 Aug 2012 21:23:31 +0000 Date: Tue, 14 Aug 2012 06:23:48 +0900 Message-ID: From: Randy Bush To: Niall O'Reilly In-Reply-To: References: <5028270F.3060204@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , ops-ads@tools.ietf.org Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:23:41 -0000 Joel: >> The plan as it stands know is to attempt to time the meeting to >> accommodate remote participants in North American I have requested >> that it start at 1600cest. that said there are still a lot of details >> to be worked out. and and time one a Saturday is going to be an >> inconvenience to some (sorry) who might otherwise make it in the >> flesh or online. Niall: > It may be worth noting that RIPE meetings usually finish before > lunch on the Friday. Would 16:00 CEST on Friday 28 September be > worth considering instead of 24 hours later? this 16:00 cest stuff is nonsense. think of what it does to the asia pacific. when we meet in north america, we meet at times convenient to north america. when in ... need i go on? the world is round and the internet is not an american property. we need to get over it. when on vega, be vague. randy, in tokyo From fgont@si6networks.com Mon Aug 13 15:01:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27A521F8697; Mon, 13 Aug 2012 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGiPT1qIwqkW; Mon, 13 Aug 2012 15:01:32 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 277E721F8694; Mon, 13 Aug 2012 15:01:32 -0700 (PDT) Received: from [190.245.182.195] (helo=[192.168.1.128]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T12hR-0006Fm-9y; Tue, 14 Aug 2012 00:01:26 +0200 Message-ID: <502978FB.2070303@si6networks.com> Date: Mon, 13 Aug 2012 19:00:27 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Smith, Donald" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com>, <50295C33.7070606@si6networks.com> <68EFACB32CF4464298EA2779B058889D0832E8D2@PDDCWMBXEX501.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0832E8D2@PDDCWMBXEX501.ctl.intranet> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:01:32 -0000 Hi, Donald, Thanks so much for your feedback! -- Please find my comments in-line.... On 08/13/2012 05:57 PM, Smith, Donald wrote: > In 3.1 Grammer nit this: > As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, > could be easily blocked by filtering IPv4 that contain their Protocol > field set to 41. This is the most effective way of filtering such > traffic. > Should be this: > As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, > could be easily blocked by filtering IPv4 that has the Protocol > field set to 41. This is the most effective way of filtering such > traffic. How about: As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 packets that have their Protocol field set to 41. This is the most effective way of filtering such traffic. ? :-) > in 3.1 you state: > Filter incoming IPv4 packets that have their Source Address set to > an address that belongs to the prefix 192.88.99.0/24. > It has been suggested that 6to4 relays send their packets with > their IPv4 Source Address set to 192.88.99.1. > > So should the blocking recommendation be 192.88.99.0/24 or the .1/32? Well, at least in theory, any of such addresses could be used for the same purpose -- one could do the experiment of using, say, 192.168.99.40 and see if 6to4 still works. That said, and in retrospective, I think that the filtering rules that consider the Src/Dst Addr should be collapsed with those mentioned as "Apply these rules if you want to filter 6to4 while still allowing other ip-proto 41 tunnels" (specified later in the same section). After all, if you don't have the requirement of filtering 6to4 while allowing other ip-proto 41 tunnels, you'd simply filter 6to4 based on the ip-proto value, without even examining the IPv4 Src/Dst addresses. Thoughts? > Other than that this looks pretty good. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Donald.Smith@CenturyLink.com Mon Aug 13 15:17:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668AB21F8697; Mon, 13 Aug 2012 15:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYwo6TYuC42Z; Mon, 13 Aug 2012 15:17:04 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAE021F8698; Mon, 13 Aug 2012 15:17:04 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q7DMH1RL024435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 16:17:02 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D08DB1E0058; Mon, 13 Aug 2012 16:16:56 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B35651E0055; Mon, 13 Aug 2012 16:16:56 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q7DMGu4J006080; Mon, 13 Aug 2012 16:16:56 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q7DMGuFX006074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 16:16:56 -0600 (MDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Mon, 13 Aug 2012 16:16:56 -0600 From: "Smith, Donald" To: Fernando Gont Thread-Topic: [OPSEC] [v6ops] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: AQHNeZ8zMd6inTyoKkejV+ZW0oHQ3JdYTImK Date: Mon, 13 Aug 2012 22:16:54 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0832E9C9@PDDCWMBXEX501.ctl.intranet> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com>, <50295C33.7070606@si6networks.com> <68EFACB32CF4464298EA2779B058889D0832E8D2@PDDCWMBXEX501.ctl.intranet>, <502978FB.2070303@si6networks.com> In-Reply-To: <502978FB.2070303@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:17:05 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________________ From: Fernando Gont [fgont@si6networks.com] Sent: Monday, August 13, 2012 4:00 PM To: Smith, Donald Cc: Eric Vyncke (evyncke); opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] [v6ops] 3 Volunteers wanted - Draft: draft-gont-opsec-= ipv6-implications-on-ipv4-nets >Hi, Donald, >Thanks so much for your feedback! -- Please find my comments in-line.... >On 08/13/2012 05:57 PM, Smith, Donald wrote: >> In 3.1 Grammer nit this: >> As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, >> could be easily blocked by filtering IPv4 that contain their Protocol >> field set to 41. This is the most effective way of filtering such >> traffic. >> Should be this: >> As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, >> could be easily blocked by filtering IPv4 that has the Protocol >> field set to 41. This is the most effective way of filtering such >> >How about: > > As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, > could be easily blocked by filtering IPv4 packets that have their > Protocol field set to 41. This is the most effective way of > filtering such traffic. >? :-) Actually you use this in the 6to4 discussion. 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41. That seems better as "their" is seen as possive in english and tends to "hu= manize" things not human :) >> in 3.1 you state: >> Filter incoming IPv4 packets that have their Source Address set to >> an address that belongs to the prefix 192.88.99.0/24. >> It has been suggested that 6to4 relays send their packets with >> their IPv4 Source Address set to 192.88.99.1. >> >> So should the blocking recommendation be 192.88.99.0/24 or the .1/32? >Well, at least in theory, any of such addresses could be used for the >same purpose -- one could do the experiment of using, say, 192.168.99.40 >and see if 6to4 still works. >That said, and in retrospective, I think that the filtering rules that >consider the Src/Dst Addr should be collapsed with those mentioned as >"Apply these rules if you want to filter 6to4 while still allowing other >ip-proto 41 tunnels" (specified later in the same section). After all, >if you don't have the requirement of filtering 6to4 while allowing other >ip-proto 41 tunnels, you'd simply filter 6to4 based on the ip-proto >value, without even examining the IPv4 Src/Dst addresses. >Thoughts? I saw the other comments and this makes sense. I can revisit it once you ha= ve that done. It is certainly easier to block based on the protocol field in most systems= . > Other than that this looks pretty good. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492= From fgont@si6networks.com Mon Aug 13 15:24:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F921F86F6; Mon, 13 Aug 2012 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5In9nYyNBiR; Mon, 13 Aug 2012 15:24:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D210221F86F2; Mon, 13 Aug 2012 15:24:58 -0700 (PDT) Received: from [190.245.182.195] (helo=[192.168.1.128]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T1347-0007qv-2X; Tue, 14 Aug 2012 00:24:53 +0200 Message-ID: <50297E71.7070109@si6networks.com> Date: Mon, 13 Aug 2012 19:23:45 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Smith, Donald" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C2DE3@xmb-aln-x02.cisco.com>, <50295C33.7070606@si6networks.com> <68EFACB32CF4464298EA2779B058889D0832E8D2@PDDCWMBXEX501.ctl.intranet>, <502978FB.2070303@si6networks.com> <68EFACB32CF4464298EA2779B058889D0832E9C9@PDDCWMBXEX501.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0832E9C9@PDDCWMBXEX501.ctl.intranet> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:24:59 -0000 On 08/13/2012 07:16 PM, Smith, Donald wrote: [....] >>> Should be this: >>> As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, >>> could be easily blocked by filtering IPv4 that has the Protocol >>> field set to 41. This is the most effective way of filtering such >>> >> How about: >> >> As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, >> could be easily blocked by filtering IPv4 packets that have their >> Protocol field set to 41. This is the most effective way of >> filtering such traffic. > >> ? :-) > > Actually you use this in the 6to4 discussion. > 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol > field of 41. > > That seems better as "their" is seen as possive in english and tends to "humanize" things not human :) Oh, sorry... I missed that one -- must admit that I should now go back to study a bit of English grammar, since I use this kind of "construction" a lot... Will fix this. :-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Mon Aug 13 15:50:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E694621F8634 for ; Mon, 13 Aug 2012 15:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwiBgYNlYMFq for ; Mon, 13 Aug 2012 15:50:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8B21F8606 for ; Mon, 13 Aug 2012 15:50:12 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7DMoAEU005553 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 13 Aug 2012 22:50:11 GMT (envelope-from joelja@bogus.com) Message-ID: <5029849D.3010304@bogus.com> Date: Mon, 13 Aug 2012 15:50:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Randy Bush References: <5028270F.3060204@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 13 Aug 2012 22:50:11 +0000 (UTC) Cc: ops-ads@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:50:13 -0000 On 8/13/12 2:23 PM, Randy Bush wrote: > Joel: >>> The plan as it stands know is to attempt to time the meeting to >>> accommodate remote participants in North American I have requested >>> that it start at 1600cest. that said there are still a lot of details >>> to be worked out. and and time one a Saturday is going to be an >>> inconvenience to some (sorry) who might otherwise make it in the >>> flesh or online. > Niall: >> It may be worth noting that RIPE meetings usually finish before >> lunch on the Friday. Would 16:00 CEST on Friday 28 September be >> worth considering instead of 24 hours later? > this 16:00 cest stuff is nonsense. think of what it does to the asia > pacific. > > when we meet in north america, we meet at times convenient to north > america. when in ... need i go on? the world is round and the > internet is not an american property. we need to get over it. If it's a dumb idea I get to shoulder a big portion of the blame for that. I take it you do not believe that this attempt at optimization is a worthwhile one. I disagree, but not strongly. Given the opportunity to pick a time that extends the window available for convenient remote participation with the goal of maximizing the opportunity for remote participation, what would you pick? If I had two or more of these to program or they were entirely virtual interims, I would probably rotate the times such that the inconvenience were shared, as it stands right now we have one. > when on vega, be vague. > > randy, in tokyo > From randy@psg.com Mon Aug 13 16:06:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8F21F8602 for ; Mon, 13 Aug 2012 16:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iart6xzV9Hsx for ; Mon, 13 Aug 2012 16:06:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F223B21F8600 for ; Mon, 13 Aug 2012 16:06:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T13iA-000GhR-2H; Mon, 13 Aug 2012 23:06:14 +0000 Date: Tue, 14 Aug 2012 08:06:30 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <5029849D.3010304@bogus.com> References: <5028270F.3060204@bogus.com> <5029849D.3010304@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ops-ads@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 23:06:17 -0000 > If it's a dumb idea I get to shoulder a big portion of the blame for > that. do i get a refund? > I take it you do not believe that this attempt at optimization is > a worthwhile one. optimization of what? us-centricism? > Given the opportunity to pick a time that extends the window available > for convenient remote participation with the goal of maximizing the > opportunity for remote participation i do not even understand that > what would you pick? 08:30 or 09:00 to 17:00ish local time on the 29th. randy From cb.list6@gmail.com Mon Aug 13 20:32:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8721F8674 for ; Mon, 13 Aug 2012 20:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tLDfaKQkd7V for ; Mon, 13 Aug 2012 20:32:54 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92DA121F8646 for ; Mon, 13 Aug 2012 20:32:53 -0700 (PDT) Received: by lahm15 with SMTP id m15so2493484lah.31 for ; Mon, 13 Aug 2012 20:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJcdEhLwvb+I0Ihj/QpJOByJSvVmpJKBU+S/cTcA6AM=; b=NW/ky4EfxrGsd7KViilu7gY8Gi+HVQBRqOemuZgUzz5HOClP50Elzq64m4AjwXee3B hxlbfz//whJ7LpnWHIf8BTi2twRo3beULSpxAoq0qhvgw4/NbT3Je1WO1BbOuJLiWG9G 1+2XVluBQvyzloENzwnyVulupybAlOHskqcZeBo6Ofv5jPU+iILmDluAsvWkfS1VytWE LYS3+G/Amyu7uElQH037UGbuoEOINMeMCbk1CXSRJrGvZhZHVnFxYaVzuG2uqvFhuQaq YDgQoQIJ3EotJN0E0Ug6Pmv86Rs9Qesz2GjMZM+9enOaaSsUgEvnPTaQ+hDUz0YQS0qb +JDg== MIME-Version: 1.0 Received: by 10.112.83.200 with SMTP id s8mr7327949lby.13.1344915172501; Mon, 13 Aug 2012 20:32:52 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Mon, 13 Aug 2012 20:32:52 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Mon, 13 Aug 2012 20:32:52 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> Date: Mon, 13 Aug 2012 20:32:52 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0401fc3f1c2c1b04c73177d2 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 03:32:55 -0000 --f46d0401fc3f1c2c1b04c73177d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 13, 2012 12:41 AM, "R=E9mi Despr=E9s" wro= te: > > > Le 2012-08-11 =E0 17:59, GangChen a =E9crit : > > > 2012/8/11, R=E9mi Despr=E9s : > >> Cameron, > >> > >> Since the point made doesn't seem clear enough, here is another try. > >> > > (*) > >> - 464XLAT as best practice where providers offer NAT64 as their ONLY IPv4 > >> support across their access networks: agreed. > >> - 464XLAT declared best practice independently of OTHER IPv4 support > >> providers may offer across their access networks, in addition to NAT64-CGN: > >> disagreed. > >> > >> If a rough consensus is nevertheless declared that ignores this, whatever > >> the reasons, I want to be clearly out of it. > > > > >> Your key argument below is that no provider would realistically support both > >> 464-CGN and DS-Lite, but this isn't right AFAIK. > > (**) > >> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" > >> [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs > >> across IPv6-only access networks such that "communications between end-nodes > >> stay within their address family" [RFC6333]. Satisfying both needs does make > >> sense. > > > > The communication model is similar but incentive is different I guess. > > DS-Lite is built on the dual-stack model. The target is to guarantee > > communication experiences within same address family across different > > family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4 > > service. RFC6180 made really clear statements for each model (see > > section 4.3 and 4.4), I guess we don't need to argue that here. So, > > why not use it to get rid of confusions. > > > > Item 1 could be clearer as > > > > 1. There is an IPv6-only Deployment [RFC6180] that uses stateful > > translation [RFC6146] > > The point is that an IPv6-only deployment with both a NAT-64-CGN and a DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable deployment (see (**) above). It is inappropriate, in this case, to write that using NAT64 is necessarily best. > - This point isn't covered by words you propose. > - I can't see what would be wrong (besides NIH) in something like: > "1. There is an IPv6-only access network that uses stateful translation [RFC6146] as its sole transition solution for IPv4 via IPv6." > =3D> (*) above is confirmed. > My co-authors and i can accept this. Is this slight wording change ok? 1. There is an IPv6-only access network that uses stateful translation [RFC6146] as the only mechanism for providing ipv4 access. Regards, CB > Regards, > RD > > > > > > > > > > >> You object to what you see as a pecking order if, for example, 464XLAT is > >> said to be "the best way of running IPv4 over IPv6 in networks that cannot > >> support encapsulation". But the word "best" in "BCP" is per se expressing > >> some order. Current text implicitly asserts that using 464XLAT IS better > >> than using DS-Lite where both are available. This isn't acceptable AFAIAC. > >> Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, > >> explicitly or implicitly, which one is best practice where 464XLAT coexists > >> with DS-Lite: it can be left unspecified. > >> > >> FWIW, > >> RD > >> > >> > >> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : > >> > >>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s < despres.remi@laposte.net> > >>> wrote: > >>>> > >>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : > >>>> > >>>> > >>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" > >>>> wrote: > >>>>> > >>>>> Did we already conclude that this is a BCP and not Informational? W= e > >>>>> should just put it in the latter category and move on/progress. > >>>>> > >>>>> > >>>> > >>>> Yes, afaik, the chairs have accepted bcp status and have accepted th= e > >>>> bcp > >>>> scenario text. > >>>> > >>>> The chairs also direct the WG to move on to any remainig technical > >>>> issuess. > >>>> > >>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > >>>> > >>>> > >>>> After that, Lorenzo proposed an approach, which I approved, to resolve > >>>> the > >>>> last issue I had raised. > >>>> If the chairs also agree, all is AFAIK OK for the draft to proceed > >>>> without > >>>> objection as BCP. > >>>> Regards,` > >>>> RD > >>>> > >>> > >>> R=E9mi, > >>> > >>> It sounds like you are deferring to the chairs. > >>> > >>> I too will defer to the chairs, since my focus is moving forward. > >>> > >>> The chairs have already made their position known, and they may > >>> re-open this issue. > >>> > >>> You and Lorenzo have supplied input to the chairs. > >>> > >>> My input to the chairs is that there should be no changes required of > >>> the current text. In very basic logical terms the text currently say= s > >>> > >>> X =3D RFC 6146 > >>> > >>> IF (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only > >>> hosts and apps on an IPv6-only access network. > >>> > >>> Your original proposal and more or less Lorenzo's proposal > >>> > >>> Y =3D DS-lite > >>> > >>> IF (X and NOT Y) then BCP for providing IPv4 service to IPv4-only > >>> hosts and apps on an IPv6-only access network > >>> > >>> The difference between "only X" and "X and not Y" is that there must > >>> be a scenario where X and Y both occur. I do not believe that is th= e > >>> case that X and Y will occur together so there is no need to > >>> complicated the document with this. And, your meaning, which i > >>> believe is to say that tunneling is better than translation, is > >>> already documented in the IETF (RFC 4213, others?) > >>> > >>> As i said before, it seems like the aim is to create a pecking order > >>> of transition solutions. If you want to do that, that is the scope o= f > >>> a different draft. > >>> > >>> > >>> CB > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> --f46d0401fc3f1c2c1b04c73177d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 13, 2012 12:41 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 2012-08-11 =E0 17:59, GangChen a =E9crit :
>
> > 2012/8/11, R=E9mi Despr=E9s <despres.remi@laposte.net>:
> >> Cameron,
> >>
> >> Since the point made doesn't seem clear enough, here is a= nother try.
> >>
>
> (*)
> >> - 464XLAT as best practice where providers offer NAT64 as the= ir ONLY IPv4
> >> support across their access networks: agreed.
> >> - 464XLAT declared best practice independently of OTHER IPv4 = support
> >> providers may offer across their access networks, in addition= to NAT64-CGN:
> >> disagreed.
> >>
> >> If a rough consensus is nevertheless declared that ignores th= is, whatever
> >> the reasons, I want to be clearly out of it.
>
>
>
> >> Your key argument below is that no provider would realistical= ly support both
> >> 464-CGN and DS-Lite, but this isn't right AFAIK.
>
> (**)
> >> NAT64 is a solution for "IPv6-only clients to contact IP= v4 servers"
> >> [RFC6146], and DS-Lite a solution for IPv4 clients to reach N= AT44-CGNs
> >> across IPv6-only access networks such that "communicatio= ns between end-nodes
> >> stay within their address family" [RFC6333]. Satisfying = both needs does make
> >> sense.
>
>
> > The communication model is similar but incentive is different I g= uess.
> > DS-Lite is built on the dual-stack model. The target is to guaran= tee
> > communication experiences within same address family across diffe= rent
> > family. 464xlat adopts IPv6-only model. It aims to serve LIMITED = ipv4
> > service. RFC6180 made really clear statements for each model (see=
> > section 4.3 and 4.4), I guess we don't need to argue that her= e. So,
> > why not use it to get rid of confusions.
> >
> > Item 1 could be clearer as
> >
> > =A0 =A0 =A01. =A0There is an IPv6-only Deployment [RFC6180] that = uses stateful
> > =A0 =A0 =A0 translation [RFC6146]
>
> The point is that an IPv6-only deployment with both a NAT-64-CGN and a= DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable deploym= ent (see (**) above). =A0It is inappropriate, in this case, to write that u= sing NAT64 is necessarily best.
> - This point isn't covered by words you propose.
> - I can't see what would be wrong (besides NIH) in something like:=
> "1. There is an IPv6-only access network that uses stateful trans= lation [RFC6146] as its sole transition solution for IPv4 via IPv6." > =3D> (*) above is confirmed.
>

My co-authors and i can accept this.

Is this slight wording change ok?

1. There is an IPv6-only access network that uses stateful=A0 translatio= n [RFC6146] as the only mechanism for providing ipv4 access.

Regards,

CB

> Regards,
> RD
>
>
>
> >
> >
> >
> >> You object to what you see as a pecking order if, for example= , 464XLAT is
> >> said to be "the best way of running IPv4 over IPv6 in ne= tworks that cannot
> >> support encapsulation". But the word "best" in= "BCP" is per se expressing
> >> some order. Current text implicitly asserts that using 464XLA= T IS better
> >> than using DS-Lite where both are available. This isn't a= cceptable AFAIAC.
> >> Note that I agree that it isn't necessary, in a 464XLAT R= FC, to tell,
> >> explicitly or implicitly, which one is best practice where 46= 4XLAT coexists
> >> with DS-Lite: it can be left unspecified.
> >>
> >> FWIW,
> >> RD
> >>
> >>
> >> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit :
> >>
> >>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s <despres.remi@laposte.net> > >>> wrote:
> >>>>
> >>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : > >>>>
> >>>>
> >>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)&q= uot; <rajiva@cisco.com>
> >>>> wrote:
> >>>>>
> >>>>> Did we already conclude that this is a BCP and no= t Informational? We
> >>>>> should just put it in the latter category and mov= e on/progress.
> >>>>>
> >>>>>
> >>>>
> >>>> Yes, afaik, the chairs have accepted bcp status and h= ave accepted the
> >>>> bcp
> >>>> scenario text.
> >>>>
> >>>> The chairs also direct the WG to move on to any remai= nig technical
> >>>> issuess.
> >>>>
> >>>> http://www.ietf.org/mail-archive/web/v6ops/current/= msg13714.html
> >>>>
> >>>>
> >>>> After that, Lorenzo proposed an approach, which I app= roved, to resolve
> >>>> the
> >>>> last issue I had raised.
> >>>> If the chairs also agree, all is AFAIK OK for the dra= ft to proceed
> >>>> without
> >>>> objection as BCP.
> >>>> Regards,`
> >>>> RD
> >>>>
> >>>
> >>> R=E9mi,
> >>>
> >>> It sounds like you are deferring to the chairs.
> >>>
> >>> I too will defer to the chairs, since my focus is moving = forward.
> >>>
> >>> The chairs have already made their position known, and th= ey may
> >>> re-open this issue.
> >>>
> >>> You and Lorenzo have supplied input to the chairs.
> >>>
> >>> My input to the chairs is that there should be no changes= required of
> >>> the current text. =A0In very basic logical terms the text= currently says
> >>>
> >>> X =3D RFC 6146
> >>>
> >>> IF =A0(X) then 464XLAT is BCP for providing IPv4 service = to IPv4-only
> >>> hosts and apps on an IPv6-only access network.
> >>>
> >>> Your original proposal and more or less Lorenzo's pro= posal
> >>>
> >>> Y =3D DS-lite
> >>>
> >>> IF (X and NOT Y) =A0then BCP =A0for providing IPv4 servic= e to IPv4-only
> >>> hosts and apps on an IPv6-only access network
> >>>
> >>> The difference between "only X" and "X and= not Y" is that there must
> >>> be a scenario where X and Y both occur. =A0 I do not beli= eve that is the
> >>> case that X and Y will occur together so there is no need= to
> >>> complicated the document with this. =A0And, your meaning,= which i
> >>> believe is to say that tunneling is better than translati= on, is
> >>> already documented in the IETF (RFC 4213, others?)
> >>>
> >>> As i said before, it seems like the aim is to create a pe= cking order
> >>> of transition solutions. =A0If you want to do that, that = is the scope of
> >>> a different draft.
> >>>
> >>>
> >>> CB
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> >>

--f46d0401fc3f1c2c1b04c73177d2-- From joelja@bogus.com Mon Aug 13 21:28:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67E21F8673 for ; Mon, 13 Aug 2012 21:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kmw0Lszy7XB for ; Mon, 13 Aug 2012 21:28:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE86821F8671 for ; Mon, 13 Aug 2012 21:28:17 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7E4SG4Z007849 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 14 Aug 2012 04:28:16 GMT (envelope-from joelja@bogus.com) Message-ID: <5029D3DF.5010508@bogus.com> Date: Mon, 13 Aug 2012 21:28:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Randy Bush References: <5028270F.3060204@bogus.com> <5029849D.3010304@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 14 Aug 2012 04:28:17 +0000 (UTC) Cc: ops-ads@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. - Remote participation as a scheduling consideration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 04:28:20 -0000 On 8/13/12 4:06 PM, Randy Bush wrote: >> If it's a dumb idea I get to shoulder a big portion of the blame for >> that. > do i get a refund? > >> I take it you do not believe that this attempt at optimization is >> a worthwhile one. > optimization of what? us-centricism? So, The proposal was based on looking back at the breakdown of ietf attendees by region across the last couple of meetings. I looked at 84 83 82. If selecting a time for an interim on the basis of it being a reasonable time for the local time and remote attendees from about +2 to -7 is inappropriate then I guess I'm wrong, or I shouldn't do that. I'd like to hear that. If we had more than one of these in the queue I belive that it would be most appropiate to share that consideration around. As of now we don't. I don't think 0900 to 1700 is necessary or warranted. We've been assiduous about fitting into no more than 4.5 hours during an IETF meeting I think 4 will work in this case. From randy@psg.com Mon Aug 13 21:30:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BC821F867E for ; Mon, 13 Aug 2012 21:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi04v0J1n7fZ for ; Mon, 13 Aug 2012 21:30:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 057F921F8671 for ; Mon, 13 Aug 2012 21:30:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T18lt-000Hkj-1m; Tue, 14 Aug 2012 04:30:25 +0000 Date: Tue, 14 Aug 2012 13:30:42 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <5029D3DF.5010508@bogus.com> References: <5028270F.3060204@bogus.com> <5029849D.3010304@bogus.com> <5029D3DF.5010508@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ops-ads@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. - Remote participation as a scheduling consideration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 04:30:27 -0000 when we met physically in paris and had remote participation, did we schedule the meetings from local afternoon to midnight? i am rather shocked at the international rudeness of this proposal and the message it sends to the world. randy From joelja@bogus.com Mon Aug 13 22:09:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8D311E809C for ; Mon, 13 Aug 2012 22:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8ULL4Rt9vQO for ; Mon, 13 Aug 2012 22:09:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0661811E8091 for ; Mon, 13 Aug 2012 22:09:24 -0700 (PDT) Received: from joels-MacBook-Air.local (18.sub-166-250-33.myvzw.com [166.250.33.18]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7E59NXH008102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 14 Aug 2012 05:09:23 GMT (envelope-from joelja@bogus.com) Message-ID: <5029DD7C.9090204@bogus.com> Date: Mon, 13 Aug 2012 22:09:16 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Randy Bush References: <5028270F.3060204@bogus.com> <5029849D.3010304@bogus.com> <5029D3DF.5010508@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 14 Aug 2012 05:09:24 +0000 (UTC) Cc: ops-ads@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. - Remote participation as a scheduling consideration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 05:09:29 -0000 On 8/13/12 9:30 PM, Randy Bush wrote: > when we met physically in paris and had remote participation, did we > schedule the meetings from local afternoon to midnight? IETF meetings have scheduled sessions that run as late as 19:40 A meeting of not more than 4 hours starting at 1600 would end at 2000 which is a reasonable time to break for dinner in a cosmopolitan city. > i am rather shocked at the international rudeness of this proposal and > the message it sends to the world. I never proposed that. > randy > From phdgang@gmail.com Mon Aug 13 23:18:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACD621F8493 for ; Mon, 13 Aug 2012 23:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxZ2KO8T0Xnb for ; Mon, 13 Aug 2012 23:18:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2727221F846D for ; Mon, 13 Aug 2012 23:18:54 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so34384vcb.31 for ; Mon, 13 Aug 2012 23:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3UmapU4Clk/tqKk3Qtvp5eXBQb3dwITu9UfcMBxaIls=; b=I9ogi2BE4pOPsTglAriNKU0F3tEgnefSV20rnAXAYpd3CCVTKlNWa4gVHo4wKGfEUt ank6a4tF9GxQ4xo/qZJpWBWU7SkemY5R1SJLGH0iFNDWklhQ3mqoPXTBCADlPUCUR3l5 2Bzm8aCXNAILNkPA2G43wIGgCH1AvDO/xr1BKMYdLY99QWGMOBM3klB6RUkrJECZcE5+ ggnP8xmB3jS4cF5qhYQdOsKo1sojYqse0CSKRT0V5fSzCIygAVk0LDbRPCYo9LxCk+47 fnVxTrgZwzsuKuoWvQT2pml4FOsd7pmeAHv76Ps5v23tGcijVsVthQiN5LNFFT1g4hze i5vA== MIME-Version: 1.0 Received: by 10.220.221.72 with SMTP id ib8mr9839527vcb.25.1344925134368; Mon, 13 Aug 2012 23:18:54 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Mon, 13 Aug 2012 23:18:54 -0700 (PDT) In-Reply-To: <5028270F.3060204@bogus.com> References: <5028270F.3060204@bogus.com> Date: Tue, 14 Aug 2012 14:18:54 +0800 Message-ID: From: GangChen To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , V6ops Chairs , "ops-ads@tools.ietf.org" Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 06:18:56 -0000 I had noticed the arrangement when the Thursday minute was came up. Since the IETF#84 Thursday meeting was conflicted with Softwires, I guess a number of participants did not have chance to voice on the meeting. So such interim meeting may have lots of people will not be able to go, can we ask how many people couldn't be there? BRs Gang 2012/8/13, joel jaeggli : > While there are some details still to be worked out it's time to get the > framework in place for the interim to coincide with the end of RIPE 65, > Amsterdam, 24 - 28 September 2012. > > We believe that the location will be: > > Hotel Okura > > Ferdinand Bolstraat 333 > 1072 LH Amsterdam > +31 (0) 20 678 7493 > > however that is not yet gospel I am told. > > The plan as it stands know is to attempt to time the meeting to > accommodate remote participants in North American I have requested that > it start at 1600cest. that said there are still a lot of details to be > worked out. and and time one a Saturday is going to be an inconvenience > to some (sorry) who might otherwise make it in the flesh or online. > > Things we can plan for however are an interim document submission > deadline two weeks out from the meeting itself. Too be considered for > inclusion in the interim agenda new or revised documented should be > submitted to the IETF document system by 23:59 UTC on Sept 14th. > > more details will follow as we get them. > > From joelja@bogus.com Mon Aug 13 23:55:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495B911E808E for ; Mon, 13 Aug 2012 23:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDZXMsR2WHLb for ; Mon, 13 Aug 2012 23:55:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDFA11E808D for ; Mon, 13 Aug 2012 23:55:42 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7E6tbtP008700 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 14 Aug 2012 06:55:38 GMT (envelope-from joelja@bogus.com) Message-ID: <5029F669.5090609@bogus.com> Date: Mon, 13 Aug 2012 23:55:37 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: GangChen References: <5028270F.3060204@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 14 Aug 2012 06:55:38 +0000 (UTC) Cc: IPv6 Ops WG , V6ops Chairs , "ops-ads@tools.ietf.org" Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 06:55:43 -0000 On 8/13/12 11:18 PM, GangChen wrote: > I had noticed the arrangement when the Thursday minute was came up. > Since the IETF#84 Thursday meeting was conflicted with Softwires, I > guess a number of participants did not have chance to voice on the > meeting. So such interim meeting may have lots of people will not be > able to go, can we ask how many people couldn't be there? Just as an observation, relatively little material should directly overlap between softwire and v6ops. We shifted presentations around so that drafts that would benefit from the input of the attendees of softwire were on Friday morning, likewise the discussion that came back from sunset4. we hope that was sufficient. > BRs > > Gang > > 2012/8/13, joel jaeggli : >> While there are some details still to be worked out it's time to get the >> framework in place for the interim to coincide with the end of RIPE 65, >> Amsterdam, 24 - 28 September 2012. >> >> We believe that the location will be: >> >> Hotel Okura >> >> Ferdinand Bolstraat 333 >> 1072 LH Amsterdam >> +31 (0) 20 678 7493 >> >> however that is not yet gospel I am told. >> >> The plan as it stands know is to attempt to time the meeting to >> accommodate remote participants in North American I have requested that >> it start at 1600cest. that said there are still a lot of details to be >> worked out. and and time one a Saturday is going to be an inconvenience >> to some (sorry) who might otherwise make it in the flesh or online. >> >> Things we can plan for however are an interim document submission >> deadline two weeks out from the meeting itself. Too be considered for >> inclusion in the interim agenda new or revised documented should be >> submitted to the IETF document system by 23:59 UTC on Sept 14th. >> >> more details will follow as we get them. >> >> From despres.remi@laposte.net Tue Aug 14 00:15:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8AB11E808D for ; Tue, 14 Aug 2012 00:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R32qWiOcqeYS for ; Tue, 14 Aug 2012 00:15:05 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0C12C21F85C6 for ; Tue, 14 Aug 2012 00:15:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 63CB37000089; Tue, 14 Aug 2012 09:15:03 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 91C2F7000085; Tue, 14 Aug 2012 09:15:02 +0200 (CEST) X-SFR-UUID: 20120814071502597.91C2F7000085@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13--598401753 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 14 Aug 2012 09:15:01 +0200 Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <2231CCD2-86F6-40B7-9EFC-A7F9C8E06BA1@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 07:15:06 -0000 --Apple-Mail-13--598401753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-14 =E0 05:32, Cameron Byrne a =E9crit : >=20 > On Aug 13, 2012 12:41 AM, "R=E9mi Despr=E9s" = wrote: > > > > > > Le 2012-08-11 =E0 17:59, GangChen a =E9crit : > > > > > 2012/8/11, R=E9mi Despr=E9s : > > >> Cameron, > > >> > > >> Since the point made doesn't seem clear enough, here is another = try. > > >> > > > > (*) > > >> - 464XLAT as best practice where providers offer NAT64 as their = ONLY IPv4 > > >> support across their access networks: agreed. > > >> - 464XLAT declared best practice independently of OTHER IPv4 = support > > >> providers may offer across their access networks, in addition to = NAT64-CGN: > > >> disagreed. > > >> > > >> If a rough consensus is nevertheless declared that ignores this, = whatever > > >> the reasons, I want to be clearly out of it. > > > > > > > > >> Your key argument below is that no provider would realistically = support both > > >> 464-CGN and DS-Lite, but this isn't right AFAIK. > > > > (**) > > >> NAT64 is a solution for "IPv6-only clients to contact IPv4 = servers" > > >> [RFC6146], and DS-Lite a solution for IPv4 clients to reach = NAT44-CGNs > > >> across IPv6-only access networks such that "communications = between end-nodes > > >> stay within their address family" [RFC6333]. Satisfying both = needs does make > > >> sense. > > > > > > > The communication model is similar but incentive is different I = guess. > > > DS-Lite is built on the dual-stack model. The target is to = guarantee > > > communication experiences within same address family across = different > > > family. 464xlat adopts IPv6-only model. It aims to serve LIMITED = ipv4 > > > service. RFC6180 made really clear statements for each model (see > > > section 4.3 and 4.4), I guess we don't need to argue that here. = So, > > > why not use it to get rid of confusions. > > > > > > Item 1 could be clearer as > > > > > > 1. There is an IPv6-only Deployment [RFC6180] that uses = stateful > > > translation [RFC6146] > > > > The point is that an IPv6-only deployment with both a NAT-64-CGN and = a DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable = deployment (see (**) above). It is inappropriate, in this case, to = write that using NAT64 is necessarily best. > > - This point isn't covered by words you propose. > > - I can't see what would be wrong (besides NIH) in something like: > > "1. There is an IPv6-only access network that uses stateful = translation [RFC6146] as its sole transition solution for IPv4 via = IPv6." > > =3D> (*) above is confirmed. > > >=20 > My co-authors and i can accept this. >=20 > Is this slight wording change ok? >=20 > 1. There is an IPv6-only access network that uses stateful = translation [RFC6146] as the only mechanism for providing ipv4 access. >=20 OK for me. Thanks, RD >=20 > Regards, >=20 > CB >=20 > > Regards, > > RD > > > > > > > > > > > > > > > > > >> You object to what you see as a pecking order if, for example, = 464XLAT is > > >> said to be "the best way of running IPv4 over IPv6 in networks = that cannot > > >> support encapsulation". But the word "best" in "BCP" is per se = expressing > > >> some order. Current text implicitly asserts that using 464XLAT IS = better > > >> than using DS-Lite where both are available. This isn't = acceptable AFAIAC. > > >> Note that I agree that it isn't necessary, in a 464XLAT RFC, to = tell, > > >> explicitly or implicitly, which one is best practice where = 464XLAT coexists > > >> with DS-Lite: it can be left unspecified. > > >> > > >> FWIW, > > >> RD > > >> > > >> > > >> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit : > > >> > > >>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s = > > >>> wrote: > > >>>> > > >>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit : > > >>>> > > >>>> > > >>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" = > > >>>> wrote: > > >>>>> > > >>>>> Did we already conclude that this is a BCP and not = Informational? We > > >>>>> should just put it in the latter category and move = on/progress. > > >>>>> > > >>>>> > > >>>> > > >>>> Yes, afaik, the chairs have accepted bcp status and have = accepted the > > >>>> bcp > > >>>> scenario text. > > >>>> > > >>>> The chairs also direct the WG to move on to any remainig = technical > > >>>> issuess. > > >>>> > > >>>> = http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > > >>>> > > >>>> > > >>>> After that, Lorenzo proposed an approach, which I approved, to = resolve > > >>>> the > > >>>> last issue I had raised. > > >>>> If the chairs also agree, all is AFAIK OK for the draft to = proceed > > >>>> without > > >>>> objection as BCP. > > >>>> Regards,` > > >>>> RD > > >>>> > > >>> > > >>> R=E9mi, > > >>> > > >>> It sounds like you are deferring to the chairs. > > >>> > > >>> I too will defer to the chairs, since my focus is moving = forward. > > >>> > > >>> The chairs have already made their position known, and they may > > >>> re-open this issue. > > >>> > > >>> You and Lorenzo have supplied input to the chairs. > > >>> > > >>> My input to the chairs is that there should be no changes = required of > > >>> the current text. In very basic logical terms the text = currently says > > >>> > > >>> X =3D RFC 6146 > > >>> > > >>> IF (X) then 464XLAT is BCP for providing IPv4 service to = IPv4-only > > >>> hosts and apps on an IPv6-only access network. > > >>> > > >>> Your original proposal and more or less Lorenzo's proposal > > >>> > > >>> Y =3D DS-lite > > >>> > > >>> IF (X and NOT Y) then BCP for providing IPv4 service to = IPv4-only > > >>> hosts and apps on an IPv6-only access network > > >>> > > >>> The difference between "only X" and "X and not Y" is that there = must > > >>> be a scenario where X and Y both occur. I do not believe that = is the > > >>> case that X and Y will occur together so there is no need to > > >>> complicated the document with this. And, your meaning, which i > > >>> believe is to say that tunneling is better than translation, is > > >>> already documented in the IETF (RFC 4213, others?) > > >>> > > >>> As i said before, it seems like the aim is to create a pecking = order > > >>> of transition solutions. If you want to do that, that is the = scope of > > >>> a different draft. > > >>> > > >>> > > >>> CB > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > >> --Apple-Mail-13--598401753 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Aug 13, 2012 12:41 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:
>
>
> Le 2012-08-11 =E0 17:59, GangChen a =E9crit :
>
> > 2012/8/11, R=E9mi Despr=E9s <despres.remi@laposte.net>:=
> >> Cameron,
> >>
> >> Since the point made doesn't seem clear enough, here is = another try.
> >>
>
> (*)
> >> - 464XLAT as best practice where providers offer NAT64 as = their ONLY IPv4
> >> support across their access networks: agreed.
> >> - 464XLAT declared best practice independently of OTHER = IPv4 support
> >> providers may offer across their access networks, in = addition to NAT64-CGN:
> >> disagreed.
> >>
> >> If a rough consensus is nevertheless declared that ignores = this, whatever
> >> the reasons, I want to be clearly out of it.
>
>
>
> >> Your key argument below is that no provider would = realistically support both
> >> 464-CGN and DS-Lite, but this isn't right AFAIK.
>
> (**)
> >> NAT64 is a solution for "IPv6-only clients to contact IPv4 = servers"
> >> [RFC6146], and DS-Lite a solution for IPv4 clients to = reach NAT44-CGNs
> >> across IPv6-only access networks such that "communications = between end-nodes
> >> stay within their address family" [RFC6333]. Satisfying = both needs does make
> >> sense.
>
>
> > The communication model is similar but incentive is different = I guess.
> > DS-Lite is built on the dual-stack model. The target is to = guarantee
> > communication experiences within same address family across = different
> > family. 464xlat adopts IPv6-only model. It aims to serve = LIMITED ipv4
> > service. RFC6180 made really clear statements for each model = (see
> > section 4.3 and 4.4), I guess we don't need to argue that = here. So,
> > why not use it to get rid of confusions.
> >
> > Item 1 could be clearer as
> >
> >      1.  There is an IPv6-only Deployment = [RFC6180] that uses stateful
> >       translation [RFC6146]
>
> The point is that an IPv6-only deployment with both a NAT-64-CGN = and a DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable = deployment (see (**) above).  It is inappropriate, in this case, to = write that using NAT64 is necessarily best.
> - This point isn't covered by words you propose.
> - I can't see what would be wrong (besides NIH) in something = like:
> "1. There is an IPv6-only access network that uses stateful = translation [RFC6146] as its sole transition solution for IPv4 via = IPv6."
> =3D> (*) above is confirmed.
>

My co-authors and i can accept this.

Is this slight = wording change ok?

1. There is an IPv6-only access network = that uses stateful  translation [RFC6146] as the only mechanism for = providing ipv4 access.

OK for = me.
Thanks,
RD


Regards,

CB

> = Regards,
> RD
>
>
>
> >
> >
> >
> >> You object to what you see as a pecking order if, for = example, 464XLAT is
> >> said to be "the best way of running IPv4 over IPv6 in = networks that cannot
> >> support encapsulation". But the word "best" in "BCP" is = per se expressing
> >> some order. Current text implicitly asserts that using = 464XLAT IS better
> >> than using DS-Lite where both are available. This isn't = acceptable AFAIAC.
> >> Note that I agree that it isn't necessary, in a 464XLAT = RFC, to tell,
> >> explicitly or implicitly, which one is best practice where = 464XLAT coexists
> >> with DS-Lite: it can be left unspecified.
> >>
> >> FWIW,
> >> RD
> >>
> >>
> >> Le 2012-08-10 =E0 18:39, Cameron Byrne a =E9crit :
> >>
> >>> On Fri, Aug 10, 2012 at 9:00 AM, R=E9mi Despr=E9s = <despres.remi@laposte.net><= br> > >>> wrote:
> >>>>
> >>>> Le 2012-08-10 =E0 16:25, Cameron Byrne a =E9crit = :
> >>>>
> >>>>
> >>>> On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" = <rajiva@cisco.com>
> >>>> wrote:
> >>>>>
> >>>>> Did we already conclude that this is a BCP and = not Informational? We
> >>>>> should just put it in the latter category and = move on/progress.
> >>>>>
> >>>>>
> >>>>
> >>>> Yes, afaik, the chairs have accepted bcp status = and have accepted the
> >>>> bcp
> >>>> scenario text.
> >>>>
> >>>> The chairs also direct the WG to move on to any = remainig technical
> >>>> issuess.
> >>>>
> >>>> = http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html
> >>>>
> >>>>
> >>>> After that, Lorenzo proposed an approach, which I = approved, to resolve
> >>>> the
> >>>> last issue I had raised.
> >>>> If the chairs also agree, all is AFAIK OK for the = draft to proceed
> >>>> without
> >>>> objection as BCP.
> >>>> Regards,`
> >>>> RD
> >>>>
> >>>
> >>> R=E9mi,
> >>>
> >>> It sounds like you are deferring to the chairs.
> >>>
> >>> I too will defer to the chairs, since my focus is = moving forward.
> >>>
> >>> The chairs have already made their position known, and = they may
> >>> re-open this issue.
> >>>
> >>> You and Lorenzo have supplied input to the chairs.
> >>>
> >>> My input to the chairs is that there should be no = changes required of
> >>> the current text.  In very basic logical terms = the text currently says
> >>>
> >>> X =3D RFC 6146
> >>>
> >>> IF  (X) then 464XLAT is BCP for providing IPv4 = service to IPv4-only
> >>> hosts and apps on an IPv6-only access network.
> >>>
> >>> Your original proposal and more or less Lorenzo's = proposal
> >>>
> >>> Y =3D DS-lite
> >>>
> >>> IF (X and NOT Y)  then BCP  for providing = IPv4 service to IPv4-only
> >>> hosts and apps on an IPv6-only access network
> >>>
> >>> The difference between "only X" and "X and not Y" is = that there must
> >>> be a scenario where X and Y both occur.   I do = not believe that is the
> >>> case that X and Y will occur together so there is no = need to
> >>> complicated the document with this.  And, your = meaning, which i
> >>> believe is to say that tunneling is better than = translation, is
> >>> already documented in the IETF (RFC 4213, others?)
> >>>
> >>> As i said before, it seems like the aim is to create a = pecking order
> >>> of transition solutions.  If you want to do that, = that is the scope of
> >>> a different draft.
> >>>
> >>>
> >>> CB
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/= mailman/listinfo/v6ops
> >>


= --Apple-Mail-13--598401753-- From phdgang@gmail.com Tue Aug 14 00:30:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ADA21F85B4 for ; Tue, 14 Aug 2012 00:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnCe1giR7DUC for ; Tue, 14 Aug 2012 00:30:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE021F85AD for ; Tue, 14 Aug 2012 00:30:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so90146vbb.31 for ; Tue, 14 Aug 2012 00:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JDYxWARAQ6NhWPR/sZwGk6iJeHxOIQcgczNU4PTs0j0=; b=mlOkNCbULIiwM2awwz/IAT8lRA0SiDohyXASx+oEKVgCvRxPAjmpHDU8h5SiLIQh+u NMhbMwJDcDUdnMEQ5Rdov+nVWL/1dAatcK/6iP3K3EInZRzhF2+6tSqE4M702D3fi0OH aq9OBxckKRoDi1+1gBaSCYMEPlv1FlwAG/w0qS/YPmqDIrity6Hch+Ld9uuakLLXJko8 ejRbJUDt1Q06oy5s+A9K7q9E42WdrtWAG0XhPpsBhJ+N5h2xa1y52SlVPOlZ/CyzIgL9 ak//RVjcxnmND0BCAbkrJdFHjxMlc3h3CSp/1RbpYTsGs2bq3T6Lcy4AaP/wnIZ9L3Nr smXg== MIME-Version: 1.0 Received: by 10.52.240.205 with SMTP id wc13mr8834738vdc.35.1344929453567; Tue, 14 Aug 2012 00:30:53 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Tue, 14 Aug 2012 00:30:53 -0700 (PDT) In-Reply-To: <5029F669.5090609@bogus.com> References: <5028270F.3060204@bogus.com> <5029F669.5090609@bogus.com> Date: Tue, 14 Aug 2012 15:30:53 +0800 Message-ID: From: GangChen To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , V6ops Chairs , "ops-ads@tools.ietf.org" Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 07:30:55 -0000 2012/8/14, joel jaeggli : > On 8/13/12 11:18 PM, GangChen wrote: >> I had noticed the arrangement when the Thursday minute was came up. >> Since the IETF#84 Thursday meeting was conflicted with Softwires, I >> guess a number of participants did not have chance to voice on the >> meeting. So such interim meeting may have lots of people will not be >> able to go, can we ask how many people couldn't be there? > Just as an observation, relatively little material should directly > overlap between softwire and v6ops. We shifted presentations around so > that drafts that would benefit from the input of the attendees of > softwire were on Friday morning, likewise the discussion that came back > from sunset4. we hope that was sufficient. There are less overlapped document, but there are more overlapped people between V6OPS and softwire who need to be asked before the decision. >> BRs >> >> Gang >> >> 2012/8/13, joel jaeggli : >>> While there are some details still to be worked out it's time to get the >>> framework in place for the interim to coincide with the end of RIPE 65, >>> Amsterdam, 24 - 28 September 2012. >>> >>> We believe that the location will be: >>> >>> Hotel Okura >>> >>> Ferdinand Bolstraat 333 >>> 1072 LH Amsterdam >>> +31 (0) 20 678 7493 >>> >>> however that is not yet gospel I am told. >>> >>> The plan as it stands know is to attempt to time the meeting to >>> accommodate remote participants in North American I have requested that >>> it start at 1600cest. that said there are still a lot of details to be >>> worked out. and and time one a Saturday is going to be an inconvenience >>> to some (sorry) who might otherwise make it in the flesh or online. >>> >>> Things we can plan for however are an interim document submission >>> deadline two weeks out from the meeting itself. Too be considered for >>> inclusion in the interim agenda new or revised documented should be >>> submitted to the IETF document system by 23:59 UTC on Sept 14th. >>> >>> more details will follow as we get them. >>> >>> > > From evyncke@cisco.com Tue Aug 14 01:42:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E86E21F85F4; Tue, 14 Aug 2012 01:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.143 X-Spam-Level: X-Spam-Status: No, score=-10.143 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2E7zjEgcvTE; Tue, 14 Aug 2012 01:42:47 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6635521F85FC; Tue, 14 Aug 2012 01:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=23704; q=dns/txt; s=iport; t=1344933767; x=1346143367; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3CbcGoBYiEPBX4HIjQIEuJ5N0OUtnyusKF6I8rBzGiI=; b=Dv1uSAQxmUbWsjsDzkvXAkzIYYFL/I849B4iJj6+eqWx+Vib0nqMaPZy s1jwdQkGlvxzmEIax0Chk9HvHuf7PwFSSnmqzE0qbXvdIN6aaYLTxa25K iZTxARJbRDqH0LepSqG2smJNSbmBGZVSDCR2rvGWqgVOfFONl/251/KvU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP4OKlCtJV2c/2dsb2JhbAA6CoJKt0SBB4IgAQEBBBIBGkwQAgEIEQQBAQsWBwcyFAkIAQEEAQ0FCAwOh2uYJaEJiwUQhUFgA4gZm1yBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208,217";a="111360488" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2012 08:42:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7E8ghlA004571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 08:42:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 03:42:43 -0500 From: "Eric Vyncke (evyncke)" To: "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" , "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71ApgGSKfgw Date: Tue, 14 Aug 2012 08:42:42 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003 x-tm-as-result: No--57.735900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E10C3A2Axmbalnx02ciscocom_" MIME-Version: 1.0 Cc: Fernando Gont Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 08:42:50 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E10C3A2Axmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fernando and Gunter, Sorry for belated comments... I agree with most comments from other reviewe= rs of course (esp Panos). I have two classes of comments: generic and deta= ils. Let's start with generic: - It should not be a BCP but rather informational - I also wonder whether it is worth an IETF RFC because it is well kn= own topics in the security area (as you probably know) - Missing point: awareness of IPV6 by CISO is the key problem, should= also add that IPv6 is not dangerous per se, and enabling IPv6 in intranet = is a good way to bypass all automatic tunnels - Intro / title should specify 'end-user network' (to avoid confusion= for ISP) - IP flow (netflow), firewall log, DNS request log could also be moni= tored to detect tunnels establishments - Using NAPT (and not NAT as previously commented) usually blocks 'ma= gically' IP protocol 41 and most tunnels - If the security policy is to force all traffic through application = proxies (done by all major organizations) then tunnels are not a threat Let's continue with the details: - 1.0 please avoid all discussion about NAPT being 'minimal/simple' s= ecurity, the days of scanning are over and have been replaced by malware do= wnload/email propagated - 2.0 congruent security policy indeed with the exception of RFC 4890= (ICMPv6) - 2.1 filtering the IPv6 ethertype is TOO dangerous (=3D could break = too many things) to be recommended in an IETF document - 3.1 should refer to the RFC - 3.3 AFAIK there is no by default implementation of 6RD in generic O= S and it requires either manual configuration or DHCPv4 option =3D> remove = this section - 3.5 leave ISATAP (automatic config through DNS) but specify that bl= ocking 41 also blocks it - 3.6 as noted, Teredo default port can be changed. The good recommen= dation anyway for enterprises is to block outbound UDP traffic (except some= pin holes for DNS of course), even my employer network blocks them since 1= 997 ;-). Also, Microsoft implementation disables Teredo when personal firew= all is disabled or when the host is in an Active Directory network - Other tunnels TSP (but also Sixxs, ...) all require explicit instal= lation and configuration by end-users. They are no more a thread than any o= ther covert channel (being IP over DNS or over ICMP or ...), I would remove= this section Hope this helps -=E9ric From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: lundi 6 ao=FBt 2012 10:43 To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implica= tions-on-ipv4-nets Dear all, Can I request the WG members for 3 volunteers to read the draft draft-gont-= opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list? This will help the OPSEC chairs to identify if the work is ready for WG ado= ption or not. The work targets are within charter of the WG, and seems to b= e interesting work for the community. Questions we are looking answers for: 1) Should it be targeted BCP or Informational? 2) Is the work quality ok to be accepted as WG document? 3) Is the topic inline with the OPSEC charter? 4) Any missing or over-described points? Many thanks in advance, Kind Regards, OPSEC Chairs, (G/, KK, Warren) --_000_97EB7536A2B2C549846804BBF3FD47E10C3A2Axmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fernando and Gunter,

 

Sorry for belated comments.= .. I agree with most comments from other reviewers of course (esp Panos). &= nbsp;I have two classes of comments: generic and details.=

 

Let’s start with gene= ric:

- &= nbsp;     It should not be a = BCP but rather informational

- &= nbsp;     I also wonder wheth= er it is worth an IETF RFC because it is well known topics in the security = area (as you probably know)

- &= nbsp;     Missing point: awar= eness of IPV6 by CISO is the key problem, should also add that IPv6 is not = dangerous per se, and enabling IPv6 in intranet is a good way to bypass all automatic tunnels

- &= nbsp;     Intro / title shoul= d specify ‘end-user network’ (to avoid confusion for ISP)<= /o:p>

- &= nbsp;     IP flow (netflow), = firewall log, DNS request log could also be monitored to detect tunnels est= ablishments

- &= nbsp;     Using NAPT (and not= NAT as previously commented) usually blocks ‘magically’ IP pro= tocol 41 and most tunnels

- &= nbsp;     If the security pol= icy is to force all traffic through application proxies (done by all major = organizations) then tunnels are not a threat

 

Let’s continue with t= he details:

- &= nbsp;     1.0 please avoid al= l discussion about NAPT being ‘minimal/simple’ security, the da= ys of scanning are over and have been replaced by malware download/email propagated

- &= nbsp;     2.0 congruent secur= ity policy indeed with the exception of RFC 4890 (ICMPv6)=

- &= nbsp;     2.1 filtering the I= Pv6 ethertype is TOO dangerous (=3D could break too many things) to be reco= mmended in an IETF document

- &= nbsp;     3.1 should refer to= the RFC

- &= nbsp;     3.3 AFAIK there is = no by default implementation of 6RD in generic OS and it requires either ma= nual configuration or DHCPv4 option =3D> remove this section

- &= nbsp;     3.5 leave ISATAP (a= utomatic config through DNS) but specify that blocking 41 also blocks it

- &= nbsp;     3.6 as noted, Tered= o default port can be changed. The good recommendation anyway for enterpris= es is to block outbound UDP traffic (except some pin holes for DNS of course), even my employer network blocks them since 1= 997 ;-). Also, Microsoft implementation disables Teredo when personal firew= all is disabled or when the host is in an Active Directory network

- &= nbsp;     Other tunnels TSP (= but also Sixxs, ...) all require explicit installation and configuration by= end-users. They are no more a thread than any other covert channel (being IP over DNS or over ICMP or ...), I would remo= ve this section

 

Hope this helps<= /span>

 

-=E9ric

 

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org= ] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: lundi 6 ao=FBt 2012 10:43
To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org)
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-= implications-on-ipv4-nets

 

Dear all,

 

Can I request the WG members fo= r 3 volunteers to read the draft draft-gont-opsec-ipv6-implications-on-ipv4= -nets and provide feedback to the list?

 

This will help the OPSEC chairs= to identify if the work is ready for WG adoption or not. The work targets = are within charter of the WG, and seems to be interesting work for the comm= unity.

 

Questions we are looking answer= s for:

 

1) &nbs= p;    Should it be targeted B= CP or Informational?

2) &nbs= p;    Is the work quality ok = to be accepted as WG document?

3) &nbs= p;    Is the topic inline wit= h the OPSEC charter?

4) &nbs= p;    Any missing or over-des= cribed points?

 

Many thanks in advance,

 

Kind Regards,=

OPSEC Chairs,=

(G/, KK, Warren)

--_000_97EB7536A2B2C549846804BBF3FD47E10C3A2Axmbalnx02ciscocom_-- From tjc@ecs.soton.ac.uk Tue Aug 14 02:29:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C4C21F8608 for ; Tue, 14 Aug 2012 02:29:02 -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=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vstaQE5ZHz3z for ; Tue, 14 Aug 2012 02:29:01 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1904C21F85AD for ; Tue, 14 Aug 2012 02:29:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7E9StR2015082; Tue, 14 Aug 2012 10:28:55 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q7E9StR2015082 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1344936535; bh=WL1UcTluZbPaPNPjgIMq7ksldxY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=DNYUFrL/zyb6UagQ/iUZlqgeuMkWQhrjKZ9XtSA/eoIjAykStlRATQgPGrH+9FciW NPkf2n6b46yo8UUs+BfVxvXkvTCotZ83QD0Tyfn3avwhbD8Gma9GcUekTMPlVHwp6W 5Ba1Tq2Yxa4LZTaXnRCcUQa0EnxKKFuXhh4E4TJQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o7DASy0430646160MY ret-id none; Tue, 14 Aug 2012 10:28:55 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7E9Sp9u029335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Aug 2012 10:28:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Tim Chown In-Reply-To: Date: Tue, 14 Aug 2012 10:28:53 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5028270F.3060204@bogus.com> <5029F669.5090609@bogus.com> <250BC0E2-AFC2-4B17-B2EB-4BA3FBB4F048@ecs.soton.ac.uk> To: IPv6 Ops WG , V6ops Chairs , ops-ads@tools.ietf.org X-Mailer: Apple Mail (2.1485) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o7DASy043064616000; tid=o7DASy0430646160MY; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q7E9StR2015082 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:29:02 -0000 On 14 Aug 2012, at 08:30, GangChen wrote: >=20 > There are less overlapped document, but there are more overlapped = people > between V6OPS and softwire who need to be asked before the decision. Are there not also multiple interim meetings being held after the RIPE = meeting, not just v6ops? If so, do we know what these are, and when they are scheduled? Are there = clashes to be avoided? Tim= From nick@inex.ie Tue Aug 14 02:54:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4398A21F85E1 for ; Tue, 14 Aug 2012 02:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMMJFizfbkKc for ; Tue, 14 Aug 2012 02:54:51 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4B21F85B8 for ; Tue, 14 Aug 2012 02:54:50 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q7E9rQu7099576 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2012 10:53:26 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <502A2068.8020307@inex.ie> Date: Tue, 14 Aug 2012 10:54:48 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5028270F.3060204@bogus.com> In-Reply-To: X-Enigmail-Version: 1.4.3 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:54:52 -0000 On 13/08/2012 10:43, Niall O'Reilly wrote: > It may be worth noting that RIPE meetings usually finish before > lunch on the Friday. Would 16:00 CEST on Friday 28 September be > worth considering instead of 24 hours later? I could get to a session on Friday 2012/09/28, but definitely not on the saturday. There is a lot of value in getting cross-pollination between the RIPE meeting and the IETF process. A friday session would help with this. By saturday, most people will have gone home (including me). I'd also see value in starting significantly earlier than 16:00. Regardless of the timezone considerations, if a session like this ends at 20:00, it means that people who live in europe will not be able to get an evening flight home, which means more hotel expenses. Nick From tjc@ecs.soton.ac.uk Tue Aug 14 02:58:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA87321F85B8 for ; Tue, 14 Aug 2012 02:58:40 -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=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvsfvYRO-YNn for ; Tue, 14 Aug 2012 02:58:40 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9031921F8670 for ; Tue, 14 Aug 2012 02:58:39 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7E9wZPa022241 for ; Tue, 14 Aug 2012 10:58:35 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q7E9wZPa022241 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1344938315; bh=/65imcEhqNajp++ogGgSe9XPXfU=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=e/b206wEzx17ytbbIJp4aZdvrQ0s2uXUOW3A5xHF9cFe6pAd3PjSDYQs3w7s0BmI8 VFfosjRnzmwTNYuAaFwDJ3yPQyLej5sbESbZ6e9slsRpgjDN29U7RY8591To/drXDB 7LA7CcuY/eLDtX5cMzx1mnmsO9Q0HQkrrfVATzJA= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o7DAwZ0430646408Sz ret-id none; Tue, 14 Aug 2012 10:58:35 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7E9wT1O003396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Aug 2012 10:58:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Tim Chown In-Reply-To: <502A2068.8020307@inex.ie> Date: Tue, 14 Aug 2012 10:58:31 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <5028270F.3060204@bogus.com> <502A2068.8020307@inex.ie> <04F00310-2B98-47F7-8D97-FDF71469BE80@ecs.soton.ac.uk> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1485) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o7DAwZ043064640800; tid=o7DAwZ0430646408Sz; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q7E9wZPa022241 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:58:40 -0000 On 14 Aug 2012, at 10:54, Nick Hilliard wrote: > On 13/08/2012 10:43, Niall O'Reilly wrote: >> It may be worth noting that RIPE meetings usually finish before >> lunch on the Friday. Would 16:00 CEST on Friday 28 September be >> worth considering instead of 24 hours later? > > I could get to a session on Friday 2012/09/28, but definitely not on the > saturday. > > There is a lot of value in getting cross-pollination between the RIPE > meeting and the IETF process. A friday session would help with this. By > saturday, most people will have gone home (including me). > > I'd also see value in starting significantly earlier than 16:00. > Regardless of the timezone considerations, if a session like this ends at > 20:00, it means that people who live in europe will not be able to get an > evening flight home, which means more hotel expenses. I agree with this. Tim From bzeeb-lists@lists.zabbadoz.net Tue Aug 14 03:35:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A121F8653 for ; Tue, 14 Aug 2012 03:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzO7z6Kj4E8n for ; Tue, 14 Aug 2012 03:35:12 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 5741D21F8648 for ; Tue, 14 Aug 2012 03:35:11 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0A90925D3A0F; Tue, 14 Aug 2012 10:35:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B2F70BE858A; Tue, 14 Aug 2012 10:35:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id f5e2DOhkpocK; Tue, 14 Aug 2012 10:34:56 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CB6ECBE8589; Tue, 14 Aug 2012 10:34:55 +0000 (UTC) Date: Tue, 14 Aug 2012 10:34:54 +0000 (UTC) From: "Bjoern A. Zeeb" To: v6ops WG In-Reply-To: Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 10:35:14 -0000 On Thu, 9 Aug 2012, Bjoern A. Zeeb wrote: A few days later than hoped.... as mentioned previously "access" network might not always be the case but as said, I'd be willing to ignore that detail unless you want to go through and do the s/access network/network/g. I might have done in a few cases. Going through the document with that in mind CLAT and PLAT are not really the right terminonlogy either as at home I am neither a provider nor a customer for example. In the 3/4G use case this might be the case. Again to be ingored for now. Please find comments inline. > Internet Engineering Task Force M. Mawatari > Internet-Draft Japan Internet Exchange Co.,Ltd. > Intended status: BCP M. Kawashima > Expires: February 8, 2013 NEC AccessTechnica, Ltd. > C. Byrne > T-Mobile USA > August 7, 2012 > > > 464XLAT: Combination of Stateful and Stateless Translation > draft-ietf-v6ops-464xlat-06 > > Abstract > > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the ... [RFC6146] ... > core and stateless protocol translation RFC 6145 at the edge. 464XLAT ... [RFC6145] ... > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > ... > 1. Introduction > > The IANA unallocated IPv4 address pool was exhausted on February 3, > 2011. Each RIR's unallocated IPv4 address pool will exhaust in the > near future. It will be difficult for many networks to assign IPv4 > addresses to end users, despite substantial IP connectivity growth > required for fast growing edge networks. Do we need this history lesson in each and every draft/RFC? It could at least be shortened to somehting like this: With the exhaustion of the IPv4 address pools, it will be difficult ... > > This document describes an IPv4 over IPv6 solution as one of the > techniques for IPv4 service extension and encouragement of IPv6 > deployment. 464XLAT is not a one for one replacement of full IPv4 ... one-for-one ... > functionality. The 464XLAT architecture only supports IPv4 in the > client server model, where the server has global IPv4 address. This ... has [insert] a [/insert] global ... > means it is not fit for IPv4 peer-to-peer communication or inbound > IPv4 connections. 464XLAT builds on IPv6 transport and includes full > any to any IPv6 communication. ... any-to-any ... > > The 464XLAT architecture described in this document uses IPv4/IPv6 > translation standardized in [RFC6145] and [RFC6146]. It does not > require DNS64 [RFC6147] since an IPv4 host may simply send IPv4 > packets, including packets to an IPv4 DNS server, which will be > translated on the CLAT to IPv6 and back to IPv4 on the PLAT. 464XLAT Expand CLAT on fist use here. Expand PLAT on fist use here. > networks may use DNS64 [RFC6147] to enable single stateful > translation [RFC6146] instead of 464XLAT double translation where > possible. The 464XLAT architecture encourages IPv6 transition by ... encourages [insert] the [/insert] IPv6 ... > making IPv4 services reachable across IPv6-only networks and > providing IPv6 and IPv4 connectivity to single-stack IPv4 or IPv6 > servers and peers. > > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4 to IPv6 translation service, which will be needed > in the future case of IPv6-only servers and peers to be reached from > legacy IPv4-only hosts across IPv6-only networks. "done twice" [remove] legacy [/remove] > > > 2. BCP Scenario > > This BCP only applies when the following two criteria are present: > > 1. There is an IPv6-only access network that uses stateful > translation [RFC6146] [append] . [/append] > > 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only access network to reach the IPv4 Internet [append] . [/append] > > > > > > > > Mawatari, et al. Expires February 8, 2013 [Page 3] > > Internet-Draft 464XLAT August 2012 > > > 3. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 4. Terminology > > PLAT: PLAT is Provider side translator(XLAT) that complies with > [RFC6146]. It translates N:1 global IPv6 packets to global > IPv4 packets, and vice versa. > > CLAT: CLAT is Customer side translator(XLAT) that complies with > [RFC6145]. It algorithmically translates 1:1 private IPv4 > packets to global IPv6 packets, and vice versa. The CLAT > function is applicable to a router or an end-node such as a > mobile phone. CLAT SHOULD perform router function to ... . [insert] The [/insert] CLAT ... > facilitate packets forwarding through the stateless > translation even if it is an end-node. This BTW has massive other implications/problems wrt to dealing with RAs, etc. Are you aware of this? I think it needs to be worded carefully to not imply that the end-node would be a "forwarding device" to not run into these problems. Generally, as an implementor, I always think it's bad to find requirement-levels language in a "Terminology" section. It usually means that the mandatory functionality explanation is either duplicated or missing in a more appropriate section. I'd suggest a line break here in case it's to stay. > In the case where the > access network does not allow for a dedicated IPv6 prefix for > translation, a NAT44 SHOULD be used between the router > function and the stateless translator function. The CLAT as > a common home router or 3G router is expected to perform or 4G? or generally "The CLAT as a router is ..."? > gateway functions such as DHCP server and DNS proxy for local > clients. The CLAT does not comply with the sentence "Both > IPv4-translatable IPv6 addresses and IPv4-converted IPv6 > addresses SHOULD use the same prefix." that is described on > Section 3.3 in [RFC6052] due to using different IPv6 prefixes > for CLAT-side and PLAT-side IPv4 addresses. > > > 5. Motivation and Uniqueness of 464XLAT > > 1. Minimal IPv4 resource requirements, maximum IPv4 efficiency > through statistical multiplexing [append] . [/append] > > 2. No new protocols required, quick deployment [append] . [/append] > > 3. IPv6-only networks are simpler and therefore less expensive to > operate [append] . [/append] > > > 6. Network Architecture > > 464XLAT architecture is shown in the following figure. There is no figure following. Maybe? "Examples of 464XLAT architectures are show in the figures in the the following sections." which would also not limit the use cases to the given examples. > > > > > > Mawatari, et al. Expires February 8, 2013 [Page 4] > > Internet-Draft 464XLAT August 2012 > > > 6.1. Wireline Network Architecture Does it really matter whether this is Wireline, WiMax, Wifi, or carrier pidgeons? > > The private IPv4 host on this diagram can reach global IPv4 hosts via > translation on both CLAT and PLAT. On the other hand, the IPv6 host > can reach other IPv6 hosts on the Internet directly without > translation. This means that the CPE can not only have the function I'd name the CLAT int he figure CPE/CLAT maybe? > of CLAT but also the function of IPv6 native router for IPv6 native ... of [insert] a [/insert] CLAT ... of [insert] an [/insert] IPv6 native router for [swap?] native IPv6 [/swap?] traffic. > traffic. > > > ---- > | v6 | > ---- > | > ---- | .---+---. .------. > | v6 |-----+ / \ / \ > ---- | ------ / IPv6 \ ------ / IPv4 \ > +---| CLAT |---+ Internet +---| PLAT |---+ Internet | > ------- | ------ \ / ------ \ / > |v4p/v6 |--+ `---------' `----+----' > ------- | | > ----- | ----- > | v4p |----+ | v4g | > ----- | ----- > > <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> > Not sure the "IPv6 Internet" needs to be the "Internet" but can also just be an IPv6 "network". > > v6 : Global IPv6 > v4p : Private IPv4 > v4g : Global IPv4 > > Figure 1: Wireline Network Topology > > 6.2. Wireless 3GPP Network Architecture > > The CLAT function on the UE provides an [RFC1918] address and IPv4 Spell out UE on first use: User Equipment (UE) ... > default route. The applications on the UE can use the private IPv4 > address for reaching global IPv4 hosts via translation on both CLAT > and PLAT. On the other hand, reaching IPv6 hosts (including host > presented via DNS64 [RFC6147]) does not require the CLAT function on > the UE. ... And a couple of other use cases missing here, not specific to 3GPP, etc. As mentioned earlier, I am happy to ignore and update once implementations exist. > > 7. Applicability > > 7.1. Wireline Network Applicability > > When an ISP has IPv6 464XLAT, the ISP can provide outgoing IPv4 > service to end users across an IPv6 access network. The result is The beginning of that first sentence needs rew-wording. What does "has IPv6 464XLAT" mean? Do you mean "Providing a PLAT device, an ISP can offer outgoing ..."? > that edge network growth is no longer tightly coupled to the > availability of scarce IPv4 addresses. > > If the IXP or another provider operates the PLAT, the edge ISP is "the IXP"? Do you mean "ISP" or do you mean "an IXP" in which case it needs to be spelt out as "IXP" is not the 'RFC Editor Abbreviations List'. > only required to deploy an IPv6 access network. All ISPs do not need > IPv4 access networks. They can migrate their access network to a > simple and highly scalable IPv6-only environment. > > Incidentally, the effectiveness of 464XLAT was confirmed in the WIDE > camp Spring 2012. The result is described in > > > > Mawatari, et al. Expires February 8, 2013 [Page 6] > > Internet-Draft 464XLAT August 2012 > > > [I-D.hazeyama-widecamp-ipv6-only-experience]. > > 7.2. Wireless 3GPP Network Applicability > > The vast majority of mobile networks are compliant to Pre-Release 9 > 3GPP standards. In Pre-Release 9 3GPP networks, GSM and UMTS > networks must signal and support both IPv4 and IPv6 Packet Data > Protocol (PDP) attachments to access IPv4 and IPv6 network > destinations [RFC6459]. Since there are 2 PDPs required to support 2 s/2/two/g > address families, this is double the number of PDPs required to > support the status quo of 1 address family, which is IPv4. s/1/one/ > > 464XLAT in combination with stateful translation [RFC6146] and DNS64 > [RFC6147] allows 85% of the Android applications to continue to work Not sure I like "85% of the Android applications" in an RFC for a lot of reasons: a) product name, b) number to be outdated the moment published, c) number certainly not applicable anymore in a few months/years. Either needs "at the time of publishing" or something or should be reworded to be more general "allows a majority of applications" or something. Remeber that also others are affected including a desktop with a 3G dongle (if these things work the same). > with single translation or native IPv6 access. For the remaining 15% > of applications that require IPv4 connectivity, the CLAT function on > the UE provides a private IPv4 address and IPv4 default-route on the > host for the applications to reference and bind to. Once again this is a current implementation specific detail I will ignore. On a UE you are good w/o a default route. s/default-route/default route/ > Connections > sourced from the IPv4 interface are immediately routed to the CLAT > function and passed to the IPv6-only mobile network, destine to the Hmm 'destine (to)' gives me a hard time. 'destined for'? > PLAT. In summary, the UE has the CLAT function that does a stateless > translation [RFC6145], but only when required. The mobile network > has a PLAT that does stateful translation [RFC6146]. > > 464XLAT works with today's existing systems as much as possible. > 464XLAT is compatible with existing network based deep packet > inspection solutions like 3GPP standardized Policy and Charging > Control (PCC) [TS.23203]. > > > 8. Implementation Considerations > > 8.1. IPv6 Address Format > > IPv6 address format in 464XLAT is defined in Section 2.2 of [prepend] The [/prepend] > [RFC6052]. > > 8.2. IPv4/IPv6 Address Translation Chart > > 8.2.1. Case of enabling only stateless XLATE on CLAT > > This case should be used when a prefix delegation mechanism such as > DHCPv6-PD [RFC3633] is available to assign a dedicated translation > prefix to the CLAT. > > > > > > > > Mawatari, et al. Expires February 8, 2013 [Page 7] > > Internet-Draft 464XLAT August 2012 In general I found it confusing to have the source address before the destination address in the direction of "travel" in all the following figures. > > Source IPv4 address > +----------------------------+ > | Global IPv4 address | > | assigned to IPv4 pool@PLAT | This could be spelt as "IPv4 PLAT pool" as well? > +--------+ +----------------------------+ > | IPv4 | Destination IPv4 address > | server | +----------------------------+ > +--------+ | Global IPv4 address | > ^ | assigned to IPv4 server | > | +----------------------------+ > +--------+ > | PLAT | Stateful XLATE(IPv4:IPv6=1:n) I feel the 1:n is confusing. First I feel it's IPv6:IPv4. Then I am not sure why it's n:1 but really n:m with m>=1, right? As a lot of sources can be mapped to one or more IPv4 (pool) addresses? Given the question came up on the list maybe a few words might help here as well? > +--------+ > ^ > | > Source IPv6 address (IPv6 cloud) > +--------------------------------------------------------------+ > | IPv4-Embedded IPv6 address | > | defined in Section 2.2 of RFC6052 | > +--------------------------------------------------------------+ > Destination IPv6 address > +--------------------------------------------------------------+ > | IPv4-Embedded IPv6 address | > | defined in Section 2.2 of RFC6052 | > +--------------------------------------------------------------+ > (IPv6 cloud) > ^ > | > +--------+ > | | In the case CLAT has a > | | dedicated IPv6 prefix for > | CLAT | translation, the CLAT can > | | perform with only Stateless > | | XLATE (IPv4:IPv6=1:1). So here it is addresses for a flow. Ok, let me go back. Kind of the problem reading from bottom up;-) > +--------+ > ^ Source IPv4 address > | +----------------------------+ > +--------+ | Private IPv4 address | > | IPv4 | | assigned to IPv4 client | > | client | +----------------------------+ > +--------+ Destination IPv4 address > +----------------------------+ > | Global IPv4 address | > | assigned to IPv4 server | > +----------------------------+ > > Case of enabling only stateless XLATE on CLAT > > > > > Mawatari, et al. Expires February 8, 2013 [Page 8] > > Internet-Draft 464XLAT August 2012 > > > 8.2.2. Case of enabling NAT44 and stateless XLATE on CLAT > ... > Internet-Draft 464XLAT August 2012 > > > Source IPv4 address > +----------------------------+ > | Global IPv4 address | > | assigned to IPv4 pool@PLAT | This could be spelt as "IPv4 PLAT pool" as well? > +--------+ +----------------------------+ > | IPv4 | Destination IPv4 address > | server | +----------------------------+ > +--------+ | Global IPv4 address | > ^ | assigned to IPv4 server | > | +----------------------------+ > +--------+ > | PLAT | Stateful XLATE(IPv4:IPv6=1:n) Once again, as in previous example, unlcear. > +--------+ > ^ > | > Source IPv6 address (IPv6 cloud) > +--------------------------------------------------------------+ > | IPv4-Embedded IPv6 address | > | defined in Section 2.2 of RFC6052 | > +--------------------------------------------------------------+ > Destination IPv6 address > +--------------------------------------------------------------+ > | IPv4-Embedded IPv6 address | > | defined in Section 2.2 of RFC6052 | > +--------------------------------------------------------------+ > (IPv6 cloud) > ^ > | > +--------+ > | | In the case CLAT does not have [insert] the [/insert] CLAT (I know space is tight) so feel free to ignore. > | | a dedicated IPv6 prefix for > | CLAT | translation, the CLAT can > | | perform with NAT44 and > | | Stateless XLATE > | | (IPv4:IPv6=1:1). > +--------+ > ^ Source IPv4 address > | +----------------------------+ > +--------+ | Private IPv4 address | > | IPv4 | | assigned to IPv4 client | > | client | +----------------------------+ > +--------+ Destination IPv4 address > +----------------------------+ > | Global IPv4 address | > | assigned to IPv4 server | > +----------------------------+ > > Case of enabling NAT44 and stateless XLATE on CLAT > > > > Mawatari, et al. Expires February 8, 2013 [Page 10] > > Internet-Draft 464XLAT August 2012 > > > 8.3. IPv6 Prefix Handling > > 8.3.1. Case of enabling only stateless XLATE on CLAT > > From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to > source and receive IPv6 packets associated with the stateless > translation [RFC6145]. > > The CLAT MAY discover the Pref64::/n of the PLAT via some method such > as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or > [I-D.ietf-behave-nat64-discovery-heuristic]. > > 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT > > In the case that DHCPv6-PD [RFC3633] is not available, the CLAT does s/does/may/ The CLAT could still know it through out of band configuration mechanisms. Or rather just remove the entire sentence. > not have dedicated IPv6 prefix for translation. If the CLAT does not > have a dedicated IPv6 prefix for translation, the CLAT can perform > with NAT44 and stateless translation [RFC6145]. > > Incoming source IPv4 packets from the LAN of [RFC1918] addresses are s/of [RFC1918 addresses// There is no need the LAN would be restircted to RFC1918 addresses; in theory ANY IPv4 address could work in this scenario, that is not conflicting with the single "external" NAT44 address of the CLAT. Assume that I do have a valid v4 prefix and I am switching to a backup over LTE using this technology, why would I not be able to continue to use my prefix internally with this CLAT? > NAT44 to the CLAT IPv4 host address. Then, the CLAT will do a > stateless translation [RFC6145] so that the IPv4 packets from the > CLAT IPv4 host address are translated to the CLAT WAN IPv6 address as > described in [RFC6052]. > > Its subnet prefix is made of the delegated prefix, completed if > needed to a /64 by a subnet ID = 0. Its interface ID is the 464XLAT > interface ID (Section 10). > > The CLAT MAY discover the Pref64::/n of the PLAT via some method such > as TR-069, DNS APL RR [RFC3123] or > [I-D.ietf-behave-nat64-discovery-heuristic]. > This leaves one question - which NAT44 address is the CLAT to use? It can be any really not comflictting with the PLAT pool. How does the CLAT learn that v4 address? Should there be a single IPv4 address specified for the NAT44 case? ... > 8.5. DNS Proxy Implementation > > The CLAT SHOULD implement a DNS proxy as defined in [RFC5625]. The > case of an IPv4-only node behind CLAT querying an IPv4 DNS server is ... behind [insert] the [/insert] CLAT ... > undesirable since it requires both stateful and stateless translation > for each DNS lookup. The CLAT SHOULD set itself as the DNS server > via DHCP or other means and proxy DNS queries for IPv4 and IPv6 > clients. Using the CLAT enabled home router or UE as a DNS proxy is > a normal consume gateway function and simplifies the traffic flow so consume[append] r [/append] > that only IPv6 native queries are made across the access network. > The CLAT SHOULD allow for a client to query any DNS server of its > choice and bypass the proxy. > > 8.6. CLAT in a Gateway > > The CLAT is a stateless translation feature which can be implemented > in a common home router or mobile phone that has a mobile router Careful with the term "mobile router". Maybe just "forwarding" or if it is a 3GPPP term qualify it. > feature. The router with CLAT function SHOULD provide common router > services such as DHCP of [RFC1918] addresses, DHCPv6, and DNS > service. The router SHOULD set itself as the DNS server advertised > via DHCP or other means to the clients so that it may implement the > DNS proxy function to avoid double translation of DNS request. ... of DNS request [add] s [/add] . Feels a bit repetitive given 8.5. > > 8.7. CLAT to CLAT communications > > While CLAT to CLAT IPv4 communication may work when the client IPv4 > subnets do not overlap, this traffic flow is out of scope. 464XLAT is > > > > Mawatari, et al. Expires February 8, 2013 [Page 12] > > Internet-Draft 464XLAT August 2012 > > > a hub and spoke architecture focused on enabling IPv4-only services > over IPv6-only access networks. > s/access// Here it's actually easily possible to do so. > > 9. Deployment Considerations This feels like it shoud be called "Traffic Engineering" or have a subsection titled like that. > > Even if the Internet access provider for consumers is different from The entire "access provider" once again reads strangely too specific to me but so be it for this version. > the PLAT provider (e.g. another internet access provider), it can > implement traffic engineering independently from the PLAT provider. > Detailed reasons are below: > > 1. The Internet access provider for consumers can figure out IPv4 s/consumers/end users/ maybe to make it more clear? Even the access provider is a consumer of his upstream's resources;-) > destination address from translated IPv6 packet header, so it can > implement traffic engineering based on IPv4 destination address > (e.g. traffic monitoring for each IPv4 destination address, > packet filtering for each IPv4 destination address, etc.). The > tunneling methods do not have such a advantage, without any deep .. such a [append] n [/append] advantage ... > packet inspection for processing the inner IPv4 packet of the > tunnel packet. > > 2. If the Internet access provider for consumers can assign IPv6 ... assign [insert] an [/insert] IPv6 ... > prefix greater than /64 for each subscriber, this 464XLAT s/for/to/ > architecture can separate IPv6 prefix for native IPv6 packets and s/prefix/prefixes/ > XLAT prefix for IPv4/IPv6 translation packets. Accordingly, it ... [add] the [/add] XLAT prefix ... > can identify the type of packets ("native IPv6 packets" and > "IPv4/IPv6 translation packets"), and implement traffic > engineering based on IPv6 prefix. ... on [insert] the [/insert] IPv6 ... > > This 464XLAT architecture has two capabilities. One is a IPv4 -> > IPv6 -> IPv4 translation for sharing global IPv4 addresses, another, > if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for > reaching IPv6-only servers from IPv4-only clients that can not > support IPv6. IPv4-only clients must be support through the long > period of global transition to IPv6. This does not match this section really. It feels like the abstract or introduction is repeated. > > > 10. Security Considerations > > To implement a PLAT, see security considerations presented in Section > 5 of [RFC6146]. > > To implement a CLAT, see security considerations presented in Section > 7 of [RFC6145]. The CLAT MAY comply with [RFC6092]. > > > 11. IANA Considerations > > IANA is requested to reserve a Modified EUI-64 identifier for 464XLAT > > > > Mawatari, et al. Expires February 8, 2013 [Page 13] > > Internet-Draft 464XLAT August 2012 > > > according to section 2.2.2 of [RFC5342]. Its suggested value is 02- > 00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00- > 00-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be > taken in reserved or available values. I could have missed something but where was this mentioned anywhere in the text above, and what is it good for? I see it was suggested by Remi given the Acknowledgements but the draft simply nowhere describes or requires it. Sorry, something is wrong here. ... > Internet-Draft 464XLAT August 2012 > > > Appendix A. Examples of IPv4/IPv6 Address Translation > > The following are examples of IPv4/IPv6 Address Translation on the > 464XLAT architecture. > > Example 1. (Case of enabling only stateless XLATE on CLAT) > > In the case that IPv6 prefix greater than /64 is assigned to end ... that [insert] an [/insert] IPv6 ... ... to [insert] an [/insert] end ... > users by such as DHCPv6-PD [RFC3633], only the function of Stateless > XLATE should be enabled on CLAT. Because the CLAT can use dedicated ... only the Stateless XLATE functionality should be ... maybe? ... on [insert] the [/insert] CLAT. ... > a /64 from the assigned IPv6 prefix for Stateless XLATE. [swap] dedicated / a [/swap] (... can use a dedicated /64 ...) It seems to only be half a sentence. Maybe: In the case that an IPv6 prefix greater than /64 is addigned to an end user by such as DHCPv6-PD [RFC3633], only the Stateless XLATE functionality should be enabled on the CLAT as the CLAT can use a dedicated /64 from the assigned IPv6 prefix. ... > Internet-Draft 464XLAT August 2012 > Prefiously in the draft you have used 2 boxes for src/dst IP, I like the single box better; maybe yout want to adjust the previous figures as well? > > Host & configuration value > +------------------------------+ > | IPv4 server | > | [198.51.100.1] | IP packet header > +------------------------------+ +--------------------------------+ > ^ | Source IP address | > | | [192.0.2.1] | > | | Destination IP address | > | | [198.51.100.1] | > +------------------------------+ +--------------------------------+ > | PLAT | ^ > | IPv4 pool address | | > | [192.0.2.1 - 192.0.2.100] | | > | PLAT-side XLATE IPv6 prefix | | > | [2001:db8:1234::/96] | | > +------------------------------+ +--------------------------------+ > ^ | Source IP address | > | | [2001:db8:aaaa::192.168.1.2] | > | | Destination IP address | > | | [2001:db8:1234::198.51.100.1] | > +------------------------------+ +--------------------------------+ > | CLAT | ^ > | PLAT-side XLATE IPv6 prefix | | > | [2001:db8:1234::/96] | | > | CLAT-side XLATE IPv6 prefix | | > | [2001:db8:aaaa::/96] | | > +------------------------------+ +--------------------------------+ > ^ | Source IP address | > | | [192.168.1.2] | > | | Destination IP address | > | | [198.51.100.1] | > +------------------------------+ +--------------------------------+ > | IPv4 client | > | [192.168.1.2/24] | > +------------------------------+ > Delegated IPv6 prefix for client: 2001:db8:aaaa::/56 > > > > > > Example 2. (Case of enabling NAT44 and stateless XLATE on CLAT) > > In the case that IPv6 prefix /64 is assigned to end users, the In case only a /64 IPv6 prefix is .... maybe? > function of NAT44 and Stateless XLATE should be enabled on CLAT. > Because the CLAT does not have dedicated IPv6 prefix for translation. Again only half a sentence. Rewrite the entire thing as well? > > > > > > Mawatari, et al. Expires February 8, 2013 [Page 17] > > Internet-Draft 464XLAT August 2012 > > > Host & configuration value > +-------------------------------+ > | IPv4 server | > | [198.51.100.1] | IP packet header > +-------------------------------+ +-------------------------------+ > ^ | Source IP address | > | | [192.0.2.1] | > | | Destination IP address | > | | [198.51.100.1] | > +-------------------------------+ +-------------------------------+ > | PLAT | ^ > | IPv4 pool address | | > | [192.0.2.1 - 192.0.2.100] | | > | PLAT-side XLATE IPv6 prefix | | > | [2001:db8:1234::/96] | | > +-------------------------------+ +-------------------------------+ > ^ | Source IP address | > | | [2001:db8:aaaa:200:5e10:0:0] | This is not a valid IPv6 source address. Also see question below on the local part. > | | Destination IP address | > | | [2001:db8:1234::198.51.100.1] | > +-------------------------------+ +-------------------------------+ > | CLAT Stateless XLATE function | ^ > | - - - - - - - - - - - - - - - | | > | PLAT-side XLATE IPv6 prefix | | > | [2001:db8:1234::/96] | | > | CLAT-side XLATE IPv6 prefix | | > | [2001:db8:aaaa::/64] | | > | CLAT-side XLATE IPv6 EUI-64 ID| | > | [02-00-5E-10-00-00-00-00] | | Here we go; now that's not described in the draft above, sorry. Not sure why it needs to be special? I guess the email archives would tell me, but really the draft should. Also, given I have no idea, I almost assume that a 00-00-00-00 might not be what I'd expect in ths example? > + - - - - - - - - - - - - - - - + +-------------------------------+ > | ^ | | Source IP address | > | | | | [10.255.255.1] | > | | | | Destination IP address | > | | | | [198.51.100.1] | > + - - - - - - - - - - - - - - - + +-------------------------------+ > | CLAT NAT44 function | ^ > | - - - - - - - - - - - - - - - | | > | NAT44 NATed address | | > | [10.255.255.1/32] | | > +-------------------------------+ +-------------------------------+ > ^ | Source IP address | > | | [192.168.1.2] | > | | Destination IP address | > | | [198.51.100.1] | > +-------------------------------+ +-------------------------------+ > | IPv4 client | > | [192.168.1.2/24] | > +-------------------------------+ ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From tom.taylor.stds@gmail.com Tue Aug 14 07:19:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235021F8709 for ; Tue, 14 Aug 2012 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfuGQAhDFd3e for ; Tue, 14 Aug 2012 07:19:05 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1EF21F8707 for ; Tue, 14 Aug 2012 07:18:59 -0700 (PDT) Received: by ggnh4 with SMTP id h4so568734ggn.31 for ; Tue, 14 Aug 2012 07:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=LbGWqTgx/IRxs81hEFQRmVy7kkCC0J1VitC7kZTWxK4=; b=NmK35yh5Aih6VY7cJtUi+xjhIylniHcMh3yF3X0+Mm/VOtgSdEXW/zQKPzo0UVNYs1 nkIVvBVo9NEYW+WyVaULWP2NLRm/eUop0xp8gXgmgAjahIbogMDpIR822o4N0wfGLdyz hWvEBqKGk7nObF0fg3l5BT4jQXMQs5Qm9w2jADPqm8W3fmPfV+bxmNStMYXU2x192pOO WMO1ypqB3fiII5SVLAdzznr4zoo21IqD6dutuJfkx2qbkQVbhXR1q8wsgG7Lgyc1YY6E rX3KJjMDLMXmkW219yE9yzu9GZ5dUFYtsv5C28eYHZIiqH+hJFxCZN5eX13dtoMJl67S /IsA== Received: by 10.101.63.11 with SMTP id q11mr4800564ank.34.1344953938944; Tue, 14 Aug 2012 07:18:58 -0700 (PDT) Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id l1sm5046276yhm.19.2012.08.14.07.18.57 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 07:18:58 -0700 (PDT) Message-ID: <502A5E4E.6060004@gmail.com> Date: Tue, 14 Aug 2012 10:18:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120814-0, 14/08/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:19:06 -0000 On 14/08/2012 6:34 AM, Bjoern A. Zeeb wrote: > On Thu, 9 Aug 2012, Bjoern A. Zeeb wrote: > > A few days later than hoped.... > ... >> >> Abstract >> >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in the > > ... [RFC6146] ... > >> core and stateless protocol translation RFC 6145 at the edge. 464XLAT > > ... [RFC6145] ... > >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >> > > ... > It's against the rules to put references in the Abstract as you suggest. The original text is OK here. From Donald.Smith@CenturyLink.com Tue Aug 14 08:54:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3621F8644; Tue, 14 Aug 2012 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkGzOOoH2uGX; Tue, 14 Aug 2012 08:54:02 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9E321F85AC; Tue, 14 Aug 2012 08:54:00 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q7EFruan021184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 09:53:57 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 389C91E00C7; Tue, 14 Aug 2012 09:53:47 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0F9BF1E00CC; Tue, 14 Aug 2012 09:53:47 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q7EFqZNm002689; Tue, 14 Aug 2012 10:52:35 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q7EFqYGW002675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 10:52:35 -0500 (CDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Tue, 14 Aug 2012 09:52:34 -0600 From: "Smith, Donald" To: "Eric Vyncke (evyncke)" , "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" , "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Thread-Index: Ac1zrndn+rK+MesNRpua2q1lf71ApgGSKfgwAA3PG14= Date: Tue, 14 Aug 2012 15:52:34 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D08330DD7@PDDCWMBXEX501.ctl.intranet> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com>, <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D08330DD7PDDCWMBXEX501ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Fernando Gont Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:54:04 -0000 --_000_68EFACB32CF4464298EA2779B058889D08330DD7PDDCWMBXEX501ct_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Eric Vyn= cke (evyncke) [evyncke@cisco.com] Sent: Tuesday, August 14, 2012 2:42 AM To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops v6ops WG (v6ops@i= etf.org) Cc: Fernando Gont Subject: Re: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-imp= lications-on-ipv4-nets > Fernando and Gunter, > > Sorry for belated comments... I agree with most comments from other= reviewers of course (esp Panos). I have two classes of comments: generic = and details. > > Let=92s start with generic: > - It should not be a BCP but rather informational I support as informational. > - I also wonder whether it is worth an IETF RFC because it is= well known topics in the security area (as you probably know) I think it helps to spell things like this out. So believe it is worthy of = being an IETF RFC. > - Missing point: awareness of IPV6 by CISO is the key problem= , should also add that IPv6 is not dangerous per se, and enabling IPv6 in i= ntranet is a good way to bypass all automatic tunnels Enabling IPv6 in the intranet doesn't stop the tunnels. That is the systems= that support tunnels can for the most part still do the tunneling even wit= h IPv6 enabled. > - Intro / title should specify =91end-user network=92 (to avo= id confusion for ISP) > - IP flow (netflow), firewall log, DNS request log could also= be monitored to detect tunnels establishments > - Using NAPT (and not NAT as previously commented) usually bl= ocks =91magically=92 IP protocol 41 and most tunnels > - If the security policy is to force all traffic through appl= ication proxies (done by all major organizations) then tunnels are not a th= reat I don't know many major organization that forces ALL TRAFFIC through applic= ation proxies. Most have various proxies and force http and some other well= known protocols through their proxies but nearly every network I have ever= seen had various pinholes for non-proxied traffic. > > Let=92s continue with the details: > - 1.0 please avoid all discussion about NAPT being =91minimal= /simple=92 security, the days of scanning are over and have been replaced b= y malware download/email propagated Conficker is still one of the largest infections out there. It spread prima= rily via scanning for open ports. Check netflow today and 445 is still the = most commonly seen ports in darknets and honey pots.. So scanning hasn't gone away. It is still very common. I would agree other = methods have been adopted by some but "scan and spolit" worms continue to f= lorish. Take a look a public sites such as atlas. http://atlas.arbor.net/ 2nd most popular port is 445. 4th is 139 also attributable to worms (confic= ker included). It also shows outbound teredo in the top attacks:) > - 2.0 congruent security policy indeed with the exception of = RFC 4890 (ICMPv6) > - 2.1 filtering the IPv6 ethertype is TOO dangerous (=3D coul= d break too many things) to be recommended in an IETF document > - 3.1 should refer to the RFC > - 3.3 AFAIK there is no by default implementation of 6RD in g= eneric OS and it requires either manual configuration or DHCPv4 option =3D>= remove this section > - 3.5 leave ISATAP (automatic config through DNS) but specify= that blocking 41 also blocks it > - 3.6 as noted, Teredo default port can be changed. The good = recommendation anyway for enterprises is to block outbound UDP traffic (exc= ept some pin holes for DNS of course), even my employer network blocks them= since 1997 ;-). Also, Microsoft implementation disables Teredo when person= al firewall is disabled or when the host is in an Active Directory network > - Other tunnels TSP (but also Sixxs, ...) all require explici= t installation and configuration by end-users. They are no more a thread th= an any other covert channel (being IP over DNS or over ICMP or ...), I woul= d remove this section > > Hope this helps > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: lundi 6 ao=FBt 2012 10:43 To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implica= tions-on-ipv4-nets Dear all, Can I request the WG members for 3 volunteers to read the draft draft-gont-= opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list? This will help the OPSEC chairs to identify if the work is ready for WG ado= ption or not. The work targets are within charter of the WG, and seems to b= e interesting work for the community. Questions we are looking answers for: 1) Should it be targeted BCP or Informational? 2) Is the work quality ok to be accepted as WG document? 3) Is the topic inline with the OPSEC charter? 4) Any missing or over-described points? Many thanks in advance, Kind Regards, OPSEC Chairs, (G/, KK, Warren) --_000_68EFACB32CF4464298EA2779B058889D08330DD7PDDCWMBXEX501ct_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: opsec-bounces@ietf.org [opsec-bounce= s@ietf.org] on behalf of Eric Vyncke (evyncke) [evyncke@cisco.com]
Sent: Tuesday, August 14, 2012 2:42 AM
To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops v6ops WG (= v6ops@ietf.org)
Cc: Fernando Gont
Subject: Re: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-i= pv6-implications-on-ipv4-nets

>       Fernando= and Gunter,
>
>       Sorry for belated comments... I ag= ree with most comments from other reviewers of course (esp Panos).  I = have two classes of comments: generic and details.
>
>       Let=92s start with generic:
>       -     &nb= sp; It should not be a BCP but rather informational

I support as informational.


>       -     &nb= sp; I also wonder whether it is worth an IETF RFC because it is well known = topics in the security area (as you probably know)

I think it h= elps to spell things like this out. So believe it is worthy of being an IET= F RFC.


>       -     &nb= sp; Missing point: awareness of IPV6 by CISO is the key problem, should als= o add that IPv6 is not dangerous per se, and enabling IPv6 in intranet is a= good way to bypass all automatic tunnels

Enabling IPv6 in the intranet doesn't stop the tunne= ls. That is the systems that support tunnels can for the most part still do= the tunneling even with IPv6 enabled.

 


>       -     &nb= sp; Intro / title should specify =91end-user network=92 (to avoid confusion= for ISP)
>       -     &nb= sp; IP flow (netflow), firewall log, DNS request log could also be monitore= d to detect tunnels establishments
>       -     &nb= sp; Using NAPT (and not NAT as previously commented) usually blocks =91magi= cally=92 IP protocol 41 and most tunnels
>       -     &nb= sp; If the security policy is to force all traffic through application prox= ies (done by all major organizations) then tunnels are not a threat

I don't know many major organization that forces ALL= TRAFFIC through application proxies. Most have various proxies and force h= ttp and some other well known protocols through their proxies but nearly ev= ery network I have ever seen had various pinholes for non-proxied traffic.


>
>       Let=92s continue with the details:=
>       -     &nb= sp; 1.0 please avoid all discussion about NAPT being =91minimal/simple=92 s= ecurity, the days of scanning are over and have been replaced by malware do= wnload/email propagated

Conficker is still one of the largest infections out= there. It spread primarily via scanning for open ports. Check netflow toda= y and 445 is still the most commonly seen ports in darknets and honey pots.= .

So scanning hasn't gone away. It is still very commo= n. I would agree other methods have been adopted by some but "scan and= spolit" worms continue to florish.

Take a look a public sites such as atlas.

http://atlas.arb= or.net/

 

2nd most popular port is 445. 4th is 139 also attrib= utable to worms (conficker included).

 

It also shows outbound teredo in the top attacks:)

 


>       -     &nb= sp; 2.0 congruent security policy indeed with the exception of RFC 4890 (IC= MPv6)
>       -     &nb= sp; 2.1 filtering the IPv6 ethertype is TOO dangerous (=3D could break too = many things) to be recommended in an IETF document
>       -     &nb= sp; 3.1 should refer to the RFC
>       -     &nb= sp; 3.3 AFAIK there is no by default implementation of 6RD in generic OS an= d it requires either manual configuration or DHCPv4 option =3D> remove t= his section
>       -     &nb= sp; 3.5 leave ISATAP (automatic config through DNS) but specify that blocki= ng 41 also blocks it
>       -     &nb= sp; 3.6 as noted, Teredo default port can be changed. The good recommendati= on anyway for enterprises is to block outbound UDP traffic (except some pin= holes for DNS of course), even my employer network blocks them since 1997 = ;-). Also, Microsoft implementation disables Teredo when personal firewall is disabled or when = the host is in an Active Directory network
>       -     &nb= sp; Other tunnels TSP (but also Sixxs, ...) all require explicit installati= on and configuration by end-users. They are no more a thread than any other= covert channel (being IP over DNS or over ICMP or ...), I would remove thi= s section
>
>       Hope this helps
>

 

From: opsec-bounces@ie= tf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: lundi 6 ao=FBt 2012 10:43
To: opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org)
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-= implications-on-ipv4-nets

 

Dear all,

 

Can I request the WG members fo= r 3 volunteers to read the draft draft-gont-opsec-ipv6-implications-on-ipv4= -nets and provide feedback to the list?

 

This will help the OPSEC chairs= to identify if the work is ready for WG adoption or not. The work targets = are within charter of the WG, and seems to be interesting work for the comm= unity.

 

Questions we are looking answer= s for:

 

1)   =    Should it be targeted BCP or Info= rmational?

2)   =    Is the work quality ok to be acce= pted as WG document?

3)   =    Is the topic inline with the OPSE= C charter?

4)   =    Any missing or over-described poi= nts?

 

Many thanks in advance,<= /p>

 

Kind Regards,

OPSEC Chairs,

(G/, KK, Warren)

--_000_68EFACB32CF4464298EA2779B058889D08330DD7PDDCWMBXEX501ct_-- From lee@asgard.org Tue Aug 14 11:58:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3755B21F879E for ; Tue, 14 Aug 2012 11:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNO+eK0zjtCf for ; Tue, 14 Aug 2012 11:58:40 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56C21F8792 for ; Tue, 14 Aug 2012 11:58:40 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.14.4/8.14.4) with ESMTP id q7EIwc1Z030827 for ; Tue, 14 Aug 2012 14:58:38 -0400 Authentication-Results: cm-omr7 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.163] ([204.235.115.163:34569] helo=HDC00042402) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CE/32-21064-EDF9A205; Tue, 14 Aug 2012 14:58:38 -0400 From: "Lee Howard" To: "'Eric Vyncke \(evyncke\)'" , "'Gunter Van de Velde \(gvandeve\)'" , , "'v6ops v6ops WG'" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> Date: Tue, 14 Aug 2012 14:58:37 -0400 Message-ID: <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD7A2D.494D4490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGGlPLakFxZCTrqhE95LHJwbjJ3AQK/mXl8l9F08BA= Content-Language: en-us Cc: 'Fernando Gont' Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:58:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CD7A2D.494D4490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke) Sent: Tuesday, August 14, 2012 4:43 AM To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops v6ops WG (v6ops@ietf.org) Cc: Fernando Gont Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets - 1.0 please avoid all discussion about NAPT being 'minimal/simple' security, the days of scanning are over and have been replaced by malware download/email propagated This is demonstrably false, and I can send you logs of scanning attempts foiled by NAPT. NAT is crap security, but it's not zero security. Lee ------=_NextPart_000_0020_01CD7A2D.494D4490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Eric Vyncke (evyncke)
Sent: Tuesday, August 14, 2012 4:43 = AM
To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops = v6ops WG (v6ops@ietf.org)
Cc: Fernando Gont
Subject: = Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: = draft-gont-opsec-ipv6-implications-on-ipv4-nets

 

-       = 1.0 = please avoid all discussion about NAPT being = ‘minimal/simple’ security, the days of scanning are over and = have been replaced by malware download/email = propagated

 

 

This is demonstrably false, and I can send = you logs of scanning attempts foiled by NAPT.  NAT is crap = security, but it’s not zero security.  =

 

Lee

<= /html> ------=_NextPart_000_0020_01CD7A2D.494D4490-- From warren@kumari.net Tue Aug 14 13:48:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97C21E80A1 for ; Tue, 14 Aug 2012 13:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.262 X-Spam-Level: X-Spam-Status: No, score=-106.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5gE0IE6nZXq for ; Tue, 14 Aug 2012 13:48:09 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AA80421E8085 for ; Tue, 14 Aug 2012 13:48:09 -0700 (PDT) Received: from [192.168.0.105] (66-87-85-207.pools.spcsdns.net [66.87.85.207]) by vimes.kumari.net (Postfix) with ESMTPSA id 108511B403E8; Tue, 14 Aug 2012 16:48:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 14 Aug 2012 16:48:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5028270F.3060204@bogus.com> <5029F669.5090609@bogus.com> <250BC0E2-AFC2-4B17-B2EB-4BA3FBB4F048@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1278) Cc: ops-ads@tools.ietf.org, IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 20:48:10 -0000 On Aug 14, 2012, at 5:28 AM, Tim Chown wrote: >=20 > On 14 Aug 2012, at 08:30, GangChen wrote: >>=20 >> There are less overlapped document, but there are more overlapped = people >> between V6OPS and softwire who need to be asked before the decision. >=20 >=20 > Are there not also multiple interim meetings being held after the RIPE = meeting, not just v6ops? Yes, I believe that there are... >=20 > If so, do we know what these are, and when they are scheduled? No. I know that there is a SIDR interim ("The SIDR working group plans a = face-to-face interim meeting on Sat 29 Sep 2012 in Amsterdam. The = meeting will be held 0900-1700.") and possibly an OpSec interim as well=85= > Are there clashes to be avoided? >=20 Yes, no, and / or maybe. Depends=85 :-P W > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --- Schizophrenia beats being alone. From cpignata@cisco.com Tue Aug 14 14:08:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3721F8630; Tue, 14 Aug 2012 14:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZTgI5zy2-+i; Tue, 14 Aug 2012 14:08:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 398E221F861E; Tue, 14 Aug 2012 14:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=8395; q=dns/txt; s=iport; t=1344978538; x=1346188138; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4XoNrR/vSmcCOEsvQbCFpWgLcOcYiz0Rh2MW9xu+aJ4=; b=C6ZwB61KVoTNFcc5emGlA2LewbWjB9wla/zOTj/Xy57/CqLubRCDFwXk 7+Kh6zYYRMNHZcL+ssqmQt9jEJnTBYKgkxHBQEudL+hlzd1ZAqRyUmkAZ pAYdoA1Jd+EFrCbPSA6xq1ZngsSqFqvKgvHeV1Ea2mOAzylg5733kHsvX 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFABS+KlCtJV2d/2dsb2JhbABFsVwBiEuBB4IgAQEBAwEBAQEPAVsLBQsCAQgYLicLJQEBBA4FDg0Hh2UGC5gXoGuLBYVRYAOOWoEghVGBFI0WgWaCXw X-IronPort-AV: E=Sophos;i="4.77,769,1336348800"; d="asc'?scan'208,217";a="111615365" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2012 21:08:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7EL8vRX008199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 21:08:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 16:08:57 -0500 From: "Carlos Pignataro (cpignata)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAarsawA= Date: Tue, 14 Aug 2012 21:08:56 +0000 Message-ID: <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> In-Reply-To: <501F8D5F.5000805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.81.8.2] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.001 x-tm-as-result: No--37.489300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_D2B117C1-4AC3-4D54-BD4B-52CA24B79CEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" , "opsec-chairs@ietf.org" , "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:08:59 -0000 --Apple-Mail=_D2B117C1-4AC3-4D54-BD4B-52CA24B79CEC Content-Type: multipart/alternative; boundary="Apple-Mail=_5D9BD657-EF4B-46A5-A340-B78EFC131FB5" --Apple-Mail=_5D9BD657-EF4B-46A5-A340-B78EFC131FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, Brian, Should "The Suggested Approach" = http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1 also = include some prescriptiveness or specific recommendation regarding the = use of RFC 5837, instead of including that solution to interface = identification as a "Caveats and Possible Workarounds" only? Thanks, -- Carlos. On Aug 6, 2012, at 5:24 AM, Brian E Carpenter wrote: > Hi, >=20 >> o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo >> request ... can be addressed to loopback addresses of routers = with >> a global scope address. Router management can also be done over >> out-of-band channels. >>=20 >> o ICMP error message can also be sourced from the global scope >> loopback address. >=20 > These statements seem too weak. Using GUAs for ICMP in particular > needs to have a normative MUST somewhere (preferably in a BCP). In the > context of this Informational draft, the language needs to state a = requirement > ("must" not "can") even if you don't use RFC 2119 terminology. >=20 > This matters because packets with a LL source address MUST NOT be = forwarded, > so a router that is misconfigured to send ICMP replies with a LL = source > address breaks both ping and traceroute. >=20 > I think the rule is that any packet that is *not* sent to a LL address = must > have a GUA as the source address. That takes care of ICMP, and = everything else > as well. >=20 > Furthermore, that GUA needs to be associated with a prefix that = belongs to > the organisation operating the router in question. Otherwise the = traceroute > results can be very confusing. We discussed that on v6ops back in = March. >=20 > Regards > Brian Carpenter >=20 >=20 >=20 >=20 > On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: >> (distributed to OPSEC WG and in cc v6ops) >>=20 >> Dear all, >>=20 >> During the OPSEC WG meeting last Wednesday there was consensus to = adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 = as working group document with Informational status. >>=20 >> Please read the draft, and if there is no violent objection on the = list, the document will be requested to be submitted as WG document in 7 = days. >>=20 >> Ciao, >> G/, KK & Warren >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_5D9BD657-EF4B-46A5-A340-B78EFC131FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1&n= bsp;also include some prescriptiveness or specific recommendation = regarding the use of RFC 5837, instead of including that solution to = interface identification as a "Caveats and Possible Workarounds" = only?

Thanks,

-- = Carlos.

On Aug 6, 2012, at 5:24 AM, Brian E = Carpenter wrote:

Hi,

  o =  Management plane traffic, such as SSH, Telnet, SNMP, ICMP = echo
=      request ... can be addressed to loopback = addresses of routers with
=      a global scope address.  Router = management can also be done over
     out-of-band = channels.

  o =  ICMP error message can also be sourced from the global = scope
=      loopback = address.

These statements seem too weak. Using GUAs = for ICMP in particular
needs to have a normative MUST somewhere = (preferably in a BCP). In the
context of this Informational draft, = the language needs to state a requirement
("must" not "can") even if = you don't use RFC 2119 terminology.

This matters because packets = with a LL source address MUST NOT be forwarded,
so a router that is = misconfigured to send ICMP replies with a LL source
address breaks = both ping and traceroute.

I think the rule is that any packet = that is *not* sent to a LL address must
have a GUA as the source = address. That takes care of ICMP, and everything else
as = well.

Furthermore, that GUA needs to be associated with a prefix = that belongs to
the organisation operating the router in question. = Otherwise the traceroute
results can be very confusing. We discussed = that on v6ops back in March.

Regards
  Brian = Carpenter




On 06/08/2012 10:03, Gunter Van de Velde = (gvandeve) wrote:
(distributed to OPSEC WG = and in cc v6ops)

Dear = all,

During the = OPSEC WG meeting last Wednesday there was consensus to adopt the draft = http://too= ls.ietf.org/html/draft-behringer-lla-only-01 as working group = document with Informational status.

Please read the = draft, and if there is no violent objection on the list, the document = will be requested to be submitted as WG document in 7 = days.

Ciao,
G/, KK = & Warren



------------------------------------------------------------= ------------

_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops
_______________________________= ________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops


= --Apple-Mail=_5D9BD657-EF4B-46A5-A340-B78EFC131FB5-- --Apple-Mail=_D2B117C1-4AC3-4D54-BD4B-52CA24B79CEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAlAqvmgACgkQtfDPGTp3USzTowCcC8PfguDU5gRCgYJOJmn5VbKx lNEAnRtYq9qzsHwi7K/Ae3rakte0UCSl =20r1 -----END PGP SIGNATURE----- --Apple-Mail=_D2B117C1-4AC3-4D54-BD4B-52CA24B79CEC-- From tjc@ecs.soton.ac.uk Tue Aug 14 14:21:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E8021F8733 for ; Tue, 14 Aug 2012 14:21:54 -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=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y88aKWQB04yf for ; Tue, 14 Aug 2012 14:21:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 032CA21F872D for ; Tue, 14 Aug 2012 14:21:52 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7ELLkZ5032097; Tue, 14 Aug 2012 22:21:46 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q7ELLkZ5032097 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1344979307; bh=goXUk803PZDZI4sj4snyVKeVwII=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=NRsCB62JDne6s49PSdEtukqLvMgBxOS7jGyozakkN4Bq+fjtjpIbgovDVpCG2davV HjYb67mh2N69UkhLs6WWPyyThJT4sPZDqiWpBGeRA9UaRwMhFpS6DEyU0gTtmDIlVG 8T96Od83PjFzX0SNvbSxRfGvSQTfPggH6W1yyePM= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o7DMLk04306507128U ret-id none; Tue, 14 Aug 2012 22:21:47 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q7ELLdEW018988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Aug 2012 22:21:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Tim Chown In-Reply-To: Date: Tue, 14 Aug 2012 22:21:43 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5028270F.3060204@bogus.com> <5029F669.5090609@bogus.com> <250BC0E2-AFC2-4B17-B2EB-4BA3FBB4F048@ecs.soton.ac.uk> <358AB3A5-4055-4B2D-93EF-A4CB3317774F@ecs.soton.ac.uk> To: Warren Kumari X-Mailer: Apple Mail (2.1485) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o7DMLk043065071200; tid=o7DMLk04306507128U; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q7ELLkZ5032097 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Ops WG , V6ops Chairs , ops-ads@tools.ietf.org Subject: Re: [v6ops] V6ops interim meeting announcement Sept 29th 2012. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:21:54 -0000 On 14 Aug 2012, at 21:48, Warren Kumari wrote: > On Aug 14, 2012, at 5:28 AM, Tim Chown wrote: >=20 >> On 14 Aug 2012, at 08:30, GangChen wrote: >>>=20 >>> There are less overlapped document, but there are more overlapped = people >>> between V6OPS and softwire who need to be asked before the decision. >>=20 >> Are there not also multiple interim meetings being held after the = RIPE meeting, not just v6ops? >=20 > Yes, I believe that there are... Thanks for the confirmation - I've prodded the WG chair mail list. Tim= From bzeeb-lists@lists.zabbadoz.net Tue Aug 14 14:30:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54BF21F865E for ; Tue, 14 Aug 2012 14:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fs-3ltojR3i for ; Tue, 14 Aug 2012 14:30:48 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 30A7121F861A for ; Tue, 14 Aug 2012 14:30:48 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 76B7625D39FD; Tue, 14 Aug 2012 21:30:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9C384BE858A; Tue, 14 Aug 2012 21:30:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id nQ6-cZjeaGfA; Tue, 14 Aug 2012 21:30:44 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 14013BE8589; Tue, 14 Aug 2012 21:30:43 +0000 (UTC) Date: Tue, 14 Aug 2012 21:30:43 +0000 (UTC) From: "Bjoern A. Zeeb" To: Tom Taylor In-Reply-To: <502A5E4E.6060004@gmail.com> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:30:48 -0000 On Tue, 14 Aug 2012, Tom Taylor wrote: > > > On 14/08/2012 6:34 AM, Bjoern A. Zeeb wrote: >> On Thu, 9 Aug 2012, Bjoern A. Zeeb wrote: >> >> A few days later than hoped.... >> > ... > >>> >>> Abstract >>> >>> This document describes an architecture (464XLAT) for providing >>> limited IPv4 connectivity across an IPv6-only network by combining >>> existing and well-known stateful protocol translation RFC 6146 in the >> >> ... [RFC6146] ... >> >>> core and stateless protocol translation RFC 6145 at the edge. 464XLAT >> >> ... [RFC6145] ... >> >>> is a simple and scalable technique to quickly deploy limited IPv4 >>> access service to IPv6-only edge networks without encapsulation. >>> >> >> ... >> > > It's against the rules to put references in the Abstract as you suggest. The > original text is OK here. Indeed .. unless they are completly defined within the abstract, which is not the case here and indeed the least I am worried about. I am still trying to find the EUI stuff in the archives, which is a PITA. In case someone has the reference (or link) I'd be happy. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From lorenzo@google.com Tue Aug 14 17:36:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0021E80D2 for ; Tue, 14 Aug 2012 17:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTHvzvUBztDe for ; Tue, 14 Aug 2012 17:36:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12B0921E80CD for ; Tue, 14 Aug 2012 17:36:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1474865obb.31 for ; Tue, 14 Aug 2012 17:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=zzlXIhEMqPZ3Zyu/iVTV7vnDjsXyRcd5Pvb/slEHv64=; b=mHMhhOOorZTwCa0SNe+y2IglmbWuK+ZxP6veHL1josder1PfXd+0W5Qruo6OsSL/71 eqdb1p03KGAPlCR9EiXACp//ZYQCnojezB66T/3u8jCSsuxqJ5y6thZn4KgMfGUhkydM QpI/i4ofMy6PwXckKakvuoiCFO6x3s1Ij5iRIbSGvILv5CH2iQ7P9GhIv2AaERdx444L gPmIoO+LhrFhTDfAYDOHfcCyXxYYTDF4T4alajd7dwuBP0G30y5ltsa9tRYrw46SsxyP i3u7Nf50eyn2YJbPZ754ptdEuE3z8E5s4veYcmWtjVf6YoLJXtQ9rortoSNGZ6hQmvKO TpOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=zzlXIhEMqPZ3Zyu/iVTV7vnDjsXyRcd5Pvb/slEHv64=; b=O7zbDt1Na0CaIq0REpRlUoPsw4L9Mrm4DVbaPAZRR192Xqzo+lcKKrA9/noRfjIndC +mJbZL5mSId5AP8QH6Rbr29KjkeupL8OLo9v6bUM6AZRYVKA58Zy60+iXYhn6gtJKAXI Z2NYmg4VLAoPxUfqa+R1jaCPQjpq3/ijR4pLb3rn4ktS4xIxNTAgK22K4qd/lIfOb1Dd qB/A0XysrOx2edXD1aCKdGf/MuFuB7yabxByelXZRGdPXqtl6tyKB0+PyM0xcZwLw79G CgUSQrq8SVsg8sYjUrp32OL6TekUApwo83bCdWN5cHknzk43CMXZ7SXCFmv1be9pQAn4 OUqA== Received: by 10.60.28.202 with SMTP id d10mr5091oeh.36.1344990976544; Tue, 14 Aug 2012 17:36:16 -0700 (PDT) Received: by 10.60.28.202 with SMTP id d10mr5077oeh.36.1344990976261; Tue, 14 Aug 2012 17:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 14 Aug 2012 17:35:56 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> From: Lorenzo Colitti Date: Wed, 15 Aug 2012 09:35:56 +0900 Message-ID: To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=e89a8fb206185dbef804c7431d41 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmNCaibeRbsLMb0xyLPgxSqsUWNc1B0EqdGewwVpuiNggVxSVGLNe6m7akJ84vXXsBDXANM3x8cV3CbgD7LZbBpJNnmEnMv8l/TcfIarr+0PQXLasMFytq+CqQWanxV+Oo6ObX9Ra3CL8V62mH0j+Q6oX3mfx6EW5GACDGzKhEY10h6678VE7MFg2B4uNtO5EQpStIE Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 00:36:17 -0000 --e89a8fb206185dbef804c7431d41 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 14, 2012 at 7:34 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > 11. IANA Considerations >> >> IANA is requested to reserve a Modified EUI-64 identifier for 464XLAT >> according to section 2.2.2 of [RFC5342]. Its suggested value is 02- >> 00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00- >> 00-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be >> taken in reserved or available values. >> > > > I could have missed something but where was this mentioned anywhere in > the text above, and what is it good for? I see it was suggested by Remi > given the Acknowledgements but the draft simply nowhere describes or > requires it. Sorry, something is wrong here. > +1. It's not clear to me why we need a special interface ID at all. --e89a8fb206185dbef804c7431d41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 14, 2012 at 7:34 PM, Bjoern A. Zeeb = <bzeeb-lists@lists.zabbadoz.net> wrote:
11. =A0IANA Considerations

=A0 =A0IANA is requested to reserve a Modified EUI-64 identifier for 464XLA= T
=A0 =A0according to section 2.2.2 of [RFC5342]. =A0Its suggested value= is 02-
=A0 =A000-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00= -
=A0 =A000-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be<= br> =A0 =A0taken in reserved or available values.


I could have missed something but where was this mentioned anywhere in the= =A0text above, and what is it good for? =A0I see it was suggested by Remi g= iven=A0the Acknowledgements but the draft simply nowhere describes or requi= res it.=A0Sorry, something is wrong here.

+1. It's not clear to me why we need a= special interface ID at all.
--e89a8fb206185dbef804c7431d41-- From cb.list6@gmail.com Tue Aug 14 17:43:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF721E80D2 for ; Tue, 14 Aug 2012 17:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVWKobtM8GG4 for ; Tue, 14 Aug 2012 17:43:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46FFA21E80CD for ; Tue, 14 Aug 2012 17:43:51 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so605231lbb.31 for ; Tue, 14 Aug 2012 17:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rm4eFrlTBt9bs4MfBC6pUfa6E29JLml1JAPpZnzOyss=; b=R+nPVk3mKp2FCMqsV++1lsR8GGzSwDVxcB2tVpM5aK0WJYV0xCqTmeftQE3PG55YAB m61QWcuyVDgdsgdnNptmg0Nzt4NcsgP/XG/do0llFSMY5y/qgjfHAOm8Wtc0tEEDkhCZ 6jqxS8NqbOoblHRb4qnm0nFWpjRfnnkbMd26PwkVys11eU46eb2q6/9N1QeXYB0NpOQf 5aFQUd23wf4KltDZz5OnHGLys1cTE2aGp7klPADQpskrOBPe65P9s7l1rSbYsZe1HiRp QNyNseMK7NpF+tmIioVjLN7VfAVDsw1fGiLIFT+7Pob1upeam7GOOJRZElCeT/UapEbJ SqFw== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr14079952lab.19.1344991430209; Tue, 14 Aug 2012 17:43:50 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Tue, 14 Aug 2012 17:43:49 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Tue, 14 Aug 2012 17:43:49 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Tue, 14 Aug 2012 17:43:49 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d0435be6e6c6f8a04c74338e2 Cc: "Bjoern A. Zeeb" , v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 00:43:52 -0000 --f46d0435be6e6c6f8a04c74338e2 Content-Type: text/plain; charset=ISO-8859-1 On Aug 14, 2012 5:36 PM, "Lorenzo Colitti" wrote: > > On Tue, Aug 14, 2012 at 7:34 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: >>> >>> 11. IANA Considerations >>> >>> IANA is requested to reserve a Modified EUI-64 identifier for 464XLAT >>> according to section 2.2.2 of [RFC5342]. Its suggested value is 02- >>> 00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00- >>> 00-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be >>> taken in reserved or available values. >> >> >> >> I could have missed something but where was this mentioned anywhere in the text above, and what is it good for? I see it was suggested by Remi given the Acknowledgements but the draft simply nowhere describes or requires it. Sorry, something is wrong here. > > > +1. It's not clear to me why we need a special interface ID at all. > > Here is a link to the discussion http://www.ietf.org/mail-archive/web/v6ops/current/msg12880.html The Android code Lorenzo is reviewing at the moment includes this afaik CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d0435be6e6c6f8a04c74338e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 14, 2012 5:36 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Tue, Aug 14, 2012 at 7:34 PM, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrot= e:
>>>
>>> 11. =A0IANA Considerations
>>>
>>> =A0 =A0IANA is requested to reserve a Modified EUI-64 identifi= er for 464XLAT
>>> =A0 =A0according to section 2.2.2 of [RFC5342]. =A0Its suggest= ed value is 02-
>>> =A0 =A000-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-0= 0-5E-10-00-00-
>>> =A0 =A000-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether = it should be
>>> =A0 =A0taken in reserved or available values.
>>
>>
>>
>> I could have missed something but where was this mentioned anywher= e in the=A0text above, and what is it good for? =A0I see it was suggested b= y Remi given=A0the Acknowledgements but the draft simply nowhere describes = or requires it.=A0Sorry, something is wrong here.
>
>
> +1. It's not clear to me why we need a special interface ID at all= .
>
>

Here is a link to the discussion

http://www.ietf.org/mail-archive/web/v6ops/current/msg12880.html

The Android code Lorenzo is reviewing at the moment includes this afaik<= /p>

CB _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--f46d0435be6e6c6f8a04c74338e2-- From fgont@si6networks.com Tue Aug 14 18:14:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772C321F870A; Tue, 14 Aug 2012 18:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE9LWfZYm1us; Tue, 14 Aug 2012 18:14:19 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF921F8702; Tue, 14 Aug 2012 18:14:19 -0700 (PDT) Received: from [186.134.26.60] (helo=[192.168.123.104]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T1SBa-0008Ud-FF; Wed, 15 Aug 2012 03:14:15 +0200 Message-ID: <502AEB54.8050904@si6networks.com> Date: Tue, 14 Aug 2012 21:20:36 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 01:14:20 -0000 Hi, Eric, Thanks so much for your feedback! -- Please find my comments in-line... On 08/14/2012 05:42 AM, Eric Vyncke (evyncke) wrote: [...] > Let’s start with generic: > > - It should not be a BCP but rather informational Just curious: what's the rationale for your preference? > - I also wonder whether it is worth an IETF RFC because it is well > known topics in the security area (as you probably know) I disagree with both points, for a number of reasons: * An IETF RFC means IETF consensus on a topic. That doesn't necessarily mean that the information is new, but rather than that's how the IETF thinks about the problem. * There has been quite some talk about the implications of transition technologies, and recommendations to "block them"... but concrete advice on how to filter each of these technologies is not always readily available. Try Google. * I generally disagree about "well known topics in the security area" (unless you clearly define what you mean by "known" and what you mean by "security area"). Most of the time I've seen any topic deemed as "well-known" in the security community, it really wasn't. And when it comes to IPv6 security in particular. there has been so much crap around it that I'd probably deem "well known IPv6 security topic" as an oxymoron. :-) > - Missing point: awareness of IPV6 by CISO is the key problem, I don't necessarily disagree, but that kind of aspect seems to be out of the scope of this particular document. > should also add that IPv6 is not dangerous per se, and enabling IPv6 in > intranet is a good way to bypass all automatic tunnels The focus of this document is how IPv6 affects your "IPv4-only" network. If you explicitly enable IPv6, then this document does not apply to your network. -- Not to mention that lots of devices are not IPv6-capable, which means that it shouldn't come up as a surprise if an admin cannot enforce enforce on v6 the same policies he enforces on v4. > - Intro / title should specify ‘end-user network’ (to avoid > confusion for ISP) Do we really need/want to make a difference, here? -- The generic issues being discussed in this document apply to any network that has "dormant IPv6 connectivity". > - IP flow (netflow), firewall log, DNS request log could also be > monitored to detect tunnels establishments Could you please elaborate a bit? > - Using NAPT (and not NAT as previously commented) usually blocks > ‘magically’ IP protocol 41 and most tunnels Agreed. I will add a note about this. > - If the security policy is to force all traffic through > application proxies (done by all major organizations) then tunnels are > not a threat Should I add any comments about this? If so, where? > Let’s continue with the details: > > - 1.0 please avoid all discussion about NAPT being > ‘minimal/simple’ security, the days of scanning are over and have been > replaced by malware download/email propagated ... yet we still use firewalls. Clearly, a NAT-PT blocks some attack vectors, and reduces host exposure. And technologies such as Teredo essentially eliminate any sort of protection that could be achieved by such NAT-PT. And they do block some attacks -- not "all" or "most", but they do block some. > - 2.0 congruent security policy indeed with the exception of RFC > 4890 (ICMPv6) I'd argue that the policy is still the same -- it's just that there are additional message types in v6 /which are not present in v4). It's quite unfortunate to hear in v6 circles things like "in v6, you cannot filter all ICMP as you do in v4" -- because even in v4 you couldn't do this without braking PMTUD. > - 2.1 filtering the IPv6 ethertype is TOO dangerous (= could break > too many things) to be recommended in an IETF document Filtering EtherType 0x86DD does what it is meant to do: block native IPv6 traffic. Note that we are not recommending that people do it, and even less to have products ship with that filter "on by default" -- we just note that if you want to prevent block native IPv6 traffic, that's one possible way to do so. > - 3.1 should refer to the RFC Done! > - 3.3 AFAIK there is no by default implementation of 6RD in > generic OS and it requires either manual configuration or DHCPv4 option > => remove this section I'd probably argue that we should argue the comment on DHCPv4 possibly enabling 6rd, rather than removing the whole section -- for instance, an attacker could exploit such vector. That aside, removing the entire section would likely trigger feedback of the form "hey guys, you forgot to describe 6rd!". > - 3.5 leave ISATAP (automatic config through DNS) but specify that > blocking 41 also blocks it The current text already notes that. > - 3.6 as noted, Teredo default port can be changed. The good > recommendation anyway for enterprises is to block outbound UDP traffic > (except some pin holes for DNS of course), even my employer network > blocks them since 1997 ;-). This is going beyond the type of advice this document is meant to provide. We want to provide advice on how to block Teredo... rather than recommend to filter all UDP. > Also, Microsoft implementation disables > Teredo when personal firewall is disabled or when the host is in an > Active Directory network That still leaves Windows systems with a firewall and no Active Directory network with Teredo "on by default". > - Other tunnels TSP (but also Sixxs, ...) all require explicit > installation and configuration by end-users. They are no more a thread > than any other covert channel (being IP over DNS or over ICMP or ...), I > would remove this section TSP could allow incoming connections to the local network, which is something quite different from an internal node being able to "send stuff out on top of DNS or ICMP". Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From phdgang@gmail.com Tue Aug 14 21:16:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D621E8084 for ; Tue, 14 Aug 2012 21:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJgvASBUNEeI for ; Tue, 14 Aug 2012 21:16:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6113A21E805E for ; Tue, 14 Aug 2012 21:16:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1296362vcb.31 for ; Tue, 14 Aug 2012 21:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fdcayZX+WHvmsvgiKjnISIcae5O+8T0WaF3QXiEiqw0=; b=BebbyBkFCZRez32PDO225OB2QENCWrc1QirPooIslzc2FCldxOGz9N917K4yrGGKmr Hwy3qvup/H1YaKpw1YrJRibgNn841qwL6Si5qAe2wfVenQKNrS/xdCJIdq/serOv7QTP V5WSDq2oksVMjh8ac0jaUIQug/9nSmYIiuwV9Q/f7n2d4T00XapCocUNcH/dHSolExZ8 JP18i1cDOtw7zmjWBvcDBA+GTvNtWQiX31bGoofJqGhskJkcaWAGkqQP067nVxdJmcJX b3Ecx3Rws/VVBozBIJMwWe0DFVBSNH/ZA3oHJtiEazL38lNpVobmkULWL7dnRCIfoFpw Bjzw== MIME-Version: 1.0 Received: by 10.52.24.227 with SMTP id x3mr1254932vdf.68.1345004165780; Tue, 14 Aug 2012 21:16:05 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Tue, 14 Aug 2012 21:16:05 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> Date: Wed, 15 Aug 2012 12:16:05 +0800 Message-ID: From: GangChen To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG , V6ops Chairs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 04:16:11 -0000 2012/8/14, Bjoern A. Zeeb : > > >> >> Source IPv4 address >> +----------------------------+ >> | Global IPv4 address | >> | assigned to IPv4 pool@PLAT | > > This could be spelt as "IPv4 PLAT pool" as well? > >> +--------+ +----------------------------+ >> | IPv4 | Destination IPv4 address >> | server | +----------------------------+ >> +--------+ | Global IPv4 address | >> ^ | assigned to IPv4 server | >> | +----------------------------+ >> +--------+ >> | PLAT | Stateful XLATE(IPv4:IPv6=1:n) > > I feel the 1:n is confusing. First I feel it's IPv6:IPv4. Then I am not > sure > why it's n:1 but really n:m with m>=1, right? As a lot of sources can be > mapped to one or more IPv4 (pool) addresses? Given the question came up > on the list maybe a few words might help here as well? 1:n is just a symbol of "IP Address Sharing" I guess > >> +--------+ >> ^ >> | >> Source IPv6 address (IPv6 cloud) >> +--------------------------------------------------------------+ >> | IPv4-Embedded IPv6 address | >> | defined in Section 2.2 of RFC6052 | >> +--------------------------------------------------------------+ >> Destination IPv6 address >> +--------------------------------------------------------------+ >> | IPv4-Embedded IPv6 address | >> | defined in Section 2.2 of RFC6052 | >> +--------------------------------------------------------------+ >> (IPv6 cloud) >> ^ >> | >> +--------+ >> | | In the case CLAT has a >> | | dedicated IPv6 prefix for >> | CLAT | translation, the CLAT can >> | | perform with only Stateless >> | | XLATE (IPv4:IPv6=1:1). > >> >> 8.3. IPv6 Prefix Handling >> >> 8.3.1. Case of enabling only stateless XLATE on CLAT >> >> From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to >> source and receive IPv6 packets associated with the stateless >> translation [RFC6145]. >> >> The CLAT MAY discover the Pref64::/n of the PLAT via some method such >> as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or >> [I-D.ietf-behave-nat64-discovery-heuristic]. >> >> 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT >> >> In the case that DHCPv6-PD [RFC3633] is not available, the CLAT does > > s/does/may/ The CLAT could still know it through out of band configuration > mechanisms. Or rather just remove the entire sentence. Is there any practice to delegate IPv6 prefix through out-band approach? >> not have dedicated IPv6 prefix for translation. If the CLAT does not >> have a dedicated IPv6 prefix for translation, the CLAT can perform >> with NAT44 and stateless translation [RFC6145]. >> >> Incoming source IPv4 packets from the LAN of [RFC1918] addresses are > > s/of [RFC1918 addresses// > > There is no need the LAN would be restircted to RFC1918 addresses; in > theory > ANY IPv4 address could work in this scenario, that is not conflicting with > the > single "external" NAT44 address of the CLAT. Assume that I do have a valid > v4 prefix and I am switching to a backup over LTE using this technology, > why > would I not be able to continue to use my prefix internally with this CLAT? I guess RFC1631 could answer your question. FWIW, ".... NAT44[RFC1631] ...." >> NAT44 to the CLAT IPv4 host address. Then, the CLAT will do a >> stateless translation [RFC6145] so that the IPv4 packets from the >> CLAT IPv4 host address are translated to the CLAT WAN IPv6 address as >> described in [RFC6052]. >> >> Its subnet prefix is made of the delegated prefix, completed if >> needed to a /64 by a subnet ID = 0. Its interface ID is the 464XLAT >> interface ID (Section 10). >> >> The CLAT MAY discover the Pref64::/n of the PLAT via some method such >> as TR-069, DNS APL RR [RFC3123] or >> [I-D.ietf-behave-nat64-discovery-heuristic]. >> > > This leaves one question - which NAT44 address is the CLAT to use? It can > be any really not comflictting with the PLAT pool. How does the CLAT learn > that v4 address? Should there be a single IPv4 address specified for the > NAT44 case? Which address to be used on NAT44 really doesn't matter imho so long as external IPv4 address doesn't conflict with internal address on NAT44. Such IPv4 address is only of meaning within CLAT. PLAT would treat incoming data as an normal IPv6 package and do translation depending on BIB/STE > > ... > >> 9. Deployment Considerations > > This feels like it shoud be called "Traffic Engineering" or have a > subsection > titled like that. (*) Indeed. My comments to section 9: It may be worth to restructure section a bit. the paragraph 1/2/3 match title of "Traffic Engineering" . the paragraph 4 match title of "Traffic Treatment Scenarios", which is name of section 8.4 I feel two approaches can try 1# 9 Deployment Considerations 9.1 Traffic Engineering .... 9.2 Traffic Treatment Scenarios .... or 2# shift last paragraph to section 8.4 BTW, I'm a little bit hard to decode the last raw in the table of section 8.4 Aligning with the statement of " This 464XLAT architecture has two capabilities. One is a IPv4 -> IPv6 -> IPv4 translation for sharing global IPv4 addresses, another, if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for reaching IPv6-only servers from IPv4-only clients that can not support IPv6. IPv4-only clients must be support through the long period of global transition to IPv6." It should be +--------+-------------+-----------------------+-------------+ | IPv6 | IPv4 | Statefull Translation | CLAT | +--------+-------------+-----------------------+-------------+ Did I miss something? > >> >> Even if the Internet access provider for consumers is different from > > The entire "access provider" once again reads strangely too specific to me > but so be it for this version. > > >> the PLAT provider (e.g. another internet access provider), it can >> implement traffic engineering independently from the PLAT provider. >> Detailed reasons are below: >> >> 1. The Internet access provider for consumers can figure out IPv4 > > s/consumers/end users/ maybe to make it more clear? Even the access > provider > is a consumer of his upstream's resources;-) > > >> destination address from translated IPv6 packet header, so it can >> implement traffic engineering based on IPv4 destination address >> (e.g. traffic monitoring for each IPv4 destination address, >> packet filtering for each IPv4 destination address, etc.). The >> tunneling methods do not have such a advantage, without any deep > > .. such a [append] n [/append] advantage ... > >> packet inspection for processing the inner IPv4 packet of the >> tunnel packet. >> >> 2. If the Internet access provider for consumers can assign IPv6 > > ... assign [insert] an [/insert] IPv6 ... > >> prefix greater than /64 for each subscriber, this 464XLAT > > s/for/to/ > >> architecture can separate IPv6 prefix for native IPv6 packets and > > s/prefix/prefixes/ > >> XLAT prefix for IPv4/IPv6 translation packets. Accordingly, it > > ... [add] the [/add] XLAT prefix ... > >> can identify the type of packets ("native IPv6 packets" and >> "IPv4/IPv6 translation packets"), and implement traffic >> engineering based on IPv6 prefix. > > ... on [insert] the [/insert] IPv6 ... > > >> >> This 464XLAT architecture has two capabilities. One is a IPv4 -> >> IPv6 -> IPv4 translation for sharing global IPv4 addresses, another, >> if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for >> reaching IPv6-only servers from IPv4-only clients that can not >> support IPv6. IPv4-only clients must be support through the long >> period of global transition to IPv6. > > This does not match this section really. It feels like the abstract > or introduction is repeated. > I feel the texts match section 8.4. =>See above (*) >> >> >> 10. Security Considerations >> >> To implement a PLAT, see security considerations presented in Section >> 5 of [RFC6146]. >> >> To implement a CLAT, see security considerations presented in Section >> 7 of [RFC6145]. The CLAT MAY comply with [RFC6092]. >> >> >> 11. IANA Considerations >> >> IANA is requested to reserve a Modified EUI-64 identifier for 464XLAT >> >> >> >> Mawatari, et al. Expires February 8, 2013 [Page 13] >> >> Internet-Draft 464XLAT August 2012 >> >> >> according to section 2.2.2 of [RFC5342]. Its suggested value is 02- >> 00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00- >> 00-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be >> taken in reserved or available values. > > > I could have missed something but where was this mentioned anywhere in the > text above, and what is it good for? I see it was suggested by Remi given > the Acknowledgements but the draft simply nowhere describes or requires it. > Sorry, something is wrong here. Modified EUI-64 ID is used only in the case of 8.2.2 as Cameron pointed the discussion http://www.ietf.org/mail-archive/web/v6ops/current/msg12880.html. One point to add is CLAT would do ND-proxy[RFC4389] implementing the v6 tethering, which is also mentioned at section 5.3 RFC6459 afaik. > > ... > >> Internet-Draft 464XLAT August 2012 >> >> >> Appendix A. Examples of IPv4/IPv6 Address Translation >> >> The following are examples of IPv4/IPv6 Address Translation on the >> 464XLAT architecture. >> >> Example 1. (Case of enabling only stateless XLATE on CLAT) >> >> In the case that IPv6 prefix greater than /64 is assigned to end > > ... that [insert] an [/insert] IPv6 ... > ... to [insert] an [/insert] end ... > >> users by such as DHCPv6-PD [RFC3633], only the function of Stateless >> XLATE should be enabled on CLAT. Because the CLAT can use dedicated > > ... only the Stateless XLATE functionality should be ... maybe? > > ... on [insert] the [/insert] CLAT. ... > >> a /64 from the assigned IPv6 prefix for Stateless XLATE. > > [swap] dedicated / a [/swap] (... can use a dedicated /64 ...) > > It seems to only be half a sentence. Maybe: > > In the case that an IPv6 prefix greater than /64 is addigned to an end user > by such as DHCPv6-PD [RFC3633], only the Stateless XLATE functionality > should > be enabled on the CLAT as the CLAT can use a dedicated /64 from the > assigned > IPv6 prefix. > > ... > >> Internet-Draft 464XLAT August 2012 >> > > Prefiously in the draft you have used 2 boxes for src/dst IP, I like the > single > box better; maybe yout want to adjust the previous figures as well? > > >> >> Host & configuration value >> +------------------------------+ >> | IPv4 server | >> | [198.51.100.1] | IP packet header >> +------------------------------+ +--------------------------------+ >> ^ | Source IP address | >> | | [192.0.2.1] | >> | | Destination IP address | >> | | [198.51.100.1] | >> +------------------------------+ +--------------------------------+ >> | PLAT | ^ >> | IPv4 pool address | | >> | [192.0.2.1 - 192.0.2.100] | | >> | PLAT-side XLATE IPv6 prefix | | >> | [2001:db8:1234::/96] | | >> +------------------------------+ +--------------------------------+ >> ^ | Source IP address | >> | | [2001:db8:aaaa::192.168.1.2] | >> | | Destination IP address | >> | | [2001:db8:1234::198.51.100.1] | >> +------------------------------+ +--------------------------------+ >> | CLAT | ^ >> | PLAT-side XLATE IPv6 prefix | | >> | [2001:db8:1234::/96] | | >> | CLAT-side XLATE IPv6 prefix | | >> | [2001:db8:aaaa::/96] | | >> +------------------------------+ +--------------------------------+ >> ^ | Source IP address | >> | | [192.168.1.2] | >> | | Destination IP address | >> | | [198.51.100.1] | >> +------------------------------+ +--------------------------------+ >> | IPv4 client | >> | [192.168.1.2/24] | >> +------------------------------+ >> Delegated IPv6 prefix for client: 2001:db8:aaaa::/56 >> >> >> >> >> >> Example 2. (Case of enabling NAT44 and stateless XLATE on CLAT) >> >> In the case that IPv6 prefix /64 is assigned to end users, the > > In case only a /64 IPv6 prefix is .... maybe? > > >> function of NAT44 and Stateless XLATE should be enabled on CLAT. >> Because the CLAT does not have dedicated IPv6 prefix for translation. > > Again only half a sentence. Rewrite the entire thing as well? > > >> >> >> >> >> >> Mawatari, et al. Expires February 8, 2013 [Page 17] >> >> Internet-Draft 464XLAT August 2012 >> >> >> Host & configuration value >> +-------------------------------+ >> | IPv4 server | >> | [198.51.100.1] | IP packet header >> +-------------------------------+ +-------------------------------+ >> ^ | Source IP address | >> | | [192.0.2.1] | >> | | Destination IP address | >> | | [198.51.100.1] | >> +-------------------------------+ +-------------------------------+ >> | PLAT | ^ >> | IPv4 pool address | | >> | [192.0.2.1 - 192.0.2.100] | | >> | PLAT-side XLATE IPv6 prefix | | >> | [2001:db8:1234::/96] | | >> +-------------------------------+ +-------------------------------+ >> ^ | Source IP address | >> | | [2001:db8:aaaa:200:5e10:0:0] | > > This is not a valid IPv6 source address. Also see question below on the > local part. > > >> | | Destination IP address | >> | | [2001:db8:1234::198.51.100.1] | >> +-------------------------------+ +-------------------------------+ >> | CLAT Stateless XLATE function | ^ >> | - - - - - - - - - - - - - - - | | >> | PLAT-side XLATE IPv6 prefix | | >> | [2001:db8:1234::/96] | | >> | CLAT-side XLATE IPv6 prefix | | >> | [2001:db8:aaaa::/64] | | >> | CLAT-side XLATE IPv6 EUI-64 ID| | >> | [02-00-5E-10-00-00-00-00] | | > > > Here we go; now that's not described in the draft above, sorry. Not sure > why it needs to be special? I guess the email archives would tell me, but > really the draft should. > > Also, given I have no idea, I almost assume that a 00-00-00-00 might not > be what I'd expect in ths example? > > >> + - - - - - - - - - - - - - - - + +-------------------------------+ >> | ^ | | Source IP address | >> | | | | [10.255.255.1] | >> | | | | Destination IP address | >> | | | | [198.51.100.1] | >> + - - - - - - - - - - - - - - - + +-------------------------------+ >> | CLAT NAT44 function | ^ >> | - - - - - - - - - - - - - - - | | >> | NAT44 NATed address | | >> | [10.255.255.1/32] | | >> +-------------------------------+ +-------------------------------+ >> ^ | Source IP address | >> | | [192.168.1.2] | >> | | Destination IP address | >> | | [198.51.100.1] | >> +-------------------------------+ +-------------------------------+ >> | IPv4 client | >> | [192.168.1.2/24] | >> +-------------------------------+ > > ... > > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Aug 15 00:49:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC5521F86F9; Wed, 15 Aug 2012 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.205 X-Spam-Level: X-Spam-Status: No, score=-101.205 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv0ZJL7AE4hh; Wed, 15 Aug 2012 00:49:50 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9121F86F4; Wed, 15 Aug 2012 00:49:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so770719wgb.13 for ; Wed, 15 Aug 2012 00:49:43 -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=qNW3F+b6iZPt2Xe+CpdpbVkEFSTN0r+Hu/4rtyyF/DE=; b=GWZppTwJNQoAbKd7bJX2S8tmsJZMOOw3RVJEfYHQGNU3Gtyn7yPabAWkhB64pBXE6Y dIabxXEKb9BKUnMGJqBqHJfbpyBUSHC19lbs1QqgNl+3zgCXl91t0uVKww3aYTYPSzrS FX47Tc76ex/FGGUxSoaAStSLZi1ZcsCL4bnNXTJO9OmXEma4hAdhPnoIBodyrKG8SOmd G/Ag6b05HZo/8QlufUVMutrvb+JeTlaEPho0SkSjAQcriOuCjJMB2vTMkxz71IhXUEyz CXsvRxm6zYR5JfHhORpSPix79U92OOeBrs9oDCzonP/299qsXVT6JRObhrsjQgWqt185 MlmA== Received: by 10.180.82.39 with SMTP id f7mr35011356wiy.2.1345016982841; Wed, 15 Aug 2012 00:49:42 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-63.as13285.net. [2.102.218.63]) by mx.google.com with ESMTPS id fr4sm2366457wib.8.2012.08.15.00.49.41 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 00:49:41 -0700 (PDT) Message-ID: <502B549A.4010708@gmail.com> Date: Wed, 15 Aug 2012 08:49:46 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> In-Reply-To: <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" , "opsec-chairs@ietf.org" , "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 07:49:51 -0000 Carlos, On 14/08/2012 22:08, Carlos Pignataro (cpignata) wrote: > Michael, Brian, > > Should "The Suggested Approach" http://tools.ietf.org/html/draft-behringer-lla-only-01#section-2.1 also include some prescriptiveness or specific recommendation regarding the use of RFC 5837, instead of including that solution to interface identification as a "Caveats and Possible Workarounds" only? I have no strong opinion on this. Just indicating the existence of 5837 seems OK, though. Looking at the current text, it says that the loopback GUA MUST be used for all ICMPv6 messages, which is good, but it also says "ICMP error message can also be sourced from the global scope loopback address." That seems unnecessary in view of the MUST, but in any case, s/can/will/. Actually my main comment on the draft is on this text in the Introduction: "We propose to configure neither globally routable IPv6 addresses nor unique local addresses on infrastructure links of routers, wherever possible. We recommend to use exclusively link-local addresses on such links." I suggest a more neutral approach, since some operators clearly prefer to use GUAs: It is possible to configure neither globally routable IPv6 addresses nor unique local addresses on infrastructure links of routers. This document describes how to use exclusively link-local addresses on such links. (and s/proposes/describes how/ in the Abstract) Thanks Brian > Thanks, > > -- Carlos. > > On Aug 6, 2012, at 5:24 AM, Brian E Carpenter wrote: > >> Hi, >> >>> o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo >>> request ... can be addressed to loopback addresses of routers with >>> a global scope address. Router management can also be done over >>> out-of-band channels. >>> >>> o ICMP error message can also be sourced from the global scope >>> loopback address. >> These statements seem too weak. Using GUAs for ICMP in particular >> needs to have a normative MUST somewhere (preferably in a BCP). In the >> context of this Informational draft, the language needs to state a requirement >> ("must" not "can") even if you don't use RFC 2119 terminology. >> >> This matters because packets with a LL source address MUST NOT be forwarded, >> so a router that is misconfigured to send ICMP replies with a LL source >> address breaks both ping and traceroute. >> >> I think the rule is that any packet that is *not* sent to a LL address must >> have a GUA as the source address. That takes care of ICMP, and everything else >> as well. >> >> Furthermore, that GUA needs to be associated with a prefix that belongs to >> the organisation operating the router in question. Otherwise the traceroute >> results can be very confusing. We discussed that on v6ops back in March. >> >> Regards >> Brian Carpenter >> >> >> >> >> On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: >>> (distributed to OPSEC WG and in cc v6ops) >>> >>> Dear all, >>> >>> During the OPSEC WG meeting last Wednesday there was consensus to adopt the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as working group document with Informational status. >>> >>> Please read the draft, and if there is no violent objection on the list, the document will be requested to be submitted as WG document in 7 days. >>> >>> Ciao, >>> G/, KK & Warren >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From markzzzsmith@yahoo.com.au Wed Aug 15 02:42:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E530021F8782 for ; Wed, 15 Aug 2012 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol3AlwYQBxsb for ; Wed, 15 Aug 2012 02:42:00 -0700 (PDT) Received: from nm26.bullet.mail.sp2.yahoo.com (nm26.bullet.mail.sp2.yahoo.com [98.139.91.96]) by ietfa.amsl.com (Postfix) with SMTP id AFE0521F86CF for ; Wed, 15 Aug 2012 02:41:55 -0700 (PDT) Received: from [98.139.91.67] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2012 09:41:55 -0000 Received: from [98.139.91.22] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2012 09:41:55 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 15 Aug 2012 09:41:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 597987.58919.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 39869 invoked by uid 60001); 15 Aug 2012 09:41:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1345023714; bh=uYG+K4zsvXGEkYbjZ7k+lExGaJTspkQEOzKok4XlLFg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KKkhb8bqFmJPNdDshsdvtLzspDHyeD/+P9anKAe03TLEvMvgz1xnybpgniEmYWxi1m8lhy9LJtz0D+OYGCxw04huP5gsrzymQRKfJHPS3lKxf5QD8gHJ1/ukYUeeBcr3skwaEY5ys4zj3k1TaSpEc6dQegmX1nyAmqeGXH9i9Z4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5Eu4Jz/K1XZE3oURnKl0u+qGxqap06rIpti9Tq4OmEbGrl869BylnDtk22pHuGmX3vu+e7A9CgvLG7lp6b0TN7SWO/h/SMjjHLCmYNu/LQ+o6UW9YNyLrW2YgJU0HtkSXFAeVzsztSGWpoblJQLWdTyDN7sd+TUbxio8eXlxZwU=; X-YMail-OSG: oINOGdkVM1ng3yN4FzeGsfdIXRLhY9lwee0QXF4ZXy76eWx ixzQDybtF1tRJdRMTnWMOWfavxUe6Ej8N7bnI2VOwvy.YCN0WT46IyHSCmBF Ktc45HAvXAYoAvKyDGyku9CMmuEJ6gI_96jN1fulvEzITac1dfPexYitA1pq FGbNi4QjY7GL5Gt7zV8xrWG8M1PEG4Rb8LNekzitQT7RaX4tyukxfNEscIda E5KDj5H_exs8l_Q9upMRjh6hBERdGNfAZOqBcGMXZc_0InFZ8JS0qHf3WP4o zdfhFoRFXR6JxIoqM9gzUINLMFmqvVoIz5qHJZRVs.L1gmCEUpq.7hOjsWJ1 KdYNNFtG.UC7P7ox.R.mVo2b4_7VnaTJGtjs_e0HT4cuKuPcUw3ykugoiaaT cLLrwPL6xm205FAAh3KUDXqhQtwEncdzBZ93_nHKO3pWoIGeqKlvEcR5tgf1 BYoRQtG2v0aXzr_.0Cu.ohEvNwj1QcdOCAlj0_UPErAS.tEmsyQu_uawZzBW SVYg- Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Wed, 15 Aug 2012 02:41:54 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> <502B549A.4010708@gmail.com> Message-ID: <1345023714.38595.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Wed, 15 Aug 2012 02:41:54 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter , "Carlos Pignataro \(cpignata\)" In-Reply-To: <502B549A.4010708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:42:01 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Carlos Pignataro (cpignata) =0A> Cc: "'draft-behringer-lla-only@tools.ietf.org' (draft-behringer-l= la-only@tools.ietf.org)" ; "opsec-= chairs@ietf.org" ; "opsec@ietf.org" = ; "v6ops v6ops WG (v6ops@ietf.org)" =0A> Sent: Wednesday, 1= 5 August 2012 5:49 PM=0A> Subject: Re: [v6ops] IPv6 LL-only as WG document = - feedback requested=0A> =0A> Carlos,=0A> =0A> On 14/08/2012 22:08, Carlos = Pignataro (cpignata) wrote:=0A>> Michael, Brian,=0A>> =0A>> Should "The S= uggested Approach" =0A> http://tools.ietf.org/html/draft-behringer-lla-only= -01#section-2.1 also include =0A> some prescriptiveness or specific recomme= ndation regarding the use of RFC 5837, =0A> instead of including that solut= ion to interface identification as a =0A> "Caveats and Possible Workarounds= " only?=0A> =0A> I have no strong opinion on this. Just indicating the exis= tence of 5837=0A> seems OK, though.=0A> =0A> Looking at the current text, i= t says that the loopback GUA MUST be used for all=0A> ICMPv6 messages, whic= h is good, but it also says=0A> "ICMP error message can also be sourced fro= m the global scope loopback =0A> address."=0A=0APerhaps it would be better = to be even more general, and just say ICMPv6 messages must come from addres= ses with a scope greater than link local? Restricting to GUAs suggests the = idea in this draft can only be used when GUAs are available, yet I'd think = it could also be useful in a private, non-Internet connected network too.= =0A=0A=0A=0ARegards,=0AMark. From despres.remi@laposte.net Wed Aug 15 03:04:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A14321F8736 for ; Wed, 15 Aug 2012 03:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1DsHd90MVLn for ; Wed, 15 Aug 2012 03:04:29 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id E695721F8734 for ; Wed, 15 Aug 2012 03:04:28 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id B6D1870000A5; Wed, 15 Aug 2012 12:04:26 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 42254700009F; Wed, 15 Aug 2012 12:04:26 +0200 (CEST) X-SFR-UUID: 20120815100426271.42254700009F@msfrf2421.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 15 Aug 2012 12:04:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> To: Bjoern A. Zeeb X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:04:29 -0000 Le 2012-08-14 =E0 23:30, Bjoern A. Zeeb a =E9crit : > On Tue, 14 Aug 2012, Tom Taylor wrote: >=20 >>=20 >>=20 >> On 14/08/2012 6:34 AM, Bjoern A. Zeeb wrote: >>> On Thu, 9 Aug 2012, Bjoern A. Zeeb wrote: >>> A few days later than hoped.... >> ... >>=20 >>>> Abstract >>>>=20 >>>> This document describes an architecture (464XLAT) for providing >>>> limited IPv4 connectivity across an IPv6-only network by = combining >>>> existing and well-known stateful protocol translation RFC 6146 in = the >>> ... [RFC6146] ... >>>=20 >>>> core and stateless protocol translation RFC 6145 at the edge. = 464XLAT >>> ... [RFC6145] ... >>>=20 >>>> is a simple and scalable technique to quickly deploy limited IPv4 >>>> access service to IPv6-only edge networks without encapsulation. >>> ... >>=20 >> It's against the rules to put references in the Abstract as you = suggest. The original text is OK here. >=20 > Indeed .. unless they are completly defined within the abstract, which > is not the case here and indeed the least I am worried about. >=20 > I am still trying to find the EUI stuff in the archives, which is a > PITA. In case someone has the reference (or link) I'd be happy. Isn't tools.ietf.org/html/rfc5342#section-2.2.2 what you are looking = for? RD >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb You have to have = visions! > Stop bit received. Insert coin for new address family. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From bzeeb-lists@lists.zabbadoz.net Wed Aug 15 05:34:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5E21F87CC for ; Wed, 15 Aug 2012 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46b8ucEBr7IR for ; Wed, 15 Aug 2012 05:34:06 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57C21F8748 for ; Wed, 15 Aug 2012 05:34:06 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3BB8B25D387C for ; Wed, 15 Aug 2012 12:34:05 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 728B2BE859A for ; Wed, 15 Aug 2012 12:34:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dps8SMUQpyFa for ; Wed, 15 Aug 2012 12:34:03 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 023FBBE8597 for ; Wed, 15 Aug 2012 12:34:02 +0000 (UTC) Date: Wed, 15 Aug 2012 12:34:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: v6ops@ietf.org In-Reply-To: <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-818261353-1345034043=:4474" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 12:34:23 -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. --0-818261353-1345034043=:4474 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 15 Aug 2012, Rémi Després wrote: Hi, > Le 2012-08-14 à 23:30, Bjoern A. Zeeb a écrit : > >> I am still trying to find the EUI stuff in the archives, which is a >> PITA. In case someone has the reference (or link) I'd be happy. > > Isn't tools.ietf.org/html/rfc5342#section-2.2.2 what you are looking for? No, I am still trying to understand why the special EUI is in the draft at all. Given the other reference I went back and read the entire thread starting April 16 all the way into May on the -02 version of the draft. CB asked for text that I have never seen in a reply, which might have helped. As it stands: 1) I need a better explanation why the special EUI range is needed? The mumbling on linux and tethering and nd proxy and whatnot did not give me any reason why it was needed. 2) If it is really needed, the draft will need the explanation from (1) and we'll need to discuss why we need our own range rather than the one 5342 already provides for v4. So let's start with (1)? The more detaied you (pl) can be and the better your concrete example is the more it would help to clarify this quickly. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-818261353-1345034043=:4474-- From dan-v6ops@drown.org Wed Aug 15 08:29:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FEF21E808F for ; Wed, 15 Aug 2012 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPlO+kVDIZwn for ; Wed, 15 Aug 2012 08:29:00 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 598BE21F8748 for ; Wed, 15 Aug 2012 08:29:00 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id C0D6FC131; Wed, 15 Aug 2012 11:28:59 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Wed, 15 Aug 2012 10:28:59 -0500 Message-ID: <20120815102859.94085azox3126tc0@mail.drown.org> Date: Wed, 15 Aug 2012 10:28:59 -0500 From: Dan Drown To: v6ops@ietf.org, "Bjoern A. Zeeb" References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:29:00 -0000 Quoting "Bjoern A. Zeeb" : > No, I am still trying to understand why the special EUI is in the draft > at all. > > Given the other reference I went back and read the entire thread > starting April 16 all the way into May on the -02 version of the > draft. CB asked for text that I have never seen in a reply, which > might have helped. > > As it stands: > > 1) I need a better explanation why the special EUI range is needed? > The mumbling on linux and tethering and nd proxy and whatnot > did not give me any reason why it was needed. Given the following constraints on a smartphone: * A handset allocated a single /64 IPv6 subnet * That subnet is used for: regular v6 traffic (from the handset), 464xlat, and regular v6 traffic (from tethered clients) * 464xlat needs its own dedicated IPv6 subnet or address You have the following choices: 1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one mapping of IPv4 addresses to IPv6 addresses 2. Allocate a single IPv6 address out of the /64 subnet, map it to a single IPv4 address, and use NAT44 to provide IPv4 access to tethered clients The drawback of choice #1 is when you have IPv6 tethering clients, you can't realisticly proxy ND the entire subnet. With this, IPv6 tethered clients have a chance of choosing an address that won't reach them, and the lack of proxy ND won't tell them of the conflict. With the choice of #2, an IPv6 address for use with 464xlat must be selected. An assigned interface id from a reserved EUI-64 range makes it less likely to conflict with a tethered client (since the /64 subnet can be used with SLAAC-configured tethering clients). Granted, the chance of conflict is already small and handled by DAD, but it's still good policy to avoid. > 2) If it is really needed, the draft will need the explanation from > (1) and we'll need to discuss why we need our own range rather than > the one 5342 already provides for v4. The IPv4 address range would be reasonable. The EUI-64 would have the local bit set to 0, which means a chance of conflicting with tethered client's privacy address, but DAD should alert that host to select a new privacy address. From phdgang@gmail.com Wed Aug 15 08:37:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1335921F86F6 for ; Wed, 15 Aug 2012 08:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgw2LxVv16HQ for ; Wed, 15 Aug 2012 08:37:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6504F21F86E0 for ; Wed, 15 Aug 2012 08:37:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1861120vbb.31 for ; Wed, 15 Aug 2012 08:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZhHOZ7QX95W2wD1zXMKDc5at33s1wJLWccIPCUG5BR8=; b=jcE0CAXCOVkQRbLY6fmMcbzlmQEupcTcutX6vtgIFEFAByISPhfU64A8A3j+k/blZw yLtJejKm1LaqCT8wSUT5cwMhfXxmAg7EfNwjhI5oRpYuliKd2/W0KDC8xxok6e2mSh1t ohmbTF35RR5B2OkArvv7bcbKwTMx/5ZbrXWARYoeAq9EL4q+4wMTl6RHQ9jjcj1cjZEH rBoJbBhZwAKjc8SlXRzVWmBMcrlEd64njtEfWqFxOsIbF69MKTgUY1g8knvk8oiaxstw CIWub0p9oCcXqRngDn0lkoox79psMMjFTmOsbMLLcItOYiGoR3IFjwkNHGbNmc4Pnk5q y/AQ== MIME-Version: 1.0 Received: by 10.58.33.234 with SMTP id u10mr12601182vei.49.1345045032747; Wed, 15 Aug 2012 08:37:12 -0700 (PDT) Received: by 10.58.165.67 with HTTP; Wed, 15 Aug 2012 08:37:12 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> Date: Wed, 15 Aug 2012 23:37:12 +0800 Message-ID: From: GangChen To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:37:14 -0000 2012/8/15, Bjoern A. Zeeb : > On Wed, 15 Aug 2012, R=E9mi Despr=E9s wrote: > > Hi, > >> Le 2012-08-14 =E0 23:30, Bjoern A. Zeeb a =E9crit : >> >>> I am still trying to find the EUI stuff in the archives, which is a >>> PITA. In case someone has the reference (or link) I'd be happy. >> >> Isn't tools.ietf.org/html/rfc5342#section-2.2.2 what you are looking for= ? > > No, I am still trying to understand why the special EUI is in the draft > at all. > > Given the other reference I went back and read the entire thread > starting April 16 all the way into May on the -02 version of the > draft. CB asked for text that I have never seen in a reply, which > might have helped. > > As it stands: > > 1) I need a better explanation why the special EUI range is needed? > The mumbling on linux and tethering and nd proxy and whatnot > did not give me any reason why it was needed. Trying to share my thought as an observer. 464xlat implementation adopts "/dev/tun" to steer incoming IPv4 packages to translation module. TUN simulates a network layer device and it require a IPv6 address to be configured. When DHCP-PD is not availed in some cases, v6 tethering would be performed through ND proxy. If the IID of IPv6 address on TUN device is regular, the IPv6 address should be eliminated within LAN side in order to avoid potential IID confliction. That increases implementation complexity in some sense. Therefore a Modified EUI-64 identifier is proposed to be IID on the tun device. The reserved identifiers could prevent the occurrence of IID confliction so as to ND-proxy doesn't need to exclude any particular IPv6 address. Besides, ISPs can also recognize doubly-translated packets by means of this particular IID. The discussion before also tried to figure out "TAP" approach as an alternative way. But it's realized it can't be achieved since TAP can't handle point to point frame if I understood correctly. > 2) If it is really needed, the draft will need the explanation from > (1) and we'll need to discuss why we need our own range rather than > the one 5342 already provides for v4. > > So let's start with (1)? The more detaied you (pl) can be and the > better your concrete example is the more it would help to clarify > this quickly. > > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. From mbehring@cisco.com Wed Aug 15 08:39:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7667821E80E7; Wed, 15 Aug 2012 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoXtX6N3kR7A; Wed, 15 Aug 2012 08:39:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9885521E80D9; Wed, 15 Aug 2012 08:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbehring@cisco.com; l=2718; q=dns/txt; s=iport; t=1345045184; x=1346254784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pUkPCuUGEpst2is2LSWbdFDHqOSWRz/LJ1pZweJooU0=; b=DyND0yQBDzoe5OWiSK5Nvu5QDuHKjfCA+vQvjOduC6aw1vWsg4vqJOGm isIoWrJ/f3nzhTY4eZxz7ah1B8hMCLGx0I+9dWiJi1C4GC1h0wiarEHsL 3plE5xkVXYTF2qtbDLoJz5ZjcElZT4pVBS9ZmV8TLVqRCdpZ/3WAY2g9z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPTBK1CtJV2Y/2dsb2JhbABFhgGzL2eBB4IgAQEBAwESARARRQwEAgEIFQMCAgYdAwICAh8RFAEQAgQBDQUIEweHXAMGBguZZ40ZiVkNiU6BIYkDZIVFMmADk3wDgmSJeIMggWaCXw X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208";a="111637137" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 15 Aug 2012 15:39:44 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7FFdh6n024121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 15:39:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 10:39:43 -0500 From: "Michael Behringer (mbehring)" To: Mark ZZZ Smith , Brian E Carpenter , "Carlos Pignataro (cpignata)" Thread-Topic: [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: AQHNeso8h2La8Dr8HUyqWkjByeNkFJda/iEw Date: Wed, 15 Aug 2012 15:39:42 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F4EC3BB@xmb-rcd-x14.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> <502B549A.4010708@gmail.com> <1345023714.38595.YahooMailNeo@web32507.mail.mud.yahoo.com> In-Reply-To: <1345023714.38595.YahooMailNeo@web32507.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.83.60] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--49.660200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:39:45 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCBbbWFp bHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXVdDQpbLi4uXQ0KPiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVu dGVyQGdtYWlsLmNvbT4NClsuLi5dDQo+ID4NCj4gPiBDYXJsb3MsDQo+ID4NCj4gPiBPbiAxNC8w OC8yMDEyIDIyOjA4LCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+ID4+ICBN aWNoYWVsLCBCcmlhbiwNCj4gPj4NCj4gPj4gIFNob3VsZCAiVGhlIFN1Z2dlc3RlZCBBcHByb2Fj aCINCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItbGxhLW9u bHktMDEjc2VjdGlvbi0yLjENCj4gPiBhbHNvIGluY2x1ZGUgc29tZSBwcmVzY3JpcHRpdmVuZXNz IG9yIHNwZWNpZmljIHJlY29tbWVuZGF0aW9uDQo+ID4gcmVnYXJkaW5nIHRoZSB1c2Ugb2YgUkZD IDU4MzcsIGluc3RlYWQgb2YgaW5jbHVkaW5nIHRoYXQgc29sdXRpb24gdG8NCj4gPiBpbnRlcmZh Y2UgaWRlbnRpZmljYXRpb24gYXMgYSAiQ2F2ZWF0cyBhbmQgUG9zc2libGUgV29ya2Fyb3VuZHMi IG9ubHk/DQo+ID4NCj4gPiBJIGhhdmUgbm8gc3Ryb25nIG9waW5pb24gb24gdGhpcy4gSnVzdCBp bmRpY2F0aW5nIHRoZSBleGlzdGVuY2Ugb2YNCj4gPiA1ODM3IHNlZW1zIE9LLCB0aG91Z2guDQoN ClR3byBjb21tZW50czogDQotIHRoZSB3b3JkaW5nICJzdWdnZXN0ZWQgYXBwcm9hY2giIGlzIGEg bGVmdC1vdmVyIGZyb20gdGhlIHRpbWVzIHdoZW4gd2Ugd2VyZSB0YXJnZXRpbmcgQkNQLiBOb3cg YXMgaW5mb3JtYXRpb25hbCB3ZSdsbCByZW1vdmUgdGhlICJzdWdnZXN0ZWQiLiANCi0gdGhlIGlu dGVudGlvbiBvZiB0aGUgZG9jIGlzIHRvIGdpdmUgZ3VpZGFuY2UgdG8gYSBuZXR3b3JrIG9wZXJh dG9yIG9uIHdoZXRoZXIgbGluayBsb2NhbCBpcyBhIGdvb2QgaWRlYSBpbiBoaXMgZW52aXJvbm1l bnQgb3Igbm90LiBTaW5jZSB0aGUgdGFyZ2V0IGlzIHRoZSBuZXR3b3JrIG9wZXJhdG9yLCBJIGRv buKAmXQgdGhpbmsgd2Ugc2hvdWxkIHJlY29tbWVuZCB0aGUgdXNlIC0gdGhlIG9wZXJhdG9yIGNh bid0IGRvIGFueXRoaW5nIGFib3V0IGl0LiBTbyBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIGxl YXZlIGl0IHdoZXJlIGl0IGlzLiANCg0KVW5sZXNzIHdlIHdhbnQgdG8gd2lkZW4gdGhlIHNjb3Bl PyAoTm90IG15IHByZWZlcnJlZCBhcHByb2FjaCB0aG91Z2ggLSBpdCdzIG5pY2UgdG8gaGF2ZSBh IGNsZWFyIHNjb3BlKQ0KDQo+ID4gTG9va2luZyBhdCB0aGUgY3VycmVudCB0ZXh0LCBpdCBzYXlz IHRoYXQgdGhlIGxvb3BiYWNrIEdVQSBNVVNUIGJlDQo+ID4gdXNlZCBmb3IgYWxsDQo+ID4gSUNN UHY2IG1lc3NhZ2VzLCB3aGljaCBpcyBnb29kLCBidXQgaXQgYWxzbyBzYXlzICJJQ01QIGVycm9y IG1lc3NhZ2UNCj4gPiBjYW4gYWxzbyBiZSBzb3VyY2VkIGZyb20gdGhlIGdsb2JhbCBzY29wZSBs b29wYmFjayBhZGRyZXNzLiINCj4gDQo+IFBlcmhhcHMgaXQgd291bGQgYmUgYmV0dGVyIHRvIGJl IGV2ZW4gbW9yZSBnZW5lcmFsLCBhbmQganVzdCBzYXkgSUNNUHY2DQo+IG1lc3NhZ2VzIG11c3Qg Y29tZSBmcm9tIGFkZHJlc3NlcyB3aXRoIGEgc2NvcGUgZ3JlYXRlciB0aGFuIGxpbmsgbG9jYWw/ DQo+IFJlc3RyaWN0aW5nIHRvIEdVQXMgc3VnZ2VzdHMgdGhlIGlkZWEgaW4gdGhpcyBkcmFmdCBj YW4gb25seSBiZSB1c2VkIHdoZW4NCj4gR1VBcyBhcmUgYXZhaWxhYmxlLCB5ZXQgSSdkIHRoaW5r IGl0IGNvdWxkIGFsc28gYmUgdXNlZnVsIGluIGEgcHJpdmF0ZSwgbm9uLQ0KPiBJbnRlcm5ldCBj b25uZWN0ZWQgbmV0d29yayB0b28uDQoNCkdvb2QgcG9pbnQuIEknbGwgY2hhbmdlIHRoYXQuIA0K DQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayEgDQpNaWNoYWVsDQoNClsuLi5dDQo= From bzeeb-lists@lists.zabbadoz.net Wed Aug 15 13:52:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EFB21F85C5 for ; Wed, 15 Aug 2012 13:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlDaNNuV2Fkd for ; Wed, 15 Aug 2012 13:52:49 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id AF04F21F85C3 for ; Wed, 15 Aug 2012 13:52:48 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4297325D387C; Wed, 15 Aug 2012 20:52:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5A5D9BE8597; Wed, 15 Aug 2012 20:52:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id yUjtZls3MXRt; Wed, 15 Aug 2012 20:52:44 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2B12ABE859B; Wed, 15 Aug 2012 20:52:43 +0000 (UTC) Date: Wed, 15 Aug 2012 20:52:43 +0000 (UTC) From: "Bjoern A. Zeeb" To: Dan Drown In-Reply-To: <20120815102859.94085azox3126tc0@mail.drown.org> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:52:51 -0000 On Wed, 15 Aug 2012, Dan Drown wrote: > Quoting "Bjoern A. Zeeb" : >> No, I am still trying to understand why the special EUI is in the draft >> at all. >> >> Given the other reference I went back and read the entire thread >> starting April 16 all the way into May on the -02 version of the >> draft. CB asked for text that I have never seen in a reply, which >> might have helped. >> >> As it stands: >> >> 1) I need a better explanation why the special EUI range is needed? >> The mumbling on linux and tethering and nd proxy and whatnot >> did not give me any reason why it was needed. > > Given the following constraints on a smartphone: > > * A handset allocated a single /64 IPv6 subnet > > * That subnet is used for: regular v6 traffic (from the handset), 464xlat, > and regular v6 traffic (from tethered clients) > > * 464xlat needs its own dedicated IPv6 subnet or address > > > You have the following choices: > > 1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one > mapping of IPv4 addresses to IPv6 addresses > > 2. Allocate a single IPv6 address out of the /64 subnet, map it to a single > IPv4 address, and use NAT44 to provide IPv4 access to tethered clients > > The drawback of choice #1 is when you have IPv6 tethering clients, you can't > realisticly proxy ND the entire subnet. With this, IPv6 tethered clients > have a chance of choosing an address that won't reach them, and the lack of > proxy ND won't tell them of the conflict. > > > With the choice of #2, an IPv6 address for use with 464xlat must be selected. > An assigned interface id from a reserved EUI-64 range makes it less likely to > conflict with a tethered client (since the /64 subnet can be used with > SLAAC-configured tethering clients). Granted, the chance of conflict is > already small and handled by DAD, but it's still good policy to avoid. Hmm `man U/L bit`? `man RFC4193`? I'd keep SLAAC out of the argument here; these shhuld really be globally unique addresses and use the other 63 (62) bit of the IID. So what's the real problem? That the locally administered address(es) clash with the single IPv6 address used for translation in the NAT44 case or the /96 address block used for 1:1 translation or that these might clash with the addresses used with privacy extensions on? They'd all live in the same 63 (62) bit space already anyway. I don't see any point in making that XLAT464 related ones any special; you already have to deal with all of this in the tethered environment or just on the local host, why to complicate matters by adding another player to the game? I clearly think (2) of my original request is not necessary. The IANA section should be emptied. There is no reason for another special clas of EUI mangling. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From lorenzo@google.com Wed Aug 15 17:55:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12FD21F848A for ; Wed, 15 Aug 2012 17:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAHhjd9Nlhr1 for ; Wed, 15 Aug 2012 17:55:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0F821F8487 for ; Wed, 15 Aug 2012 17:54:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3194663obb.31 for ; Wed, 15 Aug 2012 17:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Yh44qDTCX5cjkJJ22VN/CwiYmvcjOiud3rG+2mTM89k=; b=LLXv9Vv0sAfmT3Z94KC+vdCnnHM9EexO21T2VprAY9epqmnVJoqahxNH0bwnnLIcDU Hle6f1Q+dBmJWgpLKOlXwg1toCsiLoI5em6OOLcMBY99Tk+KAvwcGsWLit+mJIslWa77 s9K/nNaNYc/DXKg7gvo9UAscvwxGUUZTFv/JRAPT3vz6jnjgem3KKzaQp91+eU/Ronn1 oOWqeWBhQSMO1xUki6oyRlhK2yYIq5G76SPtzp0n3T2c1nmQ2cnYa09X0Mo3Rg1kc/Ut WK/MonfKuU70zkqDd/7mXP8hlT1Eo/T7560Hi+if6nvBM0Z6hhXiq4hYVKWB8Wj8FqEe uarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Yh44qDTCX5cjkJJ22VN/CwiYmvcjOiud3rG+2mTM89k=; b=XkWZqO+Ts5MAEtKwchgF1pKnquOyOpmh+dReFAsmZnSlmbv+CyjpqIV3JxDyRdWUYL Gt89x04+OaGc62khSn2UotkVPCukOeEquUheGaqsLs9tgj/YPTm9E2k0FhASQ+rP86SC 9fMNWW/iv4y5CLeY1FRSjtGdglI/Zd0liG9z3FjXdYSYPNhqN5h7C+fyp/Tc+JWgw/Eh Es5stJjBHoUF8TH5Fyf738Bt/HZGzAIdwwlmBoHy3jISxCTVnCJmKHx4Ngz2tmQCc3/M cIsrjlQ0cyzNm1JFwGq+HwLMBjmqzGIRjq3125OO8tGBEynn5XEU0xyHuBAInlV1E+zY 25dQ== Received: by 10.60.3.42 with SMTP id 10mr3281118oez.5.1345078496896; Wed, 15 Aug 2012 17:54:56 -0700 (PDT) Received: by 10.60.3.42 with SMTP id 10mr3281114oez.5.1345078496715; Wed, 15 Aug 2012 17:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 15 Aug 2012 17:54:36 -0700 (PDT) In-Reply-To: <20120815102859.94085azox3126tc0@mail.drown.org> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> From: Lorenzo Colitti Date: Thu, 16 Aug 2012 09:54:36 +0900 Message-ID: To: Dan Drown Content-Type: multipart/alternative; boundary=e89a8fb1ff14fde43304c7577d5f X-System-Of-Record: true X-Gm-Message-State: ALoCoQnoSjkMyDA0K7y9WBsZ5DWsXU+0+i2EqFW/+WWOhMBh4iwA/bM2wX8sYeHz8umWN3UcCNf12ZEG5FF2fZTKeoJuLcTGZhnZBuoX/pei+78WwyTXIMfCKciP0JmVbW//PxfGFyfPt211/G00tPVL/ZAKcOo29uPcLjbFd9lPHy865aOcv/Utv7WIB7GEQEJtw1x17vf8 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 00:55:01 -0000 --e89a8fb1ff14fde43304c7577d5f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown wrote: > You have the following choices: > > 1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one > mapping of IPv4 addresses to IPv6 addresses > > 2. Allocate a single IPv6 address out of the /64 subnet, map it to a > single IPv4 address, and use NAT44 to provide IPv4 access to tethered > clients > > The drawback of choice #1 is when you have IPv6 tethering clients, you > can't realisticly proxy ND the entire subnet. With this, IPv6 tethered > clients have a chance of choosing an address that won't reach them, and the > lack of proxy ND won't tell them of the conflict. > > > With the choice of #2, an IPv6 address for use with 464xlat must be > selected. An assigned interface id from a reserved EUI-64 range makes it > less likely to conflict with a tethered client (since the /64 subnet can be > used with SLAAC-configured tethering clients). Granted, the chance of > conflict is already small and handled by DAD, but it's still good policy to > avoid. Why not just do #2 and choose, as the interface ID, the interface ID of the interface that is providing tethering? Does that make it hard to implement? Also - if you're the tethering device, you are by definition the subnet router. Can you pick the interface ID of :: ? --e89a8fb1ff14fde43304c7577d5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown <= dan-v6ops@drown.org> wrote:
You have the following choices:

1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one ma= pping of IPv4 addresses to IPv6 addresses

2. Allocate a single IPv6 address out of the /64 subnet, map it to a single= IPv4 address, and use NAT44 to provide IPv4 access to tethered clients

The drawback of choice #1 is when you have IPv6 tethering clients, you can&= #39;t realisticly proxy ND the entire subnet. =A0With this, IPv6 tethered c= lients have a chance of choosing an address that won't reach them, and = the lack of proxy ND won't tell them of the conflict.


With the choice of #2, an IPv6 address for use with 464xlat must be selecte= d. =A0An assigned interface id from a reserved EUI-64 range makes it less l= ikely to conflict with a tethered client (since the /64 subnet can be used = with SLAAC-configured tethering clients). =A0Granted, the chance of conflic= t is already small and handled by DAD, but it's still good policy to av= oid.

Why not just do #2 and choose, as the interface ID, the= interface ID of the interface that is providing tethering? Does that make = it hard to implement?

Also - if you're the tet= hering device, you are by definition the subnet router. Can you pick the in= terface ID of :: ?
--e89a8fb1ff14fde43304c7577d5f-- From mawatari@jpix.ad.jp Wed Aug 15 21:49:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EB221F8522 for ; Wed, 15 Aug 2012 21:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZKRfx5wQwOG for ; Wed, 15 Aug 2012 21:49:21 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 600EA21F851E for ; Wed, 15 Aug 2012 21:49:19 -0700 (PDT) Received: from [192.168.0.230] (64es-v4pool5.jpix.ad.jp [202.90.12.5]) by mx20.jpix.ad.jp (Postfix) with ESMTP id AD8E6FC021 for ; Thu, 16 Aug 2012 13:49:18 +0900 (JST) Date: Thu, 16 Aug 2012 13:49:21 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: References: <20120815102859.94085azox3126tc0@mail.drown.org> Message-Id: <20120816134920.41EA.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 04:49:22 -0000 Dear all, We authors really appreciate for discussion about the case of assigning /64 to end in 464XLAT. We think that we have to clarify that this is implementors' choice in the document. Implementor of CLAT can choose from using IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc. That point is not the key proposal in 464XLAT as a architecture using combination of RFC 6145 and RFC 6146. It depends on implementor of CLAT and it is independent from interoperability between PLAT and CLAT. Finally, 464XLAT can defer to implementor of CLAT on that point. Kind Regards, Masataka MAWATARI * On Thu, 16 Aug 2012 09:54:36 +0900 * Lorenzo Colitti wrote: > On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown wrote: > > > You have the following choices: > > > > 1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one > > mapping of IPv4 addresses to IPv6 addresses > > > > 2. Allocate a single IPv6 address out of the /64 subnet, map it to a > > single IPv4 address, and use NAT44 to provide IPv4 access to tethered > > clients > > > > The drawback of choice #1 is when you have IPv6 tethering clients, you > > can't realisticly proxy ND the entire subnet. With this, IPv6 tethered > > clients have a chance of choosing an address that won't reach them, and the > > lack of proxy ND won't tell them of the conflict. > > > > > > With the choice of #2, an IPv6 address for use with 464xlat must be > > selected. An assigned interface id from a reserved EUI-64 range makes it > > less likely to conflict with a tethered client (since the /64 subnet can be > > used with SLAAC-configured tethering clients). Granted, the chance of > > conflict is already small and handled by DAD, but it's still good policy to > > avoid. > > > Why not just do #2 and choose, as the interface ID, the interface ID of the > interface that is providing tethering? Does that make it hard to implement? > > Also - if you're the tethering device, you are by definition the subnet > router. Can you pick the interface ID of :: ? From lorenzo@google.com Wed Aug 15 23:36:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC521F8582 for ; Wed, 15 Aug 2012 23:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqMZx+6kDn+b for ; Wed, 15 Aug 2012 23:36:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8293521F856D for ; Wed, 15 Aug 2012 23:36:43 -0700 (PDT) Received: by yenm5 with SMTP id m5so2813423yen.31 for ; Wed, 15 Aug 2012 23:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sTkBlFSPnWC+lk8SK4tqpCWDkw9h5+JBymcfaWVuqIs=; b=lfSUv0bLAH4rQeas1mqdUYQzgWdFtwu4Rubz76x275a9SIsadIFd5lS86DqWnUm4OU gqQ82PyM7zoGdnNLxYhktUjrnm5bFPItfvTSdB/y6KnAxRaEiM1Z6xa0m3IqoD93rIcQ 2tIFYQaJ6Gh5B4Z0ZE12h8hKhFsoTDwllrChNEU1zF182X10wZL8I358YleAbYWAU+ZM R1CjZFsv4AeV9mb/2ziNtADD0A6T+ehDftKk9qozVKE49L5X8iIMipUmuJQzr8JZbHX6 L7XchP/mMYTC+D5MamjKj20sC5nCeBR9xnF4R42EFPImFLW9iH++mDUnl6c/4rA9LjBy rjzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sTkBlFSPnWC+lk8SK4tqpCWDkw9h5+JBymcfaWVuqIs=; b=ZPEPtQJTUuJd4HLzsURUnCyvk5Z3scSrgn7xr7fCPMCawmavZkfgQD97IsDCL9SDZn vGgl7DLronbffJrOfMqo+QbsHzZWqaEMBt7ZntkkAAEb3yqV7rRngmtZd/+0Q+IGeaoz IYmkmCqt///sTgUp9D4XYhV9bHz5B+95bS8ez3g4YSz3QPbitUrCsU4nbFN7TofOxQo5 ef1pGm7pltI9YoReC4TrbZWAs7+zfV4HbvlGCLVfAKpkN9NCytSPhBGe837xlJoGAsGt KkmvZ5LVClyK0Bn+9rMljPkl7IDr2ogJhwCp6rvKRy40gAvGp/jOXhZOrkiSIhey/UiC bR7g== Received: by 10.50.217.137 with SMTP id oy9mr66845igc.56.1345099002425; Wed, 15 Aug 2012 23:36:42 -0700 (PDT) Received: by 10.50.217.137 with SMTP id oy9mr66838igc.56.1345099002291; Wed, 15 Aug 2012 23:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.224.84 with HTTP; Wed, 15 Aug 2012 23:36:22 -0700 (PDT) In-Reply-To: <20120816134920.41EA.8FE1F57E@jpix.ad.jp> References: <20120815102859.94085azox3126tc0@mail.drown.org> <20120816134920.41EA.8FE1F57E@jpix.ad.jp> From: Lorenzo Colitti Date: Thu, 16 Aug 2012 15:36:22 +0900 Message-ID: To: MAWATARI Masataka Content-Type: multipart/alternative; boundary=14dae9340e8538259604c75c44bd X-System-Of-Record: true X-Gm-Message-State: ALoCoQnSIxvKzUF20bzLy8tc/3SL3+ZrWCvAt5lqq+tqqs2b3uRwqDR1G+g8/t46RhEOuSuwFB1BJjGdf5ljibSaZ+VwEdwbjt1ZyGkL05jdnni8gq+fOLNVlevHc8Hsp6fwI7Uyl0JK2355ctkxoPRtL96d5jfsnJ0N+tvlksP1vLVzCAIBz2s+g9ycSFkO3EdYp7Ehrzkg Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 06:36:44 -0000 --14dae9340e8538259604c75c44bd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 16, 2012 at 1:49 PM, MAWATARI Masataka wrote: > We think that we have to clarify that this is implementors' > choice in the document. Implementor of CLAT can choose from using > IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc. > Well, but the implementor cannot choose to use a IANA-reserved EUI-64 unless IANA reserves an EUI-64 value for 464xlat. And IANA won't reserve an EUI-64 value for 464xlat if this document not contain a request to IANA to reserve it. This is why we are discussing whether to request a reserved EUI-64 or not. --14dae9340e8538259604c75c44bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 16, 2012 at 1:49 PM, MAWATARI Masata= ka <mawatari@jpix.ad.jp> wrote:
We think that we have to clarify that this is implementors'
choice in the document. =A0Implementor of CLAT can choose from using
IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc.

Well, but the implementor cannot choose to u= se a IANA-reserved EUI-64 unless IANA reserves an EUI-64 value for 464xlat.= And IANA won't reserve an EUI-64 value for 464xlat if this document no= t contain a request to IANA to reserve it. This is why we are discussing wh= ether to request a reserved EUI-64 or not.
--14dae9340e8538259604c75c44bd-- From despres.remi@laposte.net Thu Aug 16 00:27:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF70F21F861A for ; Thu, 16 Aug 2012 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJpGdNhqcES1 for ; Thu, 16 Aug 2012 00:27:43 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id D47B121F84EE for ; Thu, 16 Aug 2012 00:27:42 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2504.sfr.fr (SMTP Server) with ESMTP id 313A87000046; Thu, 16 Aug 2012 09:27:41 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2504.sfr.fr (SMTP Server) with ESMTP id 793DF700009E; Thu, 16 Aug 2012 09:27:40 +0200 (CEST) X-SFR-UUID: 20120816072740496.793DF700009E@msfrf2504.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25--424843718 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 16 Aug 2012 09:27:39 +0200 Message-Id: <1B28515B-8140-4EF0-BAA7-72467FD52EAD@laposte.net> References: <20120815102859.94085azox3126tc0@mail.drown.org> <20120816134920.41EA.8FE1F57E@jpix.ad.jp> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:27:43 -0000 --Apple-Mail-25--424843718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-08-16 =E0 08:36, Lorenzo Colitti : > On Thu, Aug 16, 2012 at 1:49 PM, MAWATARI Masataka = wrote: > We think that we have to clarify that this is implementors' > choice in the document. Implementor of CLAT can choose from using > IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc. >=20 > Well, but the implementor cannot choose to use a IANA-reserved EUI-64 = unless IANA reserves an EUI-64 value for 464xlat. And IANA won't reserve = an EUI-64 value for 464xlat if this document not contain a request to = IANA to reserve it. This is why we are discussing whether to request a = reserved EUI-64 or not. Right. 1. Reserving an IPv6 address for NAT44-enabled CLATs ensures that no = conflict _can exist_ between this address and that of an IPv6 host that = has a local-scope interface IDs chosen before 464XLAT activation (design = orthogonality). 2. Once this reservation is made, always using it is simpler than = permitting implementation variants. 3. The draft can be clarified concerning this address, at least by = correcting its section-number typo. Suggestions: - In 8.2.2, . s/mapped to a single IPv6 address/mapped to the single IPv6 address = specified in section 8.3.2/ =20 . In the source address of the figure, s/IPv4-Embedded IPv6 address = defined in Section 2.2 of RFC6052/IPv6 address specified in section = 8.3.2/ - In section 8.3.2,=20 . s/the CLAT WAN IPv6 address as described in [RFC6052]/the CLAT WAN = IPv6 address specified as follows/ . s/(Section 10)/(Section 11)/ (typo) - In section 11, . s/IANA is requested/For the IPv6 Interface ID of NAT44-enabled-CLATs = (Section 8.3.2), IANA is requested/ Hope it clarifies. RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-25--424843718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Thu, Aug 16, 2012 at 1:49 PM, MAWATARI Masataka = <mawatari@jpix.ad.jp> = wrote:
We think that we have to clarify that this is implementors'
choice in the document.  Implementor of CLAT can choose from = using
IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, = etc.

Well, but the implementor = cannot choose to use a IANA-reserved EUI-64 unless IANA reserves an = EUI-64 value for 464xlat. And IANA won't reserve an EUI-64 value for = 464xlat if this document not contain a request to IANA to reserve it. = This is why we are discussing whether to request a reserved EUI-64 or = not.

Right.

1. Reserving an IPv6 address for NAT44-enabled CLATs ensures = that no conflict _can exist_ between this address and that of an IPv6 = host that has a local-scope interface IDs chosen before 464XLAT = activation (design orthogonality).

2. Once this = reservation is made, always using it is simpler than permitting = implementation variants.

3. The draft can be = clarified concerning this address, at least by correcting its = section-number typo.
Suggestions:
- In = 8.2.2,
 . s/mapped to a single IPv6 address/mapped to the = single IPv6 address specified in section 8.3.2/  
 . = In the source address of the figure, s/IPv4-Embedded IPv6 = address defined in Section 2.2 of RFC6052/IPv6 address specified in = section 8.3.2/
- In section 8.3.2, 
 . = s/the CLAT WAN IPv6 address as described in [RFC6052]/the CLAT = WAN IPv6 address specified as follows/
 . s/(Section = 10)/(Section 11)/ (typo)
- In section 11,
 . = s/IANA is requested/For the IPv6 Interface ID of NAT44-enabled-CLATs =  (Section 8.3.2), IANA is requested/

Hope = it clarifies.

RD

_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-25--424843718-- From tore.anderson@redpill-linpro.com Thu Aug 16 02:42:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD521F8609 for ; Thu, 16 Aug 2012 02:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zw-IzHp9LFE for ; Thu, 16 Aug 2012 02:42:16 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79321F8497 for ; Thu, 16 Aug 2012 02:42:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 2F793182001F; Thu, 16 Aug 2012 11:42:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z59RLcYI1ECO; Thu, 16 Aug 2012 11:42:13 +0200 (CEST) Received: from envy.fud.no (cm-84.209.194.19.getinternet.no [84.209.194.19]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 8B8501820011; Thu, 16 Aug 2012 11:42:13 +0200 (CEST) Message-ID: <502CC074.6030001@redpill-linpro.com> Date: Thu, 16 Aug 2012 11:42:12 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 09:42:18 -0000 * Lorenzo Colitti > On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown > wrote: > > 2. Allocate a single IPv6 address out of the /64 subnet, map it to a > single IPv4 address, and use NAT44 to provide IPv4 access to > tethered clients > > With the choice of #2, an IPv6 address for use with 464xlat must be > selected. An assigned interface id from a reserved EUI-64 range > makes it less likely to conflict with a tethered client (since the > /64 subnet can be used with SLAAC-configured tethering clients). > Granted, the chance of conflict is already small and handled by > DAD, but it's still good policy to avoid. > > > Why not just do #2 and choose, as the interface ID, the interface ID of > the interface that is providing tethering? Does that make it hard to > implement? > > Also - if you're the tethering device, you are by definition the subnet > router. Can you pick the interface ID of :: ? A tethered Linux host with IPv6 forwarding enabled (could be done by virtualisation software, for example) will also claim :: as an interface ID, so that would likely cause a conflict. Authors: Section 8.3.2 says «Its interface ID is the 464XLAT interface ID (Section 10)». Shouldn't this say Section 11 instead? BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From bzeeb-lists@lists.zabbadoz.net Thu Aug 16 02:58:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38F521F8639 for ; Thu, 16 Aug 2012 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnjByqnkTwoO for ; Thu, 16 Aug 2012 02:58:48 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by ietfa.amsl.com (Postfix) with ESMTP id 38C1921F8627 for ; Thu, 16 Aug 2012 02:58:48 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EAF1925D39FD; Thu, 16 Aug 2012 09:58:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 451BDBE85B0; Thu, 16 Aug 2012 09:58:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id qfL0Mqf73pUP; Thu, 16 Aug 2012 09:58:44 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 171BFBE8588; Thu, 16 Aug 2012 09:58:43 +0000 (UTC) Date: Thu, 16 Aug 2012 09:58:42 +0000 (UTC) From: "Bjoern A. Zeeb" To: Tore Anderson In-Reply-To: <502CC074.6030001@redpill-linpro.com> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <502CC074.6030001@redpill-linpro.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 09:58:48 -0000 On Thu, 16 Aug 2012, Tore Anderson wrote: > A tethered Linux host with IPv6 forwarding enabled (could be done by Can we please stop modeling things after a specific OS, there are too many out there that are relevant enough. I admit and love to have runnign code but I also love to be independent in my choice on where to do my implementation. Hearing out of band that 3GPP actually makes this entire thing a lot easier as the entire /64 gets routed to the UE and the address does not need to live on the provider facing side (which it wouldn't need to anyway given v6 porposed standards) this entire discussion is really not needed. The magic EUI is just overhead; it's possible but it's overhead and unless someone convinces me that I'd save power, I don't see any reason to go the entire IANA road to get it allocated or reuse the one there for v4 mappings and bloat the draft. -1, remove it, ship it, good. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From tore.anderson@redpill-linpro.com Thu Aug 16 03:20:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D00C21F8489 for ; Thu, 16 Aug 2012 03:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXSZYMuH6vh4 for ; Thu, 16 Aug 2012 03:20:21 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id E884221F848B for ; Thu, 16 Aug 2012 03:20:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B8CDA1820030; Thu, 16 Aug 2012 12:20:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+cYNpVWsCSw; Thu, 16 Aug 2012 12:20:19 +0200 (CEST) Received: from envy.fud.no (cm-84.209.194.19.getinternet.no [84.209.194.19]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 471A01820029; Thu, 16 Aug 2012 12:20:19 +0200 (CEST) Message-ID: <502CC962.7040001@redpill-linpro.com> Date: Thu, 16 Aug 2012 12:20:18 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <502CC074.6030001@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 10:20:22 -0000 * Bjoern A. Zeeb > On Thu, 16 Aug 2012, Tore Anderson wrote: > >> A tethered Linux host with IPv6 forwarding enabled (could be done by > > Can we please stop modeling things after a specific OS, there are too > many out there that are relevant enough. I admit and love to have > runnign code but I also love to be independent in my choice on where > to do my implementation. As I understand it, any node that implements RFC 2373 section 2.6.1 and is also operating as a router must claim ::. The mention of Linux was just meant as a real-world example. There is certainly similar virtualisation software available for other operating systems, that allows the user to set up virtual internal networks and route between them and the physical ones. I don't know if those other OSes implement the subnet-router anycast address, but if they do, they will end up conflicting as well. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From despres.remi@laposte.net Thu Aug 16 03:39:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4521F85E6 for ; Thu, 16 Aug 2012 03:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08YZ-0GCgrl9 for ; Thu, 16 Aug 2012 03:39:48 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8746F21F84D9 for ; Thu, 16 Aug 2012 03:39:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id A9F1870000B5; Thu, 16 Aug 2012 12:39:46 +0200 (CEST) Received: from [192.168.1.73] (68.204.170.89.rev.sfr.net [89.170.204.68]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id D77D97000094; Thu, 16 Aug 2012 12:39:45 +0200 (CEST) X-SFR-UUID: 20120816103945882.D77D97000094@msfrf2319.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 16 Aug 2012 12:39:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <502CC074.6030001@redpill-linpro.com> To: Bjoern A. Zeeb X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 10:39:49 -0000 Hi, Bjoern, 1. As said earlier, "reserving an IPv6 address for NAT44-enabled CLATs = ensures that no conflict _can exist_ between this address and that of an = IPv6 host that has a local-scope interface IDs chosen before 464XLAT = activation". This is key where CLATs cannot have exclusive /64s, = distinct from those used for native IPv6.=20 2. Could you detail what you mean by "the address does not need to live = on the provider facing side (which it wouldn't need to anyway given v6 = proposed standards)" in cases where complete /64s are routed to UEs.=20 - Which address are you referring to? - Aren't such /64s used for both CLATs and native IPv6?=20 Thanks, RD Le 2012-08-16 =E0 11:58, Bjoern A. Zeeb a =E9crit : > On Thu, 16 Aug 2012, Tore Anderson wrote: >=20 >> A tethered Linux host with IPv6 forwarding enabled (could be done by >=20 > Can we please stop modeling things after a specific OS, there are too > many out there that are relevant enough. I admit and love to have > runnign code but I also love to be independent in my choice on where > to do my implementation. >=20 >=20 >=20 > Hearing out of band that 3GPP actually makes this entire thing a lot > easier as the entire /64 gets routed to the UE and the address does > not need to live on the provider facing side (which it wouldn't need > to anyway given v6 porposed standards) this entire discussion is > really not needed. The magic EUI is just overhead; it's possible but > it's overhead and unless someone convinces me that I'd save power, I > don't see any reason to go the entire IANA road to get it allocated or > reuse the one there for v4 mappings and bloat the draft. >=20 > -1, remove it, ship it, good. >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb You have to have = visions! > Stop bit received. Insert coin for new address family. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From evyncke@cisco.com Thu Aug 16 05:23:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7421F849C; Thu, 16 Aug 2012 05:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-z1JXHl9w-k; Thu, 16 Aug 2012 05:23:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB421F8462; Thu, 16 Aug 2012 05:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=4837; q=dns/txt; s=iport; t=1345119783; x=1346329383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FPxUUunk3PWelemJlhABuUmFNYpZiz85FHUsHzPrDIA=; b=QhS0IE5cWHTZ8PuIFZ1ENdIKIfutDG6JhhNKX6RqZAuu5zryVvbSb/El Cgy4ajva64vNB5ZHVe70C2hiYcuXdgAI8ndSfiaEm8oVXZhrR+9J02wy5 lRbWUS/msSPf13x3xip7ftz/IPphg953ffKyo4rvozsyTgzyDALY11TkU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOXkLFCtJXG+/2dsb2JhbABFuiKBB4IgAQEBAwEBAQEPAVsLDAQCAQgRBAEBAQodBycLFAkIAQEEDgUIEweHZQYLmjegHYsJhXdgA4gZjkqNGIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112178436" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 16 Aug 2012 12:23:02 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7GCN2sk006558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 12:23:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 07:23:01 -0500 From: "Eric Vyncke (evyncke)" To: Brian E Carpenter Thread-Topic: [OPSEC] [v6ops] IPv6 LL-only as WG document - feedback requested Thread-Index: Ac1zsaLKu65hBuxGQ1mVPU9TRZLT7QALZhOAAarsawAAFmF/AAAxVTWA Date: Thu, 16 Aug 2012 12:23:01 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10C6555@xmb-aln-x02.cisco.com> References: <67832B1175062E48926BF3CB27C49B24068549@xmb-aln-x12.cisco.com> <501F8D5F.5000805@gmail.com> <724010AF-C8BA-4D97-BE5D-48A53AAB960A@cisco.com> <502B549A.4010708@gmail.com> In-Reply-To: <502B549A.4010708@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--58.110100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , "opsec-chairs@ietf.org" , "'draft-behringer-lla-only@tools.ietf.org' \(draft-behringer-lla-only@tools.ietf.org\)" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] IPv6 LL-only as WG document - feedback requested X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:23:05 -0000 Brian Thanks for your suggestion about wording. I think we agree on the content a= nd your format is better :-) -=E9ric > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: mercredi 15 ao=FBt 2012 09:50 > To: Carlos Pignataro (cpignata) > Cc: 'draft-behringer-lla-only@tools.ietf.org' (draft-behringer-lla- > only@tools.ietf.org); opsec-chairs@ietf.org; opsec@ietf.org; v6ops v6ops = WG > (v6ops@ietf.org) > Subject: Re: [OPSEC] [v6ops] IPv6 LL-only as WG document - feedback > requested >=20 > Carlos, >=20 > On 14/08/2012 22:08, Carlos Pignataro (cpignata) wrote: > > Michael, Brian, > > > > Should "The Suggested Approach" http://tools.ietf.org/html/draft- > behringer-lla-only-01#section-2.1 also include some prescriptiveness or > specific recommendation regarding the use of RFC 5837, instead of includi= ng > that solution to interface identification as a "Caveats and Possible > Workarounds" only? >=20 > I have no strong opinion on this. Just indicating the existence of 5837 > seems OK, though. >=20 > Looking at the current text, it says that the loopback GUA MUST be used f= or > all > ICMPv6 messages, which is good, but it also says "ICMP error message can > also be sourced from the global scope loopback address." > That seems unnecessary in view of the MUST, but in any case, s/can/will/. >=20 > Actually my main comment on the draft is on this text in the Introduction= : >=20 > "We propose to configure neither globally routable IPv6 addresses nor > unique local addresses on infrastructure links of routers, wherever > possible. We recommend to use exclusively link-local addresses on such > links." >=20 > I suggest a more neutral approach, since some operators clearly prefer to > use GUAs: >=20 > It is possible to configure neither globally routable IPv6 addresses nor > unique local addresses on infrastructure links of routers. This document > describes how to use exclusively link-local addresses on such links. >=20 > (and s/proposes/describes how/ in the Abstract) >=20 > Thanks > Brian >=20 > > Thanks, > > > > -- Carlos. > > > > On Aug 6, 2012, at 5:24 AM, Brian E Carpenter wrote: > > > >> Hi, > >> > >>> o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo > >>> request ... can be addressed to loopback addresses of routers wi= th > >>> a global scope address. Router management can also be done over > >>> out-of-band channels. > >>> > >>> o ICMP error message can also be sourced from the global scope > >>> loopback address. > >> These statements seem too weak. Using GUAs for ICMP in particular > >> needs to have a normative MUST somewhere (preferably in a BCP). In > >> the context of this Informational draft, the language needs to state > >> a requirement ("must" not "can") even if you don't use RFC 2119 > terminology. > >> > >> This matters because packets with a LL source address MUST NOT be > >> forwarded, so a router that is misconfigured to send ICMP replies > >> with a LL source address breaks both ping and traceroute. > >> > >> I think the rule is that any packet that is *not* sent to a LL > >> address must have a GUA as the source address. That takes care of > >> ICMP, and everything else as well. > >> > >> Furthermore, that GUA needs to be associated with a prefix that > >> belongs to the organisation operating the router in question. > >> Otherwise the traceroute results can be very confusing. We discussed t= hat > on v6ops back in March. > >> > >> Regards > >> Brian Carpenter > >> > >> > >> > >> > >> On 06/08/2012 10:03, Gunter Van de Velde (gvandeve) wrote: > >>> (distributed to OPSEC WG and in cc v6ops) > >>> > >>> Dear all, > >>> > >>> During the OPSEC WG meeting last Wednesday there was consensus to ado= pt > the draft http://tools.ietf.org/html/draft-behringer-lla-only-01 as worki= ng > group document with Informational status. > >>> > >>> Please read the draft, and if there is no violent objection on the li= st, > the document will be requested to be submitted as WG document in 7 days. > >>> > >>> Ciao, > >>> G/, KK & Warren > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From cb.list6@gmail.com Thu Aug 16 06:29:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A721F865D for ; Thu, 16 Aug 2012 06:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1cEZRnIQNQK for ; Thu, 16 Aug 2012 06:29:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9221F865C for ; Thu, 16 Aug 2012 06:29:36 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so1544162lbb.31 for ; Thu, 16 Aug 2012 06:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bbqpn1cQj+ndwXNP4uItCSwndf/ZaPvYUYw0iG6z8C8=; b=Nw5KJAjARpgHeS1/S4wmiTP9xW37dtv8YgERMPt9lnGt7j+45Jw+GNUlArTFrUrTEy DeJR0Q/dzLz4JCMmc2DaVpgZO9fiR+A2TLqeK4D+KUh2cDm1pDBHuELilfMiY3G7oIU0 kXSwyCk01TBjsBgtRMdxV91Wzmvr9jkEY0pHmRv49flXpg3KXkp+IoOediKs6r3dLNS3 RL87/kwRnOOjN6gC/9r8hjjUvHljczrUsi1Y7FOhiY/mHYbssLthu/QW9kO5pPWy0DIx PPMWPyDV285lzeCWxkm6CP0m9r8aYuHjhx2p8QeyfRw9Rv0AOk9By7j/gs9n5vQQAoDM oLrA== MIME-Version: 1.0 Received: by 10.152.105.51 with SMTP id gj19mr1257876lab.38.1345123774449; Thu, 16 Aug 2012 06:29:34 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Thu, 16 Aug 2012 06:29:34 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Thu, 16 Aug 2012 06:29:34 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <502CC074.6030001@redpill-linpro.com> Date: Thu, 16 Aug 2012 06:29:34 -0700 Message-ID: From: Cameron Byrne To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=f46d04071785c146b704c7620813 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:29:38 -0000 --f46d04071785c146b704c7620813 Content-Type: text/plain; charset=ISO-8859-1 On Aug 16, 2012 2:58 AM, "Bjoern A. Zeeb" wrote: > > On Thu, 16 Aug 2012, Tore Anderson wrote: > >> A tethered Linux host with IPv6 forwarding enabled (could be done by > > > Can we please stop modeling things after a specific OS, there are too > many out there that are relevant enough. I admit and love to have > runnign code but I also love to be independent in my choice on where > to do my implementation. > > > > Hearing out of band that 3GPP actually makes this entire thing a lot > easier as the entire /64 gets routed to the UE and the address does > not need to live on the provider facing side (which it wouldn't need > to anyway given v6 porposed standards) this entire discussion is That is correct that the provider side does not consume an address from the /64 in 3gpp but may in other designs such as ftth, but i believe the challenege is on tetherside conflicts for 3gpp networks.... PC's and tablets that tether to a phone may have conflicting addresses. CB > really not needed. The magic EUI is just overhead; it's possible but > it's overhead and unless someone convinces me that I'd save power, I > don't see any reason to go the entire IANA road to get it allocated or > reuse the one there for v4 mappings and bloat the draft. > > -1, remove it, ship it, good. > > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d04071785c146b704c7620813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 16, 2012 2:58 AM, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote= :
>
> On Thu, 16 Aug 2012, Tore Anderson wrote:
>
>> A tethered Linux host with IPv6 forwarding enabled (could be done = by
>
>
> Can we please stop modeling things after a specific OS, there are too<= br> > many out there that are relevant enough. =A0I admit and love to have > runnign code but I also love to be independent in my choice on where > to do my implementation.
>
>
>
> Hearing out of band that 3GPP actually makes this entire thing a lot > easier as the entire /64 gets routed to the UE and the address does > not need to live on the provider facing side (which it wouldn't ne= ed
> to anyway given v6 porposed standards) this entire discussion is

That is correct that the provider side does not consume an address from = the /64 in 3gpp but may in other designs such as ftth, but i believe the ch= allenege is on tetherside conflicts for 3gpp networks.... PC's and tabl= ets that tether to a phone may have conflicting addresses.

CB

> really not needed. =A0The magic EUI is just overhead; it's poss= ible but
> it's overhead and unless someone convinces me that I'd save po= wer, I
> don't see any reason to go the entire IANA road to get it allocate= d or
> reuse the one there for v4 mappings and bloat the draft.
>
> -1, remove it, ship it, good.
>
>
> /bz
>
> --
> Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 You have to have visions!
> =A0 =A0 =A0 =A0 =A0Stop bit received. Insert coin for new address fami= ly.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--f46d04071785c146b704c7620813-- From dan-v6ops@drown.org Thu Aug 16 07:05:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF3921F85C4 for ; Thu, 16 Aug 2012 07:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGku1CATyfSH for ; Thu, 16 Aug 2012 07:05:46 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 773FC21F84EC for ; Thu, 16 Aug 2012 07:05:43 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id DAF76C12B; Thu, 16 Aug 2012 10:05:42 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Thu, 16 Aug 2012 09:05:42 -0500 Message-ID: <20120816090542.15476bo43zcr7aww@mail.drown.org> Date: Thu, 16 Aug 2012 09:05:42 -0500 From: Dan Drown To: Lorenzo Colitti References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120807133908kawashimam@mail.jp.nec.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:05:48 -0000 Quoting Lorenzo Colitti : > Why not just do #2 and choose, as the interface ID, the interface ID of the > interface that is providing tethering? Does that make it hard to implement? That may work for some implementations, but not for android-clat. The clat function needs its own address, and it cannot be any address that the handset considers local. From internet-drafts@ietf.org Thu Aug 16 09:05:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8746821F849D; Thu, 16 Aug 2012 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDDCbrxTJKi9; Thu, 16 Aug 2012 09:05:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0562021F84A5; Thu, 16 Aug 2012 09:05:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816160507.28949.98425.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 09:05:07 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:05:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Filename : draft-ietf-v6ops-6204bis-10.txt Pages : 22 Date : 2012-08-16 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Thu Aug 16 09:22:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC321F8471 for ; Thu, 16 Aug 2012 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 719UpjgfJ-sv for ; Thu, 16 Aug 2012 09:22:55 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5821F8476 for ; Thu, 16 Aug 2012 09:22:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0eXR9Gcsg7xOIBFgwO30NAGG6RXlWC@postini.com; Thu, 16 Aug 2012 09:22:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6543A1B82F2 for ; Thu, 16 Aug 2012 09:22:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 58BE3190052 for ; Thu, 16 Aug 2012 09:22:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 09:22:52 -0700 From: Ted Lemon To: Operations Operations Thread-Topic: I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thKDNXXf7km0GI992qo154CQ== Date: Thu, 16 Aug 2012 16:22:51 +0000 Message-ID: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:22:57 -0000 Something that came up in discussions with an ISP recently: the CPE router = doc doesn't require that the CPE router retain DHCP configuration between r= eboots. This was identified as an issue in the case of power outage recov= ery=97if the DHCP server is overloaded because a large number of machines c= ome back at once, the CPE router might fail to use the network for an exten= ded period of time, even though it still, in theory, has a valid configurat= ion. Is this something that's been discussed? Any thoughts?= From shemant@cisco.com Thu Aug 16 09:45:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53E21F8491 for ; Thu, 16 Aug 2012 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn82WONnaNEV for ; Thu, 16 Aug 2012 09:45:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9021F8472 for ; Thu, 16 Aug 2012 09:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1362; q=dns/txt; s=iport; t=1345135514; x=1346345114; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lbnrh5Rkmmuv8p0r7vjrT0sUeK9MNvc8jD7q5Vpb4II=; b=QImPGAQnkj8phT+/v0D5jTRg6WaZ0ZB9VCM4iaqTSQ/5DlHNrtBcU44c vkaWU8k30k5hOXyuUqxKit3XeXTBGn3nXlaEmFBo6UxavNRzMslF3wxdE YHkGNirQM8ZIh6EGjzSsv5sh+Yx48NiHbRwPJ0lXifDqnTHmaV1+6QIdB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHAiLVCtJV2Z/2dsb2JhbABFui2BB4IgAQEBBBIBJ0sEAgEIEQQBAQsUCQcyFAkIAgQBEggah2uaOKA1iwobhVxgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112269310" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 16 Aug 2012 16:45:13 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7GGjDUh019708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 16:45:13 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 11:45:12 -0500 From: "Hemant Singh (shemant)" To: Ted Lemon , Operations Operations Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thKDNXXf7km0GI992qo154CZdcoxZg Date: Thu, 16 Aug 2012 16:45:12 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907055A@xmb-rcd-x06.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> In-Reply-To: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.175.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--32.812200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:45:14 -0000 Ted, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 16, 2012 12:23 PM To: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt >Something that came up in discussions with an ISP recently: the CPE router= doc doesn't require that the CPE router retain DHCP configuration between = reboots. >This was identified as an issue in the case of power outage rec= overy-if the DHCP server is overloaded because a large number of machines c= ome back at once, the >CPE router might fail to use the network for an exte= nded period of time, even though it still, in theory, has a valid configura= tion. >Is this something that's been discussed? Any thoughts? Sorry, I am not aware of the issue you speak of. If more details can be pro= vided, we can discuss the issue. However, there is no text in rfc6204bis th= at mandates the CPE router retain DHCP configuration between reboots? The = subtle point is with one DHCPv6 requirement in W-5 mandates the DHCPv6 DUID= from RFC 3315 be persistent between reboots. However, for the DUID persis= tence, the CPE does not need to retain the DUID between reboots. The CPE j= ust generates the DUID-LL and the DUID is persistent across CPE reboots. Thanks, Hemant From volz@cisco.com Thu Aug 16 09:53:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F81121F85DB for ; Thu, 16 Aug 2012 09:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DaQOCPHijtW for ; Thu, 16 Aug 2012 09:53:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5F21F85DA for ; Thu, 16 Aug 2012 09:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1734; q=dns/txt; s=iport; t=1345136006; x=1346345606; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nQILNOcaDt5ufnG8oT8UYBePKuI7UdVaAYkxER4Q8s0=; b=d2sOGqY6A4Oqb4YB2byPVrcWqWbDJn8NlqfK686j/9LTV9B8T2Mqq2p4 59vNdeXrOz5b1i4gMKgdK4d3CXjMb9s/UG9g0exIfVA9/ykY8ikmPfp9v ow5JS+RKLFGDvgLr09D+/ggUZdGVy0Ma8htmq4KqMYMJh5KHWaw2R7h9r Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABwkLVCtJV2Z/2dsb2JhbABFui2BB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHawuaMaAxBIsKAgMWhVxgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112288847" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 16 Aug 2012 16:53:25 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7GGrPTS001187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 16:53:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 11:53:24 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Operations Operations Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thIfRCWZa9IkWQ7xGC17FvmpdcpYew Date: Thu, 16 Aug 2012 16:53:24 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> In-Reply-To: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.113] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--35.425100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:53:26 -0000 Ted: Can you define what you mean by reboots? For example, is this restricted to= the eRouter (eCM+eRouter) when the eCM triggers a reboot because it detect= ed the cable link went down? This does seem like a worthwhile recommendatio= n - though there are pros and cons to it because one reason the eCM might h= ave rebooted was because of a configuration change and if the server isn't = able to handle the load, the Confirm (3315)/Rebind (3633) would also not be= processed leaving the CPE without definitive information. If this were to include power failures, how would the CPE know how much tim= e has elapsed while it was down which could cause more significant issues b= ecause of the lease time -- and having to maintain a clock via battery back= up is probably not a good idea. - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 16, 2012 12:23 PM To: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Something that came up in discussions with an ISP recently: the CPE router = doc doesn't require that the CPE router retain DHCP configuration between r= eboots. This was identified as an issue in the case of power outage recov= ery-if the DHCP server is overloaded because a large number of machines com= e back at once, the CPE router might fail to use the network for an extende= d period of time, even though it still, in theory, has a valid configuratio= n. Is this something that's been discussed? Any thoughts? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Thu Aug 16 09:53:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAB521F8609 for ; Thu, 16 Aug 2012 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdmxlH5Dettq for ; Thu, 16 Aug 2012 09:53:42 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEE21F85E0 for ; Thu, 16 Aug 2012 09:53:41 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0llUwHWnlsXBPqnYL/UQKD0oO4swXm@postini.com; Thu, 16 Aug 2012 09:53:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D115A1B82F9 for ; Thu, 16 Aug 2012 09:53:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C6C1F190052; Thu, 16 Aug 2012 09:53:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 09:53:40 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe86DshH7cT8l7kexar9Ce7gUT5ddHRmA Date: Thu, 16 Aug 2012 16:53:40 +0000 Message-ID: References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <75B6FA9F576969419E42BECB86CB1B8907055A@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907055A@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_B51AAEBDF29D4009BD15A78CD1133438nominumcom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:53:42 -0000 --_000_B51AAEBDF29D4009BD15A78CD1133438nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 12:45 PM, Hemant Singh (shemant) wrote: Sorry, I am not aware of the issue you speak of. If more details can be pro= vided, we can discuss the issue. However, there is no text in rfc6204bis th= at mandates the CPE router retain DHCP configuration between reboots? The = subtle point is with one DHCPv6 requirement in W-5 mandates the DHCPv6 DUID= from RFC 3315 be persistent between reboots. However, for the DUID persis= tence, the CPE does not need to retain the DUID between reboots. The CPE j= ust generates the DUID-LL and the DUID is persistent across CPE reboots. No, I'm talking about remembering DHCP configuration information across reb= oots. If DHCP hands out an address with a one-week lifetime, and then the= re's a power outage a day later, the CPE should have retained that address = and should go through the RFC3315 Confirm processing to validate it, but sh= ould use it anyway unless the Confirm gets a negative response. Similarly= with Prefix Delegation (Confirm processing for PD is something that's not = yet standardized, but it's in process in the working group, so you'd have t= o decide whether you can tolerate a normative reference to that draft). --_000_B51AAEBDF29D4009BD15A78CD1133438nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <668D669865677643B3A0DDDCB499776C@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 12:45 PM, Hemant Singh (shemant) wrote:
Sorry, I am not aware of the issue you speak of. If more details can be provided,= we can discuss the issue. However, there is no text in rfc6204bis that man= dates the CPE router retain DHCP configuration between reboots?  The s= ubtle point is with one DHCPv6 requirement in W-5 mandates the DHCPv6 DUID from RFC 3315 be persistent between reboot= s.  However, for the DUID persistence, the CPE does not need to retain= the DUID between reboots.  The CPE just generates the DUID-LL and the= DUID is persistent across CPE reboots.

No, I'm talking about remembering DHCP configuration information acros= s reboots.   If DHCP hands out an address with a one-week lifetime, an= d then there's a power outage a day later, the CPE should have retained tha= t address and should go through the RFC3315 Confirm processing to validate it, but should use it anyway unless the Con= firm gets a negative response.   Similarly with Prefix Delegation (Con= firm processing for PD is something that's not yet standardized, but it's i= n process in the working group, so you'd have to decide whether you can tolerate a normative reference to that draf= t).

--_000_B51AAEBDF29D4009BD15A78CD1133438nominumcom_-- From Ted.Lemon@nominum.com Thu Aug 16 10:07:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B6821F8599 for ; Thu, 16 Aug 2012 10:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg0mHXisMA31 for ; Thu, 16 Aug 2012 10:07:00 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4B21F84F2 for ; Thu, 16 Aug 2012 10:06:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0orgdvSWGdxhPTE0KWMR71/l3Pxs4M@postini.com; Thu, 16 Aug 2012 10:07:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C476A1B82F2 for ; Thu, 16 Aug 2012 10:06:53 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BAC60190052; Thu, 16 Aug 2012 10:06:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 10:06:53 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8+olXva8xUzuU+K+l5W0q4CfZddIMYA Date: Thu, 16 Aug 2012 17:06:53 +0000 Message-ID: <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_9E042EC607B94F7CA50B6A9F01BCD668nominumcom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:07:01 -0000 --_000_9E042EC607B94F7CA50B6A9F01BCD668nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote: If this were to include power failures, how would the CPE know how much tim= e has elapsed while it was down which could cause more significant issues b= ecause of the lease time -- and having to maintain a clock via battery back= up is probably not a good idea. I'm specifically referring to power outages. If the CPE doesn't get a res= ponse from a Confirm, doesn't it get to use the address? The question abo= ut the clock is interesting, but it seems like a safe assumption that a pow= er cycle is short; if it's long, and wasn't the result of a power outage, t= he Confirm transaction will prevent anything bad from happening. --_000_9E042EC607B94F7CA50B6A9F01BCD668nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4ED094E368CA354BA6E628E91C8C9321@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote:
If this were to include power failures, how would the CPE know how much time = has elapsed while it was down which could cause more significant issues bec= ause of the lease time -- and having to maintain a clock via battery backup= is probably not a good idea.

I'm specifically referring to power outages.   If the CPE doesn't= get a response from a Confirm, doesn't it get to use the address?   T= he question about the clock is interesting, but it seems like a safe assump= tion that a power cycle is short; if it's long, and wasn't the result of a power outage, the Confirm transaction wil= l prevent anything bad from happening.

--_000_9E042EC607B94F7CA50B6A9F01BCD668nominumcom_-- From Ted.Lemon@nominum.com Thu Aug 16 10:10:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2276521F85DA for ; Thu, 16 Aug 2012 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqizA+Fhk646 for ; Thu, 16 Aug 2012 10:10:30 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0021F853F for ; Thu, 16 Aug 2012 10:10:23 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0pfwwTGbOoxfeRbyMsn87doobh7yWx@postini.com; Thu, 16 Aug 2012 10:10:23 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B3B141B82F2 for ; Thu, 16 Aug 2012 10:10:22 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AAC2C190052; Thu, 16 Aug 2012 10:10:22 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 10:10:22 -0700 From: Ted Lemon To: David Miles Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe86DshH7cT8l7kexar9Ce7gUT5ddHRmAgAABU4CAAANXAA== Date: Thu, 16 Aug 2012 17:10:21 +0000 Message-ID: References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <75B6FA9F576969419E42BECB86CB1B8907055A@xmb-rcd-x06.cisco.com> <809586C991144B8B8E26FDD581721FFC@pheynix.net> In-Reply-To: <809586C991144B8B8E26FDD581721FFC@pheynix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_D4F0F7911E4F4421A7207D28B1A8A0D4nominumcom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:10:31 -0000 --_000_D4F0F7911E4F4421A7207D28B1A8A0D4nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 12:58 PM, David Miles wrote: Is this saving from 4 messages to 2 messages enough? Perhaps there are bett= er ways to address the DHCP scalability issue through the use of more distr= ibuted DHCP infrastructure. The point is that if you don't get a response to a Confirm, presumably you = can continue using the address, whereas if you toss your old state and star= t over, you can't. It's not strictly a scalability issue=97any sort of prolonged outage on the= DHCP server following a power failure would do it. The idea is just to h= ave a fallback position in case for whatever reason the DHCP server can't r= espond. For instance, suppose there's a temporary DHCP server outage coin= cident with the CPE device being power cycled. We want it to come back up= even so, right? --_000_D4F0F7911E4F4421A7207D28B1A8A0D4nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <71D8B5CC878C60458842A1EDDAE1C2E9@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 12:58 PM, David Miles wrote:
Is this saving from 4 messages to 2 messages enough? Perhaps there are= better ways to address the DHCP scalability issue through the use of more = distributed DHCP infrastructure.

The point is that if you don't get a response to a Confirm, presumably= you can continue using the address, whereas if you toss your old state and= start over, you can't.

It's not strictly a scalability issue=97any sort of prolonged outage o= n the DHCP server following a power failure would do it.   The idea is= just to have a fallback position in case for whatever reason the DHCP serv= er can't respond.   For instance, suppose there's a temporary DHCP server outage coincident with the CPE device bein= g power cycled.   We want it to come back up even so, right?

--_000_D4F0F7911E4F4421A7207D28B1A8A0D4nominumcom_-- From volz@cisco.com Thu Aug 16 10:11:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFE21F8644 for ; Thu, 16 Aug 2012 10:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSSbnnl28fAc for ; Thu, 16 Aug 2012 10:11:03 -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 6B51E21F8650 for ; Thu, 16 Aug 2012 10:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=10532; q=dns/txt; s=iport; t=1345137063; x=1346346663; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ePskM4UL3P4nTU4+9oTkLM0TTIzzVVNxdmvzV9zFWrI=; b=MfMOKSs9ZScWK12ulp2wdccdDrQpYTZov2tQv7u9lXZqm5T090a5vQx2 u5ou+q59bGqXyJKcAFqv9RwJUdLCUQ5PhJyjcmxc699UUBNb8u7Yqn4hq QCAPSmuBDlNMriZRnujimwKzU+FN41GSG8MBy7yzQe329FE3A3wPMwwS2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH8oLVCtJXG8/2dsb2JhbABFgkq3Y4EHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIGodrmjegN4sKAgMWhVxgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208,217";a="112306865" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2012 17:11:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GHB2xc023109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 17:11:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 12:11:01 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thIfRCWZa9IkWQ7xGC17FvmpdcpYewgABZxID//6xuEA== Date: Thu, 16 Aug 2012 17:11:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> In-Reply-To: <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.113] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--40.762000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4ECDB6xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:11:05 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4ECDB6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Confirm doesn't return remaining lifetimes or confirm actual leases - a= ll it confirms is that the client hasn't moved (i.e., the prefixes being us= ed by the client are still valid for where it is connected). So, if the lease have indeed expired, there would be nothing to indicate th= at. Again, I think if the CPE knows it is just a reboot or has battery backup t= o keep a clock running, it would be fine for it to retain the lease informa= tion across reboots. But if not, this would be a bad idea - unless the client were to do a Renew= or Rebind when it came back instead of using Confirm. - Bernie From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, August 16, 2012 1:07 PM To: Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote: If this were to include power failures, how would the CPE know how much tim= e has elapsed while it was down which could cause more significant issues b= ecause of the lease time -- and having to maintain a clock via battery back= up is probably not a good idea. I'm specifically referring to power outages. If the CPE doesn't get a res= ponse from a Confirm, doesn't it get to use the address? The question abo= ut the clock is interesting, but it seems like a safe assumption that a pow= er cycle is short; if it's long, and wasn't the result of a power outage, t= he Confirm transaction will prevent anything bad from happening. --_000_489D13FBFA9B3E41812EA89F188F018E0F4ECDB6xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Confirm doesn’t= return remaining lifetimes or confirm actual leases – all it confirm= s is that the client hasn’t moved (i.e., the prefixes being used by the client are still valid for where it is connected).

 <= /p>

So, if the lease have ind= eed expired, there would be nothing to indicate that.

 <= /p>

Again, I think if the CPE= knows it is just a reboot or has battery backup to keep a clock running, i= t would be fine for it to retain the lease information across reboots.

 <= /p>

But if not, this would be= a bad idea – unless the client were to do a Renew or Rebind when it = came back instead of using Confirm.

 <= /p>

- =          Bernie=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, August 16, 2012 1:07 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wro= te:

If t= his were to include power failures, how would the CPE know how much time ha= s elapsed while it was down which could cause more significant issues because of the lease time -- and having to maintain a clock via bat= tery backup is probably not a good idea.

 

I'm specifically referring to power outages.   = If the CPE doesn't get a response from a Confirm, doesn't it get to use the= address?   The question about the clock is interesting, but it seems = like a safe assumption that a power cycle is short; if it's long, and wasn't the result of a power outage, the Confirm = transaction will prevent anything bad from happening.

 

--_000_489D13FBFA9B3E41812EA89F188F018E0F4ECDB6xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Thu Aug 16 10:32:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF1621F85B8 for ; Thu, 16 Aug 2012 10:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY-6BWO6o4RS for ; Thu, 16 Aug 2012 10:32:34 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4755421F85AE for ; Thu, 16 Aug 2012 10:32:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0usUcWMgXCZdHf9ZPQCBSGUM7HIOJ5@postini.com; Thu, 16 Aug 2012 10:32:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0EE5D1B8313 for ; Thu, 16 Aug 2012 10:32:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 05065190052; Thu, 16 Aug 2012 10:32:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 10:32:33 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8+olXva8xUzuU+K+l5W0q4CfZddIMYAgAABKgCAAAYBgA== Date: Thu, 16 Aug 2012 17:32:32 +0000 Message-ID: <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_53DAE40CAADF490EB471CEB32407D651nominumcom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:32:35 -0000 --_000_53DAE40CAADF490EB471CEB32407D651nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrote: The Confirm doesn=92t return remaining lifetimes or confirm actual leases = =96 all it confirms is that the client hasn=92t moved (i.e., the prefixes b= eing used by the client are still valid for where it is connected). So, if the lease have indeed expired, there would be nothing to indicate th= at. Again, I think if the CPE knows it is just a reboot or has battery backup t= o keep a clock running, it would be fine for it to retain the lease informa= tion across reboots. But if not, this would be a bad idea =96 unless the client were to do a Ren= ew or Rebind when it came back instead of using Confirm. I would be happy to see a requirement that says that if the device has a cl= ock that survives power cycles, it should Confirm the binding rather than s= tarting from scratch. --_000_53DAE40CAADF490EB471CEB32407D651nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B94EF26962FFC4D8F7A1C85813C9B2D@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrote:
The Confirm doesn=92t return remaining lifetimes or confi= rm actual leases =96 all it confirms is that the client hasn=92t moved (i.e= ., the prefixes being used by the client are still valid for where it is connected).
 
So, if the lease have indeed expired, there would be noth= ing to indicate that.
 
Again, I think if the CPE knows it is just a reboot or ha= s battery backup to keep a clock running, it would be fine for it to retain= the lease information across reboots.
 
But if not, this would be a bad idea =96 unless the clien= t were to do a Renew or Rebind when it came back instead of using Confirm.<= /span>

I would be happy to see a requirement that says that if the device has= a clock that survives power cycles, it should Confirm the binding rather t= han starting from scratch.

--_000_53DAE40CAADF490EB471CEB32407D651nominumcom_-- From bs7652@att.com Thu Aug 16 10:54:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7921F8606 for ; Thu, 16 Aug 2012 10:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2vpJ+cuZZvh for ; Thu, 16 Aug 2012 10:54:04 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 107C121F8678 for ; Thu, 16 Aug 2012 10:53:58 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 6b33d205.5f09e940.916890.00-523.2502842.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 16 Aug 2012 17:53:58 +0000 (UTC) X-MXL-Hash: 502d33b662f7ac19-8ae8fb9ebff8a41ff8280756c66c1db3d39df5ad Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id fa33d205.0.916828.00-398.2502674.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 16 Aug 2012 17:53:52 +0000 (UTC) X-MXL-Hash: 502d33b0712a0c78-c511ac50742a7be15bf4e28b6861018c700484f3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GHrlQZ032222; Thu, 16 Aug 2012 13:53:51 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GHqubp028997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 13:53:40 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 16 Aug 2012 13:50:09 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 13:50:09 -0400 From: "STARK, BARBARA H" To: Ted Lemon , "Bernie Volz (volz)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thBbFPT8Jz20arHpsDPdcX0pdc6sMAgAADxYD//8RvEA== Date: Thu, 16 Aug 2012 17:50:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61116AD97@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> In-Reply-To: <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.69.203] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61116AD97GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=hQ1IpePRphcA:10 a=VXWucX7Kxq8A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=utJyrrup0sIA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=48vgC7mUAAAA:8 a=QaaShx4KPvrbCbIlnw4A:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=EAK5hnoFZnYZvQGV:21 a=] X-AnalysisOut: [0jk4LdxUneY09QlE:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gK] X-AnalysisOut: [O2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4Au] X-AnalysisOut: [Cg-hUA:10] Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:54:06 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61116AD97GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Service providers have been dealing with "simultaneous" mass repowering of = routers for a long time. There currently exist requirements for multiple re= tries of all necessary protocols, at random intervals (within reasonable li= mits). I believe that all requirements necessary for such staggered retries= are in place, and are sufficient for dealing with mass coming-on-line. I a= lso believe that maintaining DHCP configuration across reboots is undesirab= le. If we were to say anything, I would prefer to forbid it, rather than ma= ndate it. But, I don't think we need to be saying anything at all, because,= thankfully, I'm not aware of devices that maintain DHCP config across rebo= ots. I don't believe that the scenario of mass power outage that takes out massi= ve quantities of CE routers + the DHCP server, but that leaves all other ac= cess network elements intact is a probable scenario. As such, I don't think= it's worthy of a requirement. It ain't broke. Please, let's not "fix" it. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 16, 2012 1:07 PM To: Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote: If this were to include power failures, how would the CPE know how much tim= e has elapsed while it was down which could cause more significant issues b= ecause of the lease time -- and having to maintain a clock via battery back= up is probably not a good idea. I'm specifically referring to power outages. If the CPE doesn't get a res= ponse from a Confirm, doesn't it get to use the address? The question abo= ut the clock is interesting, but it seems like a safe assumption that a pow= er cycle is short; if it's long, and wasn't the result of a power outage, t= he Confirm transaction will prevent anything bad from happening. --_000_2D09D61DDFA73D4C884805CC7865E61116AD97GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Service providers have been dealing wit= h “simultaneous” mass repowering of routers for a long time. Th= ere currently exist requirements for multiple retries of all necessary protocols, at random intervals (within reasonable limits). I believe that = all requirements necessary for such staggered retries are in place, and are= sufficient for dealing with mass coming-on-line. I also believe that maint= aining DHCP configuration across reboots is undesirable. If we were to say anything, I would prefer to forb= id it, rather than mandate it. But, I don’t think we need to be sayin= g anything at all, because, thankfully, I’m not aware of devices that= maintain DHCP config across reboots.

 

I don’t believe that the scenario= of mass power outage that takes out massive quantities of CE routers += the DHCP server, but that leaves all other access network elements intact is a probable scenario. As such, I don’t think it’s wor= thy of a requirement.

 

It ain’t broke. Please, let’= ;s not “fix” it.

Barbara

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, August 16, 2012 1:07 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wro= te:

If t= his were to include power failures, how would the CPE know how much time ha= s elapsed while it was down which could cause more significant issues because of the lease time -- and having to maintain a clock via bat= tery backup is probably not a good idea.

 

I'm specifically referring to power outages.   = If the CPE doesn't get a response from a Confirm, doesn't it get to use the= address?   The question about the clock is interesting, but it seems = like a safe assumption that a power cycle is short; if it's long, and wasn't the result of a power outage, the Confirm = transaction will prevent anything bad from happening.

 

--_000_2D09D61DDFA73D4C884805CC7865E61116AD97GAALPA1MSGUSR9NIT_-- From volz@cisco.com Thu Aug 16 10:57:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCFD21F856D for ; Thu, 16 Aug 2012 10:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jArJvB3h3vtL for ; Thu, 16 Aug 2012 10:57:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA0421F84D9 for ; Thu, 16 Aug 2012 10:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=10626; q=dns/txt; s=iport; t=1345139840; x=1346349440; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=klbrNYechBMuM9ZUZEoaSk2+l1PuihvROD3tWGe1Z/I=; b=IRFq+vTxkAwkGZ23/iqUPl86rqWyjL8nCwUR86W/2mvJAPNYxxsxc3iB pBsdN7MkOytjGtOcJgSGHPtQhCbEaipyFdgjQtm4rOoat4tparWiaklk9 xtuKbW1DesZ9uYCHgpdwQmjh1LUjfQotxr6ETOolARinkl079mvhA2igO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANczLVCtJXG8/2dsb2JhbABFgkq3Y4EHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIEweHa5pHoECLCgIDFoVcYAOje4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208,217";a="112314212" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 16 Aug 2012 17:57:19 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GHvJiL024799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 17:57:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 12:57:18 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thIfRCWZa9IkWQ7xGC17FvmpdcpYewgABZxID//6xuEIAAWr0A//+yNcA= Date: Thu, 16 Aug 2012 17:57:18 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4ECEA8@xmb-rcd-x04.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> In-Reply-To: <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.113] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--37.414500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4ECEA8xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:57:21 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4ECEA8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that would be fine with me as well. Though not sure how realistic it w= ill be as keeping the cost of these devices down is likely a key factor (a = less costly solution is likely a capacitor that would keep the clock alive = for a short duration). And, given where this document is in the pipeline, do you really think this= is worth it? - Bernie From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, August 16, 2012 1:33 PM To: Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrote: The Confirm doesn't return remaining lifetimes or confirm actual leases - a= ll it confirms is that the client hasn't moved (i.e., the prefixes being us= ed by the client are still valid for where it is connected). So, if the lease have indeed expired, there would be nothing to indicate th= at. Again, I think if the CPE knows it is just a reboot or has battery backup t= o keep a clock running, it would be fine for it to retain the lease informa= tion across reboots. But if not, this would be a bad idea - unless the client were to do a Renew= or Rebind when it came back instead of using Confirm. I would be happy to see a requirement that says that if the device has a cl= ock that survives power cycles, it should Confirm the binding rather than s= tarting from scratch. --_000_489D13FBFA9B3E41812EA89F188F018E0F4ECEA8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, that would be fine w= ith me as well. Though not sure how realistic it will be as keeping the cos= t of these devices down is likely a key factor (a less costly solution is likely a capacitor that would keep the clock alive for a short= duration).

 <= /p>

And, given where this doc= ument is in the pipeline, do you really think this is worth it?

 <= /p>

- =          Bernie=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, August 16, 2012 1:33 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrot= e:

The Confirm doesn’t= return remaining lifetimes or confirm actual leases – all it confirm= s is that the client hasn’t moved (i.e., the prefixes being used by the client are still valid for where it is connected).

 <= /p>

So, if the lease have ind= eed expired, there would be nothing to indicate that.

 <= /p>

Again, I think if the CPE= knows it is just a reboot or has battery backup to keep a clock running, i= t would be fine for it to retain the lease information across reboots.

 <= /p>

But if not, this would be= a bad idea – unless the client were to do a Renew or Rebind when it = came back instead of using Confirm.

 

I would be happy to see a requirement that says that= if the device has a clock that survives power cycles, it should Confirm th= e binding rather than starting from scratch.

 

--_000_489D13FBFA9B3E41812EA89F188F018E0F4ECEA8xmbrcdx04ciscoc_-- From warren@kumari.net Thu Aug 16 12:40:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154A21F852C; Thu, 16 Aug 2012 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbC0TuujoB4g; Thu, 16 Aug 2012 12:40:21 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 68DC521F84F7; Thu, 16 Aug 2012 12:40:21 -0700 (PDT) Received: from [192.168.1.118] (unknown [66.84.81.72]) by vimes.kumari.net (Postfix) with ESMTPSA id 61E371B4017A; Thu, 16 Aug 2012 15:40:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> Date: Thu, 16 Aug 2012 15:40:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> To: Lee Howard X-Mailer: Apple Mail (2.1278) Cc: 'v6ops v6ops WG' , opsec@ietf.org, 'Fernando Gont' Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:40:22 -0000 On Aug 14, 2012, at 2:58 PM, Lee Howard wrote: > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Eric Vyncke (evyncke) > Sent: Tuesday, August 14, 2012 4:43 AM > To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops v6ops WG = (v6ops@ietf.org) > Cc: Fernando Gont > Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: = draft-gont-opsec-ipv6-implications-on-ipv4-nets > =20 > - 1.0 please avoid all discussion about NAPT being = =91minimal/simple=92 security, the days of scanning are over and have = been replaced by malware download/email propagated > =20 > =20 > This is demonstrably false, and I can send you logs of scanning = attempts foiled by NAPT. NAT is crap security, but it=92s not zero = security.=20 >=20 Heretic! Actually, I'd go so far as to drop the "crap" from the above -- while it = isn't "real" security (whatever that means) it has become cool to simply = beat on the NAT.=20 Yes, it's not awesome, but it *does* help prevent the secretary's = desktop from getting owned quite as often. Yes, he should have it = patched, yes it should be capable of protecting itself, yes, there = should be a "real" security widget in front of it, but, well=85=20 W > Lee > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --=20 With Feudalism, it's your Count that votes. From shemant@cisco.com Thu Aug 16 12:46:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DFB21F845D for ; Thu, 16 Aug 2012 12:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIKnuyT8XEPp for ; Thu, 16 Aug 2012 12:46:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B57BF21F845F for ; Thu, 16 Aug 2012 12:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=12605; q=dns/txt; s=iport; t=1345146393; x=1346355993; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wk10qTEq7uho0de2CFnyHG0L+yqO2p1dDHcdKjzxQJU=; b=Mcru6Ap4GfFmrFy/SwgTGH1tjvW8px77K1oLhnSV/HX8x+BqqmMT9yfO VD7ISRTqAgnDU5CckKKxOQNJ530PMyOESuEm74iTIl+DXbKdonsumbg5b MuNutSOAOjikc/k+gRi06JS7jSgJsT/AMJ6qpXltbWNp5BBFJuMN2MN5F 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGVNLVCtJV2Y/2dsb2JhbABFgkq3ZIEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBMHh2uaWaBGiwoCAxaFXGADo3uBZoJf X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208,217";a="112383936" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2012 19:46:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GJkUFc000884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 19:46:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 14:46:29 -0500 From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , Ted Lemon Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thKDNXXf7km0GI992qo154CZdcpYewgABZxID//6xuEIAAWr0A//+yNcCAAB7/IA== Date: Thu, 16 Aug 2012 19:46:28 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890708FB@xmb-rcd-x06.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECEA8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4ECEA8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.175.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--39.562300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B890708FBxmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:46:35 -0000 --_000_75B6FA9F576969419E42BECB86CB1B890708FBxmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The -10 was published today to address review in the IESG. Thus we really = should stay away from adding any new requirement to rfc6204bis. Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Thursday, August 16, 2012 1:57 PM To: Ted Lemon Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Yes, that would be fine with me as well. Though not sure how realistic it w= ill be as keeping the cost of these devices down is likely a key factor (a = less costly solution is likely a capacitor that would keep the clock alive = for a short duration). And, given where this document is in the pipeline, do you really think this= is worth it? - Bernie From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, August 16, 2012 1:33 PM To: Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrote: The Confirm doesn't return remaining lifetimes or confirm actual leases - a= ll it confirms is that the client hasn't moved (i.e., the prefixes being us= ed by the client are still valid for where it is connected). So, if the lease have indeed expired, there would be nothing to indicate th= at. Again, I think if the CPE knows it is just a reboot or has battery backup t= o keep a clock running, it would be fine for it to retain the lease informa= tion across reboots. But if not, this would be a bad idea - unless the client were to do a Renew= or Rebind when it came back instead of using Confirm. I would be happy to see a requirement that says that if the device has a cl= ock that survives power cycles, it should Confirm the binding rather than s= tarting from scratch. --_000_75B6FA9F576969419E42BECB86CB1B890708FBxmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The -10 was published tod= ay to address review in the IESG.  Thus we really should stay away fro= m adding any new requirement to rfc6204bis.

 <= /p>

Hemant<= /p>

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Thursday, August 16, 2012 1:57 PM
To: Ted Lemon
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

Yes, that would be fine w= ith me as well. Though not sure how realistic it will be as keeping the cos= t of these devices down is likely a key factor (a less costly solution is likely a capacitor that would keep the clock alive for a short= duration).

 <= /p>

And, given where this doc= ument is in the pipeline, do you really think this is worth it?

 <= /p>

- =        Bernie=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, August 16, 2012 1:33 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrot= e:

The Confirm doesn’t= return remaining lifetimes or confirm actual leases – all it confirm= s is that the client hasn’t moved (i.e., the prefixes being used by the client are still valid for where it is connected).

 <= /p>

So, if the lease have ind= eed expired, there would be nothing to indicate that.

 <= /p>

Again, I think if the CPE= knows it is just a reboot or has battery backup to keep a clock running, i= t would be fine for it to retain the lease information across reboots.

 <= /p>

But if not, this would be= a bad idea – unless the client were to do a Renew or Rebind when it = came back instead of using Confirm.

 

I would be happy to see a requirement that says that= if the device has a clock that survives power cycles, it should Confirm th= e binding rather than starting from scratch.

 

--_000_75B6FA9F576969419E42BECB86CB1B890708FBxmbrcdx06ciscocom_-- From Ted.Lemon@nominum.com Thu Aug 16 12:53:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC421F8644 for ; Thu, 16 Aug 2012 12:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq3A85mZsEEz for ; Thu, 16 Aug 2012 12:53:08 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F1FA321F85C4 for ; Thu, 16 Aug 2012 12:53:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUC1PoppHPY4JYIZU5hD5GtTfvzgvGMEK@postini.com; Thu, 16 Aug 2012 12:53:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 460431B830A for ; Thu, 16 Aug 2012 12:53:05 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3C122190052; Thu, 16 Aug 2012 12:53:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 12:53:05 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8+olXva8xUzuU+K+l5W0q4CfZddIMYAgAABKgCAAAYBgIAABu8AgAAegACAAAHWAA== Date: Thu, 16 Aug 2012 19:53:04 +0000 Message-ID: <7FD516DF-3445-4E80-BD10-78C6096B823C@nominum.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECEA8@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B890708FB@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890708FB@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_7FD516DF34454E80BD1078C6096B823Cnominumcom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:53:09 -0000 --_000_7FD516DF34454E80BD1078C6096B823Cnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 3:46 PM, Hemant Singh (shemant) wrote: The -10 was published today to address review in the IESG. Thus we really = should stay away from adding any new requirement to rfc6204bis. Okay, sorry=97I didn't realize it was in IESG review. Maybe in 6204bisbis= ... --_000_7FD516DF34454E80BD1078C6096B823Cnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 3:46 PM, Hemant Singh (shemant) wrote:
The -10 was published today to address review in the IESG= .  Thus we really should stay away from adding any new requirement to = rfc6204bis.

Okay, sorry=97I didn't realize it was in IESG review.   Maybe in = 6204bisbis...


--_000_7FD516DF34454E80BD1078C6096B823Cnominumcom_-- From shemant@cisco.com Thu Aug 16 12:57:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA51521F854E for ; Thu, 16 Aug 2012 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY26ubmkn0uo for ; Thu, 16 Aug 2012 12:57:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C9CDD21F851B for ; Thu, 16 Aug 2012 12:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5395; q=dns/txt; s=iport; t=1345147022; x=1346356622; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sozIcLxvUU13+GO+hz7GOsoCR9qwJLUDuRzE6uwc3VY=; b=IW6kiWVvgzKr9YFNcDVTc7gERItZXg3POtmyQlkjh6cmJ/2UOc+1fNKQ lOZFpStc8XsPAnpK3aICDA/jHh4KtTxpz2URFMcri83VJKz7XrSnPjNgF LLMmc7+mjMiXnDy+4xnKpkb3wgeY1OxdESvOUvnMK2HnBup2UpeAboDI+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALxPLVCtJV2Z/2dsb2JhbABFgkq3ZoEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIGodrmlCgQ4sKhXdgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208,217";a="112390322" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2012 19:57:02 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7GJv2B5031297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 19:57:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 14:57:01 -0500 From: "Hemant Singh (shemant)" To: Ted Lemon Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thKDNXXf7km0GI992qo154CZdcpYewgABZxID//6xuEIAAWr0A//+yNcCAAB7/IIAAVhAA//+tGDA= Date: Thu, 16 Aug 2012 19:57:01 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89070948@xmb-rcd-x06.cisco.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECDB6@xmb-rcd-x04.cisco.com> <53DAE40C-AADF-490E-B471-CEB32407D651@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECEA8@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B890708FB@xmb-rcd-x06.cisco.com> <7FD516DF-3445-4E80-BD10-78C6096B823C@nominum.com> In-Reply-To: <7FD516DF-3445-4E80-BD10-78C6096B823C@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.182.72] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--41.516000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B89070948xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:57:03 -0000 --_000_75B6FA9F576969419E42BECB86CB1B89070948xmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No problem, Ted. 6204ter be OK. We call bisbis as tertiary. Thanks, Hemant From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, August 16, 2012 3:53 PM To: Hemant Singh (shemant) Cc: Bernie Volz (volz); Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 3:46 PM, Hemant Singh (shemant) wrote: The -10 was published today to address review in the IESG. Thus we really = should stay away from adding any new requirement to rfc6204bis. Okay, sorry-I didn't realize it was in IESG review. Maybe in 6204bisbis..= . --_000_75B6FA9F576969419E42BECB86CB1B89070948xmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No problem, Ted.  62= 04ter be OK.  We call bisbis as tertiary.

 <= /p>

Thanks,=

 <= /p>

Hemant<= /p>

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, August 16, 2012 3:53 PM
To: Hemant Singh (shemant)
Cc: Bernie Volz (volz); Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

On Aug 16, 2012, at 3:46 PM, Hemant Singh (shemant) = wrote:

The -10 was published tod= ay to address review in the IESG.  Thus we really should stay away fro= m adding any new requirement to rfc6204bis.

 

Okay, sorry—I didn't realize it was in IESG re= view.   Maybe in 6204bisbis...

 

 

--_000_75B6FA9F576969419E42BECB86CB1B89070948xmbrcdx06ciscocom_-- From marka@isc.org Thu Aug 16 17:11:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7849621F854D; Thu, 16 Aug 2012 17:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_FROM=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdh0bm-+u6-x; Thu, 16 Aug 2012 17:11:36 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F39AA21F84D1; Thu, 16 Aug 2012 17:11:35 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 17E51C95E8; Fri, 17 Aug 2012 00:11:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:cfc:a4ca:b051:82cf]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C9D05216C6B; Fri, 17 Aug 2012 00:11:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AA2D123ABFA7; Fri, 17 Aug 2012 10:11:16 +1000 (EST) To: Warren Kumari From: Mark Andrews References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> In-reply-to: Your message of "Thu, 16 Aug 2012 15:40:15 -0400." Date: Fri, 17 Aug 2012 10:11:16 +1000 Message-Id: <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> Cc: 'Fernando Gont' , opsec@ietf.org, 'v6ops v6ops WG' Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:11:36 -0000 In message , Warren Kumari writes: > > On Aug 14, 2012, at 2:58 PM, Lee Howard wrote: > > > > > > > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Eric Vyncke (evyncke) > > Sent: Tuesday, August 14, 2012 4:43 AM > > To: Gunter Van de Velde (gvandeve); opsec@ietf.org; v6ops v6ops WG (v6ops > @ietf.org) > > Cc: Fernando Gont > > Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opse > c-ipv6-implications-on-ipv4-nets > > > > > - 1.0 please avoid all discussion about NAPT being =91minimal/simpl > e=92 security, the days of scanning are over and have been replaced by malw > are download/email propagated > > > This is demonstrably false, and I can send you logs of scanning attempts > foiled by NAPT. NAT is crap security, but it=92s not zero security. > > Heretic! > > Actually, I'd go so far as to drop the "crap" from the above -- while it is > n't "real" security (whatever that means) it has become cool to simply beat > on the NAT. > > > Yes, it's not awesome, but it *does* help prevent the secretary's desktop f > rom getting owned quite as often. Yes, he should have it patched, yes it sh > ould be capable of protecting itself, yes, there should be a "real" securit > y widget in front of it, but, well=85 > > > W But the problem is that people think they need "NAT" as opposed to a "stateful firewall with default allow out all, block in all". NAPT effectively establishes the latter + munges with addresses and ports. It's the state table not the address/port translation that stops scans. Stateless NAT44 or NAT66 doesn't stop scans. As for the secretary's desktop how many of them would be owned if LSR was being used to scan 192.168/16 though the NAT box? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bzeeb-lists@lists.zabbadoz.net Fri Aug 17 03:42:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136621F8532 for ; Fri, 17 Aug 2012 03:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRJATBx1bCuf for ; Fri, 17 Aug 2012 03:42:46 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF821F852E for ; Fri, 17 Aug 2012 03:42:46 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 9C50F25D39FF; Fri, 17 Aug 2012 10:42:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 6810EBE85B0; Fri, 17 Aug 2012 10:42:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id evdqB5qGAe2M; Fri, 17 Aug 2012 10:42:41 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 77F1FBE827C; Fri, 17 Aug 2012 10:42:39 +0000 (UTC) Date: Fri, 17 Aug 2012 10:42:38 +0000 (UTC) From: "Bjoern A. Zeeb" To: Dan Drown In-Reply-To: <20120816090542.15476bo43zcr7aww@mail.drown.org> Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 10:42:47 -0000 On Thu, 16 Aug 2012, Dan Drown wrote: > Quoting Lorenzo Colitti : >> Why not just do #2 and choose, as the interface ID, the interface ID of the >> interface that is providing tethering? Does that make it hard to implement? > > That may work for some implementations, but not for android-clat. The clat > function needs its own address, and it cannot be any address that the handset > considers local. /me bites his tongue. Seriously? Out of curiosity, can you elaborate (feel free to do so unicast). -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From carlosm3011@gmail.com Fri Aug 17 06:51:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8A21F846C for ; Fri, 17 Aug 2012 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnfayTX0hFoa for ; Fri, 17 Aug 2012 06:51:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF33021F846B for ; Fri, 17 Aug 2012 06:51:52 -0700 (PDT) Received: by yenm5 with SMTP id m5so4389896yen.31 for ; Fri, 17 Aug 2012 06:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Na8Qm40T9TXkVLCzL5vNxcphYMXjg15LMQjil1l6uv0=; b=yhaMs1pi5H9Fq9BaXMXIoK7LJPdkqmGVydAZ4eYjpOojxEvePbR7MZn3YBXVvkfvdE VUS8T4Ddoc2N9fIHBzwlrqECxUFClROTzerITcerCrQswFZQeONLvN1KfDBvTTC37gVR ADc1ISOVXXrGmzBp+6enw+ofEvT/CfdhuQ3KGoQNmlVj+XSCrfUGWGynrlrSQVVXfl64 s89/QmVO1vLVOKhAGqIhESSS/e7LSpXJ6+LgL8EgrqyMrsXtZLbEZLri12wqAZ4bugTP TrH6jiXA2IO6BKgLLEjU3lWEwvlgXwU2PTAvKxjlaNirBEfezOawz+LJYsGNTo43PfS5 uSig== Received: by 10.236.77.163 with SMTP id d23mr7950771yhe.75.1345211512424; Fri, 17 Aug 2012 06:51:52 -0700 (PDT) Received: from europa.local ([200.7.85.154]) by mx.google.com with ESMTPS id o25sm13918479yhm.14.2012.08.17.06.51.50 (version=SSLv3 cipher=OTHER); Fri, 17 Aug 2012 06:51:51 -0700 (PDT) Message-ID: <502E4C76.4000008@gmail.com> Date: Fri, 17 Aug 2012 10:51:50 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <502AEB54.8050904@si6networks.com> In-Reply-To: <502AEB54.8050904@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:51:53 -0000 Is a third volunteer still needed ? ~Carlos On 8/14/12 9:20 PM, Fernando Gont wrote: > Hi, Eric, > > Thanks so much for your feedback! -- Please find my comments in-line... > > > On 08/14/2012 05:42 AM, Eric Vyncke (evyncke) wrote: > [...] >> Let’s start with generic: >> >> - It should not be a BCP but rather informational > > Just curious: what's the rationale for your preference? > > > >> - I also wonder whether it is worth an IETF RFC because it is well >> known topics in the security area (as you probably know) > > I disagree with both points, for a number of reasons: > > * An IETF RFC means IETF consensus on a topic. That doesn't necessarily > mean that the information is new, but rather than that's how the IETF > thinks about the problem. > > * There has been quite some talk about the implications of transition > technologies, and recommendations to "block them"... but concrete advice > on how to filter each of these technologies is not always readily > available. Try Google. > > * I generally disagree about "well known topics in the security area" > (unless you clearly define what you mean by "known" and what you mean by > "security area"). Most of the time I've seen any topic deemed as > "well-known" in the security community, it really wasn't. And when it > comes to IPv6 security in particular. there has been so much crap around > it that I'd probably deem "well known IPv6 security topic" as an > oxymoron. :-) > > >> - Missing point: awareness of IPV6 by CISO is the key problem, > > I don't necessarily disagree, but that kind of aspect seems to be out of > the scope of this particular document. > > >> should also add that IPv6 is not dangerous per se, and enabling IPv6 in >> intranet is a good way to bypass all automatic tunnels > > The focus of this document is how IPv6 affects your "IPv4-only" network. > > If you explicitly enable IPv6, then this document does not apply to your > network. -- Not to mention that lots of devices are not IPv6-capable, > which means that it shouldn't come up as a surprise if an admin cannot > enforce enforce on v6 the same policies he enforces on v4. > > > >> - Intro / title should specify ‘end-user network’ (to avoid >> confusion for ISP) > > Do we really need/want to make a difference, here? -- The generic issues > being discussed in this document apply to any network that has "dormant > IPv6 connectivity". > > > >> - IP flow (netflow), firewall log, DNS request log could also be >> monitored to detect tunnels establishments > > Could you please elaborate a bit? > > > >> - Using NAPT (and not NAT as previously commented) usually blocks >> ‘magically’ IP protocol 41 and most tunnels > > Agreed. I will add a note about this. > > > >> - If the security policy is to force all traffic through >> application proxies (done by all major organizations) then tunnels are >> not a threat > > Should I add any comments about this? If so, where? > > > >> Let’s continue with the details: >> >> - 1.0 please avoid all discussion about NAPT being >> ‘minimal/simple’ security, the days of scanning are over and have been >> replaced by malware download/email propagated > > ... yet we still use firewalls. Clearly, a NAT-PT blocks some attack > vectors, and reduces host exposure. And technologies such as Teredo > essentially eliminate any sort of protection that could be achieved by > such NAT-PT. And they do block some attacks -- not "all" or "most", but > they do block some. > > > >> - 2.0 congruent security policy indeed with the exception of RFC >> 4890 (ICMPv6) > > I'd argue that the policy is still the same -- it's just that there are > additional message types in v6 /which are not present in v4). > > It's quite unfortunate to hear in v6 circles things like "in v6, you > cannot filter all ICMP as you do in v4" -- because even in v4 you > couldn't do this without braking PMTUD. > > > >> - 2.1 filtering the IPv6 ethertype is TOO dangerous (= could break >> too many things) to be recommended in an IETF document > > Filtering EtherType 0x86DD does what it is meant to do: block native > IPv6 traffic. Note that we are not recommending that people do it, and > even less to have products ship with that filter "on by default" -- we > just note that if you want to prevent block native IPv6 traffic, that's > one possible way to do so. > > > >> - 3.1 should refer to the RFC > > Done! > > > >> - 3.3 AFAIK there is no by default implementation of 6RD in >> generic OS and it requires either manual configuration or DHCPv4 option >> => remove this section > > I'd probably argue that we should argue the comment on DHCPv4 possibly > enabling 6rd, rather than removing the whole section -- for instance, an > attacker could exploit such vector. > > That aside, removing the entire section would likely trigger feedback of > the form "hey guys, you forgot to describe 6rd!". > > >> - 3.5 leave ISATAP (automatic config through DNS) but specify that >> blocking 41 also blocks it > > The current text already notes that. > > > >> - 3.6 as noted, Teredo default port can be changed. The good >> recommendation anyway for enterprises is to block outbound UDP traffic >> (except some pin holes for DNS of course), even my employer network >> blocks them since 1997 ;-). > > This is going beyond the type of advice this document is meant to > provide. We want to provide advice on how to block Teredo... rather than > recommend to filter all UDP. > > >> Also, Microsoft implementation disables >> Teredo when personal firewall is disabled or when the host is in an >> Active Directory network > > That still leaves Windows systems with a firewall and no Active > Directory network with Teredo "on by default". > > >> - Other tunnels TSP (but also Sixxs, ...) all require explicit >> installation and configuration by end-users. They are no more a thread >> than any other covert channel (being IP over DNS or over ICMP or ...), I >> would remove this section > > TSP could allow incoming connections to the local network, which is > something quite different from an internal node being able to "send > stuff out on top of DNS or ICMP". > > Thoughts? > > Thanks! > > Best regards, > From dan-v6ops@drown.org Fri Aug 17 07:49:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC7411E80D7 for ; Fri, 17 Aug 2012 07:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80LYTVlNhzsP for ; Fri, 17 Aug 2012 07:49:54 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id A656A11E80D5 for ; Fri, 17 Aug 2012 07:49:54 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 23B22C12B; Fri, 17 Aug 2012 10:49:53 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Fri, 17 Aug 2012 09:49:53 -0500 Message-ID: <20120817094953.10350hmgauyyi9e8@mail.drown.org> Date: Fri, 17 Aug 2012 09:49:53 -0500 From: Dan Drown To: "Bjoern A. Zeeb" References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:49:55 -0000 Quoting "Bjoern A. Zeeb" : > On Thu, 16 Aug 2012, Dan Drown wrote: >> That may work for some implementations, but not for android-clat. >> The clat function needs its own address, and it cannot be any >> address that the handset considers local. > > /me bites his tongue. > > Seriously? Out of curiosity, can you elaborate (feel free to do so unicast). Yes. The implementation of clat for android is done in userspace (using a tun interface to pass traffic between the kernel and the userspace program), and needs its own address. Otherwise native traffic from the handset to the plat prefix (apps that support DNS64's rewritten AAAA answers) can't be seperated from translated traffic from the clat. Perhaps this is just an implementation detail that doesn't need to go into the standard, but it's unavoidable for me. From lee@asgard.org Fri Aug 17 08:15:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB9021E8045 for ; Fri, 17 Aug 2012 08:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYngWOGpxaly for ; Fri, 17 Aug 2012 08:15:51 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0511E80D5 for ; Fri, 17 Aug 2012 08:15:51 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7HFFolH019968 for ; Fri, 17 Aug 2012 11:15:50 -0400 Authentication-Results: cm-omr8 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.163] ([204.235.115.163:18490] helo=HDC00042402) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 68/42-11452-6206E205; Fri, 17 Aug 2012 11:15:50 -0400 From: "Lee Howard" To: "'Mark Andrews'" , "'Warren Kumari'" References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> In-Reply-To: <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> Date: Fri, 17 Aug 2012 11:15:49 -0400 Message-ID: <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGGlPLakFxZCTrqhE95LHJwbjJ3AQK/mXl8AqNTmP4CG5HaMANbc19el5UYViA= Content-Language: en-us Cc: 'Fernando Gont' , 'v6ops v6ops WG' , opsec@ietf.org Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:15:52 -0000 > > > - 1.0 please avoid all discussion about NAPT being =91minimal/simpl > > e=92 security, the days of scanning are over and have been replaced by > > malw are download/email propagated > > > > > This is demonstrably false, and I can send you logs of scanning > > > attempts > > foiled by NAPT. NAT is crap security, but it=92s not zero security. > > > > Heretic! > > > > Actually, I'd go so far as to drop the "crap" from the above -- while > > it is n't "real" security (whatever that means) it has become cool to > > simply beat on the NAT. > > But the problem is that people think they need "NAT" as opposed to a "stateful firewall with > default allow out all, block in all". > NAPT effectively establishes the latter + munges with addresses and ports. It's the state table > not the address/port translation that stops scans. That is true, but is not a flaw in the document. The offending text is: Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network. Thus, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure. That is, the aforementioned technologies might inadvertently allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall. Would you be happy if it said: to traverse Network Address Translators (NATs), which, by keeping a state table and only allowing inbound packets to hosts which have established outbound communication, provides a minimum level of protection. . . I don't think a more thorough discussion of the different risk profiles of full cone versus symmetric NAT, etc., is warranted here. I absolutely agree that networks should have a stateful firewall. Would you say that a stateful firewall is *even more important* now (with IPv6 ramping up) than it ever was before? > Stateless NAT44 or NAT66 doesn't stop scans. True. How is that relevant to a discussion of how unintentional IPv6 may affect IPv4 networks? > As for the secretary's desktop how many of them would be owned if LSR was being used to > scan 192.168/16 though the NAT box? Fewer than if it were even easier. Again, not really the point of the document. Lee > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Fri Aug 17 08:28:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C81011E80D7 for ; Fri, 17 Aug 2012 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ0Cxbow0eiQ for ; Fri, 17 Aug 2012 08:28:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3806311E80D5 for ; Fri, 17 Aug 2012 08:28:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so2246833lah.31 for ; Fri, 17 Aug 2012 08:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3MOMc6Hstg5Hw3RHBOmAvcGkFURXbJCeKPnjHe0aM1M=; b=U6KzDtL5Wg+Mw5g3/4o8jIfWfCD8Zj2BLdxwU56iAk/rx7Z49PC/XzAEO/y91BJCCF BKT+3AEjU9DdTC7R7gP57uyqSnmJMan1+XE4jd1hxKufafJfUiHtcD7Qtx9/PXv3FbPn rp5LhTVuItXYRAyZx6MmRXAqkICfwwLC6WI/3qRe7u9Nyivi6ZlTQn7yjUc4w7kSEPyr 6FoVlsxT2/rKoTdjs4ttprILi1lS8gphXDHpzZ/wIbD2Xk7sly8b9i5a4XnlJz+IJT2I A6BoR/Esjmw0bOTcUFI1dVZxC6TSNj80JyHKOQSVnHGZpMYZHHixnOKfXSCiUK2Clo8M vFEw== MIME-Version: 1.0 Received: by 10.152.105.51 with SMTP id gj19mr5225635lab.38.1345217312143; Fri, 17 Aug 2012 08:28:32 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 17 Aug 2012 08:28:31 -0700 (PDT) Received: by 10.112.28.67 with HTTP; Fri, 17 Aug 2012 08:28:31 -0700 (PDT) In-Reply-To: <20120817094953.10350hmgauyyi9e8@mail.drown.org> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> Date: Fri, 17 Aug 2012 08:28:31 -0700 Message-ID: From: Cameron Byrne To: Dan Drown Content-Type: multipart/alternative; boundary=f46d04071785093ad404c777d0b3 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:28:34 -0000 --f46d04071785093ad404c777d0b3 Content-Type: text/plain; charset=ISO-8859-1 On Aug 17, 2012 7:50 AM, "Dan Drown" wrote: > > Quoting "Bjoern A. Zeeb" : >> >> On Thu, 16 Aug 2012, Dan Drown wrote: >>> >>> That may work for some implementations, but not for android-clat. The clat function needs its own address, and it cannot be any address that the handset considers local. >> >> >> /me bites his tongue. >> >> Seriously? Out of curiosity, can you elaborate (feel free to do so unicast). > > > Yes. The implementation of clat for android is done in userspace (using a tun interface to pass traffic between the kernel and the userspace program), and needs its own address. Otherwise native traffic from the handset to the plat prefix (apps that support DNS64's rewritten AAAA answers) can't be seperated from translated traffic from the clat. Perhaps this is just an implementation detail that doesn't need to go into the standard, but it's unavoidable for me. > The benefit of running code (thanks Dan!) is that we can learn these lessons early and publish the most fit solution. That said, the IANA section is useful for some implementors and has no known drawbacks. It is up to the implementor to decide the best method, this I-D just provides the tools and options. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d04071785093ad404c777d0b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 17, 2012 7:50 AM, "Dan Drown" <dan-v6ops@drown.org> wrote:
>
> Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>:
>>
>> On Thu, 16 Aug 2012, Dan Drown wrote:
>>>
>>> That may work for some implementations, but not for android-cl= at. =A0The clat function needs its own address, and it cannot be any addres= s that the handset considers local.
>>
>>
>> /me bites his tongue.
>>
>> Seriously? =A0Out of curiosity, can you elaborate (feel free to do= so unicast).
>
>
> Yes. =A0The implementation of clat for android is done in userspace (u= sing a tun interface to pass traffic between the kernel and the userspace p= rogram), and needs its own address. =A0Otherwise native traffic from the ha= ndset to the plat prefix (apps that support DNS64's rewritten AAAA answ= ers) can't be seperated from translated traffic from the clat. =A0Perha= ps this is just an implementation detail that doesn't need to go into t= he standard, but it's unavoidable for me.
>

The benefit of running code (thanks Dan!) is that we can learn these les= sons early and publish the most fit solution.

That said, the IANA section is useful for some implementors and has no k= nown drawbacks. It is up to the implementor to decide the best method, this= I-D just provides the tools and options.

CB

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--f46d04071785093ad404c777d0b3-- From pkern@spike.0x539.de Fri Aug 17 09:53:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6B21F85DD for ; Fri, 17 Aug 2012 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOtcml4DFarX for ; Fri, 17 Aug 2012 09:53:32 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id C02B821F84B9 for ; Fri, 17 Aug 2012 09:53:32 -0700 (PDT) Received: from [2001:470:720c:0:2567:7561:401d:6b98] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1T2Pn9-0005Od-CZ for v6ops@ietf.org; Fri, 17 Aug 2012 18:52:59 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1T2Pnd-00034E-Oc for v6ops@ietf.org; Fri, 17 Aug 2012 18:53:29 +0200 Date: Fri, 17 Aug 2012 18:53:29 +0200 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20120817165329.GA7568@spike.0x539.de> References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:53:33 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Lee, am Fri, Aug 17, 2012 at 11:15:49AM -0400 hast du folgendes geschrieben: > Finally, > some transition/co-existence mechanisms (notably Teredo) are designed > to traverse Network Address Translators (NATs), which in many > deployments provide a minimum level of protection by only allowing > those instances of communication that have been initiated from the > internal network. Thus, these mechanisms might cause an internal > host with otherwise limited IPv4 connectivity to become globally > reachable over IPv6, therefore resulting in increased (and possibly > unexpected) host exposure. That is, the aforementioned technologies > might inadvertently allow incoming IPv6 connections from the Internet > to hosts behind the organizational firewall. and how is that different from obtaining a global IPv4 through a VPN connec= tion to the outside? If you allow the UDP communication to the Teredo relays, yo= u're probably not stopping such VPNing neither. The lesson being that you need to know what passes your organizational firewall and whitelist if you care abo= ut that. But then I guess your point is that such tunnels are automatic and not necessarily user-initiated. But that's an implementation detail with one vendor's implementation=E2=80=A6 \: Kind regards Philipp Kern --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlAudwkACgkQ7Ro5M7LPzdjSKACeMS1lcDz0ET6BnhuBE6xb0Quh P0kAn1GQwW1Nc3z/9QNfCTqQFJPBTWC7 =gUxy -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From jeroen@unfix.org Fri Aug 17 09:58:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC311E80A5 for ; Fri, 17 Aug 2012 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YpSR8kW7kVU for ; Fri, 17 Aug 2012 09:58:18 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3411E809B for ; Fri, 17 Aug 2012 09:58:17 -0700 (PDT) Received: from kami.ch.unfix.org (211-46.62-188.cust.bluewin.ch [188.62.46.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id E7DE3801C2B5; Fri, 17 Aug 2012 18:58:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1345222696; bh=dlvyLiZ9ELtmBUI92hF1YombmXQ/ixlMZF7kDjv2ckk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sJeBqCCXJue9wMOoucpMTY2vzADWkIOMnJhK0b4fRlehGRSTLHawdjmt9shYFyF48 LbBapTWpOA346WzG72wsGCwf/hddUBYoy+DGHchFZZE8RJOEj/xew6qpNHT95rBx8T xYPi7Chma7BpAvo2rY1JBSYl/LY/eNcALG2nl4wob7M0BDDYOwa8q7gQ9oxbIYABFL mn89eZyk4EmO1Z1m4Tyk2WvRIo5sR/p6afw6CnskfhGqLuwyqoP1dYJALK/X9s2WFK xfrePCjpqRR3k7mnaWeuk5ruZrykdY0PqWXKdKQaZZ80VKWlfJ0gf9bZE6Wtei7rkQ 6bBTHuhuf+XSg== Message-ID: <502E7826.2080000@unfix.org> Date: Fri, 17 Aug 2012 18:58:14 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Philipp Kern References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> <20120817165329.GA7568@spike.0x539.de> In-Reply-To: <20120817165329.GA7568@spike.0x539.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:58:18 -0000 On 2012-08-17 18:53, Philipp Kern wrote: > Lee, > > am Fri, Aug 17, 2012 at 11:15:49AM -0400 hast du folgendes geschrieben: >> Finally, >> some transition/co-existence mechanisms (notably Teredo) are designed >> to traverse Network Address Translators (NATs), which in many [..] > and how is that different from obtaining a global IPv4 through a VPN connection > to the outside? If you allow the UDP communication to the Teredo relays, you're > probably not stopping such VPNing neither. The lesson being that you need to > know what passes your organizational firewall and whitelist if you care about > that. But then I guess your point is that such tunnels are automatic and not > necessarily user-initiated. But that's an implementation detail with one > vendor's implementation… \: That one vendor you mean, being Microsoft, actually disables Teredo when the host PC is inside an Active Directory/Windows domain, as such, this covers most organizations. But even then, per default Teredo on Windows is configured to not allow incoming connections when the standard Windows Firewall is active. And indeed, if you want to properly firewall, then you need to educate your users and whitelist, anything else does not work as there are way too many ways that one can get out and play... Also note that the NAT there is obviously not a firewall, as it allows any connection to be made and tunnels to be punched through it. Greets, Jeroen From markzzzsmith@yahoo.com.au Sun Aug 19 13:33:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941121F8564 for ; Sun, 19 Aug 2012 13:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3sHKt4S14o7 for ; Sun, 19 Aug 2012 13:33:51 -0700 (PDT) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 1B7FF21F84B2 for ; Sun, 19 Aug 2012 13:33:51 -0700 (PDT) Received: from [72.30.22.77] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 20:33:42 -0000 Received: from [98.139.91.24] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 20:33:42 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 20:33:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 666376.48918.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 83199 invoked by uid 60001); 19 Aug 2012 20:33:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1345408422; bh=wpoOSnNOn3rOEh2m+OusvUGNJrekt0BlOlVF553nj7M=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b4VEiwNDuhksezI6mwZiL7AZhG6DsEY9k/P0eDQ59RqLWObYRZKDdCI8RqT+44JB4VfSAs/eLxSfmA7y1D69zThRR9ukmd7jM3ZpO4co6IbHp07lCKbVC9bNhi25xaztGAh1kes6aKzGzml/Txdv1xVpcTIay1bA45QUklb8/xw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RxdvJKAbTQvPA8SzkY6Pj2IXBVcjy7+RGRFfCRvYQfB9aMShADjFmJIRQ9Qz2WTTuCAan8YJikYSghVcYm8PoNuqKHACir0/HTDMkN4pCxmvdspRslnGVNXlhOsqre7l+gML38pl9VeA5XAVlPrhmF/JOT44hXSRsLNtCagOEtE=; X-YMail-OSG: RN2BOXoVM1ldsZQuZiX6rTPws0qxhBAoJrY7isjSqregk1N .2XxqL6VeTp9_EEJbvB7TnGNWEl1W7jVS84hWNzO5qiDTmzksJjzkLAYVqgI gxJBlNtnWqKiKM61jruDgT51xct2wnljE2ekTYVa9O60wOqVvPLQviN.4uTb 5SM28ceTjHpxsLsH01mkeuerQtNQ9B9egRlZifiDRHZAW2vAJfx175NqVntt YzlFlA5dtkA5TtQEVskmJZKYnqq2ogAjQTQ9YXMrAqOkVIGf71uoVujTAu6G rrh6j175b4GmwETz3mUMxoR0OkTVa1x4HGx2Kffu9.qk32SU1veXL4dEokgk HO0tCghtpUkN0y_0Fn_UydcK4z18xM8SYunnzvGJ0P4tnPLr2gCudkrpvx.Z RzpbAd37NP.sMTSkxBLnHdPtvXdJy4eV8QgjAhSdam5grKq7t74UNa0LkVyW VpHspXl2WpqIBEnoxn7StmSJMdcXc9tt915ggbLKuPZk- Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Sun, 19 Aug 2012 13:33:42 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <20120817091141.27675.7555.idtracker@ietfa.amsl.com> Message-ID: <1345408422.78071.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Sun, 19 Aug 2012 13:33:42 -0700 (PDT) From: Mark ZZZ Smith To: 'v6ops v6ops WG' In-Reply-To: <20120817091141.27675.7555.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 20:33:51 -0000 Hi,=0A=0ABased on valuable review and comments by Nick Hilliard, here is a = new version of my draft proposing a larger IPv6 loopback prefix.=0A=0AThis = version is much shorter (about half as many words, and 1/3 less pages) and = much more direct about why I think there is a need for a larger IPv6 loopba= ck prefix. Review and suggestions on this version would be most appreciated= .=0A=0AThanks very much,=0AMark.=0A=0A=0A----- Forwarded Message -----=0A> = From: "internet-drafts@ietf.org" =0A> To: markzzz= smith@yahoo.com.au=0A> Cc: =0A> Sent: Friday, 17 August 2012 7:11 PM=0A> Su= bject: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-= prefix-01.txt=0A> =0A> =0A> A new version of I-D, draft-smith-v6ops-larger-= ipv6-loopback-prefix-01.txt=0A> has been successfully submitted by Mark Smi= th and posted to the=0A> IETF repository.=0A> =0A> Filename:=A0=A0=A0 draf= t-smith-v6ops-larger-ipv6-loopback-prefix=0A> Revision:=A0=A0=A0 01=0A> Ti= tle:=A0=A0=A0 =A0=A0=A0 A Larger Loopback Prefix for IPv6=0A> Creation dat= e:=A0=A0=A0 2012-08-17=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submissio= n=0A> Number of pages: 8=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ie= tf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback-prefix-01.txt= =0A> Status:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf.org/doc/draft-= smith-v6ops-larger-ipv6-loopback-prefix=0A> Htmlized:=A0 =A0 =A0 =A0 =0A> h= ttp://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-01= =0A> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/rfcdiff?url2=3Dd= raft-smith-v6ops-larger-ipv6-loopback-prefix-01=0A> =0A> Abstract:=0A> =A0 = During the development of a network application, it can be useful to=0A> = =A0 run multiple instances of the application using the same transport=0A>= =A0 layer protocol port on the same development host, while also having= =0A> =A0 network access to the application instances limited to the local= =0A> =A0 host.=A0 Under IPv4, this has been possible by using different lo= opback=0A> =A0 addresses within 127/8.=A0 It is not possible under IPv6, a= s the=0A> =A0 loopback prefix of ::1/128 only provides a single loopback a= ddress.=0A> =A0 This memo proposes a new larger loopback prefix that will = provide=0A> =A0 many loopback IPv6 addresses.=0A> =0A> =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> = =A0 =0A> =0A> =0A> The IETF Secretariat=0A> From washam.fan@gmail.com Sun Aug 19 22:47:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0558C21F85C4; Sun, 19 Aug 2012 22:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWBSzaCPyeeI; Sun, 19 Aug 2012 22:47:02 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E000821F8514; Sun, 19 Aug 2012 22:47:01 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so3058958wib.1 for ; Sun, 19 Aug 2012 22:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ctcorPJp40ZNjZHX6yFX75Beg4Hak2yyg54SljI/8c=; b=ioGRK1p4kTb0co4v6X9WjRv9vJx654oGbw1Lu4MdRWhBSB1K3OorTXf7rQ72zHMFem E/v8m16ALikQC024afutn+a1H3KyBd6ejmVRuFG6umEgUfTfEaJVy+aCOA8JX3nG/47V RNYg99csd0MygUSZ6nZFLZL/IaS3Y4sVXSNCpSEFBsjTrCD/c087SsNup3D3etwQTdE1 HipsAjcHQCgUZCRlnLaEWN1T6Mqq8si+zNv2GAgFFAUOo/uC589uYVQvaGtE1YOJHpxg MLFInFyn0pnigZtrZ9H3U+dzqOimSAYR4CurRTTrNMJS+T6Hrm1AdqYQzQfnz+sDllPr QzRQ== MIME-Version: 1.0 Received: by 10.180.86.3 with SMTP id l3mr24934211wiz.16.1345441620720; Sun, 19 Aug 2012 22:47:00 -0700 (PDT) Received: by 10.216.205.96 with HTTP; Sun, 19 Aug 2012 22:47:00 -0700 (PDT) In-Reply-To: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 13:47:00 +0800 Message-ID: From: Washam Fan To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 05:47:03 -0000 Hi, Sorry for the late response. I finally got a chance to review this edition and had some confusions 1. in sec 8.3.2, it lacks of elaborating on how to differentiate native IPv6 packet from translated IPv6 packet. is it where reserved IANA Modified EUI-64 ID comes in? 2. BIH only mentioned in two places in the draft and not mentioned in abstract. If we want to cover BIH, shouldn't we elaborate a bit on how to combine BIH with 464xlate? Or is it too obvious to talk about that? 3. Are BIH exclusive with rfc6145? in other words, enabling both BIH and rfc6145 on CLAT is OK? Thanks, washam 2012/8/7 : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-06.txt > Pages : 19 > Date : 2012-08-06 > > Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Sun Aug 19 23:04:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82D721F867C; Sun, 19 Aug 2012 23:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVoy3znHGKiW; Sun, 19 Aug 2012 23:04:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423A421F8653; Sun, 19 Aug 2012 23:04:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120820060408.21754.25653.idtracker@ietfa.amsl.com> Date: Sun, 19 Aug 2012 23:04:08 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 06:04:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-07.txt Pages : 19 Date : 2012-08-19 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kawashimam@vx.jp.nec.com Sun Aug 19 23:09:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6BB21F867D for ; Sun, 19 Aug 2012 23:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NujWpfvcJhxE for ; Sun, 19 Aug 2012 23:09:46 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id D503521F8616 for ; Sun, 19 Aug 2012 23:09:45 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q7K69iXu019813 for ; Mon, 20 Aug 2012 15:09:44 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q7K69iH05069 for v6ops@ietf.org; Mon, 20 Aug 2012 15:09:44 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q7K69hAH023276 for ; Mon, 20 Aug 2012 15:09:43 +0900 (JST) Received: from togyo.jp.nec.com ([10.26.220.4] [10.26.220.4]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-979454; Mon, 20 Aug 2012 15:08:40 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Mon, 20 Aug 2012 15:08:40 +0900 To: v6ops@ietf.org In-reply-to: <20120820060408.21754.25653.idtracker@ietfa.amsl.com> Message-Id: <20120820150840kawashimam@mail.jp.nec.com> References: <20120820060408.21754.25653.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: Masanobu Kawashima Date: Mon, 20 Aug 2012 15:08:39 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 06:09:47 -0000 Hi all, Thank you for many comments. I've published draft-ietf-v6ops-464xlat-07. We authors considered all comments from v6ops community. Please check Diff1 or Diff2 in tools.ietf.org. BTW, can we start WGLC by this version? Regards, Masanobu > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-07.txt > Pages : 19 > Date : 2012-08-19 > >Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From warren@kumari.net Mon Aug 20 01:54:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E795821F8691; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY0JIDb62JA1; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F221F8682; Mon, 20 Aug 2012 01:54:36 -0700 (PDT) Received: from [192.168.202.132] (unknown [74.125.121.33]) by vimes.kumari.net (Postfix) with ESMTPSA id AE6FA1B4085C; Mon, 20 Aug 2012 04:54:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> Date: Mon, 20 Aug 2012 04:11:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org> To: Lee Howard X-Mailer: Apple Mail (2.1278) Cc: 'Fernando Gont' , 'v6ops v6ops WG' , opsec@ietf.org Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:54:41 -0000 On Aug 17, 2012, at 11:15 AM, Lee Howard wrote: >>>> - 1.0 please avoid all discussion about NAPT being > =3D91minimal/simpl >>> e=3D92 security, the days of scanning are over and have been = replaced by >>> malw are download/email propagated >>>=20 >>>> This is demonstrably false, and I can send you logs of scanning >>>> attempts >>> foiled by NAPT. NAT is crap security, but it=3D92s not zero = security. >>>=20 >>> Heretic! >>>=20 >>> Actually, I'd go so far as to drop the "crap" from the above -- = while >>> it is n't "real" security (whatever that means) it has become cool = to >>> simply beat on the NAT. >>=20 >> But the problem is that people think they need "NAT" as opposed to a > "stateful firewall with >> default allow out all, block in all". >> NAPT effectively establishes the latter + munges with addresses and = ports. > It's the state table >> not the address/port translation that stops scans. >=20 > That is true, but is not a flaw in the document. =20 > The offending text is: > Finally, > some transition/co-existence mechanisms (notably Teredo) are = designed > to traverse Network Address Translators (NATs), which in many > deployments provide a minimum level of protection by only allowing > those instances of communication that have been initiated from the > internal network. Thus, these mechanisms might cause an internal > host with otherwise limited IPv4 connectivity to become globally > reachable over IPv6, therefore resulting in increased (and possibly > unexpected) host exposure. That is, the aforementioned technologies > might inadvertently allow incoming IPv6 connections from the = Internet > to hosts behind the organizational firewall. >=20 > Would you be happy if it said: > to traverse Network Address Translators (NATs), which, by keeping a > state table and only allowing inbound packets to hosts which have > established outbound communication, provides a minimum level of > protection. . .=20 >=20 Personally I'm fine with either=85.=20 I was just mumbling, don't have any particularly strong feelings on = this=85 > I don't think a more thorough discussion of the different risk = profiles of > full > cone versus symmetric NAT, etc., is warranted here. I absolutely = agree that >=20 > networks should have a stateful firewall. Would you say that a = stateful > firewall is *even more important* now (with IPv6 ramping up) than it = ever > was before? =20 >=20 >> Stateless NAT44 or NAT66 doesn't stop scans. >=20 > True. How is that relevant to a discussion of how unintentional IPv6 = may > affect > IPv4 networks? >=20 >> As for the secretary's desktop how many of them would be owned if LSR = was > being used to >> scan 192.168/16 though the NAT box? >=20 > Fewer than if it were even easier. Again, not really the point of the > document. >=20 > Lee >=20 >=20 >>=20 >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --=20 "He who laughs last, thinks slowest."=20 -- Anonymous From ietfc@btconnect.com Mon Aug 20 02:41:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009B521F86FF for ; Mon, 20 Aug 2012 02:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqv5O4yeIq4T for ; Mon, 20 Aug 2012 02:41:54 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D821F86FA for ; Mon, 20 Aug 2012 02:41:54 -0700 (PDT) Received: from mail232-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 09:41:53 +0000 Received: from mail232-va3 (localhost [127.0.0.1]) by mail232-va3-R.bigfish.com (Postfix) with ESMTP id 1BC7650027F; Mon, 20 Aug 2012 09:41:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz9371I936eI542M1432I1418I14ffIzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail232-va3 (localhost.localdomain [127.0.0.1]) by mail232-va3 (MessageSwitch) id 13454557117740_31772; Mon, 20 Aug 2012 09:41:51 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.251]) by mail232-va3.bigfish.com (Postfix) with ESMTP id F259460006B; Mon, 20 Aug 2012 09:41:50 +0000 (UTC) Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 09:41:50 +0000 Received: from SN2PRD0610HT001.namprd06.prod.outlook.com (157.56.234.133) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.108.4; Mon, 20 Aug 2012 09:41:45 +0000 Message-ID: <00a301cd7eb7$5b80e020$4001a8c0@gateway.2wire.net> From: t.petch To: , Masanobu Kawashima References: <20120820060408.21754.25653.idtracker@ietfa.amsl.com> <20120820150840kawashimam@mail.jp.nec.com> Date: Mon, 20 Aug 2012 10:36:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.133] X-OriginatorOrg: btconnect.com Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:41:55 -0000 ----- Original Message ----- From: "Masanobu Kawashima" To: Sent: Monday, August 20, 2012 7:08 AM > Hi all, > > Thank you for many comments. > > I've published draft-ietf-v6ops-464xlat-07. > We authors considered all comments from v6ops community. > Please check Diff1 or Diff2 in tools.ietf.org. Tweak, tweak. Trouble is, every time a new version appears I read it and generate comments I have not made before (please stop issuing new versions:-). This time, and thank you for incorporating my previous comments, it is s.7.2. " The vast majority of mobile networks are compliant to Pre-Release 9" Does that mean Pre-Release 9 or later, or is this specific to Pre-Release 9? And given that this RFC will be around for decades and is likely to be read for years, I think that this statement needs qualifying, such as "At the time of writing, in August 2012, the vast majority of mobile networks ..." Tom Petch > > BTW, can we start WGLC by this version? > > Regards, > Masanobu > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > > > Title : 464XLAT: Combination of Stateful and Stateless Translation > > Author(s) : Masataka Mawatari > > Masanobu Kawashima > > Cameron Byrne > > Filename : draft-ietf-v6ops-464xlat-07.txt > > Pages : 19 > > Date : 2012-08-19 > > > >Abstract: > > This document describes an architecture (464XLAT) for providing > > limited IPv4 connectivity across an IPv6-only network by combining > > existing and well-known stateful protocol translation RFC 6146 in the > > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > > is a simple and scalable technique to quickly deploy limited IPv4 > > access service to IPv6-only edge networks without encapsulation. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > From despres.remi@laposte.net Mon Aug 20 07:32:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A121F847A for ; Mon, 20 Aug 2012 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh7r3Sr2X4wC for ; Mon, 20 Aug 2012 07:32:54 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1A21F8475 for ; Mon, 20 Aug 2012 07:32:53 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id CCE5E7000085; Mon, 20 Aug 2012 16:32:52 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 36FF57000088; Mon, 20 Aug 2012 16:32:52 +0200 (CEST) X-SFR-UUID: 20120820143252225.36FF57000088@msfrf2209.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120820150840kawashimam@mail.jp.nec.com> Date: Mon, 20 Aug 2012 16:32:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120820060408.21754.25653.idtracker@ietfa.amsl.com> <20120820150840kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:32:55 -0000 Hi, Masanobu-san, Thanks for the latest progress, in particular the clarification of = section 8.3.2 on what is achieved with the IANA-assigned interface ID. With Tom's suggestion and (1) and (2) below taken care of, the draft is = AFAIAC ready for WGLC. (1) A further progress on the 464XLAT interface ID is possible by = proposing in Section 11 only one value (02-00-5E-10-00-00-00-00, the = value used in the appendix).=20 (Hesitation between a "reserved" or "available" range of RFC5342 is = AFAIK historical, due to something I had written and never updated. = Fortunately, it isn't too late.)=20 (2) In 8.3.2, instead of=20 "If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of = the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID = ...",=20 proposed text:=20 "The CLAT SHOULD use the reserved IANA assigned EUI-64 ID of Section 11 = ..."=20 Rationale is simplicity. Even if the CLAT node can do ND proxy, it has = to be decided which interface ID it excludes, and this excluded ID may = be in addition to that of the node at its IPv6 WAN interface. Without = explaining this, the specification would be incomplete. Once there is a = reserved ID, using it is trivial. (3) In 8.1, just a minor suggestion: After "The IPv6 address format in 464XLAT is defined in Section 2.2 of = [RFC6052]" add " completed, if applicable according to Section 8.3.2, = with the 464XLAT interface ID of Section 11."=20 Regards, RD 2012-08-20 08:08, Masanobu Kawashima : >=20 > Hi all, >=20 > Thank you for many comments. >=20 > I've published draft-ietf-v6ops-464xlat-07. > We authors considered all comments from v6ops community. > Please check Diff1 or Diff2 in tools.ietf.org. >=20 > BTW, can we start WGLC by this version? >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >>=20 >> Title : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-07.txt >> Pages : 19 >> Date : 2012-08-19 >>=20 >> Abstract: >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in = the >> core and stateless protocol translation RFC 6145 at the edge. = 464XLAT >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Mon Aug 20 07:45:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D9321F86B1 for ; Mon, 20 Aug 2012 07:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAbhtKNn2ewT for ; Mon, 20 Aug 2012 07:45:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 649C521F8525 for ; Mon, 20 Aug 2012 07:45:22 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 9B99D2DC6E0; Mon, 20 Aug 2012 16:45:21 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 81FCF27C053; Mon, 20 Aug 2012 16:45:21 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 20 Aug 2012 16:45:01 +0200 From: To: joel jaeggli , IPv6 Ops WG Date: Mon, 20 Aug 2012 16:45:00 +0200 Thread-Topic: [v6ops] Problem in citing http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1ochAnsxUZBdVeRVGhGqJt05vh/AWbzXLg Message-ID: <94C682931C08B048B7A8645303FDC9F36E512B4705@PUEXCB1B.nanterre.francetelecom.fr> References: <500CA7FC.2040209@bogus.com> In-Reply-To: <500CA7FC.2040209@bogus.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.20.135415 Subject: Re: [v6ops] Problem in citing http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:45:23 -0000 Dear Joel, all, FYI, a new version is now available at:=20 http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-03 Comments are more than welcome; particularly about this section 2.1. IPv6 May Also Be Concerned . . . . . . . . . . . . . . . . 6 The new version of the draft does not include any recommendation as this wa= s objected during the intarea wglc. The document can be cited for various purposes, e.g.,: (1) acknowledge the technical issue (2) point to the definition of the HOST_ID concept (3) list candidate solutions (4) pick a favourite solution for a given deployment context. Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de joel jaeggli >Envoy=E9 : lundi 23 juillet 2012 03:25 >=C0 : IPv6 Ops WG >Objet : [v6ops] Problem in citing=20 >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 > >I have seen in at least two discussions recently as well as a document=20 >that I'm reviewing citations of: > > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 > > Analysis of Solution Candidates to Reveal a Host Identifier=20 >(HOST_ID) > in Shared Address Deployments > > From my vantage point this document analyzes the solution space, it=20 >does not solve the problem of host identification in=20 >particular it does=20 >not today mitigate problems with source identification through=20 >translation. > >Pointing to this document as solution, is IMHO tantamount to saying=20 >there isn't an operationally relevant solution, and should be=20 >acknowledged accordingly. > >The analysis in my opinion is a terribly important document and we=20 >should read it closely, and use it to inform work on the problem. > >thanks >joel >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From lorenzo@google.com Mon Aug 20 19:23:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2A11E80A2 for ; Mon, 20 Aug 2012 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hcCS1VIaM1F for ; Mon, 20 Aug 2012 19:23:51 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2B8411E809A for ; Mon, 20 Aug 2012 19:23:50 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12088839obb.31 for ; Mon, 20 Aug 2012 19:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2gn1rk1KxFiri+JO232+vlg0uNjvrG6JuMMHdrU+T2g=; b=oxhl5VIyojxwgUJYy1R9B8YYz+pnT4H+rEPYDueuKieM34z6D8h0V6/6oFC60mxA/k cObramfP56qXtDrFl78XRk19L2ZYHzOCNtSHgd6yylnuR28UpqVjO3Rof7fsgyiza4GP wtv3Es15vHxh807gzIODokQk3YQkVPKFUBfz2no0ZbSN2AWS1TGEe4dJ7tGJ3uqRyEEF PyjNCWQnW5XX9QP4/2uKgRTYcQY+sueG8wyyppoPWwPrQTxDoUlja6vCSROctsDiMTs1 N2OASH6yZHU4DdjC+MWrpBhorkhtTAC7Ury4vTsfAsOnscdVrPrgTYj2I6LlGzp6EM5u Jx4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=2gn1rk1KxFiri+JO232+vlg0uNjvrG6JuMMHdrU+T2g=; b=RSSVkO+wuY1o1dn2bonmsp1uwV3+rxmCDBTlRKbQkjIwMXBQzVEZuUGMapwmfYmztE is+UNeqBn6gKcg4Y745uhrjwkrNg54uzyK70MY9btb9FoLCMxyZ56InZIMOO2dgkTXLm Ey5hFvYUSuomZ9Pci7pjM6oixgjiVnTa4Ex46kewoAdEORUU2lz2UzoCWUbtlbcfwdse AoRo3sAIQrYBLTTROApKSMxj3ZtpyTat3nqklqGaP4OyDU1uvgX1o57gXj2R3CggyddM 496OiRGEnymy2eLVIH2xPSPCZN1nUZqqp6OX6ksjfq3649F2yiPyEnD2jAWLdfM5QphU pBsw== Received: by 10.182.48.8 with SMTP id h8mr11678637obn.75.1345515830515; Mon, 20 Aug 2012 19:23:50 -0700 (PDT) Received: by 10.182.48.8 with SMTP id h8mr11678627obn.75.1345515830270; Mon, 20 Aug 2012 19:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 20 Aug 2012 19:23:30 -0700 (PDT) In-Reply-To: <20120817094953.10350hmgauyyi9e8@mail.drown.org> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> From: Lorenzo Colitti Date: Tue, 21 Aug 2012 11:23:30 +0900 Message-ID: To: Dan Drown Content-Type: multipart/alternative; boundary=f46d04462fe41a5a7804c7bd5180 X-System-Of-Record: true X-Gm-Message-State: ALoCoQml1yRBtKyBQCFX0epRdzmINKMvaRfBlIGrSCf9fkW1i3oGs1Af95ZbYtf0QBmHIWpPD/vPGxQ/4Qkivz9ZpC9ZIKFV0eiEonTvOkw7AZRV4WDbN9ekJu15o8262PbAEqk9cWN5t1kkfTS3fgLRW5G1Kwk2+sRm0PsatPwR9FrKqv1UMFRIb3zjezsVDJyWIxq4zR54 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 02:23:51 -0000 --f46d04462fe41a5a7804c7bd5180 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown wrote: > Quoting "Bjoern A. Zeeb" > >: > >> On Thu, 16 Aug 2012, Dan Drown wrote: >> >>> That may work for some implementations, but not for android-clat. The >>> clat function needs its own address, and it cannot be any address that the >>> handset considers local. >>> >> >> /me bites his tongue. >> >> Seriously? Out of curiosity, can you elaborate (feel free to do so >> unicast). >> > > Yes. The implementation of clat for android is done in userspace (using a > tun interface to pass traffic between the kernel and the userspace > program), and needs its own address. Otherwise native traffic from the > handset to the plat prefix (apps that support DNS64's rewritten AAAA > answers) can't be seperated from translated traffic from the clat. Perhaps > this is just an implementation detail that doesn't need to go into the > standard, but it's unavoidable for me. > Fair enough. But that doesn't require a special EUI-64 to be allocated, right? All you need is an IPv6 address that can be defended against DAD. Can we then just say "if the CLAT picks an IPv6 address to use on the LAN side, then it must make sure to reply to DAD on that address"? --f46d04462fe41a5a7804c7bd5180 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <= dan-v6ops@drown.org> wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbado= z.net>:
On Thu, 16 Aug 2012, Dan Drown wrote:
That may work for some implementations, but not for android-clat. =A0The cl= at function needs its own address, and it cannot be any address that the ha= ndset considers local.

/me bites his tongue.

Seriously? =A0Out of curiosity, can you elaborate (feel free to do so unica= st).

Yes. =A0The implementation of clat for android is done in userspace (using = a tun interface to pass traffic between the kernel and the userspace progra= m), and needs its own address. =A0Otherwise native traffic from the handset= to the plat prefix (apps that support DNS64's rewritten AAAA answers) = can't be seperated from translated traffic from the clat. =A0Perhaps th= is is just an implementation detail that doesn't need to go into the st= andard, but it's unavoidable for me.

Fair enough. But that doesn't require a spe= cial EUI-64 to be allocated, right? All you need is an IPv6 address that ca= n be defended against DAD. Can we then just say "if the CLAT picks an = IPv6 address to use on the LAN side, then it must make sure to reply to DAD= on that address"?
--f46d04462fe41a5a7804c7bd5180-- From cb.list6@gmail.com Mon Aug 20 20:21:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F74E11E80A5; Mon, 20 Aug 2012 20:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1NoSweRMu-i; Mon, 20 Aug 2012 20:21:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D28D711E80A2; Mon, 20 Aug 2012 20:21:50 -0700 (PDT) Received: by lahm15 with SMTP id m15so3835296lah.31 for ; Mon, 20 Aug 2012 20:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xlc0sdF8IfFPOfYpov+PqFUjqMwmQrtCgIQug/XkSH8=; b=l7hWGAJOUvHw1hoaZkR6qk4cUdzYxHUsd2tulIhtX2cN+K1xPVD8lOnGZgHR6mNVPs dt/elM640hoPMpZRFs1qW8Wwg6tRlM6xYbsjziRF/JRwL1/pQgbcyayrNSWnyVztOF+5 F6CrDa+DBUsfXMY5ystUDsd6335T5DtKGyBWtxbDGerFoplZIk6XJefZbaJcZsRholuf FUJxOK7gzXTB4WJnUf/bz7SHcQk4GFh8cOjGt6eZhoEydlaI2CjIYacMN7A5QfXDtZB1 cVPthYAI3NRr2VwW7WOoc369eqQnA20TXO+thShMrqr3t5oDC+nz+LMjce1tZ0ADS0Ml R5tA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr15760020lab.47.1345519305342; Mon, 20 Aug 2012 20:21:45 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 20 Aug 2012 20:21:45 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 20:21:45 -0700 Message-ID: From: Cameron Byrne To: Washam Fan Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 03:21:52 -0000 Thanks for the review. On Sun, Aug 19, 2012 at 10:47 PM, Washam Fan wrote: > Hi, > > Sorry for the late response. I finally got a chance to review this > edition and had some confusions > 1. in sec 8.3.2, it lacks of elaborating on how to differentiate > native IPv6 packet from translated IPv6 packet. is it where reserved > IANA Modified EUI-64 ID comes in? Example 2 should help make this clear http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#appendix-A > 2. BIH only mentioned in two places in the draft and not mentioned in > abstract. If we want to cover BIH, shouldn't we elaborate a bit on how > to combine BIH with 464xlate? Or is it too obvious to talk about that? We do not have real experience with BIH, so we choose to only mention how it fits into the architecture for the future case of IPv4-only client to IPv6-only server without going into too much detail. > 3. Are BIH exclusive with rfc6145? in other words, enabling both BIH > and rfc6145 on CLAT is OK? > It should be OK. The BIH functions and the CLAT RFC6145 functions should happen independently. CB > Thanks, > washam > > 2012/8/7 : >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : 464XLAT: Combination of Stateful and Stateless Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-06.txt >> Pages : 19 >> Date : 2012-08-06 >> >> Abstract: >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in the >> core and stateless protocol translation RFC 6145 at the edge. 464XLAT >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-06 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Mon Aug 20 20:54:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21411E80CC; Mon, 20 Aug 2012 20:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biABeegc9p4z; Mon, 20 Aug 2012 20:54:08 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id AA40711E80BF; Mon, 20 Aug 2012 20:54:07 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so3434326wib.13 for ; Mon, 20 Aug 2012 20:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/mkcq8dNK57AYiKdTGYwg1aF7o1FuZJWSQ2jc/2ZE0=; b=uHC5wXEW7jyrzjx4cCiz6AT00XtyFaTfYUF3fdSdTq5Zz5ZBw0gVCORjxSDySziDUB 9oT27NH2DY1U/pMM9dvkRAEbnX/QRwITa6dqzMzuKxTwdHy+ZS+ubH/Xw3IicMOCsIbx mByDo6Ao7Hxja1CAcV8hZ67t82zm8+dilJJaQB36TAzxYvKgY73rWiAklpn19gY22zXm TCMOlpPvSBU2CtR/ZIHErv5qVo/ezPWlyqPX6BPKj2JKpCWctvMyAl8loEh375c2r4IV 02Q8qaSqd9XKa+y/fvQhb3bX370Ix/TgyU/HOogf8486An7dpVwJ6HffMY+e1Qvr5Oj5 dPSg== MIME-Version: 1.0 Received: by 10.217.1.201 with SMTP id n51mr7963058wes.124.1345521246537; Mon, 20 Aug 2012 20:54:06 -0700 (PDT) Received: by 10.216.205.96 with HTTP; Mon, 20 Aug 2012 20:54:06 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 11:54:06 +0800 Message-ID: From: Washam Fan To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 03:54:09 -0000 Hi Cameron, Please see inline. 2012/8/21 Cameron Byrne : > Thanks for the review. > > On Sun, Aug 19, 2012 at 10:47 PM, Washam Fan wrote: >> Hi, >> >> Sorry for the late response. I finally got a chance to review this >> edition and had some confusions >> 1. in sec 8.3.2, it lacks of elaborating on how to differentiate >> native IPv6 packet from translated IPv6 packet. is it where reserved >> IANA Modified EUI-64 ID comes in? > > Example 2 should help make this clear > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#appendix-A Yes. 464xlat-07 addresses this concern a lot. But what if the address 2001:db8:aaaa:0:200:5e10:: present in the example 2 is used for native IPv6 communication? Or any methods preventing such use should be mentioned? >> 2. BIH only mentioned in two places in the draft and not mentioned in >> abstract. If we want to cover BIH, shouldn't we elaborate a bit on how >> to combine BIH with 464xlate? Or is it too obvious to talk about that? > > We do not have real experience with BIH, so we choose to only mention > how it fits into the architecture for the future case of IPv4-only > client to IPv6-only server without going into too much detail. > If so, why just remove BIH to keep the memo concise. Thanks, washam >> 3. Are BIH exclusive with rfc6145? in other words, enabling both BIH >> and rfc6145 on CLAT is OK? >> > > It should be OK. The BIH functions and the CLAT RFC6145 functions > should happen independently. > > CB > >> Thanks, >> washam >> >> 2012/8/7 : >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>> >>> Title : 464XLAT: Combination of Stateful and Stateless Translation >>> Author(s) : Masataka Mawatari >>> Masanobu Kawashima >>> Cameron Byrne >>> Filename : draft-ietf-v6ops-464xlat-06.txt >>> Pages : 19 >>> Date : 2012-08-06 >>> >>> Abstract: >>> This document describes an architecture (464XLAT) for providing >>> limited IPv4 connectivity across an IPv6-only network by combining >>> existing and well-known stateful protocol translation RFC 6146 in the >>> core and stateless protocol translation RFC 6145 at the edge. 464XLAT >>> is a simple and scalable technique to quickly deploy limited IPv4 >>> access service to IPv6-only edge networks without encapsulation. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-06 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Aug 20 21:21:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C7121F84B5 for ; Mon, 20 Aug 2012 21:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uhUZGPam6HQ for ; Mon, 20 Aug 2012 21:21:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEF21F84B2 for ; Mon, 20 Aug 2012 21:21:28 -0700 (PDT) Received: by lahm15 with SMTP id m15so3852758lah.31 for ; Mon, 20 Aug 2012 21:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UiBSqW+4bve3kE2cD7MMVAjOKke3zj8O04YzeoJ9Bhk=; b=VyMUoR1duH+ueZBd7EXW2ZE59kLC8oKE5poDvueXChSB0vLne1fYr45Rkyk7hUMVkk LQ4NWJnzQvTkAQ7vxlCNj7721u/UdMEBtUjLY/rHJv4TiVJFW8WaZIh9V5cVXiq+YPK9 Bm6M6ysMlnvLJV2esON/FXNtPgheQ0aUcFHqaqnRMDXjGwsGnZkEmsHWL5JZAgijt+kr RdyG7VY+04tKGhX/ZLzctrDgT15rvFqLIqO7pYXljKO+KMAYQlqwNnPJ43noEdugUjOH h/sN+3od3ukN2aFn6tl0q2l/Vp5L61SEYFnk7c3hIMrER48BtOj1t2O6qpXwquJ0oYCC m2ww== MIME-Version: 1.0 Received: by 10.112.54.100 with SMTP id i4mr6978710lbp.97.1345522886661; Mon, 20 Aug 2012 21:21:26 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 20 Aug 2012 21:21:26 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 21:21:26 -0700 Message-ID: From: Cameron Byrne To: Washam Fan Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 04:21:35 -0000 Washam, On Mon, Aug 20, 2012 at 8:54 PM, Washam Fan wrote: > Hi Cameron, > > Please see inline. > > 2012/8/21 Cameron Byrne : >> Thanks for the review. >> >> On Sun, Aug 19, 2012 at 10:47 PM, Washam Fan wrote: >>> Hi, >>> >>> Sorry for the late response. I finally got a chance to review this >>> edition and had some confusions >>> 1. in sec 8.3.2, it lacks of elaborating on how to differentiate >>> native IPv6 packet from translated IPv6 packet. is it where reserved >>> IANA Modified EUI-64 ID comes in? >> >> Example 2 should help make this clear >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#appendix-A > > Yes. 464xlat-07 addresses this concern a lot. But what if the address > 2001:db8:aaaa:0:200:5e10:: present in the example 2 is used for native > IPv6 communication? Or any methods preventing such use should be > mentioned? > That scenarios is statistically unlikely enough for me, and with a dedicate EUI-64 further unlikely for even the pessimist in the WG >>> 2. BIH only mentioned in two places in the draft and not mentioned in >>> abstract. If we want to cover BIH, shouldn't we elaborate a bit on how >>> to combine BIH with 464xlate? Or is it too obvious to talk about that? >> >> We do not have real experience with BIH, so we choose to only mention >> how it fits into the architecture for the future case of IPv4-only >> client to IPv6-only server without going into too much detail. >> > If so, why just remove BIH to keep the memo concise. > There was a fairly long conversation here, there are also others: http://www.ietf.org/mail-archive/web/v6ops/current/msg12630.html The conclusion was that the 464XLAT is more complete by making a reference to BIH scenario. CB > Thanks, > washam >>> 3. Are BIH exclusive with rfc6145? in other words, enabling both BIH >>> and rfc6145 on CLAT is OK? >>> >> >> It should be OK. The BIH functions and the CLAT RFC6145 functions >> should happen independently. >> >> CB >> >>> Thanks, >>> washam >>> >>> 2012/8/7 : >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>>> >>>> Title : 464XLAT: Combination of Stateful and Stateless Translation >>>> Author(s) : Masataka Mawatari >>>> Masanobu Kawashima >>>> Cameron Byrne >>>> Filename : draft-ietf-v6ops-464xlat-06.txt >>>> Pages : 19 >>>> Date : 2012-08-06 >>>> >>>> Abstract: >>>> This document describes an architecture (464XLAT) for providing >>>> limited IPv4 connectivity across an IPv6-only network by combining >>>> existing and well-known stateful protocol translation RFC 6146 in the >>>> core and stateless protocol translation RFC 6145 at the edge. 464XLAT >>>> is a simple and scalable technique to quickly deploy limited IPv4 >>>> access service to IPv6-only edge networks without encapsulation. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-06 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Mon Aug 20 22:31:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB221F855A for ; Mon, 20 Aug 2012 22:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJytxc6Dd-8Z for ; Mon, 20 Aug 2012 22:31:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0E821F848F for ; Mon, 20 Aug 2012 22:31:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T3h3S-00021y-Og; Tue, 21 Aug 2012 05:31:07 +0000 Date: Tue, 21 Aug 2012 14:31:26 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 05:31:09 -0000 > Fair enough. But that doesn't require a special EUI-64 to be allocated, > right? All you need is an IPv6 address that can be defended against > DAD. you certainly have convinced me of this point. so consider this a wglc 'to be fixed' request. randy From despres.remi@laposte.net Tue Aug 21 00:41:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1821F8650 for ; Tue, 21 Aug 2012 00:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YAdCWOpWTZB for ; Tue, 21 Aug 2012 00:41:38 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19A21F8648 for ; Tue, 21 Aug 2012 00:41:37 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id BF5737000090; Tue, 21 Aug 2012 09:41:36 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 3A9D6700008F; Tue, 21 Aug 2012 09:41:36 +0200 (CEST) X-SFR-UUID: 20120821074136240.3A9D6700008F@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-29-7988837 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 09:41:32 +0200 Message-Id: <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:41:39 -0000 --Apple-Mail-29-7988837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-08-21 04:23, Lorenzo Colitti : > On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown = wrote: > Quoting "Bjoern A. Zeeb" : > On Thu, 16 Aug 2012, Dan Drown wrote: > That may work for some implementations, but not for android-clat. The = clat function needs its own address, and it cannot be any address that = the handset considers local. >=20 > /me bites his tongue. >=20 > Seriously? Out of curiosity, can you elaborate (feel free to do so = unicast). >=20 > Yes. The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address. Otherwise native traffic = from the handset to the plat prefix (apps that support DNS64's rewritten = AAAA answers) can't be seperated from translated traffic from the clat. = Perhaps this is just an implementation detail that doesn't need to go = into the standard, but it's unavoidable for me. >=20 > Fair enough. But that doesn't require a special EUI-64 to be = allocated, right? All you need is an IPv6 address that can be defended = against DAD. Can we then just say "if the CLAT picks an IPv6 address to = use on the LAN side, then it must make sure to reply to DAD on that = address"? Sure, the CLAT node must indeed reply to DAD on the address it has on = the LAN side (as usual). But the point is that, if the interface ID used by the CLAT the WAN-side = is one that a host may use on the LAN (according to RFC 4291), this ID = must be excluded on the LAN side IN ADDITION to that of the LAN-side = address. This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is = reserved for CLAT addressing. (It belongs to a range that is precisely = "available for allocation" in RFC 5342, and therefore to never be used = by any host). =20 Note that, with words proposed in = www.ietf.org/mail-archive/web/v6ops/current/msg13856.html using this ID = in NAT44-enabled cases is only a SHOULD. This permits implementations = that don't use it if found preferable for some good reason. But, at = least, it also permits implementations that takes advantage of this ID. Your insistance to go backward on this issue is hard to understand. Regards, RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-29-7988837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <dan-v6ops@drown.org> = wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>:
On Thu, 16 Aug 2012, Dan Drown wrote:
That may work for some implementations, but not for android-clat. =  The clat function needs its own address, and it cannot be any = address that the handset considers local.

/me bites his tongue.

Seriously?  Out of curiosity, can you elaborate (feel free to do so = unicast).

Yes.  The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address.  Otherwise native = traffic from the handset to the plat prefix (apps that support DNS64's = rewritten AAAA answers) can't be seperated from translated traffic from = the clat.  Perhaps this is just an implementation detail that = doesn't need to go into the standard, but it's unavoidable for me.

Fair enough. But that doesn't require a = special EUI-64 to be allocated, right? All you need is an IPv6 address = that can be defended against DAD. Can we then just say "if the CLAT = picks an IPv6 address to use on the LAN side, then it must make sure to = reply to DAD on that = address"?

Sure, the CLAT node must = indeed reply to DAD on the address it has on the LAN side (as = usual).

But the point is that, if the interface = ID used by the CLAT the WAN-side is one that a host may use on the = LAN (according to RFC 4291), this ID must be excluded on the LAN = side IN ADDITION to that of the LAN-side address.
This = obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is reserved for CLAT addressing. = (It belongs to a range that is = precisely "available for allocation" in RFC 5342, and therefore to never be used by any = host).

Note that, with = words proposed in = www.ietf.org/mail-archive/web/v6ops/current/msg13856.html using this = ID in NAT44-enabled cases is only a SHOULD. This permits implementations = that don't use it if found preferable for some good reason. = But, at least, it also permits implementations that takes advantage of this = ID.
Your insistance to = go backward on this issue is hard to understand.

Regards,
RD



<= div>


_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-29-7988837-- From lorenzo@google.com Tue Aug 21 00:56:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCBE21F86C9 for ; Tue, 21 Aug 2012 00:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDSoqB4b9NWm for ; Tue, 21 Aug 2012 00:56:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73B21F86B6 for ; Tue, 21 Aug 2012 00:56:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12549476obb.31 for ; Tue, 21 Aug 2012 00:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=l9EiQNQ47huvoF2n3Z0Zyg0XUuqcIcW2ECDihToTI/U=; b=iNts7dI9vgNCkfPkKDa8ANcousLZHpyMCG1z2UYOdRctlkR1vMLFNm9n8/BXIA1Zpy +ia7CkDIWuwKmGtjGCCSrgntoPRtatHQ82LMwRNzO9pKvhSKzUdyYpWcRue39LfYTpZ/ KBMY1jDgl6HzyFZY5iNmz8TpJA3mpZXieKUVTo3VeowpiXpVxppJdH7H3jxbFoRRsUuQ /bymRCyV02ER6/ieggBwJCO/EmA+1WeV1AxB2wr2roftIhEXVkgLgqrVHExZ+N+Zwd/V JKFLzdZ74Ap+s/DtBVxlklQLmbH/Vt4KQpmErIg4GYeWtfmApBP7fqk+U8kMOdwG0zkH kF8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=l9EiQNQ47huvoF2n3Z0Zyg0XUuqcIcW2ECDihToTI/U=; b=jLY+6T65Yy75G5i7ruhOys7zVsTR+j1DE1XmDvso0jMGIhuB/9u0m1R08FJQILS9P4 LTgwNQr+zn0OgeI0vwLBL7voxDVpnasleGoGX3IdZdQrBg5fREGT0VNFL5JRS8t3Lu50 fN7w3C5FgwV4237wPrwcVa1gBW15nGZ7LPDJ/Beh7dxrLEHfVxu66Uobw4tjsZzHrQrv Dy+I2KjVH1lc9sgHV/2m8L0CdPkwq+6IVj+GTQW+SwvqXpctnpmhilijLsmexCZ8lW9A 3fljDr+uHNHcwVxYtxFbmI1lYvG4TYdWVpsRauk/8yTYNiUtYozcXQo2cBaaFREyMoTj krJw== Received: by 10.182.131.98 with SMTP id ol2mr12186416obb.69.1345535778057; Tue, 21 Aug 2012 00:56:18 -0700 (PDT) Received: by 10.182.131.98 with SMTP id ol2mr12186399obb.69.1345535777706; Tue, 21 Aug 2012 00:56:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 21 Aug 2012 00:55:57 -0700 (PDT) In-Reply-To: <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> From: Lorenzo Colitti Date: Tue, 21 Aug 2012 16:55:57 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f5028be1013a404c7c1f611 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlsq7ZFM2ro8A2cKd7TNnGGUsK6hUCKrW84D93WlMfq89Yq7KA6XfMLwUW3mNXiGsAmFq+gSPUD4jD7uZgKC0bo/jxXKEQQRLDyVlS0La+ME14MmNkw1+f7RAYG39du70uqedAi/cVxv/+Z5UnOAE/8FkZuSMhD5rmDJKWhlnpxMy3IF5JGJue1Z5PR0cF5KOzKggVV Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:56:19 -0000 --e89a8f5028be1013a404c7c1f611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9s wrote: > > 2012-08-21 04:23, Lorenzo Colitti : > > On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown wrote: > >> Quoting "Bjoern A. Zeeb" >> >: >> >>> On Thu, 16 Aug 2012, Dan Drown wrote: >>> >>>> That may work for some implementations, but not for android-clat. The >>>> clat function needs its own address, and it cannot be any address that= the >>>> handset considers local. >>>> >>> >>> /me bites his tongue. >>> >>> Seriously? Out of curiosity, can you elaborate (feel free to do so >>> unicast). >>> >> >> Yes. The implementation of clat for android is done in userspace (using >> a tun interface to pass traffic between the kernel and the userspace >> program), and needs its own address. Otherwise native traffic from the >> handset to the plat prefix (apps that support DNS64's rewritten AAAA >> answers) can't be seperated from translated traffic from the clat. Perh= aps >> this is just an implementation detail that doesn't need to go into the >> standard, but it's unavoidable for me. >> > > Fair enough. But that doesn't require a special EUI-64 to be allocated, > right? All you need is an IPv6 address that can be defended against DAD. > Can we then just say "if the CLAT picks an IPv6 address to use on the LAN > side, then it must make sure to reply to DAD on that address"? > > > Sure, the CLAT node must indeed reply to DAD on the address it has on the > LAN side (as usual). > > But the point is that, if the interface ID used by the CLAT the WAN-side > is one that a host may use on the LAN (according to RFC 4291), this ID mu= st > be excluded on the LAN side IN ADDITION to that of the LAN-side address. > Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it must defend that address against DAD on the LAN interface. > This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is > reserved for CLAT addressing. (It belongs to a range that is precisely "a= vailable > for allocation" in RFC 5342, and therefore to never be used by any host). > That's one way to solve the problem: avoid duplicate addresses by making CLAT use a range that is reserved only for CLAT. In essence, you're avoiding duplicate addresses by forbidding them. Another way to solve the problem is to use the standard IPv6 mechanism used to avoid duplicate addresses, i.e., DAD. Why can't we just say that the CLAT MUST perform DAD properly for all the addresses that it uses, and just leave it at that? It seems excessive to request a reserved range from IANA just for the purposes of avoiding duplicate addresses, when DAD would do the job just fine. --e89a8f5028be1013a404c7c1f611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:

2012-08-21 04:23, Lorenzo= Colitti :

On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <dan-v= 6ops@drown.org> wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net<= /a>>:

Yes. =A0The implementation of clat for android is done in userspace (using = a tun interface to pass traffic between the kernel and the userspace progra= m), and needs its own address. =A0Otherwise native traffic from the handset= to the plat prefix (apps that support DNS64's rewritten AAAA answers) = can't be seperated from translated traffic from the clat. =A0Perhaps th= is is just an implementation detail that doesn't need to go into the st= andard, but it's unavoidable for me.

Fair enough. But that doesn't require a spe= cial EUI-64 to be allocated, right? All you need is an IPv6 address that ca= n be defended against DAD. Can we then just say "if the CLAT picks an = IPv6 address to use on the LAN side, then it must make sure to reply to DAD= on that address"?


This obligation is avoided if= interface ID=A0= 02-00-5E-10-00-00-00-00 is reserved for CLAT addressing. (It belongs to a range that= is precisely "available for allocation" in RFC 5342, and therefore to never be use= d by any host).


Another way to solve the problem is to use the standard= IPv6 mechanism used to avoid duplicate addresses, i.e., DAD.
Why can't we just say that the CLAT MUST perform DAD proper= ly for all the addresses that it uses, and just leave it at that? It seems = excessive to request a reserved range from IANA just for the purposes of av= oiding duplicate addresses, when DAD would do the job just fine.
--e89a8f5028be1013a404c7c1f611-- From despres.remi@laposte.net Tue Aug 21 01:08:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB48721F8620 for ; Tue, 21 Aug 2012 01:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqClX+kYbCED for ; Tue, 21 Aug 2012 01:08:06 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3389D21F860D for ; Tue, 21 Aug 2012 01:07:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id DB1777000047; Tue, 21 Aug 2012 10:07:53 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 6522870000B8; Tue, 21 Aug 2012 10:07:53 +0200 (CEST) X-SFR-UUID: 20120821080753414.6522870000B8@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30-9565737 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 10:07:49 +0200 Message-Id: <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.dro wn.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:08:07 -0000 --Apple-Mail-30-9565737 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-21 =E0 09:55, Lorenzo Colitti a =E9crit : > On Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9s = wrote: >=20 > 2012-08-21 04:23, Lorenzo Colitti : >=20 >> On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown = wrote: >> Quoting "Bjoern A. Zeeb" : >> On Thu, 16 Aug 2012, Dan Drown wrote: >> That may work for some implementations, but not for android-clat. = The clat function needs its own address, and it cannot be any address = that the handset considers local. >>=20 >> /me bites his tongue. >>=20 >> Seriously? Out of curiosity, can you elaborate (feel free to do so = unicast). >>=20 >> Yes. The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address. Otherwise native traffic = from the handset to the plat prefix (apps that support DNS64's rewritten = AAAA answers) can't be seperated from translated traffic from the clat. = Perhaps this is just an implementation detail that doesn't need to go = into the standard, but it's unavoidable for me. >>=20 >> Fair enough. But that doesn't require a special EUI-64 to be = allocated, right? All you need is an IPv6 address that can be defended = against DAD. Can we then just say "if the CLAT picks an IPv6 address to = use on the LAN side, then it must make sure to reply to DAD on that = address"? >=20 > Sure, the CLAT node must indeed reply to DAD on the address it has on = the LAN side (as usual). >=20 > But the point is that, if the interface ID used by the CLAT the = WAN-side is one that a host may use on the LAN (according to RFC 4291), = this ID must be excluded on the LAN side IN ADDITION to that of the = LAN-side address. >=20 > Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it = must defend that address against DAD on the LAN interface. > =20 > This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is = reserved for CLAT addressing. (It belongs to a range that is precisely = "available for allocation" in RFC 5342, and therefore to never be used = by any host). =20 >=20 > That's one way to solve the problem: avoid duplicate addresses by = making CLAT use a range that is reserved only for CLAT. In essence, = you're avoiding duplicate addresses by forbidding them. >=20 > Another way to solve the problem is to use the standard IPv6 mechanism = used to avoid duplicate addresses, i.e., DAD. >=20 > Why can't we just say that the CLAT MUST perform DAD properly for all = the addresses that it uses, and just leave it at that? It seems = excessive to request a reserved range from IANA just for the purposes of = avoiding duplicate addresses, when DAD would do the job just fine. Note that it is only ONE allocated value (in a range "available for = allocation").=20 I can't understand why consuming a value, among many that have been made = available for that, would be a big issue, especially since doing so = permits to simplify some implementations. Have you some reason you can share for such a concern? RD --Apple-Mail-30-9565737 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Tue, Aug 21, 2012 at 4:41 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

2012-08-21 04:23, = Lorenzo Colitti :

On Fri, Aug 17, 2012 at 11:49 = PM, Dan Drown <dan-v6ops@drown.org> wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>:
On Thu, 16 Aug 2012, Dan Drown wrote:
That may work for some implementations, but not for android-clat. =  The clat function needs its own address, and it cannot be any = address that the handset considers local.

/me bites his tongue.

Seriously?  Out of curiosity, can you elaborate (feel free to do so = unicast).

Yes.  The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address.  Otherwise native = traffic from the handset to the plat prefix (apps that support DNS64's = rewritten AAAA answers) can't be seperated from translated traffic from = the clat.  Perhaps this is just an implementation detail that = doesn't need to go into the standard, but it's unavoidable for me.

Fair enough. But that doesn't require a = special EUI-64 to be allocated, right? All you need is an IPv6 address = that can be defended against DAD. Can we then just say "if the CLAT = picks an IPv6 address to use on the LAN side, then it must make sure to = reply to DAD on that address"?

Sure, the CLAT node must = indeed reply to DAD on the address it has on the LAN side (as = usual).

But the point is that, if the interface = ID used by the CLAT the WAN-side is one that a host may use on the = LAN (according to RFC 4291), this ID must be excluded on the LAN = side IN ADDITION to that of the LAN-side address.

Agreed. If the CLAT assigns = itself an IPv6 address on the WAN site, it must defend that address = against DAD on the LAN interface.
 
This obligation is avoided = if interface ID 02-00-5E-10-00-00-00-= 00 is reserved for CLAT addressing. (It belongs to a = range that is precisely "available = for = allocation" in RFC 5342, and therefore to never be used by any host). =

That's one way to solve the = problem: avoid duplicate addresses by making CLAT use a range that is = reserved only for CLAT. In essence, you're avoiding duplicate addresses = by forbidding them.

Another way to solve the problem is to use the = standard IPv6 mechanism used to avoid duplicate addresses, i.e., = DAD.

Why can't we just say that the CLAT MUST = perform DAD properly for all the addresses that it uses, and just leave = it at that? It seems excessive to request a reserved range from IANA = just for the purposes of avoiding duplicate addresses, when DAD would do = the job just fine.

Note that it is only ONE allocated value (in = a range "available for = allocation"). 

I can't understand = why consuming a value, among many that have been made available for = that, would be a big issue, especially since doing so permits to = simplify some implementations.
Have you some reason you can = share for such a = concern?

RD


= --Apple-Mail-30-9565737-- From randy@psg.com Tue Aug 21 01:17:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBDA21F8661 for ; Tue, 21 Aug 2012 01:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Vnud7tgMyi for ; Tue, 21 Aug 2012 01:17:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7279621F8628 for ; Tue, 21 Aug 2012 01:17:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T3jeG-0002M0-LM; Tue, 21 Aug 2012 08:17:17 +0000 Date: Tue, 21 Aug 2012 17:17:36 +0900 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:17:21 -0000 > I can't understand why consuming a value, among many that have been > made available for that, would be a big issue, especially since doing > so permits to simplify some implementations. Have you some reason you > can share for such a concern? because it is *not* *needed* and solves nothing. use the existing mechanism, dad. and, if you are prudent, you will have to do so anyway, iana special or not. randy From bzeeb-lists@lists.zabbadoz.net Tue Aug 21 01:27:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947E421F8701 for ; Tue, 21 Aug 2012 01:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmXB-+0C-Y1I for ; Tue, 21 Aug 2012 01:27:19 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F621F86FC for ; Tue, 21 Aug 2012 01:27:19 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 604A325D3888; Tue, 21 Aug 2012 08:27:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 77700BE84BC; Tue, 21 Aug 2012 08:27:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5B4JraaD5woJ; Tue, 21 Aug 2012 08:27:14 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C028DBE84BA; Tue, 21 Aug 2012 08:27:13 +0000 (UTC) Date: Tue, 21 Aug 2012 08:27:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: Lorenzo Colitti In-Reply-To: Message-ID: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:27:19 -0000 On Tue, 21 Aug 2012, Lorenzo Colitti wrote: > Why can't we just say that the CLAT MUST perform DAD properly for all the > addresses that it uses, and just leave it at that? It seems excessive to There is not even a need to say that. If you talk IPv6 you need to do this and any IPv6 address configured for use by the CLAT or just for plain v6 needs to do it. You would even need to do it for a special EUI address. End of story. The real problem I see and from what I learnt is that people are thinking too many global addresses on a single device once again; there is no need for two global addresses, one on the outside (3GPP/DSL/ CABLE/you name it) and one on the wifi interface to my understanding as long as the entire prefix is routed to the device, which it is in the tethering case I have been told, which what this entire discussion is about. Correct me if I am wrong. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From despres.remi@laposte.net Tue Aug 21 01:56:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648221F8710 for ; Tue, 21 Aug 2012 01:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+0-AziWposC for ; Tue, 21 Aug 2012 01:56:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8C51521F870B for ; Tue, 21 Aug 2012 01:56:14 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 44AA59400E3; Tue, 21 Aug 2012 10:56:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 10:56:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <000904D2-6476-4293-A636-43319098B3FA@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:56:17 -0000 Le 2012-08-21 =E0 10:17, Randy Bush a =E9crit : >> I can't understand why consuming a value, among many that have been >> made available for that, would be a big issue, especially since doing >> so permits to simplify some implementations. Have you some reason = you >> can share for such a concern? >=20 > because it is *not* *needed* and solves nothing. use the existing > mechanism, dad. and, if you are prudent, you will have to do so = anyway, > iana special or not. My question was, why would it be difficult to get IANA to register an = interface ID, one which is in a range explicitly "available for = allocation". AFAIK it isn't difficult (but open to hear what others have = to say). Solves nothing is the point of different understanding. - DAD isn't a solution if 464XLAT is activated after hosts have been = given their interface IDs.=20 - Keeping functions independent has always been better than creating = mutual constraints. (I suspect you agree on this.) Having code against a particular manual misconfiguration of a host = address (one that doesn't comply with RFC 4291) would AFAIK be excessive = "prudence". No need for it. RD >=20 > randy From randy@psg.com Tue Aug 21 02:02:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB76321F871C for ; Tue, 21 Aug 2012 02:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeL+sfLthur8 for ; Tue, 21 Aug 2012 02:02:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA5421F8718 for ; Tue, 21 Aug 2012 02:02:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T3kLk-0002ad-LJ; Tue, 21 Aug 2012 09:02:13 +0000 Date: Tue, 21 Aug 2012 18:02:32 +0900 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <000904D2-6476-4293-A636-43319098B3FA@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <000904D2-6476-4293-A636-43319098B3FA@laposte.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:02:14 -0000 >> because it is *not* *needed* and solves nothing. use the existing >> mechanism, dad. and, if you are prudent, you will have to do so anyway, >> iana special or not. > > My question was, why would it be difficult to get IANA to register an > interface ID, one which is in a range explicitly "available for > allocation". AFAIK it isn't difficult (but open to hear what others > have to say). while we are asking the iana for things which are not needed but are not difficult, let's get some ports, a few ipv4 address blocks, and some ipv6 space while we're at it. this is ridiculous. randy From lorenzo@google.com Tue Aug 21 02:12:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA5921F86E0 for ; Tue, 21 Aug 2012 02:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XElN3xeXZ4AH for ; Tue, 21 Aug 2012 02:12:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDDB421F86B8 for ; Tue, 21 Aug 2012 02:12:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12663628obb.31 for ; Tue, 21 Aug 2012 02:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=yqntrnww+1aXAF5oiJU7Qd1kmOtEm11XjHFIKxCunms=; b=lXUlQ0OGBy/sgsDhzmj6/n6YIMpUPz68b9LiPmoEAEdjlnXL+JNPTp85hqbE0aBTbP COqbQVhJXwPjsAlaAhtQKaBQ5cBfhqu/ebQWFGFg09OpM0cItN3i9rqGKAdOo9WcRMa6 QruQsGyCGP6JFT/+07wzl2HH3pqnHd0t4BY9Hg+vS/SYvTN66mdOIEbU8NVF+2S2Mi4A 0Z3UWTaFF3/jA95TCeXtNIYr+mCAOh3T7F54Oqr1lNkLXKLaVuw+yqXy4AnO7pymbbr6 3fAAt6Sa5k3a6WbJw1uyKcF0Wv7JiqctjPCXlPvd0RKcUUKhmSWdRitmIalXIZZEODwN zpzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=yqntrnww+1aXAF5oiJU7Qd1kmOtEm11XjHFIKxCunms=; b=FQC/kvny8IsxCh3cqW1L5J4i80FfewbbB+tqrhy+2BECg7p/Ex1JEg4UAbTaUy0QBO 3XCfxQJtlqh9kJ2Px96jKnrLHvOiQ4Y3vZtXEL+Di66d41Jd/MziolY7edEkT2q1xTww EeBLxXK30Ojh2ylcB5AUsRDUqoThTgB/dc+4F/msNIj3v3IWAEDhAabA1ub2hNi9xdth UFcnjdFV3NuWydQ4f5NqBcUIOTiJx/uGG900rpezOaIfsAAXgeNhPzSk8IkvJ1xK9gdb 05PHhP9VoAkMla1kipBG7FIM7DYpZqGoxna0G6l5GPlfYd8Bum08sv94q25WkYa6wvLT cQTw== Received: by 10.60.10.6 with SMTP id e6mr12790209oeb.45.1345540348494; Tue, 21 Aug 2012 02:12:28 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr12790197oeb.45.1345540348277; Tue, 21 Aug 2012 02:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 21 Aug 2012 02:12:08 -0700 (PDT) In-Reply-To: <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> From: Lorenzo Colitti Date: Tue, 21 Aug 2012 18:12:08 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2028a7d753e04c7c3065d X-System-Of-Record: true X-Gm-Message-State: ALoCoQnToCWwuljf3HjYS5BeDTFfTLLDpDjUIgV2aDnSVsanMsl2BFVzNta5mCEfE7inWqCQLa6PTkksHh+DwnLmUs5pNJfGMmcNfX2xFBVw8xN9FVG0g78dguofLe5rEok8N0vkg00sQ39qhmu1pOCCr/37ngjFr1PgTmLIlRifDB5LfJ7fIs3abPgib35qyBlLJ6rWnUXx Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:12:30 -0000 --e89a8fb2028a7d753e04c7c3065d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 21, 2012 at 5:07 PM, R=E9mi Despr=E9s wrote: > > Le 2012-08-21 =E0 09:55, Lorenzo Colitti a =E9crit : > > On Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9s wrote: > >> >> 2012-08-21 04:23, Lorenzo Colitti : >> >> On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown wrote: >> >>> Quoting "Bjoern A. Zeeb" >>> >: >>> >>>> On Thu, 16 Aug 2012, Dan Drown wrote: >>>> >>>>> That may work for some implementations, but not for android-clat. Th= e >>>>> clat function needs its own address, and it cannot be any address tha= t the >>>>> handset considers local. >>>>> >>>> >>>> /me bites his tongue. >>>> >>>> Seriously? Out of curiosity, can you elaborate (feel free to do so >>>> unicast). >>>> >>> >>> Yes. The implementation of clat for android is done in userspace (usin= g >>> a tun interface to pass traffic between the kernel and the userspace >>> program), and needs its own address. Otherwise native traffic from the >>> handset to the plat prefix (apps that support DNS64's rewritten AAAA >>> answers) can't be seperated from translated traffic from the clat. Per= haps >>> this is just an implementation detail that doesn't need to go into the >>> standard, but it's unavoidable for me. >>> >> >> Fair enough. But that doesn't require a special EUI-64 to be allocated, >> right? All you need is an IPv6 address that can be defended against DAD. >> Can we then just say "if the CLAT picks an IPv6 address to use on the LA= N >> side, then it must make sure to reply to DAD on that address"? >> >> >> Sure, the CLAT node must indeed reply to DAD on the address it has on th= e >> LAN side (as usual). >> >> But the point is that, if the interface ID used by the CLAT the WAN-side >> is one that a host may use on the LAN (according to RFC 4291), this ID m= ust >> be excluded on the LAN side IN ADDITION to that of the LAN-side address. >> > > Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it > must defend that address against DAD on the LAN interface. > > >> This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is >> reserved for CLAT addressing. (It belongs to a range that is precisely "= available >> for allocation" in RFC 5342, and therefore to never be used by any >> host). >> > > That's one way to solve the problem: avoid duplicate addresses by making > CLAT use a range that is reserved only for CLAT. In essence, you're > avoiding duplicate addresses by forbidding them. > > Another way to solve the problem is to use the standard IPv6 mechanism > used to avoid duplicate addresses, i.e., DAD. > > Why can't we just say that the CLAT MUST perform DAD properly for all the > addresses that it uses, and just leave it at that? It seems excessive to > request a reserved range from IANA just for the purposes of avoiding > duplicate addresses, when DAD would do the job just fine. > > > Note that it is only ONE allocated value (in a range "available foralloca= tion"). > > > I can't understand why consuming a value, among many that have been made > available for that, would be a big issue, especially since doing so permi= ts > to simplify some implementations. > Have you some reason you can share for such a concern? > > RD > > > Not really. The issues that I see are: a) It's not needed. If we make a request to IANA, others might ask the same question. "Why are you asking IANA to reserve an interface ID when you can just do DAD?" b) Reserving an IID and not doing DAD will tempt implementations to assume the IID unique, creating problems when (not if) it's not unique any more. Think of two CLAT gateways on the same link, for example. b) Reserving an IID will also tempt operators to assume that the IID never changes, and use that information for support or billing purposes. d) It doesn't really simplify implementations, since there are now two modes (reserved IID and DAD). --e89a8fb2028a7d753e04c7c3065d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 21, 2012 at 5:07 PM, R=E9mi = Despr=E9s <despres.remi@laposte.net> wrote:

Le 2012-08-21 =E0 09:55, = Lorenzo Colitti a =E9crit :

On Tue, Aug 21, 2012 at 4:41 PM, R=E9= mi Despr=E9s <despres.remi@laposte.net> wrote:

2012-08-21 04:23, Lorenzo= Colitti :

On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <<= a href=3D"mailto:dan-v6ops@drown.org" target=3D"_blank">dan-v6ops@drown.org= > wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net<= /a>>:

Yes. =A0The implementation of clat for android is done in userspace (using = a tun interface to pass traffic between the kernel and the userspace progra= m), and needs its own address. =A0Otherwise native traffic from the handset= to the plat prefix (apps that support DNS64's rewritten AAAA answers) = can't be seperated from translated traffic from the clat. =A0Perhaps th= is is just an implementation detail that doesn't need to go into the st= andard, but it's unavoidable for me.

Fair enough. But that doesn't require a spe= cial EUI-64 to be allocated, right? All you need is an IPv6 address that ca= n be defended against DAD. Can we then just say "if the CLAT picks an = IPv6 address to use on the LAN side, then it must make sure to reply to DAD= on that address"?


This obligation is avoided if= interface ID=A0= 02-00-5E-10-00-00-00-00 is reserved for CLAT addressing. (It belongs to a range that= is precisely "available for allocation" in RFC 5342, and therefore to never be use= d by any host).


Another way to solve the problem is to use the standard= IPv6 mechanism used to avoid duplicate addresses, i.e., DAD.
Why can't we just say that the CLAT MUST perform DAD proper= ly for all the addresses that it uses, and just leave it at that? It seems = excessive to request a reserved range from IANA just for the purposes of av= oiding duplicate addresses, when DAD would do the job just fine.


I can't understand why consuming a value, among man= y that have been made available for that, would be a big issue, especially = since doing so permits to simplify some implementations.
Have you= some reason you can share for such a concern?

RD
=



Not really. The issues that I see are:

a) It= 9;s not needed. If we make a request to IANA, others might=A0ask the same q= uestion. "Why are you asking IANA to reserve an interface ID when you = can just do DAD?"
b) Reserving an IID and not doing DAD will tempt implementations to as= sume the IID unique, creating problems when (not if) it's not unique an= y more. Think of two CLAT gateways on the same link, for example.
b) Reserving an IID will also tempt operators to assume that the IID n= ever changes, and use that information for support or billing purposes.
d) It doesn't really simplify implementations, since there are n= ow two modes (reserved IID and DAD).
--e89a8fb2028a7d753e04c7c3065d-- From despres.remi@laposte.net Tue Aug 21 02:15:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DD421F85AE for ; Tue, 21 Aug 2012 02:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-+5zznXlE6a for ; Tue, 21 Aug 2012 02:15:16 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A521F85A7 for ; Tue, 21 Aug 2012 02:15:16 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id 05FFC7000072; Tue, 21 Aug 2012 11:15:15 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id A20027000069; Tue, 21 Aug 2012 11:15:14 +0200 (CEST) X-SFR-UUID: 20120821091514663.A20027000069@msfrf2203.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 11:15:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01C827C4-B373-49B0-9A77-50E507D37C35@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <000904D2-6 476-4293-A636-43319098B3FA@laposte.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:15:17 -0000 Le 2012-08-21 =E0 11:02, Randy Bush a =E9crit : >>> because it is *not* *needed* and solves nothing. use the existing >>> mechanism, dad. and, if you are prudent, you will have to do so = anyway, >>> iana special or not. >>=20 >> My question was, why would it be difficult to get IANA to register an >> interface ID, one which is in a range explicitly "available for >> allocation". AFAIK it isn't difficult (but open to hear what others >> have to say). >=20 > while we are asking the iana for things which are not needed but are = not > difficult, let's get some ports, a few ipv4 address blocks, and some > ipv6 space while we're at it. > this is ridiculous. At least, we agree that the proposal above (not mine) can be described = as you say,=20 RD >=20 > randy From lorenzo@google.com Tue Aug 21 02:19:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC821F86AB for ; Tue, 21 Aug 2012 02:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKjGni2uSrhe for ; Tue, 21 Aug 2012 02:19:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48CA021F8643 for ; Tue, 21 Aug 2012 02:19:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12674891obb.31 for ; Tue, 21 Aug 2012 02:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rK54FthhUQZKh+Ci9DSl7/qORCgm4HPJx75OnUCOaZ4=; b=GlB7kRhSnBlb/upa8Li2UsPQXvgeWsWBKDk+7yFwbyktr9ieThxj/kmMUcGkZlq61k fVoGEwhkPwYIHYMfQ2MwNQdFcVMUn/dvJhMa9+vdIeqEYDLkdQoFQ2ErYrXVDweB7Rn4 X7U3befaIwq831sOhay1/b8749EVcaVgVXAys16xWX7LG6YUilE8I4STf/GaOwBajfzO bXATfDXc3h2YPHyNNHI517AeKGlmS46mXHKij4GKwZqQsPA+LMmDlzPAvwFbYJs1dcDV u1dw9uT4sFcFGfXQ7hdG1qvd40YFXDKQeR8DKRMw3xAK+6Lws1YzrxhIjZnU3Q1iIYo2 SDvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rK54FthhUQZKh+Ci9DSl7/qORCgm4HPJx75OnUCOaZ4=; b=npET+7ErkQpmpmyNSJL6ZZXu9tldCGnO9lx/v02VBjZvwbFmTs4qoujy0qv6tLExXD R6C9PSEfdo7D5QFu3ed/M7F53ZftnIg4paD3/+BSUuQyiWpODY0zK8t/kjWZpf7ZaMKa D6eLIetdWiSteuYkPmolD3IwThYetjHJe4pBnTRu1QiPRfHa8C6GZ2To/xJQVCpbfb6V pq2YkDPWngwbNfOW01jzVLXNBlqMjNhBDSFu0dPfjeiHiFjhN5NBNpdeUmjmLvu6Rgrt /F4oBs5MvbtiXBMl6c8xXga9nAQFT4uM6MhFPrWTqGKyB38tf26g2jfEXTv40U78NA/p KwlQ== Received: by 10.182.110.40 with SMTP id hx8mr12589639obb.47.1345540794801; Tue, 21 Aug 2012 02:19:54 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr12589621obb.47.1345540794467; Tue, 21 Aug 2012 02:19:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 21 Aug 2012 02:19:34 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> From: Lorenzo Colitti Date: Tue, 21 Aug 2012 18:19:34 +0900 Message-ID: To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=f46d044516dd15c63b04c7c3210c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkOVoGGf5Fsvjgj8RfP253cGru/4uTk5RnpAXsVpmj0q8uTeSc+EUiU2bWCHV8wF8xsBBgNn9otg2gO8VuxAWxuOfVByVq0ymor+nmJ9RLJfeAKzxBrqwio6/EWPC194oXoB7suk1m09Jyi6iPDfOWbyWPPaed3Va0gj7Yie4wS5j1Q920oAtfRVClBW9TwDVVSxa3R Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:19:56 -0000 --f46d044516dd15c63b04c7c3210c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 21, 2012 at 5:27 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > The real problem I see and from what I learnt is that people are > thinking too many global addresses on a single device once again; > there is no need for two global addresses, one on the outside (3GPP/DSL/ > CABLE/you name it) and one on the wifi interface to my understanding > as long as the entire prefix is routed to the device, which it is in > the tethering case I have been told, which what this entire discussion > is about. Correct me if I am wrong. That's not a problem with the specification, but with the implementation. IMO: - The draft should state that any addresses assigned to the clat must be subject to duplicate address detection as usual. - An implementation can use one address if it wants. - Some implementations, like Dan's implementation of CLAT, use two. There are plenty of addresses in the /64, and this is not a problem. No? --f46d044516dd15c63b04c7c3210c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2012 at 5:27 PM, Bjoern A. Zeeb = <bzeeb-lists@lists.zabbadoz.net> wrote: The real problem I see and from what I learnt is that people are
thinking too many global addresses on a single device once again;
there is no need for two global addresses, one on the outside (3GPP/DSL/ CABLE/you name it) and one on the wifi interface to my understanding
as long as the entire prefix is routed to the device, which it is in
the tethering case I have been told, which what this entire discussion
is about. =A0Correct me if I am wrong.

That= 's not a problem with the specification, but with the implementation. I= MO:

- The draft should state that any addresses as= signed to the clat must be subject to duplicate address detection as usual.=
-=A0An implementation can use one address if it wants.
- Som= e implementations, like=A0Dan's implementation of CLAT, use two.
<= div>
There are plenty of addresses in the /64, and this is no= t a problem.

No?
--f46d044516dd15c63b04c7c3210c-- From despres.remi@laposte.net Tue Aug 21 02:56:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9368821F8627 for ; Tue, 21 Aug 2012 02:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSZpzaEZcPPD for ; Tue, 21 Aug 2012 02:56:15 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id DCB2521F861F for ; Tue, 21 Aug 2012 02:56:14 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 71A72700009D; Tue, 21 Aug 2012 11:56:13 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id C75057000095; Tue, 21 Aug 2012 11:56:12 +0200 (CEST) X-SFR-UUID: 20120821095612816.C75057000095@msfrf2106.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 11:56:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63B55E95-0DC3-4DF1-A033-D1662EC5E896@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:56:15 -0000 Le 2012-08-21 =E0 10:27, Bjoern A. Zeeb a =E9crit : > On Tue, 21 Aug 2012, Lorenzo Colitti wrote: >=20 >> Why can't we just say that the CLAT MUST perform DAD properly for all = the >> addresses that it uses, and just leave it at that? It seems excessive = to >=20 > There is not even a need to say that. If you talk IPv6 you need to do > this and any IPv6 address configured for use by the CLAT or just for > plain v6 needs to do it. You would even need to do it for a special > EUI address. End of story. For non EUI addresses (which would be the case without the CLAT = interface ID), RFC 4862 says (section 5.4.5 "When Duplicate Address = Detection Fails"): "On the other hand, if the duplicate link-local address is not formed = from an interface identifier based on the hardware address, which is = supposed to be uniquely assigned, IP operation on the interface MAY be = continued." Consequences can be messy, while they are simply avoided with an = exclusive CLAT interface ID. > The real problem I see and from what I learnt is that people are > thinking too many global addresses on a single device once again; > there is no need for two global addresses, one on the outside = (3GPP/DSL/ > CABLE/you name it) and one on the wifi interface to my understanding > as long as the entire prefix is routed to the device, which it is in > the tethering case I have been told, which what this entire discussion > is about. Correct me if I am wrong. Note that the CLAT interface ID is NOT configured an any IPv6-link = interface. RD >=20 >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb You have to have = visions! > Stop bit received. Insert coin for new address family. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Tue Aug 21 02:59:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DD421F8627 for ; Tue, 21 Aug 2012 02:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UAKjCMhcyCq for ; Tue, 21 Aug 2012 02:59:02 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3A21F851C for ; Tue, 21 Aug 2012 02:59:02 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 759937000056; Tue, 21 Aug 2012 11:59:01 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id D11167000050; Tue, 21 Aug 2012 11:59:00 +0200 (CEST) X-SFR-UUID: 20120821095900856.D11167000050@msfrf2106.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31-16236870 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 11:59:00 +0200 Message-Id: <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:59:03 -0000 --Apple-Mail-31-16236870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-21 =E0 11:12, Lorenzo Colitti a =E9crit : >=20 >=20 > On Tue, Aug 21, 2012 at 5:07 PM, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-08-21 =E0 09:55, Lorenzo Colitti a =E9crit : >=20 >> On Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9s = wrote: >>=20 >> 2012-08-21 04:23, Lorenzo Colitti : >>=20 >>> On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown = wrote: >>> Quoting "Bjoern A. Zeeb" : >>> On Thu, 16 Aug 2012, Dan Drown wrote: >>> That may work for some implementations, but not for android-clat. = The clat function needs its own address, and it cannot be any address = that the handset considers local. >>>=20 >>> /me bites his tongue. >>>=20 >>> Seriously? Out of curiosity, can you elaborate (feel free to do so = unicast). >>>=20 >>> Yes. The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address. Otherwise native traffic = from the handset to the plat prefix (apps that support DNS64's rewritten = AAAA answers) can't be seperated from translated traffic from the clat. = Perhaps this is just an implementation detail that doesn't need to go = into the standard, but it's unavoidable for me. >>>=20 >>> Fair enough. But that doesn't require a special EUI-64 to be = allocated, right? All you need is an IPv6 address that can be defended = against DAD. Can we then just say "if the CLAT picks an IPv6 address to = use on the LAN side, then it must make sure to reply to DAD on that = address"? >>=20 >> Sure, the CLAT node must indeed reply to DAD on the address it has on = the LAN side (as usual). >>=20 >> But the point is that, if the interface ID used by the CLAT the = WAN-side is one that a host may use on the LAN (according to RFC 4291), = this ID must be excluded on the LAN side IN ADDITION to that of the = LAN-side address. >>=20 >> Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, = it must defend that address against DAD on the LAN interface. >> =20 >> This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is = reserved for CLAT addressing. (It belongs to a range that is precisely = "available for allocation" in RFC 5342, and therefore to never be used = by any host). =20 >>=20 >> That's one way to solve the problem: avoid duplicate addresses by = making CLAT use a range that is reserved only for CLAT. In essence, = you're avoiding duplicate addresses by forbidding them. >>=20 >> Another way to solve the problem is to use the standard IPv6 = mechanism used to avoid duplicate addresses, i.e., DAD. >>=20 >> Why can't we just say that the CLAT MUST perform DAD properly for all = the addresses that it uses, and just leave it at that? It seems = excessive to request a reserved range from IANA just for the purposes of = avoiding duplicate addresses, when DAD would do the job just fine. >=20 > Note that it is only ONE allocated value (in a range "available for = allocation").=20 >=20 > I can't understand why consuming a value, among many that have been = made available for that, would be a big issue, especially since doing so = permits to simplify some implementations. > Have you some reason you can share for such a concern? >=20 > RD >=20 >=20 >=20 > Not really. The issues that I see are: >=20 > a) It's not needed. If we make a request to IANA, others might ask the = same question. "Why are you asking IANA to reserve an interface ID when = you can just do DAD?" DAD, even played in unusual conditions, doesn't provide a complete a = solution (see my answer to Bjoern). > b) Reserving an IID and not doing DAD will tempt implementations to = assume the IID unique, creating problems when (not if) it's not unique = any more. Think of two CLAT gateways on the same link, for example. Not unique interface ID any more? (Once registered a by IANA, it remains = unique.) With NAT44s in CLAT nodes, which is the assumption, the two nodes must = have, I suppose, different IPv6 prefixes. I don't see any problem.=20 > b) Reserving an IID will also tempt operators to assume that the IID = never changes, and use that information for support or billing purposes. Are you suggesting that the 464XLAT model should be completed by a = suggestion to change the CLAT IPv6 address from time to time? We are getting really far from the question at hand. > d) It doesn't really simplify implementations, since there are now two = modes (reserved IID and DAD). 1. Suggestion: take the CLAT IID, and forget the theoretical and = operational problems that can occur if relying only on a patched DAD. 2. Is you point that you personally find it difficult to implement the = allocated CLAT IID (that of example 2 in the appendix)?=20 If not, your request to change the draft on this is AFAIK a request for = a step backward. To conclude at this stage: if a rough consensus would be declared in the = WG that an allocated CLAT IID should be deleted from the draft because = it is assumed to serve no purpose, it would in my understanding be a = mistake. Reasons for this may not have been understood, but they have at = least been documented. Each one remains responsible for what he writes. RD --Apple-Mail-31-16236870 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Tue, Aug 21, 2012 at = 5:07 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

Le 2012-08-21 =E0 = 09:55, Lorenzo Colitti a =E9crit :

On = Tue, Aug 21, 2012 at 4:41 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:

2012-08-21 04:23, = Lorenzo Colitti :

On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <dan-v6ops@drown.org> wrote:
Quoting "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>:
On Thu, 16 Aug 2012, Dan Drown wrote:
That may work for some implementations, but not for android-clat. =  The clat function needs its own address, and it cannot be any = address that the handset considers local.

/me bites his tongue.

Seriously?  Out of curiosity, can you elaborate (feel free to do so = unicast).

Yes.  The implementation of clat for android is done in userspace = (using a tun interface to pass traffic between the kernel and the = userspace program), and needs its own address.  Otherwise native = traffic from the handset to the plat prefix (apps that support DNS64's = rewritten AAAA answers) can't be seperated from translated traffic from = the clat.  Perhaps this is just an implementation detail that = doesn't need to go into the standard, but it's unavoidable for me.

Fair enough. But that doesn't require a = special EUI-64 to be allocated, right? All you need is an IPv6 address = that can be defended against DAD. Can we then just say "if the CLAT = picks an IPv6 address to use on the LAN side, then it must make sure to = reply to DAD on that address"?

Sure, the CLAT node must = indeed reply to DAD on the address it has on the LAN side (as = usual).

But the point is that, if the interface = ID used by the CLAT the WAN-side is one that a host may use on the = LAN (according to RFC 4291), this ID must be excluded on the LAN = side IN ADDITION to that of the LAN-side address.

Agreed. If the CLAT assigns = itself an IPv6 address on the WAN site, it must defend that address = against DAD on the LAN interface.
 
This obligation is avoided = if interface ID 02-00-5E-10-00-00-00-= 00 is reserved for CLAT addressing. (It belongs to a = range that is precisely "available = for = allocation" in RFC 5342, and therefore to never be used by any host). =

That's one way to solve the = problem: avoid duplicate addresses by making CLAT use a range that is = reserved only for CLAT. In essence, you're avoiding duplicate addresses = by forbidding them.

Another way to solve the problem is to use the = standard IPv6 mechanism used to avoid duplicate addresses, i.e., = DAD.

Why can't we just say that the CLAT MUST = perform DAD properly for all the addresses that it uses, and just leave = it at that? It seems excessive to request a reserved range from IANA = just for the purposes of avoiding duplicate addresses, when DAD would do = the job just fine.

Note that it is only ONE = allocated value (in a range "available = for = allocation"). 

I can't understand why consuming a value, among many = that have been made available for that, would be a big issue, especially = since doing so permits to simplify some implementations.
Have = you some reason you can share for such a concern?

RD



Not really. The issues = that I see are:

a) It's not needed. If we make = a request to IANA, others might ask the same question. "Why are you = asking IANA to reserve an interface ID when you can just do = DAD?"

DAD, even played in unusual = conditions, doesn't provide a complete a solution (see my answer to = Bjoern).


b) Reserving an IID and not doing DAD will tempt implementations to = assume the IID unique, creating problems when (not if) it's not unique = any more. Think of two CLAT gateways on the same link, for = example.

Not unique interface ID = any more? (Once registered a by IANA, it remains unique.)
With = NAT44s in CLAT nodes, which is the assumption, the two nodes must have, = I suppose, different IPv6 prefixes. I don't see any = problem. 


b) Reserving an IID will also tempt operators to assume that the = IID never changes, and use that information for support or billing = purposes.

Are you suggesting that = the 464XLAT model should be completed by a suggestion to change the CLAT = IPv6 address from time to time?
We are getting really far from = the question at hand.

d) It = doesn't really simplify implementations, since there are now two modes = (reserved IID and DAD).

1. Suggestion: take the CLAT IID, and forget = the theoretical and operational problems that can occur if relying only = on a patched DAD.

2. Is you point that you = personally find it difficult to implement the allocated CLAT IID (that = of example 2 in the appendix)? 
If not, your request to = change the draft on this is AFAIK a request for a step = backward.


To conclude at this = stage: if a rough consensus would be declared in the WG that an = allocated CLAT IID should be deleted from the draft because it is = assumed to serve no purpose, it would in my understanding be a mistake. = Reasons for this may not have been understood, but they have at least = been documented. Each one remains responsible for what he = writes.


RD






= --Apple-Mail-31-16236870-- From lorenzo@google.com Tue Aug 21 04:24:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0318721F867F for ; Tue, 21 Aug 2012 04:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.755 X-Spam-Level: X-Spam-Status: No, score=-102.755 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8AYMtwizM59 for ; Tue, 21 Aug 2012 04:24:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 646DC21F857A for ; Tue, 21 Aug 2012 04:24:48 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12852174obb.31 for ; Tue, 21 Aug 2012 04:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=IDDkeIHvr3AKjN8edeis0xE0Le8SITRFMYXXiMZYhAg=; b=StLBQOpr9setTBprVrhpOt2GNtZGtjIfjSyRD7dD3XM/ik6666BUwE5duDAXhwq0jg R/oCTVBa5tHaDwxS8hIR3c6qkse2rKVNF4dCZWqvRiXGVkPL3hRGC0NUQ66vdSjFO+Xs 3MYIdS55b1XA1FXJ/nTyNw7S6ivFG89JqcZwrpKvDfcNCq+7gXFXvk8ixUjWthArGDo4 fS+Iody9Cd5KZj/H3f4UvBM0Crcy/V74NKc0nYgJhQExF+Ii8BTBcLv4lI5PjQlEJs8w yeiCsV0WFyIvNKgbkBeej+4WD9RtFeaaS0WRbp5gYc2mMpNaLOHz1jwV3xeXuo4U77mD 4yUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=IDDkeIHvr3AKjN8edeis0xE0Le8SITRFMYXXiMZYhAg=; b=Uno9Q53eY1TrlzxQiRmt5bEK8PzS43J5ioGxhvXCyJV5pp8ODiNE+dsTevv75IzMGr 2V4Udoq143lsvHuyplk3Bz2qddvsbB+aF7lZz6fcL93ehtTyqqGYV+I6ezYHtTJQAe8M QKvi2NMbIJiGuYJayPlqMKvnrJ4HqacI6UrWTeQbGSywjKlIVm4JNU6iJrwc8e/yFENk 5tkA/8vhGr3klg3PrshQJVv+tq196gNVj7H/gSxll26F0t3tvk83To2Z3GSj5I0ED74b +jvZmFqYzHZNUH2m1IuTKlPopFn0fyJdHEO/2VNX138UaJun1jui7uORKBGNf5b8uo7e qEYA== Received: by 10.60.170.229 with SMTP id ap5mr12528627oec.101.1345548288005; Tue, 21 Aug 2012 04:24:48 -0700 (PDT) Received: by 10.60.170.229 with SMTP id ap5mr12528617oec.101.1345548287685; Tue, 21 Aug 2012 04:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 21 Aug 2012 04:24:27 -0700 (PDT) In-Reply-To: <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@laposte.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> From: Lorenzo Colitti Date: Tue, 21 Aug 2012 20:24:27 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=bcaec54b4ac0b734fc04c7c4df48 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk5gAbkwsmEsCuPgvjKAu1UAY7wwuY814fQ3oBh5sEtX+Fm4UUx3F8FkHbIZlPi7HqJhK3S3BHKiLKvC+ms2vQyhaUFd2Zl44hsL6TDLZ/KOvlkB62j72pzjoeFvlIr6QwohuVAYwXokUXxLtxkdtXWgAsAQeIpJ8hoe/zQqNPT24om4basaZcypbdJ6eLKQ2ILDsJ8 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 11:24:49 -0000 --bcaec54b4ac0b734fc04c7c4df48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 21, 2012 at 6:59 PM, R=E9mi Despr=E9s wrote: > 2. Is you point that you personally find it difficult to implement the > allocated CLAT IID (that of example 2 in the appendix)? > No (and I'm not the one doing the implementation). The reasons why I think we should not request IANA to allocate an IID are: 1. Operational experience that while it's good to ensure things are unique by decree, in practice that leads to things not being unique some of the time (e.g., MAC addresses - they're supposed to be duplicates, but guess what, they're not). Thus, I prefer methods that are dynamic. 2. It's better to avoid hard-coding things if you can. 3. I just don't see a compelling need for a unique IID. The translation mechanism would work fine without it (assuming you do DAD, which these nodes need to do anyway for other addresses such as their link-local addresses). I don't see why we need to trouble IANA with a request for a unique IID if we don't need one. --bcaec54b4ac0b734fc04c7c4df48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2012 at 6:59 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
2. Is you point that you personall= y find it difficult to implement the allocated CLAT IID (that of example 2 = in the appendix)?=A0
=A0
No (and I&#= 39;m not the one doing the implementation). The reasons why I think we shou= ld not request IANA to allocate an IID are:

1. Operational experience that while it's good to e= nsure things are unique by decree, in practice that leads to things not bei= ng unique some of the time (e.g., MAC addresses - they're supposed to b= e duplicates, but guess what, they're not). Thus, I prefer methods that= are dynamic.
2. It's better to avoid hard-coding things if you can.
3= . I just don't see a compelling need for a unique IID.=A0The translatio= n mechanism would work fine without it (assuming you do DAD, which these no= des need to do anyway for other addresses such as their link-local addresse= s). I don't see why we need to trouble IANA with a request for a unique= IID if we don't need one.
--bcaec54b4ac0b734fc04c7c4df48-- From despres.remi@laposte.net Tue Aug 21 06:05:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEDC21F8611 for ; Tue, 21 Aug 2012 06:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl0kZl08qfa4 for ; Tue, 21 Aug 2012 06:05:44 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5353D21F8600 for ; Tue, 21 Aug 2012 06:05:42 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 05DDD940008; Tue, 21 Aug 2012 15:05:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32-27428039 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Aug 2012 15:05:31 +0200 Message-Id: <7DBB6836-2BBD-49E9-9474-6466061E334B@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@lap oste.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 13:05:45 -0000 --Apple-Mail-32-27428039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-21 =E0 13:24, Lorenzo Colitti a =E9crit : > On Tue, Aug 21, 2012 at 6:59 PM, R=E9mi Despr=E9s = wrote: > 2. Is you point that you personally find it difficult to implement the = allocated CLAT IID (that of example 2 in the appendix)?=20 > =20 > No (and I'm not the one doing the implementation). I take is as a confirmation that implementation is trivial once the CLAT = IID is defined. > The reasons why I think we should not request IANA to allocate an IID = are: >=20 > 1. Operational experience that while it's good to ensure things are = unique by decree, in practice that leads to things not being unique some = of the time (e.g., MAC addresses - they're supposed to be duplicates, = but guess what, they're not). The good news is that implementations don't use the CLAT IID won't = disturb those that do, and conversely. There is no interworking issue = here. To be constructive, I can agree to a MAY in place of the previously = proposed SHOULD. This permits to use it, my recommendation, or not to = use it, your recommendation. > Thus, I prefer methods that are dynamic. > 2. It's better to avoid hard-coding things if you can. Sometimes yes, sometimes no (the more parameters, the more complex is = product qualification). > 3. I just don't see a compelling need for a unique IID.=20 Seeing no compelling reason to impose it is not contradictory to = permitting it. > The translation mechanism would work fine without it (assuming you do = DAD, which these nodes need to do anyway for other addresses such as = their link-local addresses). I don't see why we need to trouble IANA = with a request for a unique IID if we don't need one. IANA isn't AFAIK a body to be troubled by doing its job of registering = assigned numbers found useful in IETF. I therefore hope we can agree to "The CLAT MAY use the reserved IANA = assigned EUI-64 ID of Section 11 ..." in section 8.3.2 would satisfy = expressed concerns. Regards, RD --Apple-Mail-32-27428039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Tue, Aug 21, 2012 at 6:59 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
2. Is you point that you = personally find it difficult to implement the allocated CLAT IID (that = of example 2 in the = appendix)? 
 
No (and = I'm not the one doing the = implementation).

I take is = as a confirmation that implementation is trivial once the CLAT IID is = defined.


The reasons why I think we should not = request IANA to allocate an IID are:

1. Operational experience that while it's good to = ensure things are unique by decree, in practice that leads to things not = being unique some of the time (e.g., MAC addresses - they're supposed to = be duplicates, but guess what, they're not). =

The good news is that = implementations don't use the CLAT IID won't disturb those that do, and = conversely. There is no interworking issue = here.

To be constructive, I can agree to a MAY = in place of the previously proposed SHOULD. This permits to = use it, my recommendation, or not to use it, your = recommendation.


Thus, I prefer methods that are = dynamic.
2. It's better to avoid hard-coding things if you = can.

Sometimes yes, sometimes no = (the more parameters, the more complex is product = qualification).

3. I just don't see a compelling need for a = unique IID. 

Seeing no = compelling reason to impose it is not contradictory to permitting = it.

The translation mechanism would work fine = without it (assuming you do DAD, which these nodes need to do anyway for = other addresses such as their link-local addresses). I don't see why we = need to trouble IANA with a request for a unique IID if we don't need = one.

IANA isn't AFAIK a body to be troubled by = doing its job of registering assigned numbers found useful in = IETF.

I therefore hope we can agree to "The CLAT = MAY use the reserved  IANA assigned EUI-64 ID of Section 11 ..." in = section 8.3.2 would satisfy expressed concerns.
Regards,
In-Reply-To: Date: Tue, 21 Aug 2012 15:26:36 +0200 Message-Id: <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@lap oste.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 13:26:54 -0000 --Apple-Mail=_57A10980-6676-44B8-BB6D-D2C4823A82BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > 2. Is you point that you personally find it difficult to implement the = allocated CLAT IID (that of example 2 in the appendix)?=20 > =20 > No (and I'm not the one doing the implementation). The reasons why I = think we should not request IANA to allocate an IID are: >=20 > 1. Operational experience that while it's good to ensure things are = unique by decree, in practice that leads to things not being unique some = of the time (e.g., MAC addresses - they're supposed to be duplicates, = but guess what, they're not). Thus, I prefer methods that are dynamic. > 2. It's better to avoid hard-coding things if you can. > 3. I just don't see a compelling need for a unique IID. The = translation mechanism would work fine without it (assuming you do DAD, = which these nodes need to do anyway for other addresses such as their = link-local addresses). I don't see why we need to trouble IANA with a = request for a unique IID if we don't need one. +1. keep it simple. it isn't at all clear to me what value a reserved = IID has. just putting two CLATs on the same link would result in a = collision... cheers, Ole= --Apple-Mail=_57A10980-6676-44B8-BB6D-D2C4823A82BF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIxMTMyNjM2WjAjBgkqhkiG9w0BCQQxFgQUaCFKsPVzKPlKzbwO R2kTm4bahn4wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAFbqqnl8ytqCS1uxKjXJG /W2s2Itu3+R1UP+UOIPIuwX82goWjQRt1Yg8VfHCYjNgngpDszLynrCoy15rnQl9bmUcu5I8HpR5 XlCcY3HgL9/SKmguRrIHfMUdX8WTOA/YVsDC5TL+eQ647ZoIPOP0nZs/ykMGdKJ0AhIwsSEdodvC Cbb9FzedQV3kM+YNa+TjY/eAeBwyZT/KK7W6vmnnUiCiYLPkmegNygTN4eug1Js0dZlW5aIDum9Y 2VecRlwD4Bzr0ZWpp0sfVVUPWn+FHXa2KW+CfXl0JzdppsBrZYWR//joOHSpt9FmBseGGAIUuVE9 N2sOwW4VuXGWP5xWRwAAAAAAAA== --Apple-Mail=_57A10980-6676-44B8-BB6D-D2C4823A82BF-- From tom.taylor.stds@gmail.com Tue Aug 21 06:53:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943421F86BA for ; Tue, 21 Aug 2012 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhQITj6+Nm-2 for ; Tue, 21 Aug 2012 06:53:40 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C74D721F8503 for ; Tue, 21 Aug 2012 06:53:40 -0700 (PDT) Received: by ggnh4 with SMTP id h4so6433429ggn.31 for ; Tue, 21 Aug 2012 06:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=iEMR1tWT+gpPoopQmFZyIk4YMujiCKn9I9tu49ucuRQ=; b=yoaCwwwbKAWD8Fmai+iWEN+jdH+8Kg1IJnGP5laTCklxeoAi5Qk1NZRwiuEotQBHey slE//fjBvF+xNKcBoOB7SNcL0G3u4PLZWdpTxWc7wi/tHGhL8EakJsq2y2nQzuknvlku Ti/PMy75ifQibNKF20h5fbVY/9S4WHtRnCXPY+6FIsbBjvNLEzDLcBBZ+EBkmRhPRfUr z2wNfA7jSbhuvJbkZSMUguY9DnULTuIv4SM4nfrzJbuzKdEVa1x6x4tSM5W6tG8i1m4w wIX4tDHTAEA2PZ6ZjRBTMZ+WROowuBuYW7y7zoRqI64an5+GR2RDc1xVtkG/xP9KSY+n GeKA== Received: by 10.50.135.72 with SMTP id pq8mr12235881igb.53.1345557219970; Tue, 21 Aug 2012 06:53:39 -0700 (PDT) Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id xm2sm2914486igb.3.2012.08.21.06.53.38 (version=SSLv3 cipher=OTHER); Tue, 21 Aug 2012 06:53:39 -0700 (PDT) Message-ID: <503392DE.9060302@gmail.com> Date: Tue, 21 Aug 2012 09:53:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@lap oste.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <7DBB6836-2BBD-49E9-9474-6466061E334B@laposte.net> In-Reply-To: <7DBB6836-2BBD-49E9-9474-6466061E334B@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120821-0, 21/08/2012), Outbound message X-Antivirus-Status: Clean Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 13:53:41 -0000 If you are determined to see an EUI registered, the best solution might be to write another draft doing so and indicating how it could be used in the 464xlat case and any other case you imagine. On 21/08/2012 9:05 AM, Rémi Després wrote: > ... > > The good news is that implementations don't use the CLAT IID won't > disturb those that do, and conversely. There is no interworking issue > here. > > To be constructive, I can agree to a MAY in place of the previously > proposed SHOULD. This permits to use it, my recommendation, or not to > use it, your recommendation. > > ... From fred@cisco.com Tue Aug 21 08:45:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913321F8723 for ; Tue, 21 Aug 2012 08:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.333 X-Spam-Level: X-Spam-Status: No, score=-110.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UJxF8qnG2vg for ; Tue, 21 Aug 2012 08:45:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7F86021F8713 for ; Tue, 21 Aug 2012 08:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=428; q=dns/txt; s=iport; t=1345563922; x=1346773522; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0bJj5EbpSv9mV21Meu/9rCV0pzGmXK7zT/9wDbrp0ls=; b=WhpcX1pTJ+aIvGsZ7dBFYgPx/VDLGPbzZa2xAYjTh+VAGN6VDw7+kYt8 jBzOG0mP8ngJCM0O8e4Xhm6sXFjTBn8K/kI7+F5cty9aq0wNaEOUXnyxY VRlPy/OV+hJR8XkPVZSD4XSbiePvVhO+7GWlDvNRDm4kMeoS5MqjQ/9IA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAKirM1CtJV2b/2dsb2JhbABFhTq1KIEHgicSASdRAT5CJwQ1h2sLl2OBKKA8kURgA5VSgRSNGYFmgmE X-IronPort-AV: E=Sophos;i="4.77,802,1336348800"; d="scan'208";a="113810694" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2012 15:45:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7LFjMuu020256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Aug 2012 15:45:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 10:45:22 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: draft-ietf-v6ops-464xlat WGLC Thread-Index: AQHNf7P4ADwY8/kMB0ykw3t0El8NXw== Date: Tue, 21 Aug 2012 15:45:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.005 x-tm-as-result: No--23.802700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4836CD2EA316C94D99A5D5D59FFB8319@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:45:35 -0000 This is to open a two week Working Group last Call on=20 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulness t= o its target audience.= From despres.remi@laposte.net Tue Aug 21 08:46:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689CA21F878A for ; Tue, 21 Aug 2012 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTdzO658hPtd for ; Tue, 21 Aug 2012 08:46:11 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id B873721F8780 for ; Tue, 21 Aug 2012 08:46:09 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 85FB1940195; Tue, 21 Aug 2012 17:46:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <503392DE.9060302@gmail.com> Date: Tue, 21 Aug 2012 17:45:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@lap oste.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <7DBB6836-2BBD-49E9-9474-6466061E334B@laposte.net> <503392DE.9060302@gm ail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:46:11 -0000 Le 2012-08-21 =E0 15:53, Tom Taylor a =E9crit : > If you are determined to see an EUI registered, the best solution = might > be to write another draft doing so and indicating how it could be used > in the 464xlat case and any other case you imagine. Keeping the draft with it makes more sense. With a MAY, I don't see any valid objection that remains. Remember that the draft was considered by authors ready for WGLC with = this registered EUI. RD >=20 > On 21/08/2012 9:05 AM, R=E9mi Despr=E9s wrote: >>=20 > ... >=20 >>=20 >> The good news is that implementations don't use the CLAT IID won't >> disturb those that do, and conversely. There is no interworking issue >> here. >>=20 >> To be constructive, I can agree to a MAY in place of the previously >> proposed SHOULD. This permits to use it, my recommendation, or not to >> use it, your recommendation. >>=20 >>=20 > ... From despres.remi@laposte.net Tue Aug 21 09:23:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87421F86B1 for ; Tue, 21 Aug 2012 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yBdGqy3s69x for ; Tue, 21 Aug 2012 09:23:49 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3E21F8661 for ; Tue, 21 Aug 2012 09:23:46 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id AC8A9700005E; Tue, 21 Aug 2012 18:23:45 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 3ED0C7000059; Tue, 21 Aug 2012 18:23:45 +0200 (CEST) X-SFR-UUID: 20120821162345257.3ED0C7000059@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> Date: Tue, 21 Aug 2012 18:23:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <71522AF1-4CD0-40AC-A868-F61F356F5266@lap oste.net> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:23:51 -0000 Hi, Ole, 2012-08-21 15:26, Ole Tr=F8an: >> 2. Is you point that you personally find it difficult to implement = the allocated CLAT IID (that of example 2 in the appendix)?=20 >>=20 >> No (and I'm not the one doing the implementation). The reasons why I = think we should not request IANA to allocate an IID are: >>=20 >> 1. Operational experience that while it's good to ensure things are = unique by decree, in practice that leads to things not being unique some = of the time (e.g., MAC addresses - they're supposed to be duplicates, = but guess what, they're not). Thus, I prefer methods that are dynamic. >> 2. It's better to avoid hard-coding things if you can. >> 3. I just don't see a compelling need for a unique IID. The = translation mechanism would work fine without it (assuming you do DAD, = which these nodes need to do anyway for other addresses such as their = link-local addresses). I don't see why we need to trouble IANA with a = request for a unique IID if we don't need one. >=20 > +1. keep it simple. > it isn't at all clear to me what value a reserved IID has. Many explanations have been given, and can be read. > just putting two CLATs on the same link would result in a collision... Collision of what, where? A FUD entertaining statement should at least = be supported with some technical explanation (IMHO).=20 But here, the statement is simply false: - Each CLAT having its exclusive /64, any address derived from it = belongs only to this CLAT, and cannot collide - Even without a CLAT assigned interface ID, two CLATs can use common = interface IDs on the WAN side. RD >=20 > cheers, > Ole From fred@cisco.com Tue Aug 21 11:41:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967D521F8679 for ; Tue, 21 Aug 2012 11:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NhXbC6fcIYo for ; Tue, 21 Aug 2012 11:41:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E79B121F8678 for ; Tue, 21 Aug 2012 11:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1027; q=dns/txt; s=iport; t=1345574483; x=1346784083; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7vqlnJnPVzzqCLgFbPCmLGTNuUFDaEIrofHzGBsbwxA=; b=F0RcZHPlpptjmqiv3S+q5bfu19MMvtUxrbon19Jtdtqi1B8v6URg7VZ7 EEP+JeneRuTKuUseTOqRRBrUgBHb8CLKCduY98Ok4zpL2fVCUQNaPbSLm 8bvU2kX/pZLPFx9dvnkVsLP5iu9dUtWD3H0nyAWFjVZUq+6HtkFGYtXYk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKfVM1CtJV2Z/2dsb2JhbABFumaBB4IgAQEBAwEBAQEPASc0EAsCAQg2ECcLJQIEEyKHZQYLmRigQYsIhjxgA5VSgRSNGYFmgmE X-IronPort-AV: E=Sophos;i="4.77,803,1336348800"; d="scan'208";a="113903777" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 21 Aug 2012 18:41:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7LIfMEq003201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Aug 2012 18:41:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 13:41:19 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat WGLC Thread-Index: AQHNf8yNVzM+JZWuPECOR8lN4MgyZA== Date: Tue, 21 Aug 2012 18:41:19 +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: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.001 x-tm-as-result: No--27.442100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <74DB5FABE1362F4C88F700ADF407E487@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:41:23 -0000 I should note that the current thread has a subject line reading -06.txt, b= ut the current version is -07.txt. You may find the diffs (fairly extensive= ) at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > This is to open a two week Working Group last Call on=20 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >=20 > Please read it now. We are interested in, among other things, technical c= ommentary on the draft and the working group's perception on its usefulness= to its target audience. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From randy@psg.com Tue Aug 21 13:03:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4A021F8686 for ; Tue, 21 Aug 2012 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqm8EnS-hRCG for ; Tue, 21 Aug 2012 13:03:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 608B121F8604 for ; Tue, 21 Aug 2012 13:03:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T3ufd-0004h5-0f; Tue, 21 Aug 2012 20:03:25 +0000 Date: Wed, 22 Aug 2012 05:03:44 +0900 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 20:03:32 -0000 >> it isn't at all clear to me what value a reserved IID has. > Many explanations have been given, and can be read. and they did not stand up. wg last call has started. i dissent. i hope there is no need to repeat the discussion. randy From jhw@apple.com Tue Aug 21 13:52:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884CF11E80FE for ; Tue, 21 Aug 2012 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZDlQvDI3+ys for ; Tue, 21 Aug 2012 13:52:36 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1266211E80FB for ; Tue, 21 Aug 2012 13:52:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M94007ZDHR3UBB5@mail-out.apple.com> for v6ops@ietf.org; Tue, 21 Aug 2012 13:52:34 -0700 (PDT) X-AuditID: 11807130-b7f646d000003c19-73-5033f511a068 Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 87.9C.15385.215F3305; Tue, 21 Aug 2012 13:52:34 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M94001HHHZKYVA0@chicory.apple.com> for v6ops@ietf.org; Tue, 21 Aug 2012 13:52:33 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 21 Aug 2012 13:52:32 -0700 Message-id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FCcrCv01TjA4PMEIYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9f6AywFR9grbhzay9bA+Iu1i5GDQ0LARKKvj6mLkRPIFJO4 cG89WxcjF4eQwBQmib3bvzKDJIQEZjBJfF9pCGIzC2hJrN95HKyBV0APqOEdI4gtLOAgsX5m CyuIzSagIvHt8l2wGk6g+o5D58FsFgFVic/vDzNBzJGT+NN2kgXC1pZ48u4CK8RMG4k3F39D HfGJXeL9+z52kISIgIZE15Y/bBCXykp8P3yebQKjwCwkN81CctMsJHMXMDKvYhQsSs1JrDQ0 1EssKMhJ1UvOz93ECA69QoMdjGt/8h9iFOBgVOLhfTHFKECINbGsuDL3EKMEB7OSCG/RZOMA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxM14FSAumJJanZqakFqUUwWSYOTqkGxtxld9XXiW95 ul9MQ3xN9N5XDoEXpM6vYfJ00LMwvi9kcTdK7lmphb5/2Fd7/oXF5+58vvz9wIyuRcLrtsmH fGrYwL9yhWhAn02Gh4Dx77u32WZM8SyTTA0/ymZdZNUvtcUm5uT+7FMRx7XOezS0qB8Lenv9 xYXJKr3FUSXhcT2i/qFfLn99qcRSnJFoqMVcVJwIAHTmbgA5AgAA Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 20:52:36 -0000 On Aug 21, 2012, at 13:03 , Randy Bush wrote: > > wg last call has started. i dissent. I've been quietly following this discussion, and I think it's time I stood up to say that I agree with Mr. Bush and those who say the request for IANA to reserve a modified EUI-64 is unnecessary and arguably counter-productive. It should be removed before the draft is sent to the IESG for review. For my own part, I don't see why avoiding DAD should be a worthwhile objective unless the concern is about the time it takes to perform DAD while the address is still in the TENTATIVE state, to which I reply *cough* RFC 4429 *cough*. I am not sanguine about arguments that a Best Current Practice should recommend a work-around for an implementation issue in one particular platform that isn't generally required everywhere. -- james woodyatt member of technical staff, core os networking From lorenzo@google.com Tue Aug 21 17:28:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A111E808D for ; Tue, 21 Aug 2012 17:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq5jQlltJdN8 for ; Tue, 21 Aug 2012 17:28:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7158911E808A for ; Tue, 21 Aug 2012 17:28:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so552226obb.31 for ; Tue, 21 Aug 2012 17:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fBJhboP0pQFslrIvfO/iw2Xde/XGJRT/yDMXolyls1M=; b=GqeTHcTDiF3sPJJVgjvjSlDND32kwFJqief2JfuC0qRbINy/UjEXnbnCd2ab858XQO 3xCmA0/2KIO/j9WWtLiEq9L/EvRYoOCZ44yMYVT1PU2pJEnDHOpvxs1WRrbdnl0uU89f rBqXLYHb96tcJHApvKX0oz3Qs6OyDlyMnmgjh+QHB9Uxc+PINGLwnv36/1hLZ96Ayu9y usNHgukrXWuNSWQW7BbJcW5Nsg9zm+fuXNrP7G/vpmGOCIKoWWyf6DZeurwMtevDp7nJ 8jIo5YY1c9dDL64ARBC7WWuQOta8hxvVm7tgL9b8wjboOIF3FOKEjXtziS4dPGNxs72+ XXZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fBJhboP0pQFslrIvfO/iw2Xde/XGJRT/yDMXolyls1M=; b=pnhYND6FwrYuGPtyX8DGj4vPEehDmGuk6C2JcTvbv0V8sBrJsDPBdSAXJSq+3nGv6b l0uLU2ryiNhHBmN+wZ6+DXJ8eXK4tLmT/nY7rOVbWfgLYxgq9/7e7pCCgKNqFntOpsCU 0NDrGme5elBnjCCHfxvozmPPJf5qBnFYcdwIO4hHyt49eovqYmzMMzxXI2sI9aisp/fH JaTLOUthH3yqWNQm3mR5D9Zu6r36LwB8pKqT1PJiBPVh1EWsAOngipbuIxwoSeRbmfWd 6jgkSWqqILwB1edJtY4FM5GeivYp9qKFJMXQAoDK15csQhmwg+zTHUNOSztas+W9FZau ji3A== Received: by 10.60.2.193 with SMTP id 1mr14304954oew.29.1345595294096; Tue, 21 Aug 2012 17:28:14 -0700 (PDT) Received: by 10.60.2.193 with SMTP id 1mr14304941oew.29.1345595294000; Tue, 21 Aug 2012 17:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Tue, 21 Aug 2012 17:27:53 -0700 (PDT) In-Reply-To: <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 09:27:53 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb1ee1e82a7b104c7cfd1c1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm0V4B/BjP2erLEw8cjDZA7OhlcRnSxGTsn8dYHoSS0cF6XDoj1VITN0rYi14Mtcm8MYRNYUBnsarPGznEgcYBZS9VLI21/751E/nGBi1+0CvQ3n5vf/VNmwlhO/drwSWQ08PhqgC9/mn2oH2GhUIjrwHj/7uyhml6g0LONyYVnU1gM/wDjPCRWPId7sLi486WEuzz4 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 00:28:15 -0000 --e89a8fb1ee1e82a7b104c7cfd1c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 1:23 AM, R=E9mi Despr=E9s wrote: > > just putting two CLATs on the same link would result in a collision... > > Collision of what, where? A FUD entertaining statement should at least be > supported with some technical explanation (IMHO). > > But here, the statement is simply false: > - Each CLAT having its exclusive /64, any address derived from it belongs > only to this CLAT, and cannot collide > - Even without a CLAT assigned interface ID, two CLATs can use common > interface IDs on the WAN side. > Put one CLAT behind the other. The first CLAT gets a /64 from upstream and passes it on to its downstream. The second CLAT gets the RA from the first with the same /64. Both are on the same /64. They both pick the same IID because that's what the draft tells them to do. Voila, the same IPv6 address is assigned to two hosts. --e89a8fb1ee1e82a7b104c7cfd1c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 1:23 AM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
> just putting two CLATs on the same link would result= in a collision...

Collision of what, where? A FUD entertaining statement should at leas= t be supported with some technical explanation (IMHO).

But here, the statement is simply false:
- Each CLAT having its exclusive /64, any address derived from it belongs o= nly to this CLAT, and cannot collide
- Even without a CLAT assigned interface ID, two CLATs can use common inter= face IDs on the WAN side.

Put one CLAT = behind the other. The first CLAT gets a /64 from upstream and passes it on = to its downstream. The second CLAT gets the RA from the first with the same= /64. Both are on the same /64. They both pick the same IID because that= 9;s what the draft tells them to do. Voila, the same IPv6 address is assign= ed to two hosts.
--e89a8fb1ee1e82a7b104c7cfd1c1-- From washam.fan@gmail.com Tue Aug 21 21:36:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2633911E80F4 for ; Tue, 21 Aug 2012 21:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS5CpJ9l-fA7 for ; Tue, 21 Aug 2012 21:36:40 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59BA211E8091 for ; Tue, 21 Aug 2012 21:36:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so299918wgb.13 for ; Tue, 21 Aug 2012 21:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JgWmjoTlV8Ku09y4P1OVFn7BssWdpOzh8YUNv4oWGBw=; b=mcTHZP+SI1FJwfn3jXpw8Zk4AhwwCeAkDkAadkkLr6WaM9WQPzzVtvFKEpaOg6jS44 iG43Uz/nu/9g4G9NtAy0XTaXChIh85oW11kkR14s99PovSZ7ULprw6XZqVI9cP1YU/P0 igJWW/c8cLbjSujcEZbl5zZ0gOuAZ13ny2XI1xFIkLz7ydHkaMaTpXRfLyR/k+6wEd3R R14DLayy+CMOv4saIEEpJ55qehVJ8s83N+ncEiRlxx6dUXBDuaFi6nj4OyYeWGqGlfNA r3d0l7bSr3RfyEXcnR5LQWuC3aD/1/RNtkqSoBv+0xKDMqUr/6LGFYEppPB6YB4MMG/9 0OYA== MIME-Version: 1.0 Received: by 10.180.106.97 with SMTP id gt1mr2550945wib.5.1345610199136; Tue, 21 Aug 2012 21:36:39 -0700 (PDT) Received: by 10.216.205.96 with HTTP; Tue, 21 Aug 2012 21:36:38 -0700 (PDT) In-Reply-To: <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 12:36:38 +0800 Message-ID: From: Washam Fan To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 04:36:46 -0000 Hi Remi, 2012/8/22 R=E9mi Despr=E9s : > Hi, Ole, > > 2012-08-21 15:26, Ole Tr=F8an: > >>> 2. Is you point that you personally find it difficult to implement the = allocated CLAT IID (that of example 2 in the appendix)? >>> >>> No (and I'm not the one doing the implementation). The reasons why I th= ink we should not request IANA to allocate an IID are: >>> >>> 1. Operational experience that while it's good to ensure things are uni= que by decree, in practice that leads to things not being unique some of th= e time (e.g., MAC addresses - they're supposed to be duplicates, but guess = what, they're not). Thus, I prefer methods that are dynamic. >>> 2. It's better to avoid hard-coding things if you can. >>> 3. I just don't see a compelling need for a unique IID. The translation= mechanism would work fine without it (assuming you do DAD, which these nod= es need to do anyway for other addresses such as their link-local addresses= ). I don't see why we need to trouble IANA with a request for a unique IID = if we don't need one. >> >> +1. keep it simple. > >> it isn't at all clear to me what value a reserved IID has. > > Many explanations have been given, and can be read. > >> just putting two CLATs on the same link would result in a collision... > > Collision of what, where? A FUD entertaining statement should at least be= supported with some technical explanation (IMHO). > > But here, the statement is simply false: > - Each CLAT having its exclusive /64, any address derived from it belongs= only to this CLAT, and cannot collide What about the collision between the CLAT and the hosts behind it? It can not be guaranteed that the IPv6 address derived from so-called reserved EUI-64 ID would not be used by any host behind the CLAT. I.e., DAD is not avoidable. Thanks, washam > - Even without a CLAT assigned interface ID, two CLATs can use common int= erface IDs on the WAN side. > > RD > > > > > > >> >> cheers, >> Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed Aug 22 00:14:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DA511E80DE for ; Wed, 22 Aug 2012 00:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud+k1g4-UlOI for ; Wed, 22 Aug 2012 00:14:30 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7E86711E80D7 for ; Wed, 22 Aug 2012 00:14:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id A1F847000057; Wed, 22 Aug 2012 09:14:26 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 1BFA97000083; Wed, 22 Aug 2012 09:14:26 +0200 (CEST) X-SFR-UUID: 20120822071426114.1BFA97000083@msfrf2517.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35-92762006 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 09:14:25 +0200 Message-Id: <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:14:30 -0000 --Apple-Mail-35-92762006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 02:27, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 1:23 AM, R=E9mi Despr=E9s = wrote: > > just putting two CLATs on the same link would result in a = collision... >=20 > Collision of what, where? A FUD entertaining statement should at least = be supported with some technical explanation (IMHO). >=20 > But here, the statement is simply false: > - Each CLAT having its exclusive /64, any address derived from it = belongs only to this CLAT, and cannot collide > - Even without a CLAT assigned interface ID, two CLATs can use common = interface IDs on the WAN side. >=20 > Put one CLAT behind the other. "On the same link" was part of the statement (which remains AFAIK = remains a false statement). > The first CLAT gets a /64 from upstream and passes it on to its = downstream. The second CLAT gets the RA from the first with the same = /64. Both are on the same /64. They both pick the same IID because = that's what the draft tells them to do. Voila, the same IPv6 address is = assigned to two hosts. Cascading CLATs isn't part of the 464XLAT model where the WAN side is = IPv6 only and the LAN side supports private IPv4. RD= --Apple-Mail-35-92762006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 1:23 = AM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
> just putting two CLATs on the same link would = result in a collision...

Collision of what, where? A FUD entertaining statement should at = least be supported with some technical explanation (IMHO).

But here, the statement is simply false:
- Each CLAT having its exclusive /64, any address derived from it = belongs only to this CLAT, and cannot collide
- Even without a CLAT assigned interface ID, two CLATs can use common = interface IDs on the WAN side.

Put = one CLAT behind the = other.

"On the same link" = was part of the statement (which remains AFAIK remains a false = statement).

The first CLAT gets a /64 from upstream and = passes it on to its downstream. The second CLAT gets the RA from the = first with the same /64. Both are on the same /64. They both pick the = same IID because that's what the draft tells them to do. Voila, the same = IPv6 address is assigned to two hosts.

Cascading CLATs isn't part of the 464XLAT = model where the WAN side is IPv6 only and the LAN side supports private = IPv4.

RD
= --Apple-Mail-35-92762006-- From phdgang@gmail.com Wed Aug 22 00:16:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC8A11E80EA for ; Wed, 22 Aug 2012 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5q1i3aM3wQ5 for ; Wed, 22 Aug 2012 00:16:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E046811E80DE for ; Wed, 22 Aug 2012 00:16:47 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so758521vcb.31 for ; Wed, 22 Aug 2012 00:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=am10DY/y27/BMY0VAqx3nWmQwAxFRQMKDuxazhQKAsM=; b=o4kkuzy8v0a7q1Dgy2RvSPnDyLMWfQE55++EL0n2FX+ez97NaalfmRDQLSaDo70IHo GOquogO1NRR3c6B2B+lUzX3bO8cv4UfjupSpazVIAh/IlAudZ7X9zCB9/JMhXKZaN74c FrLOr8X5z9xF42yiChxziX2Xh++CWp76oputysHpxaNjncWatiTQbng3ISGFy/5nv9i/ 4f7VKk1qFgT22FYu0ooMYMFZvuWR3u6pnXBchQsXi81rdNoi6j3z4WGW+/47jaXJWslg 5Ck0TEIS9AdgysIaean3KhXv3Qeq7ZvVNnf0cUWbYy3xur6NXLYzIn8cAtCoi6xkHrJC sylA== MIME-Version: 1.0 Received: by 10.220.141.202 with SMTP id n10mr15628016vcu.49.1345619806973; Wed, 22 Aug 2012 00:16:46 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 22 Aug 2012 00:16:46 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 15:16:46 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:16:48 -0000 2012/8/22, Lorenzo Colitti : > On Wed, Aug 22, 2012 at 1:23 AM, R=E9mi Despr=E9s > wrote: > >> > just putting two CLATs on the same link would result in a collision... >> >> Collision of what, where? A FUD entertaining statement should at least b= e >> supported with some technical explanation (IMHO). >> >> But here, the statement is simply false: >> - Each CLAT having its exclusive /64, any address derived from it belong= s >> only to this CLAT, and cannot collide >> - Even without a CLAT assigned interface ID, two CLATs can use common >> interface IDs on the WAN side. >> > > Put one CLAT behind the other. The first CLAT gets a /64 from upstream an= d > passes it on to its downstream. The second CLAT gets the RA from the firs= t > with the same /64. Both are on the same /64. They both pick the same IID > because that's what the draft tells them to do. Voila, the same IPv6 > address is assigned to two hosts. The scenario may be invalid in the case ND proxy, RFC4389 says "If an RA with the P bit set has arrived on a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a proxy interface; i.e., proxy functionality is disabled on that interface. " From phdgang@gmail.com Wed Aug 22 00:21:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EFF11E80D5 for ; Wed, 22 Aug 2012 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS2wxumVpCo2 for ; Wed, 22 Aug 2012 00:21:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B511E80D7 for ; Wed, 22 Aug 2012 00:21:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so763571vbb.31 for ; Wed, 22 Aug 2012 00:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cb5L5+3qf5FFHeJLVKxHs2L134usFtxnOXc1Nf5kOzc=; b=HUd+idRaVHcqxO/6oK7YPKmKVw2WGQZ6DLEI7pEPE8EKWvK4J80MHs2xdNHh2YqudQ 9RFZI+U/p0OEAVY9JsHLSeroRbDWavAGwOTk2L2O8GfLDny2Pi9lkNwuyGTO1N1ffvK3 96ZFzKTmAUv0lxs5aNFtpzcJ+RT+VtwkkudnnfyMVVcVobGxOvd7XidYVidcbGqqdw+6 pJCdv4Hs7Lb4PkcHskIZ0Q5SHZnPf1gYszir9M4u1SGas9yS6luGUWqSvCxU22n8srkK Tl/VCx71P2OfwTMaeARZSdOWNM4kCBNH5diDy6GNPhLfXMUnfeSrSSLj2vZQ8l3SMTGl 86Bw== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr9547132ved.13.1345620077827; Wed, 22 Aug 2012 00:21:17 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 22 Aug 2012 00:21:17 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 15:21:17 +0800 Message-ID: From: GangChen To: Washam Fan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:21:25 -0000 2012/8/22, Washam Fan : > Hi Remi, > > 2012/8/22 R=E9mi Despr=E9s : >> Hi, Ole, >> >> 2012-08-21 15:26, Ole Tr=F8an: >> >>>> 2. Is you point that you personally find it difficult to implement the >>>> allocated CLAT IID (that of example 2 in the appendix)? >>>> >>>> No (and I'm not the one doing the implementation). The reasons why I >>>> think we should not request IANA to allocate an IID are: >>>> >>>> 1. Operational experience that while it's good to ensure things are >>>> unique by decree, in practice that leads to things not being unique so= me >>>> of the time (e.g., MAC addresses - they're supposed to be duplicates, >>>> but guess what, they're not). Thus, I prefer methods that are dynamic. >>>> 2. It's better to avoid hard-coding things if you can. >>>> 3. I just don't see a compelling need for a unique IID. The translatio= n >>>> mechanism would work fine without it (assuming you do DAD, which these >>>> nodes need to do anyway for other addresses such as their link-local >>>> addresses). I don't see why we need to trouble IANA with a request for= a >>>> unique IID if we don't need one. >>> >>> +1. keep it simple. >> >>> it isn't at all clear to me what value a reserved IID has. >> >> Many explanations have been given, and can be read. >> >>> just putting two CLATs on the same link would result in a collision... >> >> Collision of what, where? A FUD entertaining statement should at least b= e >> supported with some technical explanation (IMHO). >> >> But here, the statement is simply false: >> - Each CLAT having its exclusive /64, any address derived from it belong= s >> only to this CLAT, and cannot collide > > What about the collision between the CLAT and the hosts behind it? It > can not be guaranteed that the IPv6 address derived from so-called > reserved EUI-64 ID would not be used by any host behind the CLAT. > I.e., DAD is not avoidable. Avoiding DAD may not the point of reserved IID. A main advantage is to fit the case where CLAT cannot perform ND Proxy. This was already documented in the draft-07. > Thanks, > washam > >> - Even without a CLAT assigned interface ID, two CLATs can use common >> interface IDs on the WAN side. >> >> RD >> >> >> >> >> >> >>> >>> cheers, >>> Ole >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From washam.fan@gmail.com Wed Aug 22 00:28:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF221F84FB for ; Wed, 22 Aug 2012 00:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7dnSzBn0im8 for ; Wed, 22 Aug 2012 00:28:21 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 050AC21F84F8 for ; Wed, 22 Aug 2012 00:28:20 -0700 (PDT) Received: by wicr5 with SMTP id r5so4344580wic.13 for ; Wed, 22 Aug 2012 00:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LynquVQKafeumjVIuToMjgVMbdVd4MMd85iacQsluJ8=; b=Ixx9jB8d0TNplbBYOu/ca3NUSWNT7Bqv08fdfVZ6kPiBr7LzbhMUzo1Va5bcM4jQYR EoGyBvBzKTyLUC51BSsBMTDlokiuHuVITLuGF+Zwa0EaoQLIamn280TExT4i6jo1aiKe nkfmXm2A1R9aYJfOP4LgId7xhxX72+iKUWGPy+7xnDlvyRWRF+t2/4YSfDASqm92r+gk RfAGo/4l2p5qagX4e3gZrzrS+kp8BE5hYHuBHxm0RID6mqz6ucNQP8nCNAAbXdWBGmVq of/vfcxdEAstQtMH0McaV/IRFcJwe7GEsIjhAnnN/ymeiRJTbTPBNI3w4YfN5AYHdS2x zFrg== MIME-Version: 1.0 Received: by 10.217.1.201 with SMTP id n51mr9980110wes.124.1345620499997; Wed, 22 Aug 2012 00:28:19 -0700 (PDT) Received: by 10.216.205.96 with HTTP; Wed, 22 Aug 2012 00:28:19 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 15:28:19 +0800 Message-ID: From: Washam Fan To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:28:25 -0000 Hi, 2012/8/22 GangChen : > 2012/8/22, Washam Fan : >> Hi Remi, >> >> 2012/8/22 R=E9mi Despr=E9s : >>> Hi, Ole, >>> >>> 2012-08-21 15:26, Ole Tr=F8an: >>> >>>>> 2. Is you point that you personally find it difficult to implement th= e >>>>> allocated CLAT IID (that of example 2 in the appendix)? >>>>> >>>>> No (and I'm not the one doing the implementation). The reasons why I >>>>> think we should not request IANA to allocate an IID are: >>>>> >>>>> 1. Operational experience that while it's good to ensure things are >>>>> unique by decree, in practice that leads to things not being unique s= ome >>>>> of the time (e.g., MAC addresses - they're supposed to be duplicates, >>>>> but guess what, they're not). Thus, I prefer methods that are dynamic= . >>>>> 2. It's better to avoid hard-coding things if you can. >>>>> 3. I just don't see a compelling need for a unique IID. The translati= on >>>>> mechanism would work fine without it (assuming you do DAD, which thes= e >>>>> nodes need to do anyway for other addresses such as their link-local >>>>> addresses). I don't see why we need to trouble IANA with a request fo= r a >>>>> unique IID if we don't need one. >>>> >>>> +1. keep it simple. >>> >>>> it isn't at all clear to me what value a reserved IID has. >>> >>> Many explanations have been given, and can be read. >>> >>>> just putting two CLATs on the same link would result in a collision... >>> >>> Collision of what, where? A FUD entertaining statement should at least = be >>> supported with some technical explanation (IMHO). >>> >>> But here, the statement is simply false: >>> - Each CLAT having its exclusive /64, any address derived from it belon= gs >>> only to this CLAT, and cannot collide >> >> What about the collision between the CLAT and the hosts behind it? It >> can not be guaranteed that the IPv6 address derived from so-called >> reserved EUI-64 ID would not be used by any host behind the CLAT. >> I.e., DAD is not avoidable. > > Avoiding DAD may not the point of reserved IID. A main advantage is to > fit the case where CLAT cannot perform ND Proxy. This was already > documented in the draft-07. > > Then what if DAD fails due to some host behind CLAT already occupied the address derived from the reserved IID? Thanks, washam >> >>> - Even without a CLAT assigned interface ID, two CLATs can use common >>> interface IDs on the WAN side. >>> >>> RD >>> >>> >>> >>> >>> >>> >>>> >>>> cheers, >>>> Ole >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From phdgang@gmail.com Wed Aug 22 00:34:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73D421F851A for ; Wed, 22 Aug 2012 00:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByIOc6vPKTzl for ; Wed, 22 Aug 2012 00:34:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 597BE21F8514 for ; Wed, 22 Aug 2012 00:34:48 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so774467vcb.31 for ; Wed, 22 Aug 2012 00:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vPkVQHKwNN+vZMMFiMZgqdDJ0WgCAMD/OHbtsAX4a+o=; b=wP4cbGwFul/A3dFvoz8vhbMzKJd2imz4tciXCavkM3rlJ/BigLtJw2GI06fAPai76z SCDHIcp2uHYCMuNbGnSZZ4l+MVmpDJWbPZH6JQW5plPWH8KAlKfVwyPZ9+By43eIQdK4 yv57lXqZ6k1dVJVDgbmzzscl9yV42XQKFLSG619mx+UWtWZRpl83G2EG50PHGbnvr6Vi xHUQKE9IByYvb3Sl/o91/0iM1MEl8DzCExENpP/X0sfRieQIeH55npvlghA41F4lWmGj R2uGrjJxfuofG09lgsUOygoQg6YOsxPy6a5J+dK62cCKJLqC1c8FlLBodVL7e7vCA6ug qg7A== MIME-Version: 1.0 Received: by 10.52.26.75 with SMTP id j11mr13419243vdg.75.1345620887712; Wed, 22 Aug 2012 00:34:47 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 22 Aug 2012 00:34:47 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 15:34:47 +0800 Message-ID: From: GangChen To: Washam Fan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:34:52 -0000 2012/8/22, Washam Fan : > Hi, > > 2012/8/22 GangChen : >> 2012/8/22, Washam Fan : >>> Hi Remi, >>> >>> 2012/8/22 R=E9mi Despr=E9s : >>>> Hi, Ole, >>>> >>>> 2012-08-21 15:26, Ole Tr=F8an: >>>> >>>>>> 2. Is you point that you personally find it difficult to implement >>>>>> the >>>>>> allocated CLAT IID (that of example 2 in the appendix)? >>>>>> >>>>>> No (and I'm not the one doing the implementation). The reasons why I >>>>>> think we should not request IANA to allocate an IID are: >>>>>> >>>>>> 1. Operational experience that while it's good to ensure things are >>>>>> unique by decree, in practice that leads to things not being unique >>>>>> some >>>>>> of the time (e.g., MAC addresses - they're supposed to be duplicates= , >>>>>> but guess what, they're not). Thus, I prefer methods that are >>>>>> dynamic. >>>>>> 2. It's better to avoid hard-coding things if you can. >>>>>> 3. I just don't see a compelling need for a unique IID. The >>>>>> translation >>>>>> mechanism would work fine without it (assuming you do DAD, which >>>>>> these >>>>>> nodes need to do anyway for other addresses such as their link-local >>>>>> addresses). I don't see why we need to trouble IANA with a request f= or >>>>>> a >>>>>> unique IID if we don't need one. >>>>> >>>>> +1. keep it simple. >>>> >>>>> it isn't at all clear to me what value a reserved IID has. >>>> >>>> Many explanations have been given, and can be read. >>>> >>>>> just putting two CLATs on the same link would result in a collision..= . >>>> >>>> Collision of what, where? A FUD entertaining statement should at least >>>> be >>>> supported with some technical explanation (IMHO). >>>> >>>> But here, the statement is simply false: >>>> - Each CLAT having its exclusive /64, any address derived from it >>>> belongs >>>> only to this CLAT, and cannot collide >>> >>> What about the collision between the CLAT and the hosts behind it? It >>> can not be guaranteed that the IPv6 address derived from so-called >>> reserved EUI-64 ID would not be used by any host behind the CLAT. >>> I.e., DAD is not avoidable. >> >> Avoiding DAD may not the point of reserved IID. A main advantage is to >> fit the case where CLAT cannot perform ND Proxy. This was already >> documented in the draft-07. >> >> > Then what if DAD fails due to some host behind CLAT already occupied > the address derived from the reserved IID? RFC5342 keep the collision chance as small as it can. Conversely, DAD would fail when there is no ND proxy. Which one is the best to you? BRs Gang > Thanks, > washam >>> >>>> - Even without a CLAT assigned interface ID, two CLATs can use common >>>> interface IDs on the WAN side. >>>> >>>> RD >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> cheers, >>>>> Ole >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From despres.remi@laposte.net Wed Aug 22 00:38:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30F721F858A for ; Wed, 22 Aug 2012 00:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4lQcENpNoon for ; Wed, 22 Aug 2012 00:38:34 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7EA21F8514 for ; Wed, 22 Aug 2012 00:38:34 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id BA4327000057; Wed, 22 Aug 2012 09:38:33 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 3F9B4700008D; Wed, 22 Aug 2012 09:38:33 +0200 (CEST) X-SFR-UUID: 20120822073833260.3F9B4700008D@msfrf2517.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 09:38:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> To: Washam Fan X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:38:38 -0000 Le 2012-08-22 =E0 06:36, Washam Fan a =E9crit : > Hi Remi, >=20 > 2012/8/22 R=E9mi Despr=E9s : >> Hi, Ole, >>=20 >> 2012-08-21 15:26, Ole Tr=F8an: >>=20 >>>> 2. Is you point that you personally find it difficult to implement = the allocated CLAT IID (that of example 2 in the appendix)? >>>>=20 >>>> No (and I'm not the one doing the implementation). The reasons why = I think we should not request IANA to allocate an IID are: >>>>=20 >>>> 1. Operational experience that while it's good to ensure things are = unique by decree, in practice that leads to things not being unique some = of the time (e.g., MAC addresses - they're supposed to be duplicates, = but guess what, they're not). Thus, I prefer methods that are dynamic. >>>> 2. It's better to avoid hard-coding things if you can. >>>> 3. I just don't see a compelling need for a unique IID. The = translation mechanism would work fine without it (assuming you do DAD, = which these nodes need to do anyway for other addresses such as their = link-local addresses). I don't see why we need to trouble IANA with a = request for a unique IID if we don't need one. >>>=20 >>> +1. keep it simple. >>=20 >>> it isn't at all clear to me what value a reserved IID has. >>=20 >> Many explanations have been given, and can be read. >>=20 >>> just putting two CLATs on the same link would result in a = collision... >>=20 >> Collision of what, where? A FUD entertaining statement should at = least be supported with some technical explanation (IMHO). >>=20 >> But here, the statement is simply false: >> - Each CLAT having its exclusive /64, any address derived from it = belongs only to this CLAT, and cannot collide >=20 > What about the collision between the CLAT and the hosts behind it? Different subject. > It > can not be guaranteed that the IPv6 address derived from so-called > reserved EUI-64 ID would not be used by any host behind the CLAT. > I.e., DAD is not avoidable. As already said, no host that COMPLIES with the IPv6-addressing RFC = (RFC4291) can collide with the CLAT. (The CLAT IID has been chosen for = this.) Now, it has been discussed that manual configuration permits to assign a = host an address that doesn't comply with RFC4291. Right. But = consequences of configuring an invalid address are numerous anyway, = including various unreachability. No specific code is needed to try and = prevent such consequences. Besides, as already noted, RFC4862 says "if the duplicate link-local = address is not formed from an interface identifier based on the hardware = address, which is supposed to be uniquely assigned, IP operation on the = interface MAY be continued". Thus, DAD doesn't firmly prohibit operation = with a host that happens to use the CLAT IPv6 address. With the = CLAT-assigned IID, there is no such concern. =20 Regards, RD >=20 > Thanks, > washam >=20 >> - Even without a CLAT assigned interface ID, two CLATs can use common = interface IDs on the WAN side. >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> cheers, >>> Ole >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed Aug 22 00:43:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B878E21F84CE for ; Wed, 22 Aug 2012 00:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIVCa5VAPTc1 for ; Wed, 22 Aug 2012 00:43:55 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 86FA321F844B for ; Wed, 22 Aug 2012 00:43:55 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id B0C31700016B; Wed, 22 Aug 2012 09:43:54 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 4088A70000B9; Wed, 22 Aug 2012 09:43:54 +0200 (CEST) X-SFR-UUID: 20120822074354264.4088A70000B9@msfrf2517.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 09:43:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> To: Washam Fan X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:43:59 -0000 2012-08-22 =E0 09:28, Washam Fan: > Hi, >=20 > 2012/8/22 GangChen : >> 2012/8/22, Washam Fan : ... >>=20 >> Avoiding DAD may not the point of reserved IID. A main advantage is = to >> fit the case where CLAT cannot perform ND Proxy. This was already >> documented in the draft-07. >>=20 >>=20 > Then what if DAD fails due to some host behind CLAT already occupied > the address derived from the reserved IID? Unless the host has been manually configured with an address that = doesn't comply with RFC4291, this cannot happen. This is precisely what = the CLAT IID ensures.=20 RD =20 >=20 > Thanks, > washam >>>=20 >>>> - Even without a CLAT assigned interface ID, two CLATs can use = common >>>> interface IDs on the WAN side. >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> cheers, >>>>> Ole >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 From despres.remi@laposte.net Wed Aug 22 01:05:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD5521F850D for ; Wed, 22 Aug 2012 01:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUlQNTMqQNe6 for ; Wed, 22 Aug 2012 01:05:28 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4A21F8602 for ; Wed, 22 Aug 2012 01:05:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 174037000141; Wed, 22 Aug 2012 10:05:27 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 8A17970000B9; Wed, 22 Aug 2012 10:05:26 +0200 (CEST) X-SFR-UUID: 20120822080526565.8A17970000B9@msfrf2517.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 10:05:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BCD592E-5E00-48BB-AA58-7DE3F3CFFAFB@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:05:32 -0000 Hi, James, 2012-08-21 22:52, james woodyatt: > On Aug 21, 2012, at 13:03 , Randy Bush wrote: >>=20 >> wg last call has started. i dissent. >=20 > I've been quietly following this discussion, and I think it's time I = stood up to say that I agree with Mr. Bush and those who say the request = for IANA to reserve a modified EUI-64 is unnecessary and arguably = counter-productive. It should be removed before the draft is sent to = the IESG for review. >=20 > For my own part, I don't see why avoiding DAD should be a worthwhile = objective unless the concern is about the time it takes to perform DAD = while the address is still in the TENTATIVE state, to which I reply = *cough* RFC 4429 *cough*. The point isn't avoiding DAD (which is always present). It's making sure = that DAD is irrelevant because hosts that have valid addresses = (complying with RFC4291) have no risk to collide anyway.=20 DAD does detect collisions, yes, but isn't sufficient to avoid their = occurrence, and even operation with them for addresses "not formed from = an interface identifier based on the hardware address". =20 > I am not sanguine about arguments that a Best Current Practice should = recommend a work-around for an implementation issue in one particular = platform that isn't generally required everywhere. In my understanding, all valid technical concerns that have been = expressed are covered if, in section 8.3.2, the first part of the = following sentence is deleted: "If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of = the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID = for creating a translated IPv6 address to be used in stateless = translation [RFC6145]." This permits your implementation to ignore the CLAT-assigned IID, if you = so wish, and permits implementations that take advantage of it. Regards, RD=20 >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed Aug 22 02:19:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402E621F85FF for ; Wed, 22 Aug 2012 02:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.746 X-Spam-Level: X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZZ56N6rVp93 for ; Wed, 22 Aug 2012 02:19:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3316721F8643 for ; Wed, 22 Aug 2012 02:19:02 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1263807obb.31 for ; Wed, 22 Aug 2012 02:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7M4Oy2Hs0aLhmtVDf1go7UQqIntmOc1+tgpGtUMnL20=; b=jl6/YcxTZZIZjczIwRjYnPId2I1jBp3yH10dwTPCIeFjTsZCHqA9Y40+kYMZg2vDdB b2n4fJCCLxagILpTv6yLIlaKNIyqSokV+XTDh8yyQrozCmUpuzdRlgf0d2soUtnQ2gSl OIlfKRUeUlVwl5LQA9ECtIRbxCZYmX9X7sEsmlaFkoN0lcDxfaDD52/nre81pQWZTkbk iUs1bI8hhmByzEvl+iJ1Ayihr+V5108Hl9MFrXPHCCCalYhoB+fXvAmZLNTHD8G8iad+ SBn4hHE8vzwie3jyz3KqIZzC2Lp/TcWMIr8HsxW8UvlpKhcgQ5QwHTNHwuZ0JFgNalL5 L58A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7M4Oy2Hs0aLhmtVDf1go7UQqIntmOc1+tgpGtUMnL20=; b=Qfz6AzZhxYwsb1MCNLmvTxM8YVwAk35r8PvRCEZNOUTLRit1jvfrZ5hMAvfahR7zwG cnkoQWOnbkt1YJbGq0qUTliI1yGeu1G6rA38g6uxMBSm7hSOkwS26tHggVPC5D6dXvEo jEjLrexsnzwRHYxSVcJdSSGVi6dCHiRgWIEI7AgZgn2fIvU77BZbXneXQ0yqb/fGMcqf 0KEftdr0YPB73nCG44ya3TDKtp6s4hLrfm1+xuYtxbFVyOj9ZFOXkei/MUBO1R+0isTf G1y23PT0pBCoC7W2FmjUHyAzyOubi8eXEFU4Mx+zrANJa51As+pZzLaCLbZg26K1ICWH Ahdg== Received: by 10.182.1.72 with SMTP id 8mr14997770obk.61.1345627142643; Wed, 22 Aug 2012 02:19:02 -0700 (PDT) Received: by 10.182.1.72 with SMTP id 8mr14997758obk.61.1345627142446; Wed, 22 Aug 2012 02:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 02:18:42 -0700 (PDT) In-Reply-To: <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 18:18:42 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04462fe0d3600d04c7d73b1c X-System-Of-Record: true X-Gm-Message-State: ALoCoQmrZESDTnHH/VuirarsY+ffmDcd81wNR7tZ7iqlJx3e0Tqr1anUZtTf3zncbEqtpxqrwW4o73q18yZihKVpnPMBoLf7lU5jnhkDuohj9oWmSqRptn91Ri0/cBJabIrG9AxqKU8qrSTkxd15WyKKQN7apcr9jjMv1p8G5fHEoi9K9DBjALsEelH9ZIe4eG/ahKN4cBHx Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:19:04 -0000 --f46d04462fe0d3600d04c7d73b1c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 4:14 PM, R=E9mi Despr=E9s wrote: > > Put one CLAT behind the other. > > > "On the same link" was part of the statement (which remains AFAIK remains > a false statement). > If you put the two CLATs one behind the other, you have to connect them using a link. Therefore, they are by definition on the same link.. > The first CLAT gets a /64 from upstream and passes it on to its > downstream. The second CLAT gets the RA from the first with the same /64. > Both are on the same /64. They both pick the same IID because that's what > the draft tells them to do. Voila, the same IPv6 address is assigned to t= wo > hosts. > > > Cascading CLATs isn't part of the 464XLAT model where the WAN side is IPv= 6 > only and the LAN side supports private IPv4. > But it can happen in practice, and in this model, using a reserved IID breaks things, while using DAD does not. --f46d04462fe0d3600d04c7d73b1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 4:14 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
Put one CLAT behind the other.

"On the same link"= ; was part of the statement (which remains AFAIK remains a false statement)= .

If you put the two CLATs one b= ehind the other, you have to connect them using a link. Therefore, they are= by definition on the same link..
=A0
The first CLAT gets a /64 from up= stream and passes it on to its downstream. The second CLAT gets the RA from= the first with the same /64. Both are on the same /64. They both pick the = same IID because that's what the draft tells them to do. Voila, the sam= e IPv6 address is assigned to two hosts.

Cascading CLATs isn't part of the 464= XLAT model where the WAN side is IPv6 only and the LAN side supports privat= e IPv4.

But it can happen in pr= actice, and in this model, using a reserved IID breaks things, while using = DAD does not.
--f46d04462fe0d3600d04c7d73b1c-- From lorenzo@google.com Wed Aug 22 02:32:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0D521F867B for ; Wed, 22 Aug 2012 02:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLxUBeRW+S3h for ; Wed, 22 Aug 2012 02:32:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F075B21F8570 for ; Wed, 22 Aug 2012 02:32:10 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1283866obb.31 for ; Wed, 22 Aug 2012 02:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=n024aZ3zL3NwQkF9Ax7mymtNB7CDSLQNF25KL/3t+xQ=; b=nEB9fsPNo4xyTt2PFQuI4SfbJB/12k/D8IsfueZ0bfzJIPrSjadL2BGCfKlMFoCqy5 /GBGNXIlbUi39pdS8/Ha2tzL9td5qLeWj9INJ0W4LSmQaB+7MWLUVJJCK6+jsSr4musH 7PKCA2sN06TtgMMAuC1nfre4hvAky1I7bcYvYloUSV5d7o7MOJKopOqrhDW/3LzPl1RR 1RiwH8uWhE68xYz2QD1qIPD7lJTW8RaHZCAOlgBdTzfiOcQy8fTum2Zn78OysggqWeue V3sDbcvznolILHOLBaDJ7TCiTQ3OoU3WjUNYw5TeCgC+tc+niTJZIPhngHitHm/0WROr 2/Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=n024aZ3zL3NwQkF9Ax7mymtNB7CDSLQNF25KL/3t+xQ=; b=mGxZ0Xnz0VuEtOO8kOTovHlHL3PKqibrU14DtLcBg467SdZz031fzUe8zJ+rCOv71v PaTNs7gqXrFVi5lDdW63GYVXNznYVxHA81WJFprWm3NZNXoSLZphzAYaaY7jsZ7awWVV fG9kaWQuxLXfvVd43WkzP4X+wR9Oe8o3GUtuValXkP+t9cFaOPCmSn4ENnPtm8KKg96e YqFgIio8Mlv/WTI4LjZZd80U0DRBlsn5/0XMeNHRcolInntVdZPFR/D0rl4rOjkjUUg7 DVf1X9jCfv0E75sltdd75OEr7lL6wyNdqaNgwC+OAZSRKuMT7+wtDhJ9QMTihIVEz0qt v3tQ== Received: by 10.60.2.193 with SMTP id 1mr15113455oew.29.1345627930506; Wed, 22 Aug 2012 02:32:10 -0700 (PDT) Received: by 10.60.2.193 with SMTP id 1mr15113447oew.29.1345627930318; Wed, 22 Aug 2012 02:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 02:31:50 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 18:31:50 +0900 Message-ID: To: Washam Fan Content-Type: multipart/alternative; boundary=e89a8fb1ee1ec955ae04c7d76a33 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmvqLHo3iPeuELMLB+l+mRWPoBO3uuKJAcw9HzA+WXTpLF/EorW34jHwRESSyqWtC7SFKRe8vk51L1xr7JcnHJ9HFOZyDrNBauuqKw7atn75NKM4o+ecoIl8c97eEmHpz5NhGRd4+E3SWqGLG+jIiQXguLj7gsPMOJw8jv2wVDciCk6+3toS4661xbZDKPGCMka8/mT Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:32:11 -0000 --e89a8fb1ee1ec955ae04c7d76a33 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 22, 2012 at 4:28 PM, Washam Fan wrote: > Then what if DAD fails due to some host behind CLAT already occupied > the address derived from the reserved IID? The same thing that happens if any a router fails to assign a global address on an interface because a host already has that address. --e89a8fb1ee1ec955ae04c7d76a33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 4:28 PM, Washam Fan <washam.fan@gmail.com> wrote:
Then what if DAD fails due to some host behind CLAT already occupied
the address derived from the reserved IID?

= The same thing that happens if any a router fails to assign a global addres= s on an interface because a host already has that address.
--e89a8fb1ee1ec955ae04c7d76a33-- From lorenzo@google.com Wed Aug 22 02:42:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977F121F861C for ; Wed, 22 Aug 2012 02:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2MS8F2bngkF for ; Wed, 22 Aug 2012 02:42:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F163921F861B for ; Wed, 22 Aug 2012 02:42:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1299941obb.31 for ; Wed, 22 Aug 2012 02:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lndTXV27ZoLAqKAXM76Rfh1O12y7UPq1i7SCfrjU9Ag=; b=df6RjtbFzFI9iUirSSpcNh7ARWt8CRGYrQKZX3eP8Dprz1k1HL+hLUJPonlFAOXB9B gJF3ygRAEtwA+If1oq2/CxEKuQS4eD040DTiRDwY42V/4N5SfGrfqkOYFSaeEERFbtH9 3rXvx/xMab90psvJJzK4V/VrHEG2G9jgCiry33qq4wqHhUeaAtKqEw3W0VIcEiwEy/vu p+Gd+jYgsMGz3jONMZydMLOP+75vdRcmmmjjU7ZlRnx7qJtOBdT1BXa4g9bt6Ig4S+Lm VtlyxXT0RFkiJgm7zAvSSSFt2ZwtuTghIY8M4803HSRLtnz4Y1bt8OY22PufHXcdd6d+ 4gJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=lndTXV27ZoLAqKAXM76Rfh1O12y7UPq1i7SCfrjU9Ag=; b=Wh9uL8H8qHyE1xf1A8X0YE86qwU9bL/NmAF/OMYR0IrwQagoTvJNAMDURM9sqSBDJb e+mhJ+E1+hNIHEuMCtcF0dckus8C62dbToAThIr3KF4oZaM+pa+QMY6OkhLcfNwfpJ33 JFqQQNp67nWcIyJRD8Fh6BiGlHVcH0b8VRDsN0Y9HXbBE73XMxoDk6irRM/u0/z5zsMW vYE6+F6b+3v/176znzMVd4KsGv5FOFSmFqvyDIVx6A+tjtUkky8wu7/bfkrCYnsBDEJI HLv6as1pip9lmRxhfiCnnNswsF3KyveCFxZ+r/tfs7/+QmWUNUS7j3vIZdxdMBtlb4vN MrPA== Received: by 10.182.110.40 with SMTP id hx8mr15319797obb.47.1345628547390; Wed, 22 Aug 2012 02:42:27 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr15319787obb.47.1345628547270; Wed, 22 Aug 2012 02:42:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 02:42:07 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 18:42:07 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=f46d044516dd8f476604c7d78f84 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn7jP3OxQ5w/LWa+aQPgZI9mFB22Rv/Yr4+pxr7qphSsXGNj7Hu0bKsoOBXohHyKpqPf6sh88qCXOmyFpNR3vTxGLmMUvEpAiVnnjNXtmGFJcX3Ekx1+kuXeL1BKKgvpxHfCl3og7aJU17NzblnSn+oekppLMwEhAR40k8qpHyhZ0sPgATJdSGkv4eGO1NbRHa2TG41 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:42:28 -0000 --f46d044516dd8f476604c7d78f84 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 22, 2012 at 4:21 PM, GangChen wrote: > > What about the collision between the CLAT and the hosts behind it? It > > can not be guaranteed that the IPv6 address derived from so-called > > reserved EUI-64 ID would not be used by any host behind the CLAT. > > I.e., DAD is not avoidable. > > Avoiding DAD may not the point of reserved IID. A main advantage is to > fit the case where CLAT cannot perform ND Proxy. This was already > documented in the draft-07. Actually, I think a reserved IID does not help. Rationale: 1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then the CLAT does not need to perform ND proxying at all in order to provide its clients with connectivity. All it needs to do is claim an IPv6 address from the /64 and enable IPv6 forwarding. The important thing is not proxying, but defending the address against DAD. 2. If the CLAT's upstream interface is not point-to-point, and the CLAT doesn't perform ND proxying, then connectivity is broken anyway. Nodes on the upstream interface and nodes on the downstream are on the same /64, but they can't reach each other. So you already have a much bigger problem than IID collisions, and a reserved IID will not fix it. --f46d044516dd8f476604c7d78f84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 4:21 PM, GangChen <phdg= ang@gmail.com> wrote:
> What about the collision between the CLAT and the hosts behi= nd it? It
> can not be guaranteed that the IPv6 address derived from so-called
> reserved EUI-64 ID would not be used by any host behind the CLAT.
> I.e., DAD is not avoidable.

Avoiding DAD may not the point of reserved IID. A main advantag= e is to
fit the case where CLAT cannot perform ND Proxy. This was already
documented in the draft-07.

Actually, I thi= nk a reserved IID does not help. Rationale:

1. If = the CLAT's upstream interface is point-to-point (e.g., 3G), then the=A0= CLAT does not need to perform ND proxying at all in order to provide its cl= ients with connectivity. All it needs to do is claim an IPv6 address from t= he /64 and enable IPv6 forwarding. The important thing is not proxying, but= defending the address against DAD.

2. If the CLAT's upstream interface is not point-to= -point, and the CLAT doesn't perform ND proxying, then connectivity is = broken anyway. Nodes on the upstream interface and nodes on the downstream = are on the same /64, but they can't reach each other.=A0So you already = have a much bigger problem than IID collisions, and a=A0reserved IID will n= ot fix it.
--f46d044516dd8f476604c7d78f84-- From despres.remi@laposte.net Wed Aug 22 02:59:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687021F85FF for ; Wed, 22 Aug 2012 02:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5gm7yCYVR4z for ; Wed, 22 Aug 2012 02:59:12 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56D21F861F for ; Wed, 22 Aug 2012 02:59:11 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 6B83B70000A9; Wed, 22 Aug 2012 11:59:10 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id B4E647000097; Wed, 22 Aug 2012 11:59:09 +0200 (CEST) X-SFR-UUID: 20120822095909741.B4E647000097@msfrf2321.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-36-102645706 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 11:59:09 +0200 Message-Id: <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@lap oste.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:59:13 -0000 --Apple-Mail-36-102645706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 11:18, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 4:14 PM, R=E9mi Despr=E9s = wrote: >> Put one CLAT behind the other. >=20 > "On the same link" was part of the statement (which remains AFAIK = remains a false statement). >=20 > If you put the two CLATs one behind the other, you have to connect = them using a link. Therefore, they are by definition on the same link.. > =20 >> The first CLAT gets a /64 from upstream and passes it on to its = downstream. The second CLAT gets the RA from the first with the same = /64. Both are on the same /64. They both pick the same IID because = that's what the draft tells them to do. Voila, the same IPv6 address is = assigned to two hosts. >=20 > Cascading CLATs isn't part of the 464XLAT model where the WAN side is = IPv6 only and the LAN side supports private IPv4. >=20 > But it can happen in practice, and in this model, using a reserved IID = breaks things, while using DAD does not. You seem interested in pursuing this example where a CLAT would be = activated on a dual-stack private network (i.e. out of scope for = 464XLAT), behind a CLAT that, as requested by the draft, is activated on = an IPv6-only network. 1. I don't see what should work and would be broken if either CLAT use = the CLAT-reserved IID. 2. Unless you insist, I would be glad to stop spending time on this = case. It is too far from the question at hand: is there any good reason = to prohibit those for whom it is useful to use a reserved CLAT IID?=20 RD --Apple-Mail-36-102645706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 4:14 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
Put one CLAT behind the = other.

"On the same = link" was part of the statement (which remains AFAIK remains a false = statement).

If you put the two CLATs = one behind the other, you have to connect them using a link. Therefore, = they are by definition on the same = link..
 
The first CLAT gets a /64 = from upstream and passes it on to its downstream. The second CLAT gets = the RA from the first with the same /64. Both are on the same /64. They = both pick the same IID because that's what the draft tells them to do. = Voila, the same IPv6 address is assigned to two hosts.

Cascading CLATs isn't part of the = 464XLAT model where the WAN side is IPv6 only and the LAN side supports = private IPv4.

But it can = happen in practice, and in this model, using a reserved IID breaks = things, while using DAD does not.

You seem interested in pursuing this example = where a CLAT would be activated on a dual-stack private network (i.e. = out of scope for 464XLAT), behind a CLAT that, as requested by the = draft, is activated on an IPv6-only network.
1. I don't see = what should work and would be broken if either CLAT use the = CLAT-reserved IID.
2. Unless you insist, I would be glad to = stop spending time on this case. It is too far from the question at = hand: is there any good reason to prohibit those for whom it is = useful to use a reserved CLAT = IID? 

RD


= --Apple-Mail-36-102645706-- From despres.remi@laposte.net Wed Aug 22 03:03:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F221F863F for ; Wed, 22 Aug 2012 03:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+CKt0Is6BIV for ; Wed, 22 Aug 2012 03:03:42 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6321F851E for ; Wed, 22 Aug 2012 03:03:31 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 328837000086; Wed, 22 Aug 2012 12:03:31 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 8AF2570000A2; Wed, 22 Aug 2012 12:03:30 +0200 (CEST) X-SFR-UUID: 20120822100330569.8AF2570000A2@msfrf2321.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-37-102906330 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 12:03:29 +0200 Message-Id: <26F61151-CBDA-457E-9906-1024B734E090@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:03:46 -0000 --Apple-Mail-37-102906330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 11:42, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 4:21 PM, GangChen wrote: > > What about the collision between the CLAT and the hosts behind it? = It > > can not be guaranteed that the IPv6 address derived from so-called > > reserved EUI-64 ID would not be used by any host behind the CLAT. > > I.e., DAD is not avoidable. >=20 > Avoiding DAD may not the point of reserved IID. A main advantage is to > fit the case where CLAT cannot perform ND Proxy. This was already > documented in the draft-07. >=20 > Actually, I think a reserved IID does not help. Rationale: >=20 > 1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then = the CLAT does not need to perform ND proxying at all in order to provide = its clients with connectivity. All it needs to do is claim an IPv6 = address from the /64 and enable IPv6 forwarding. The important thing is = not proxying, but defending the address against DAD. >=20 > 2. If the CLAT's upstream interface is not point-to-point, and the = CLAT doesn't perform ND proxying, then connectivity is broken anyway. = Nodes on the upstream interface and nodes on the downstream are on the = same /64, but they can't reach each other. So you already have a much = bigger problem than IID collisions, and a reserved IID will not fix it. Not sure to understand the case.=20 Are you suggesting that the /64 assigned to a CLAT node is also a prefix = valid on the upstream link? RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-37-102906330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 4:21 = PM, GangChen <phdgang@gmail.com> wrote:
> What about the collision between the CLAT and the hosts = behind it? It
> can not be guaranteed that the IPv6 address derived from = so-called
> reserved EUI-64 ID would not be used by any host behind the = CLAT.
> I.e., DAD is not avoidable.

Avoiding DAD may not the point of reserved IID. A main = advantage is to
fit the case where CLAT cannot perform ND Proxy. This was already
documented in the draft-07.

Actually, I = think a reserved IID does not help. = Rationale:

1. If the CLAT's upstream interface = is point-to-point (e.g., 3G), then the CLAT does not need to = perform ND proxying at all in order to provide its clients with = connectivity. All it needs to do is claim an IPv6 address from the /64 = and enable IPv6 forwarding. The important thing is not proxying, but = defending the address against DAD.

2. If the CLAT's upstream interface is not = point-to-point, and the CLAT doesn't perform ND proxying, then = connectivity is broken anyway. Nodes on the upstream interface and nodes = on the downstream are on the same /64, but they can't reach each = other. So you already have a much bigger problem than IID = collisions, and a reserved IID will not fix = it.

Not sure to understand = the case. 
Are you suggesting that the /64 assigned to a = CLAT node is also a prefix valid on the upstream = link?

RD


_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-37-102906330-- From lorenzo@google.com Wed Aug 22 03:05:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626CD21F866D for ; Wed, 22 Aug 2012 03:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+ndKyNg-Vns for ; Wed, 22 Aug 2012 03:05:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A262621F8514 for ; Wed, 22 Aug 2012 03:05:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1334134obb.31 for ; Wed, 22 Aug 2012 03:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4OQv7uNNYqzLIf0+z4hHwH2bpkTLWPlBw8frCCxsZFU=; b=M7O9+N7VqTXyFDK8H68Ob+TFx0m93RUF2z7E3Xba/fwRQDlTRAz41HYc69GZl2ZUkI vgg64GhTFJOLWWY9ILh4tCf8UTxf5yvlM27mgpvm7NppJiwS6MfAEju5O4oM080BBUzQ YyIGQJd6zEJ9keGEbB/KZfqp7VbqwbDdGkOPOrwnsCDHZLDEDiaO/49lYb2qTxKvY5e+ iJrlyd/LtfMvr84Am9zqJKRo8Cu3Hico5MRWbPODLsA/qaC4iakzx4dnlGvI2L75ALAl fl5A7WMg33IdQLj3FY/J/V9CopXSlA0X1eItl38zE7Rtlozpb3RwJz9h+Giuvp5tsS59 2VcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4OQv7uNNYqzLIf0+z4hHwH2bpkTLWPlBw8frCCxsZFU=; b=dtTSurNZSW5qCu6xVM8uqVr161DHOuLLmXO9E647FocET15Q/YIdkQpNkBBhXHr7Fw tWjIO8IJEdPp9+xVnyxkIGu3oOu/ndOemqQt9R49hg3IqzNVRFMUqFB0mfOfbcxqa/8a 0+FTnqtghPj/reYZ0VW9oCy7DRss3IbgB+DIBuRMgWA6JXcvd7knMR1JuyusbZc0jD25 bbyNWvqq4657xtljmuZUpSaRyhAG4pOXcyvnjHJX8X911BqxsaXXG9KEq3JiQxcX0EK4 Dfly/DhS6OFL2PJZ3c/Jahc1PZS7jmdVZFtjqRTaBoARt9DUGl3JzSe/M82+nA9ocq3n ZZ0w== Received: by 10.182.48.8 with SMTP id h8mr15047858obn.75.1345629901107; Wed, 22 Aug 2012 03:05:01 -0700 (PDT) Received: by 10.182.48.8 with SMTP id h8mr15047839obn.75.1345629900905; Wed, 22 Aug 2012 03:05:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 03:04:39 -0700 (PDT) In-Reply-To: <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 19:04:39 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04462fe43e1b8404c7d7e0b1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn+a3lbtTAo2ZZG/fIx+JbjBsORI5ia7HZnlmJueY6xFEXIl7fLQdAoPpDEDn4S0vOAhEExfrKvyl2TMSqn+UkzjQnWJmNns9ds88McwjZT79NGoPAIimdZlGtZ5bP7kghrsBE0dI34FN5VNKlpUFnXF2XoHZbYRKgRFA6HqNPeA2ox91P8DhWeu23irM3fOXjP+DbU Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:05:02 -0000 --f46d04462fe43e1b8404c7d7e0b1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 6:59 PM, R=E9mi Despr=E9s wrote: > You seem interested in pursuing this example where a CLAT would be > activated on a dual-stack private network (i.e. out of scope for 464XLAT)= , > behind a CLAT that, as requested by the draft, is activated on an IPv6-on= ly > network. > I'm just pointing out a situation where a reserved IID can cause a problem. You may call it a problem that's out of scope; I call it robust. > 2. Unless you insist, I would be glad to stop spending time on this case. > It is too far from the question at hand: is there any good reason to > prohibit those for whom it is useful to use a reserved CLAT IID? > The fundamental problem is that I don't see where there is a use for a reserved IID. --f46d04462fe43e1b8404c7d7e0b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 6:59 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
You seem interested in pursuing th= is example where a CLAT would be activated on a dual-stack private network = (i.e. out of scope for 464XLAT), behind a CLAT that, as requested by the dr= aft, is activated on an IPv6-only network.

I'm just pointing out a situatio= n where a reserved IID can cause a problem. You may call it a problem that&= #39;s out of scope; I call it robust.
=A0
2. Unless you insist, I would be g= lad to stop spending time on this case. It is too far from the question at = hand: is there any good reason to prohibit=A0those for whom it is useful to= use=A0a reserved CLAT IID?=A0

The fundamental problem is that I do= n't see where there is a use for a reserved IID.
--f46d04462fe43e1b8404c7d7e0b1-- From lorenzo@google.com Wed Aug 22 03:06:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DD21F866C for ; Wed, 22 Aug 2012 03:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.747 X-Spam-Level: X-Spam-Status: No, score=-102.747 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cne8NDCkh8cz for ; Wed, 22 Aug 2012 03:06:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C47621F866A for ; Wed, 22 Aug 2012 03:06:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1336403obb.31 for ; Wed, 22 Aug 2012 03:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Cf9PhFdWE8oLx+Nv1kyUKNv927C9pLQ56tR2+94aEc8=; b=dVREBirI2TDEV3SItMuKtefTMoI7UVTHWDHid7mosrsMREIDTTCui4OJ9w9aLiTcw+ JTrnbqzUevv5HzknXjCkba/nSO9fUtpc9k9a0+7ZG+u/ZegOCLWHX3dv0GheqJb5YuAk YyVbsfATfqdyXKe1rckOB4OIzIgc7ZMq//RIzF17dDzu4w1BbnCKlMY/VcG3bHZrdmDl 77JpncN8KNPntLc8s+O5rEB6Xig0VaxdVRVDrFfkBE9nvnlXuerC+h5oCnBDo5uTdHqS kB8Y/9aqgjIpodQj0ZBWJhRyoNbrM515zIHpFDbB627tlPrI02+h840WLF7emvceknc+ lJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Cf9PhFdWE8oLx+Nv1kyUKNv927C9pLQ56tR2+94aEc8=; b=Qs7Fx9Bq1LemUlEirOf55LD3emoVTv/NHsTaZd18qy1ISlhOQMbLj5wTo72YEZEpBj Uqp4maq/ZPfeQPe7ZNoFpX0Cm55cn6CpEpUGAqNt7rtIkrWeI4rXqRZrbUWYzgRBnGad EyxKCNhP57O96K2Ul/Pj72AjHWG5OqmrFFIqxPowl2GF/est2CYKtVfkVq9ToAAXa8td 9Q46o9Mu3VJhP3a6zpvwf4AcVJt1/xbrxEocBevqmDNg7uD0OoD5sNpwy4LM3SAxCF6q NkHYq/j1Ii7CYsoZfdndvxr/OqM0M60PTlxXGQxTFUYjiLlKo0JYw6MXyh2ToW+OrJy+ Va8g== Received: by 10.60.6.73 with SMTP id y9mr15548755oey.17.1345629995229; Wed, 22 Aug 2012 03:06:35 -0700 (PDT) Received: by 10.60.6.73 with SMTP id y9mr15548743oey.17.1345629995132; Wed, 22 Aug 2012 03:06:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 03:06:14 -0700 (PDT) In-Reply-To: <26F61151-CBDA-457E-9906-1024B734E090@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <26F61151-CBDA-457E-9906-1024B734E090@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 19:06:14 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8ff25014dbe5f004c7d7e561 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnW/TMLlaxX+pRs7qIOCNk2duY1o3RG56ueTy8YUc7ZA6JjoeCsCgQafJGMIcOCj0Pi34Bgi5BMb+7XQAzASBgDl0yJeJTtHAKesd54bW2Q5EwEfi4Jm2/hS/QFQNqn41MCobgCHBnqVvtdZSlwqSnW9HEFIamzGeGTU94wObSb27erMc9ykHtZp2gUEwjwC5wK9h9g Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:06:36 -0000 --e89a8ff25014dbe5f004c7d7e561 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 7:03 PM, R=E9mi Despr=E9s wrote: > Not sure to understand the case. > Are you suggesting that the /64 assigned to a CLAT node is also a prefix > valid on the upstream link? > Yes, because GangChen was referring to the Proxy ND RFC, and that's the basic scenario covered in that RFC. --e89a8ff25014dbe5f004c7d7e561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 7:03 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
Not sure to understand the ca= se.=A0
Are you suggesting that the /64 assigned to a CLAT node is= also a prefix valid on the upstream link?

Yes, because GangChen was referring to the Proxy ND RFC, and= that's the basic scenario covered in that RFC.
--e89a8ff25014dbe5f004c7d7e561-- From despres.remi@laposte.net Wed Aug 22 03:13:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4C21F8613 for ; Wed, 22 Aug 2012 03:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7LXMfHOsJCU for ; Wed, 22 Aug 2012 03:13:38 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id F3C8621F860E for ; Wed, 22 Aug 2012 03:13:37 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id A19E170000B2; Wed, 22 Aug 2012 12:13:36 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id DD8CB7000091; Wed, 22 Aug 2012 12:13:35 +0200 (CEST) X-SFR-UUID: 20120822101335907.DD8CB7000091@msfrf2502.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-38-103511916 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 12:13:35 +0200 Message-Id: <6C4BAE4F-5DD8-4429-836A-9B74C88D0313@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@lap oste.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <26F61151-CBDA-457E-9906-1024B734E090@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:13:39 -0000 --Apple-Mail-38-103511916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 12:06, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 7:03 PM, R=E9mi Despr=E9s = wrote: > Not sure to understand the case.=20 > Are you suggesting that the /64 assigned to a CLAT node is also a = prefix valid on the upstream link? >=20 > Yes, because GangChen was referring to the Proxy ND RFC, and that's = the basic scenario covered in that RFC. Proxy ND is a tool that excludes addresses other than that or those = configured on the considered link. Using it to exclude the CLAT WAN-side address can therefore be = understood without suggesting that a provider assigns several addresses = on a /64 it has assigned to one of its customers. RD= --Apple-Mail-38-103511916 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 7:03 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
Not sure to understand the = case. 
Are you suggesting that the /64 assigned to a CLAT = node is also a prefix valid on the upstream = link?

Yes, because GangChen was referring to the Proxy ND RFC, = and that's the basic scenario covered in that RFC.

Proxy ND is a tool that excludes = addresses other than that or those configured on the considered = link.
Using it to exclude the CLAT WAN-side address can = therefore be understood without suggesting that a provider assigns = several addresses on a /64 it has assigned to one of its = customers.

RD
= --Apple-Mail-38-103511916-- From despres.remi@laposte.net Wed Aug 22 03:21:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5821F8668 for ; Wed, 22 Aug 2012 03:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGvHi1P87XYg for ; Wed, 22 Aug 2012 03:21:44 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB221F863B for ; Wed, 22 Aug 2012 03:21:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id BF3157000091; Wed, 22 Aug 2012 12:21:43 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id 18E5870000BA; Wed, 22 Aug 2012 12:21:43 +0200 (CEST) X-SFR-UUID: 20120822102143102.18E5870000BA@msfrf2502.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-39-103999148 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 12:21:42 +0200 Message-Id: <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:21:45 -0000 --Apple-Mail-39-103999148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 12:04, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 6:59 PM, R=E9mi Despr=E9s = wrote: > You seem interested in pursuing this example where a CLAT would be = activated on a dual-stack private network (i.e. out of scope for = 464XLAT), behind a CLAT that, as requested by the draft, is activated on = an IPv6-only network. >=20 > I'm just pointing out a situation where a reserved IID can cause a = problem. You may call it a problem that's out of scope; I call it = robust. > =20 > 2. Unless you insist, I would be glad to stop spending time on this = case. It is too far from the question at hand: is there any good reason = to prohibit those for whom it is useful to use a reserved CLAT IID?=20 >=20 > The fundamental problem is that I don't see where there is a use for a = reserved IID. Good. This is different from suggesting that it would break something = that should work.=20 Yes, you and some others haven't seen such a use, but some others have = identified such use for quite some time, as reflected the current draft. Since the IID reservation doesn't hurt you in any way, time might be = saved if you could just accept it with a MAY making its use optional. This seems to me normal IETF consensus approach. RD =20 --Apple-Mail-39-103999148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 6:59 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
You seem interested in pursuing = this example where a CLAT would be activated on a dual-stack private = network (i.e. out of scope for 464XLAT), behind a CLAT that, as = requested by the draft, is activated on an IPv6-only network.

I'm just pointing out a situation = where a reserved IID can cause a problem. You may call it a problem = that's out of scope; I call it robust.
 
2. Unless you insist, I would = be glad to stop spending time on this case. It is too far from the = question at hand: is there any good reason to prohibit those for = whom it is useful to use a reserved CLAT IID? 

The fundamental problem is that I = don't see where there is a use for a reserved IID.

Good. This is different from suggesting that = it would break something that should work. 

Yes, = you and some others haven't seen such a use, but some others have = identified such use for quite some time, as reflected the current = draft.
Since the IID reservation doesn't hurt you in any way, = time might be saved if you could just accept it with a MAY making its = use optional.
This seems to me normal IETF consensus = approach.

RD
  

= --Apple-Mail-39-103999148-- From shemant@cisco.com Wed Aug 22 03:27:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14E21F8668 for ; Wed, 22 Aug 2012 03:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJnTz5eYJRoP for ; Wed, 22 Aug 2012 03:27:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D03BB21F8650 for ; Wed, 22 Aug 2012 03:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6893; q=dns/txt; s=iport; t=1345631249; x=1346840849; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KBVcN/qqOCrDJ1LHqLZ5uZTdSsla+s53uK6HY6SlTvA=; b=lTxS0W752OySVTivg3RGONtyflXisG7fXwDmAth6tSfM15JUx9vhAI0P cZUNTfb5MZsga/7Cxrmp3L0DO7kVOCLpkEu5ORnK/NdF2i9z8s1H3y8rE lEi6/LC81Zqw67LSPNx7dbPQShhZx8tjUcPNqsoK5IJ6KwYfeGYjoSxrH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFuzNFCtJV2Y/2dsb2JhbABFgkq3doEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBqHa5lToE+LCIY8YAOIGptlgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208,217";a="111094298" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 22 Aug 2012 10:27:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7MART0t011957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 10:27:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 05:27:28 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt Thread-Index: AQHNgE3XkSzjbj7hrkSKW/KJE6ZKcZdlnrZg Date: Wed, 22 Aug 2012 10:27:27 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890741E3@xmb-rcd-x06.cisco.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <26F61151-CBDA-457E-9906-1024B734E090@laposte.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.67] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.005 x-tm-as-result: No--33.471500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B890741E3xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: "Bjoern A. Zeeb" , "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:27:34 -0000 --_000_75B6FA9F576969419E42BECB86CB1B890741E3xmbrcdx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: Wednesday, August 22, 2012 6:06 AM To: R=E9mi Despr=E9s Cc: Bjoern A. Zeeb; v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt >Yes, because GangChen was referring to the Proxy ND RFC, and that's the ba= sic scenario covered in that RFC. Maybe we just have a terminology issue. When we speak of Proxy ND we are t= alking about a DAD Proxy and not an ND Proxy? Please note ND Proxy is not a completely solved problem and that is why RFC= 4389 is an Experimental RFC. Erik Nordmark noted some issues in the past = with RFC 4389. "Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in essen= ce forwards IP (ND) packets without decrementing ttl, which can lead to cat= astrophic loops. The RFC tries to ameliorate that by detecting loops. Howev= er, the loop detection is based on receiving RAs (with the P-bit) which han= dles some cases. But it isn't robust against somebody connecting what was t= wo Ethernet segments after ND proxy has sent its two P-bit RAs." Hemant --_000_75B6FA9F576969419E42BECB86CB1B890741E3xmbrcdx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Wednesday, August 22, 2012 6:06 AM
To: R=E9mi Despr=E9s
Cc: Bjoern A. Zeeb; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt

 

 

>Yes, becaus= e GangChen was referring to the Proxy ND RFC, and that's the basic scenario= covered in that RFC.

 <= /p>

Maybe we just have a terminology issue.=   When we speak of Proxy ND we are talking about a DAD Proxy and not a= n ND Proxy?

 <= /p>

Please note ND Proxy is not a comple= tely solved problem and that is why RFC 4389 is an Experimental RFC.  = Erik Nordmark noted some issues in the past with RFC 4389.

 

“Issues with RFC 4389 such as = weakness in loop avoidance. ND proxy in essence forwards IP (ND) packets without decrement= ing ttl, which can lead to catastrophic loops. The RFC tries to ameliorate = that by detecting loops. However, the loop detection is based on receiving RAs (with the P-bit) which handles some cases. But it i= sn't robust against somebody connecting what was two Ethernet segments afte= r ND proxy has sent its two P-bit RAs.”

 <= /p>

Hemant

--_000_75B6FA9F576969419E42BECB86CB1B890741E3xmbrcdx06ciscocom_-- From lorenzo@google.com Wed Aug 22 03:31:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D940C21F84FB for ; Wed, 22 Aug 2012 03:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.744 X-Spam-Level: X-Spam-Status: No, score=-102.744 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBMUQNboN7rE for ; Wed, 22 Aug 2012 03:31:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEDF21F84F9 for ; Wed, 22 Aug 2012 03:31:13 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1372066obb.31 for ; Wed, 22 Aug 2012 03:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=+NdszDGWUdoWaj/Y3O1Ee/1xMmirW+vWmv1ZNg5JYTs=; b=IB1TK6T4QeBgwiaToYyXrr3lqXr8MFx9xPAr3UYOmcK0B+6TSXtaHdm/62+3LNHx/n Xz0Tl9u2XV+s8VOA2VETszDqYadoYaQOzEsljdUYLDn7SjktRmyvyCNsnvGsucGaPIE4 X7HvckLDbXpIkD1sxvsQdCwY8BcFTmHNjMbKxkNVxVNE0qj7nXuJfmWANsAAg5jl+UrS PxWTYfxzQg9GucJ4HgONcCF63QZxgYzmqMOnlszY0PsvDDABKPAVfZyGRNr+JetJ/ZMm 4PT4nVMbPn5MyOrL3clmz9jjZ+EEGOAnjNiGhkB2/2P+DTLnXcrZXRS7A/f1CX9DxPrB ks6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=+NdszDGWUdoWaj/Y3O1Ee/1xMmirW+vWmv1ZNg5JYTs=; b=kDy5hLz+WKlKf/XcDrVkuVssOLtOoL8lp8TWLXX0bVi7iTlZGJfhsUZo12k2Y+V5gv oO7r7IhUYGa2xBhEnLbMJbvh7I4oX0E0Yy4+7XJtliq9EsVD5E0k/zNiHkELQd6hlBPI YQRvbj+6a8+RGB6IveUGEsXAlcFZtAwqsmgw+wYeqGUGhVpAV+NMY4fVB8IuNM/gobDV 6+4ZTB/luTOFsAZbA7W5QX6QcpIko9kbxp8OvCu+tSGblvaokSHuFufCbAIoMkifw/ru 7fUCQ3T4ksc/JL1HgiKJNJRzGoiAsKPLFu6q85dSUdia9weWQqP4EdpXeBIbT7GhtqIB s8SA== Received: by 10.182.89.66 with SMTP id bm2mr15446714obb.87.1345631472753; Wed, 22 Aug 2012 03:31:12 -0700 (PDT) Received: by 10.182.89.66 with SMTP id bm2mr15446705obb.87.1345631472656; Wed, 22 Aug 2012 03:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 03:30:52 -0700 (PDT) In-Reply-To: <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> From: Lorenzo Colitti Date: Wed, 22 Aug 2012 19:30:52 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04479f7ded1f9d04c7d83ddc X-System-Of-Record: true X-Gm-Message-State: ALoCoQkTviHJ8qm9oWnz2i/PXXKP0gNb6S7j8+15VOIbDAGVYU9KlD750kzJZ/Py45MQd4C24TcOjbWWmnr/ceN/mSMUmsKMcpxt5cadcrP7FWwD0DDnL8rrnYHg/bAS7nUtSRKw0n6gM6VPr7oOxumuNO9urzO8suJ82SV2Pq637BfgpJnfkYRSuFYbvA/7bp2l5KlhQMm6 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:31:14 -0000 --f46d04479f7ded1f9d04c7d83ddc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 7:21 PM, R=E9mi Despr=E9s wrote: > Yes, you and some others haven't seen such a use, but some others have > identified such use for quite some time, as reflected the current draft. > The only thing I see in the current draft is: If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID I think this text is incorrect for the reasons I listed above: if you have a p2p upstream link you don't need to perform ND proxying, and if you don't have a p2p upstream link, either you perform ND proxying or things break pretty badly. Therefore, I think it should be removed. If that text is removed, is there any other reason to reserve an IID? --f46d04479f7ded1f9d04c7d83ddc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 7:21 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
Yes, you and some others haven'= ;t seen such a use, but some others have identified such use for quite some= time, as reflected the current draft.

The only thing I see in the current draft is:

=A0 =A0 If the CLAT cannot perform ND Proxy [RFC4389] due to the rest= riction
=A0 =A0of the implementation, the CLAT may use a dedicate= d IANA assigned
=A0 =A0EUI-64 ID

I think this text is i= ncorrect for the reasons I listed above: if you have a p2p upstream link yo= u don't need to perform ND proxying, and if you don't have a p2p up= stream link, either you perform ND proxying or things break pretty badly. T= herefore, I think it should be removed.

If that text is removed, is there any other reason to r= eserve an IID?
--f46d04479f7ded1f9d04c7d83ddc-- From phdgang@gmail.com Wed Aug 22 04:39:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E37721F8681 for ; Wed, 22 Aug 2012 04:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epMWDlr7gTgi for ; Wed, 22 Aug 2012 04:39:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E521F861C for ; Wed, 22 Aug 2012 04:39:46 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1005087vbb.31 for ; Wed, 22 Aug 2012 04:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LK0krZ/TsBTafC1xaEiuhhUQZXxR8+LFqKjClrjRHdU=; b=RVLsMSOMnExoBfLwIZBSEPRPiiFHMvEq6lvfmv19JN6mNRPsGZbF15oi/nBLH4Y9VM mgR4zZcy8hv6JjLTikJJB1Ukzpvxrin9z30PbUXOZTAXKisDsb3e+/hBvKa4CPaF8flp HpLH/GfWff8oupUJk5RyEDOSvkuKncsRb8pehrMdd0lmfbYR30LjaefN2X9IpNMJDdy6 5pb9eFSPw6qhAgzcqZP57JlxDTkCQAvHSkRs9RBiOG8s3vLntqr6HvXIEQOTj4lejWKo eBLMszxd6TLCU4OZrCZAH8wy72CXOE4c/HGvxmYHv3cyqbhEd/u9sQZlAauQ+ItdE8t+ FOTQ== MIME-Version: 1.0 Received: by 10.52.92.169 with SMTP id cn9mr10937475vdb.72.1345635582437; Wed, 22 Aug 2012 04:39:42 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 22 Aug 2012 04:39:42 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Wed, 22 Aug 2012 19:39:42 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:39:47 -0000 2012/8/22, Lorenzo Colitti : > On Wed, Aug 22, 2012 at 4:21 PM, GangChen wrote: > >> > What about the collision between the CLAT and the hosts behind it? It >> > can not be guaranteed that the IPv6 address derived from so-called >> > reserved EUI-64 ID would not be used by any host behind the CLAT. >> > I.e., DAD is not avoidable. >> >> Avoiding DAD may not the point of reserved IID. A main advantage is to >> fit the case where CLAT cannot perform ND Proxy. This was already >> documented in the draft-07. > > > Actually, I think a reserved IID does not help. Rationale: > > 1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then > the CLAT does not need to perform ND proxying at all in order to provide > its clients with connectivity. All it needs to do is claim an IPv6 address > from the /64 and enable IPv6 forwarding. Would the purpose of "claim an IPv6 address" exclude the CLAT WAN-side address (More precisely it is IPv6 address on a virtual interface) ? > The important thing is not > proxying, but defending the address against DAD. > > 2. If the CLAT's upstream interface is not point-to-point, and the CLAT > doesn't perform ND proxying, then connectivity is broken anyway. Nodes on > the upstream interface and nodes on the downstream are on the same /64, but > they can't reach each other. So you already have a much bigger problem than > IID collisions, and a reserved IID will not fix it. > From despres.remi@laposte.net Wed Aug 22 04:59:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B64621F86AA for ; Wed, 22 Aug 2012 04:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sCxyPb8P4iY for ; Wed, 22 Aug 2012 04:59:02 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 110D921F8624 for ; Wed, 22 Aug 2012 04:59:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 54671700012B; Wed, 22 Aug 2012 13:59:00 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 3B2D47000129; Wed, 22 Aug 2012 13:58:59 +0200 (CEST) X-SFR-UUID: 20120822115859242.3B2D47000129@msfrf2401.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-40-109831167 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Aug 2012 13:58:54 +0200 Message-Id: <2E0D0DFC-2EDC-44D3-97E7-AAF5198DC4FB@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@lap oste.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:59:03 -0000 --Apple-Mail-40-109831167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-22 =E0 12:30, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 7:21 PM, R=E9mi Despr=E9s = wrote: > Yes, you and some others haven't seen such a use, but some others have = identified such use for quite some time, as reflected the current draft. >=20 > The only thing I see in the current draft is: >=20 > If the CLAT cannot perform ND Proxy [RFC4389] due to the = restriction > of the implementation, the CLAT may use a dedicated IANA assigned > EUI-64 ID >=20 > I think this text is incorrect for the reasons I listed above: if you = have a p2p upstream link you don't need to perform ND proxying, and if = you don't have a p2p upstream link, either you perform ND proxying or = things break pretty badly. Therefore, I think it should be removed. >=20 > If that text is removed, is there any other reason to reserve an IID? 1. As said in particular in my answer to James Woodyatt: 'In my understanding, all valid technical concerns that have been = expressed are covered if, in section 8.3.2, the first part of the = following sentence is deleted: "If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of = the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID = for creating a translated IPv6 address to be used in stateless = translation [RFC6145]."' 2. The next sentence in the draft gives this reason: "This will allow the CLAT to avoid possible IPv6 address duplication = issues between an IPv6 address for stateless translation [RFC6145] in = the CLAT and an IPv6 address assigned to native IPv6 nodes behind the = CLAT."=20 This is IMHO clear enough. (Could be editorially improved with s/an IPv6 = address/the IPv6 address/ and s/native IPv6 nodes/a native IPv6 node/ RD --Apple-Mail-40-109831167 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 7:21 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
Yes, you and some others = haven't seen such a use, but some others have identified such use for = quite some time, as reflected the current = draft.

The only thing I see in the current draft = is:

    If the CLAT cannot = perform ND Proxy [RFC4389] due to the restriction
  =  of the implementation, the CLAT may use a dedicated IANA = assigned
   EUI-64 ID

I think this = text is incorrect for the reasons I listed above: if you have a p2p = upstream link you don't need to perform ND proxying, and if you don't = have a p2p upstream link, either you perform ND proxying or things break = pretty badly. Therefore, I think it should be removed.

If that text is removed, is there any other reason = to reserve an IID?

1. As said in particular in my answer to = James Woodyatt:
'In my understanding, all valid = technical concerns that have been expressed are covered if, in section = 8.3.2, the first part of the following sentence is deleted:"If the CLAT cannot perform ND Proxy [RFC4389] due to the = restriction of the implementation, the CLAT may use a dedicated IANA = assigned EUI-64 ID for creating a translated IPv6 address to be used in = stateless translation [RFC6145]."'
2. The next sentence in the draft = gives this reason:
"This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 = address for stateless translation [RFC6145] = in the CLAT and an IPv6 address assigned to = native IPv6 nodes behind the CLAT." 
This is IMHO clear enough. (Could be editorially improved = with s/an IPv6 address/the IPv6 address/ and s/native = IPv6 nodes/a native IPv6 node/


, v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 13:10:27 -0000 On 8/22/12 3:21 AM, Rémi Després wrote: > > Since the IID reservation doesn't hurt you in any way, time might be > saved if you could just accept it with a MAY making its use optional. It is not clear to me why you would reserve something that you don't need. I have to wonder what the IESG will thing of that. From despres.remi@laposte.net Wed Aug 22 07:06:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFBF21F854E for ; Wed, 22 Aug 2012 07:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi7QUZz0Q9O8 for ; Wed, 22 Aug 2012 07:06:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 99FAD21F83EF for ; Wed, 22 Aug 2012 07:06:18 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4585C940149; Wed, 22 Aug 2012 16:06:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5034DA3F.8010302@bogus.com> Date: Wed, 22 Aug 2012 16:06:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88878424-914F-4BF9-AF53-6F1EB09874A1@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <50 34DA3F.8010302@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:06:21 -0000 Hi, Joel, 2012-08-22 15:10, joel jaeggli : > On 8/22/12 3:21 AM, R=E9mi Despr=E9s wrote: >>=20 >> Since the IID reservation doesn't hurt you in any way, time might be = saved if you could just accept it with a MAY making its use optional. >=20 > It is not clear to me why you would reserve something that you don't = need. I have to wonder what the IESG will thing of that. The sentence you answer here was preceded by "you and some others = haven't seen such a use, but some others have identified such use for = quite some time, as reflected the current draft".=20 This partial answer was expected to be sufficient in the context of what = I was answering myself, but here is a self contained answer explaining = what we need: 1. The draft itself explains, about the "IANA assigned EUI-64 ID": "This = will allow the CLAT to avoid possible IPv6 address duplication issues = between an IPv6 address for stateless translation [RFC6145] in the CLAT = and an IPv6 address assigned to native IPv6 nodes behind the CLAT". 2. The proposed alternative, i.e. using DAD to deal with these = duplications isn't a complete solution, in particular because a = conflicting local-scope IID may have been assigned before 464XLAT is = activated. Recommending to be on the safe side by using this IID is = therefore arguably the right approach.=20 Yet, it is a fact that some WG members want freedom of doing only DAD. = This is why the NEED is limited to _permitting_ what some others see as = the safe approach. =20 3. Secondarily, implementations using the CLAT-reserved IID can arguably = be considered simpler than without it. (There is apparently no consensus = on this, but no consensus to the opposite either.) Hope it clarifies. Regards, RD From tom.taylor.stds@gmail.com Wed Aug 22 09:03:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D3A21F8592 for ; Wed, 22 Aug 2012 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrlPxWOgUFrq for ; Wed, 22 Aug 2012 09:03:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6D21F8574 for ; Wed, 22 Aug 2012 09:03:36 -0700 (PDT) Received: by ghbg16 with SMTP id g16so869826ghb.31 for ; Wed, 22 Aug 2012 09:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=ZhodW71d5s50hqsYaNju9cRENkQ8gqjPNoCWOOYHF8A=; b=tOFsMxVK2+OmZ/nZi3Apkwgu7KJzpoObG3p43BiVA7fG+k2/S4qa/FdSpO6ljNLF2w sobCQrY3teWhMkg71uPA0DpK6o+PohtypMjubqmE4MTdsloVp0If9m2IkZ82Q+kXoIAE 8w/QQ30zlAvJ6YHgan6qKTgnN/fhGXXEJWJ3wG0jfDl4yGMY3xB5ry3G+q2mxnZigzPs pgiPX5wy7wxv/TCKsujqzyCIbUhlC4UGM6phfesr9fgZiFyHheyRECmxNq5n83TykplV 0OhGW8A0eQwwx6txh4OJQ0Ha/brdVJ9mcXWgamUT9wsUoXEfC3Fawf2ZnRX0WBM60wh6 BrbQ== Received: by 10.50.152.141 with SMTP id uy13mr2683288igb.64.1345651415932; Wed, 22 Aug 2012 09:03:35 -0700 (PDT) Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id i2sm15253444igl.8.2012.08.22.09.03.33 (version=SSLv3 cipher=OTHER); Wed, 22 Aug 2012 09:03:34 -0700 (PDT) Message-ID: <503502D4.8050907@gmail.com> Date: Wed, 22 Aug 2012 12:03:32 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> In-Reply-To: <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120821-0, 21/08/2012), Outbound message X-Antivirus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:03:38 -0000 The normal IETF consensus approach is "rough consensus", not total consensus. I say again, if you are willing to make your reserved IID a MAY, it is definitely an option, and easily accommodated by a separate draft. That way the main draft is cleaner. On 22/08/2012 6:21 AM, Rémi Després wrote: > ...> Yes, you and some others haven't seen such a use, but some others have identified such use for quite some time, as reflected the current draft. > Since the IID reservation doesn't hurt you in any way, time might be > saved if you could just accept it with a MAY making its use > optional. This seems to me normal IETF consensus approach. > > RD > > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Wed Aug 22 09:25:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0535B21F85C4 for ; Wed, 22 Aug 2012 09:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3W6+ry2lwW6 for ; Wed, 22 Aug 2012 09:25:54 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 21BA221F84C4 for ; Wed, 22 Aug 2012 09:25:52 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id D9C32940134; Wed, 22 Aug 2012 18:25:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <503502D4.8050907@gmail.com> Date: Wed, 22 Aug 2012 18:25:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <50 3502D4.8050907@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:25:55 -0000 Le 2012-08-22 =E0 18:03, Tom Taylor a =E9crit : > The normal IETF consensus approach is "rough consensus", not total = consensus. Clear to all of us, I think. > I say again, if you are willing to make your reserved IID a MAY, it is = definitely an option, and easily accommodated by a separate draft. This seems to mean that, at least, you have no technical objection. > That way the main draft is cleaner. Different view. Leaving room for ill controlled consequences in case of unlikely but = possible collisions, and avoiding to document in the draft itself the = known way to avoid "possible IPv6 address duplication issues between an = IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 = address assigned to native IPv6 nodes behind the CLAT" wouldn't make the = draft any cleaner. (Trying to hide information by having it in a different place doesn't = help RFC readers to understand what IETF is doing, IMHO.) RD =20 >=20 > On 22/08/2012 6:21 AM, R=E9mi Despr=E9s wrote: >>=20 > ...> Yes, you and some others haven't seen such a use, but some others > have identified such use for quite some time, as reflected the current > draft. >> Since the IID reservation doesn't hurt you in any way, time might be >> saved if you could just accept it with a MAY making its use >> optional. This seems to me normal IETF consensus approach. >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 From tom.taylor.stds@gmail.com Wed Aug 22 09:33:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C85121F8534 for ; Wed, 22 Aug 2012 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSnwG2nUmkQV for ; Wed, 22 Aug 2012 09:33:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E60CA21F851B for ; Wed, 22 Aug 2012 09:33:36 -0700 (PDT) Received: by iabz21 with SMTP id z21so1143541iab.31 for ; Wed, 22 Aug 2012 09:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=ubcNziSDEfLnQhF1r2QDK9snTXy4hGhBbBBot1lNwZM=; b=xWtiQSy+dS+Csrubq7LISJJDRGXKIMkYZ0lTnJnLa8C2Fuazk666Il3dP1+PDlJPMy dFyrGwGqzXv/bG0Bxf1JUg/MYR/FcTa6w5wOvUC8g2xYRAAcCSatvpFkYeyNoTYcALu5 tOMOJ1NmNhexYieWzrOepyhi/RW8NBLWbHr3em5mrdZJdfMX301Qr8yzVWncxxY/W7HX xvEerV/5HJCXhLbn2OtX05TI0sQIcueE8lfPJv78zfzdzWlQg1Z88j5N/fZqei9TUOP/ XHge0k5VMzt6teV2bINN7N5vO6zoEbbY/y1H0/j5/kVi44TfwBcaMTkXy85Gbb7wR6oK e+sg== Received: by 10.42.54.133 with SMTP id r5mr17859043icg.9.1345653216392; Wed, 22 Aug 2012 09:33:36 -0700 (PDT) Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id p5sm9233227igm.13.2012.08.22.09.33.34 (version=SSLv3 cipher=OTHER); Wed, 22 Aug 2012 09:33:35 -0700 (PDT) Message-ID: <503509DD.3010102@gmail.com> Date: Wed, 22 Aug 2012 12:33:33 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?windows-1252?Q?R=E9mi_Despr=E9s?= References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <50 3502D4.8050907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120821-0, 21/08/2012), Outbound message X-Antivirus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:33:37 -0000 On 22/08/2012 12:25 PM, Rémi Després wrote: > > Le 2012-08-22 à 18:03, Tom Taylor a écrit : > ... > > This seems to mean that, at least, you have no technical objection. > ... [PTT] The technical objection is that you are introducing brittleness by specifying a well-known IID. There are circumstances (already described and potentially lurking) where that can cause trouble. From despres.remi@laposte.net Wed Aug 22 09:39:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8121F8652 for ; Wed, 22 Aug 2012 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P54Za5tuCHXc for ; Wed, 22 Aug 2012 09:39:38 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id C549321F8630 for ; Wed, 22 Aug 2012 09:39:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id 78BF67000061; Wed, 22 Aug 2012 18:39:37 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id 2160C700005D; Wed, 22 Aug 2012 18:39:37 +0200 (CEST) X-SFR-UUID: 20120822163937136.2160C700005D@msfrf2507.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <503509DD.3010102@gmail.com> Date: Wed, 22 Aug 2012 18:39:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <50 3502D4.8050907@gmail.com> <503509DD.3010102@gmai l.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:39:39 -0000 Le 2012-08-22 =E0 18:33, Tom Taylor a =E9crit : >=20 > On 22/08/2012 12:25 PM, R=E9mi Despr=E9s wrote: >>=20 >> Le 2012-08-22 =E0 18:03, Tom Taylor a =E9crit : >>=20 > ... >=20 >>=20 >> This seems to mean that, at least, you have no technical objection. >>=20 > ... > [PTT] The technical objection is that you are introducing brittleness = by specifying a well-known IID. There are circumstances (already = described and potentially lurking) where that can cause trouble. None of these "circumstances" has been documented to a point where it = could be understood. AFAIK, they don't exist. RD From jhw@apple.com Wed Aug 22 10:54:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1621F8624 for ; Wed, 22 Aug 2012 10:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.409 X-Spam-Level: X-Spam-Status: No, score=-110.409 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-mRUgDp1Whu for ; Wed, 22 Aug 2012 10:54:58 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3122821F8569 for ; Wed, 22 Aug 2012 10:54:58 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M96009HM3XCRNV1@mail-out.apple.com> for v6ops@ietf.org; Wed, 22 Aug 2012 10:54:57 -0700 (PDT) X-AuditID: 11807130-b7f9b6d000000bad-d8-50351cf1b68b Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 73.42.02989.1FC15305; Wed, 22 Aug 2012 10:54:57 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M96005GN4FKSS20@spicerack.apple.com> for v6ops@ietf.org; Wed, 22 Aug 2012 10:54:57 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <9BCD592E-5E00-48BB-AA58-7DE3F3CFFAFB@laposte.net> Date: Wed, 22 Aug 2012 10:54:55 -0700 Content-transfer-encoding: quoted-printable Message-id: <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> To: =?windows-1252?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FCsoftRxjTA4O9+HYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+VXM2vBGbaKNT9PszcwLmTtYuTkkBAwkfhw+TMbhC0mceHe eiCbi0NIYAaTxO1Xp1kgnDlMEl2HGphBqoQFAiQ+Ne4DSnBwMAvoSdy/qAUS5gUyL9x7xwhR 4iCxfmYL2AI2ARWJb5fvMoHYnAL2EnMfPwCLswioSqw8tQYsziygIfH5xi8WCFtb4sm7C6wQ M20kbi/+BXXQJ3aJ9+/72EH2igg4Sbz57Q1xtKzE98Pn2SYwCs5CuGgWkotmIZm6gJF5FaNg UWpOYqWhoV5iQUFOql5yfu4mRnBAFhrsYFz7k/8QowAHoxIPr0WQSYAQa2JZcWXuIUYJDmYl Ed5ANtMAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxBvEApgfTEktTs1NSC1CKYLBMHp1QDY53H hVCJRp+f/opb8wUO7nEz3CNhNKPsTwCbxrY5BtniTXdnqn49JD1r1bVd92peT3T4I+N6mj84 8Fg5Z/DRv03KAt7vZYs5Vurtsck4/Sx64r9d191/LM5aczrk5GbeDW+nrn6/vu1KLcuCH7nr xOMYvkTrZfgsEyj6LbJS3JSzi5391Nbjs5RYijMSDbWYi4oTAbmpvFFEAgAA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 17:54:58 -0000 On Aug 22, 2012, at 01:05 , R=E9mi Despr=E9s = wrote: >=20 > This permits your implementation to ignore the CLAT-assigned IID, if = you so wish, and permits implementations that take advantage of it. Here's my concern. Do I need to modify all my host implementations that = don't know anything about 464XLAT=97- and hopefully will never need to = know anything about them-- so that they disallow manual configuration of = the IID reserved by IANA for this purpose? If so, then that's a price = that I think is far too high for this draft to ask to be paid by every = IPv6 host implementation in the world that might ever find itself behind = a 464XLAT router, and I would oppose publication for that reason. -- james woodyatt member of technical staff, core os networking From v6ops@globis.net Wed Aug 22 11:49:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CF421F860D for ; Wed, 22 Aug 2012 11:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxz4XCBmbAL3 for ; Wed, 22 Aug 2012 11:49:02 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAA121F860B for ; Wed, 22 Aug 2012 11:49:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 197BC8700AB; Wed, 22 Aug 2012 20:48:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWnN32itOBNz; Wed, 22 Aug 2012 20:48:17 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 48006870089; Wed, 22 Aug 2012 20:48:17 +0200 (CEST) Message-ID: <5035296B.6010201@globis.net> Date: Wed, 22 Aug 2012 20:48:11 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: james woodyatt References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> In-Reply-To: <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:49:03 -0000 The proposed reservation is already taken from an existing IANA reserved range of Modified EUI-64 from rfc5342#section-2.2.2 Dumb question: why would you have to take any (new) special action due to publication of 464xLAT? Presumably you already protect against manually assigning these accidentally? james woodyatt wrote: > On Aug 22, 2012, at 01:05 , Rémi Després wrote: >> This permits your implementation to ignore the CLAT-assigned IID, if you so wish, and permits implementations that take advantage of it. > > Here's my concern. Do I need to modify all my host implementations that don't know anything about 464XLAT—- and hopefully will never need to know anything about them-- so that they disallow manual configuration of the IID reserved by IANA for this purpose? If so, then that's a price that I think is far too high for this draft to ask to be paid by every IPv6 host implementation in the world that might ever find itself behind a 464XLAT router, and I would oppose publication for that reason. > > > -- > james woodyatt > member of technical staff, core os networking > > > > From jhw@apple.com Wed Aug 22 12:21:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF42621F8650 for ; Wed, 22 Aug 2012 12:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbExbVDv2ZGM for ; Wed, 22 Aug 2012 12:21:39 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 19D2521F85EA for ; Wed, 22 Aug 2012 12:21:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M960044R8EYN2L4@mail-out.apple.com> for v6ops@ietf.org; Wed, 22 Aug 2012 12:21:38 -0700 (PDT) X-AuditID: 11807136-b7f6b6d00000741d-e7-50353142917f Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 1A.E6.29725.24135305; Wed, 22 Aug 2012 12:21:38 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by orrisroot.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M96009NG8G12910@orrisroot.apple.com> for v6ops@ietf.org; Wed, 22 Aug 2012 12:21:37 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <5035296B.6010201@globis.net> Date: Wed, 22 Aug 2012 12:21:37 -0700 Message-id: <3F09A058-1C74-4C14-AF3E-F68033972FD0@apple.com> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> <5035296B.6010201@glo> To: Ray Hunter X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FCcpetkaBpg8HemnMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8evjOtaCpewVE7ouMzYwvmLtYuTkkBAwkdi1+TQLhC0mceHe erYuRi4OIYGZTBLPDu1ggnDmMEks+d4PViUsECDxqXEfkM3BwSygJ3H/ohZImBfIvHDvHSNE iYPE+pktYAvYBFQkvl2+ywRicwpoSTyf/RRsDIuAqsTZ/U1g9cwCWRLdWzayQ9jaEk/eXWAF Gc8rYCPReIUL4oR2Dol15zrB5ogIKEpM//eFCeJoWYnvh8+zTWAUnIVw0SwkF81CMnUBI/Mq RsGi1JzESkNTvcSCgpxUveT83E2M4IAsNNvBuOOv3CFGAQ5GJR5eiyCTACHWxLLiytxDjBIc zEoivIFspgFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeUvVgVIC6YklqdmpqQWpRTBZJg5OqQZG 28LK2UW/3LumM2pLrXDc6Oviayi2v3fG7kMfHNv4797R3H9tls+2Gey/18kxhPs1bY1syTu1 /7F1nWSj+6PD+f9s+bc9X78o0ni1eY26+B95rsdTAjMM/pt/rX4f6q5dn7fO0F15nU+1v8K8 3x5MmcHshxxkQybIWL3k9irdpj61+E/QqywlluKMREMt5qLiRAB3D4H5RAIAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:21:41 -0000 On Aug 22, 2012, at 11:48 , Ray Hunter wrote: > > Dumb question: why would you have to take any (new) special action due to publication of 464xLAT? Stupid answer: now that I have been made properly aware of this reserved IID range, I suppose my technical concern is already addressed. Still, I remain unpersuaded on procedural grounds, because it seems to me that consumption of this reserved IID in a BCP is not well justified by the objective of accommodating the peculiar limitations of a certain platform architecture. Rather, I should think that best current practice would be to fix the platform to remove the limitation, no? > Presumably you already protect against manually assigning these accidentally? One might presume. I'll have to check. Separable problem, I guess. -- james woodyatt member of technical staff, core os networking From joelja@bogus.com Wed Aug 22 15:56:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE121F8673; Wed, 22 Aug 2012 15:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiSM15zfBYl0; Wed, 22 Aug 2012 15:56:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3F32221F8650; Wed, 22 Aug 2012 15:56:39 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7MMubOi024895 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Aug 2012 22:56:38 GMT (envelope-from joelja@bogus.com) Message-ID: <503563A0.2060607@bogus.com> Date: Wed, 22 Aug 2012 15:56:32 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120815 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs , iesg-secretary@ietf.org, "ops-ads@tools.ietf.org" Content-Type: multipart/mixed; boundary="------------010806090909000207000601" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 22 Aug 2012 22:56:38 +0000 (UTC) Subject: [v6ops] v6ops interim meeting as part of the Sept 29th LIM Amsterdam Netherlands. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:56:40 -0000 This is a multi-part message in MIME format. --------------010806090909000207000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings folks, The commentary on our proposal was appreciated. The slot that IAD has allocated to us is: 1330 - 1630 CEST on the 29th of Sept 2012 I am aware so far, that opsec is planning to meet in the same location from 0900-1200 and the SIDR has an interim scheduled for the entire day that Saturday. While there are some details still to be worked out it's time to get the framework in place for the interim to coincide with the end of RIPE 65, Amsterdam, 24 - 28 September 2012. Location is: Hotel Okura Ferdinand Bolstraat 333 1072 LH Amsterdam +31 (0) 20 678 7493 I think we should plan to maintain an interim document submission deadline two weeks out from the meeting itself. Too be considered for inclusion in the interim agenda new or revised documented should be submitted to the IETF document system by 23:59 UTC on Sept 14th. Documents currently being hashed out on the list are certainly fair game for inclusion in the interim. I have attached the ical for the document-submission deadline to the meeting. Thanks Joel --------------010806090909000207000601 Content-Type: text/calendar; name="iCal-20120812-145046.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iCal-20120812-145046.ics" BEGIN:VCALENDAR CALSCALE:GREGORIAN VERSION:2.0 X-WR-CALNAME:V6ops Interim Meeting document submission deadline METHOD:PUBLISH PRODID:-//Apple Inc.//Mac OS X 10.8//EN BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU DTSTART:20070311T020000 TZNAME:PDT TZOFFSETTO:-0700 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0700 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU DTSTART:20071104T020000 TZNAME:PST TZOFFSETTO:-0800 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20120812T214712Z UID:A784AB91-4382-4D39-93C4-2B30B887CD7D DTEND;TZID=America/Los_Angeles:20120914T170000 TRANSP:OPAQUE SUMMARY:V6ops Interim Meeting document submission deadline DTSTART;TZID=America/Los_Angeles:20120914T165900 DTSTAMP:20120812T214906Z SEQUENCE:9 BEGIN:VALARM X-WR-ALARMUID:2E53CB93-179D-41F3-AC53-E77FB035A12D UID:2E53CB93-179D-41F3-AC53-E77FB035A12D TRIGGER:-PT15S X-APPLE-DEFAULT-ALARM:TRUE ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR --------------010806090909000207000601-- From lorenzo@google.com Wed Aug 22 18:35:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C677921F859A for ; Wed, 22 Aug 2012 18:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtID3j8sQZGY for ; Wed, 22 Aug 2012 18:35:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0A21F859C for ; Wed, 22 Aug 2012 18:35:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so583827obb.31 for ; Wed, 22 Aug 2012 18:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=R1fRFNEQnmp41iyvRJADXkHWc+fFFTWyIeJF+maY+Bo=; b=Z6ck2VJqmfro0KH6IzkSvaPrGEe4QsltpsVQGU0mq1RojuaGIHFhDDD+sfAlh4KMBM yCwjBRomCc8CXb7j4G8XqGI/qsf7sCmyLlaBv8uJIcQ6l0r0CyoGZmO6qBPl3uxvnEuM X6Xwjhv3IDzwVqVnfPVPk3aHn9jtHxnT+EQHdojlBK0yFhYDmBAhN+upwdQynWVMfGJn OX2KDYvaaLAG1FSbuNBUyWeY/1bnlZCVcnrqHxpNecjzVwueB6/uN4VyNwuqYAPMbqc0 aTGj5/FIVCiSUZI6RSBBfz/5iwyv79pdilJHdr0AJPhzB5+gkrO2CKD6EqIK1deWa1nO k/MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=R1fRFNEQnmp41iyvRJADXkHWc+fFFTWyIeJF+maY+Bo=; b=VIm/jyLOJzHp6xJLRwGpfKXkwHevlqULqsZHlGtLj9NjeQn5dDizhQzyGi0UyIjiip l+Fh1zEGstEBuRdk6/AtmozQl+gyukrYnKAIg8qqotJ0/QmkHwYm8D+R9m9QJLDSB2Gc iIdESNp3Oda5fDVOwCM0fK5iSF27LTjYs3Dy8C+tMF6u/jZHSVFrCaKazSjqxueASuz9 nf4l9Pj8GxET+TYZWyPewunMKorrPhcLEjwzmGq0yk3hP1+ONJeryOCkT0ZAWMNApckb OutFtHZ+jHC1RfTNDblmKIpGOb0fkHKgv7LmMAWHHrOpJs8RmHXzBL4ELOq7QegK3fXI glEw== Received: by 10.60.170.229 with SMTP id ap5mr16923260oec.101.1345685724450; Wed, 22 Aug 2012 18:35:24 -0700 (PDT) Received: by 10.60.170.229 with SMTP id ap5mr16923252oec.101.1345685724350; Wed, 22 Aug 2012 18:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Wed, 22 Aug 2012 18:35:04 -0700 (PDT) In-Reply-To: <88878424-914F-4BF9-AF53-6F1EB09874A1@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <88878424-914F-4BF9-AF53-6F1EB09874A1@laposte.net> From: Lorenzo Colitti Date: Thu, 23 Aug 2012 10:35:04 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=bcaec54b4ac094494604c7e4df93 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkyceI314ZkkR2/O7QxUxXtEJizu6cM3Et0qIG4ItPw9zjqSC9iTion5tPtuQzhwv+n/BO7gkhCZ5AHdvIwpxj6bOmII/LXSkidxZDI4enhnCGQsVRFAdsKbHYzMX2rlfpXyGWjgsuDN6iUiZEodHMPis2M1y1Nj/yJ2NOcbTcfLNCgY7Q8xdow7vtEozUtf179U3kV Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 01:35:25 -0000 --bcaec54b4ac094494604c7e4df93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 11:06 PM, R=E9mi Despr=E9s wrote: > here is a self contained answer explaining what we need: > Ok, so let me parse this out clearly so we're sure we're all discussing the same thing. > 1. The draft itself explains, about the "IANA assigned EUI-64 ID": "This > will allow the CLAT to avoid possible IPv6 address duplication issues > between an IPv6 address for stateless translation [RFC6145] in the CLAT a= nd > an IPv6 address assigned to native IPv6 nodes behind the CLAT". > Ok. So this point is not an argument in support of the reserved IID solution. It's a problem statement. What it says is, "we need to avoid address duplication issues between the CLAT and its clients." It doesn't advocate a particular solution. Both DAD and a reserved interface IDs are solutions. (I would argue that a reserved IID is much more brittle, and requires needless red tape, so it's a worse solution, but let's ignore that point for now.) We all agree that this is a problem statement; we only disagree on how to solve it. So there's no need to discuss this point further. 2. The proposed alternative, i.e. using DAD to deal with these duplications > isn't a complete solution, in particular because a conflicting local-scop= e > IID may have been assigned before 464XLAT is activated. Recommending to b= e > on the safe side by using this IID is therefore arguably the right approa= ch. > Ok, so this is your argument #1. 3. Secondarily, implementations using the CLAT-reserved IID can arguably be > considered simpler than without it. (There is apparently no consensus on > this, but no consensus to the opposite either.) > Ok. So this is your argument #2. In summary, you're arguing that a reserved ID is necessary for two reasons: 1. If you don't have a reserved IID, the CLAT might not be able to provide service to a client, since that client might already have formed an IPv6 address using that IID. 2. If you use a reserved IID, it simplifies implementation. Do you agree that this is a summary of your arguments for using a reserved IID? If so: - I really don't think #1 makes sense. You might as well say, "we need to reserve an IID range for routers, because otherwise, a router's IIDs might already have been taken by a host on the link when the router is switched on, and the router wouldn't be able to provide service to hosts". We don't do that for routers. Why should we do it for the CLAT? - I don't think #2 makes much sense either. The CLAT already has a DAD implementation, because it's an IPv6 node. I think it's not that hard to make the CLAT respond to DAD for the other address as well - it's probably just a matter of assigning it to the downstream interface and letting the kernel handle DAD. In the standard tethering scenario, you can also avoid this by simply configuring your address before you send the RA. --bcaec54b4ac094494604c7e4df93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 11:06 PM, R=E9mi Despr= =E9s <despres.remi@laposte.net> wrote:
here is a self contained answer explaining what we need:

Ok, so let me parse this out clearly so we're sure we= 're all discussing the same thing.
=A0
1. The draft itself explains, about the "IANA assigned EUI-64 ID"= : "This will allow the CLAT to avoid possible IPv6 address duplication= issues between an IPv6 address for stateless translation [RFC6145] in the = CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT"= ;.

Ok. So this point is not an argument in su= pport of the reserved IID solution. It's a problem statement. What it s= ays is,=A0"we need to avoid address duplication issues between the CLA= T and its clients." It doesn't advocate a particular solution. Bot= h DAD and a reserved interface IDs are solutions. (I would argue that a res= erved IID is much more brittle, and requires needless red tape, so it's= a worse solution, but let's ignore that point for now.) We all agree t= hat this is a problem statement; we only disagree on how to solve it.=A0So = there's no need to discuss this point further.

2. The proposed alternative, = i.e. using DAD to deal with these duplications isn't a complete solutio= n, in particular because a conflicting local-scope IID may have been assign= ed before 464XLAT is activated. Recommending to be on the safe side by usin= g this IID is therefore arguably the right approach.

Ok, so this is your argument #1.

3. Secondarily, implementations u= sing the CLAT-reserved IID can arguably be considered simpler than without = it. (There is apparently no consensus on this, but no consensus to the oppo= site either.)

Ok. So this is=A0your=A0argument #2.
=

In summary, you're arguing that a reserved ID is ne= cessary for two reasons:

1. If you don't have = a reserved IID, the CLAT might not be able to provide service to a client, = since that client might already have formed an IPv6 address using that IID.=
2. If you use a reserved IID, it simplifies implementation.
=
Do you agree that this is a summary of your arguments for us= ing a reserved IID? If so:

- I really don't th= ink #1 makes sense. You might as well say, "we need to reserve an IID = range for routers, because otherwise, a router's IIDs might already hav= e been taken by a host on the link when the router is switched on, and the = router wouldn't be able to provide service to hosts". We don't= do that for routers. Why should we do it for the CLAT?
-=A0I don't think #2 makes much sense either. The CLAT already has= a DAD implementation, because it's an IPv6 node. I think it's not = that hard to make the CLAT respond to DAD for the other address as well - i= t's probably just a matter of assigning it to the downstream interface = and letting the kernel handle DAD. In the standard tethering scenario, you = can also avoid this by simply configuring your address before you send the = RA.
--bcaec54b4ac094494604c7e4df93-- From phdgang@gmail.com Wed Aug 22 21:43:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87B411E80C5 for ; Wed, 22 Aug 2012 21:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3uPdXyAy0Wy for ; Wed, 22 Aug 2012 21:43:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90A5311E80AE for ; Wed, 22 Aug 2012 21:43:45 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so392545vcb.31 for ; Wed, 22 Aug 2012 21:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AkGrwSJ0koALZOFloWLBgoA+44jDPOETLtxQb0N1HKc=; b=mEBbYfRUQ+yV0Dmxwosmd6ZBEe2DWM8DiYyJNvqImW1ooggvYkNW8AzJOwgmOgdRqz OZk51u+EJf4zXxVbaWpsQlV0OfOLzic0Xi/3aY0+CuELdKSavjz65p3uXQWbPoAMonm5 PG1B9qGoqE4BUVc/DL8YjjeUjpl3ZVdKv36Tve+lGSiqKJlVtGnHmcMW0WjQJnmLXMhT vpl8DUyD4Zq2v7Z8XNDgiZwUlyOKVZl9T0xJVWp7UPN0vjN5UzS6u5BY0herqCFGtu/4 GnxAUXfzz/rvQkfkw+OO8xywljbL6cQgOnhg9OUde3+moWO7KuhHingQHJNKft805oDe 71Mg== MIME-Version: 1.0 Received: by 10.52.26.75 with SMTP id j11mr136508vdg.75.1345697024933; Wed, 22 Aug 2012 21:43:44 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 22 Aug 2012 21:43:44 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <56E775E2-E8EA-4B8A-8FAD-4C4DAC43A014@laposte.net> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> Date: Thu, 23 Aug 2012 12:43:44 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 04:43:46 -0000 2012/8/22, Lorenzo Colitti : > On Wed, Aug 22, 2012 at 4:21 PM, GangChen wrote: > >> > What about the collision between the CLAT and the hosts behind it? It >> > can not be guaranteed that the IPv6 address derived from so-called >> > reserved EUI-64 ID would not be used by any host behind the CLAT. >> > I.e., DAD is not avoidable. >> >> Avoiding DAD may not the point of reserved IID. A main advantage is to >> fit the case where CLAT cannot perform ND Proxy. This was already >> documented in the draft-07. > > > Actually, I think a reserved IID does not help. Rationale: > > 1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then > the CLAT does not need to perform ND proxying at all in order to provide > its clients with connectivity. All it needs to do is claim an IPv6 address > from the /64 and enable IPv6 forwarding. The important thing is not > proxying, but defending the address against DAD. The statement of "The important thing is not proxying, but defending the address against DAD" is arguable to what an ND proxy exactly is. It seems to me that is a DAD proxy behaviour, since the purpose is to defend an IPv6 address used on the WAN site of CLAT. It's also unclear to me how to implement it without RFC4389. It probably likes you said in another mail "it's probably just a matter of assigning it to the downstream interface and letting the kernel handle DAD". But it would be great if someone could share more experiences to confirm that is a doable way. Many thanks Gang > 2. If the CLAT's upstream interface is not point-to-point, and the CLAT > doesn't perform ND proxying, then connectivity is broken anyway. Nodes on > the upstream interface and nodes on the downstream are on the same /64, but > they can't reach each other. So you already have a much bigger problem than > IID collisions, and a reserved IID will not fix it. > From v6ops@globis.net Wed Aug 22 23:39:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0D11E80D3 for ; Wed, 22 Aug 2012 23:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NREiVjOjgiIQ for ; Wed, 22 Aug 2012 23:39:47 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8625E11E80C5 for ; Wed, 22 Aug 2012 23:39:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AE1748700ED; Thu, 23 Aug 2012 08:39:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWc0ecu0Dd3g; Thu, 23 Aug 2012 08:39:14 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 129878700E6; Thu, 23 Aug 2012 08:39:13 +0200 (CEST) Message-ID: <5035D009.7040909@globis.net> Date: Thu, 23 Aug 2012 08:39:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: james woodyatt References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> <5035296B.6010201@glo> <3F09A058-1C74-4C14-AF3E-F68033972FD0@apple.com> In-Reply-To: <3F09A058-1C74-4C14-AF3E-F68033972FD0@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:39:48 -0000 I've been lurking on this draft. The allocation of the reserved IID is problematic for me. I still don't understand how allocation of a reserved IID will always guarantee that 464xlat will work as designed. Especially since I'd expect to find a list of necessary restrictions and assumptions on the CLAT to guarantee correct operation of 464xlat e.g. location in the network, cascading of devices, or number of CLAT's per device. But these do not seem to be fully defined in the current draft. Equally, I don't understand what would break if the reserved IID was removed from the draft. The intention behind RFC5342 seems to suggest that reserved IID parameters are assigned "by Expert Review" I don't feel I can perform expert review of this point at this time. I'll send nits in a separate post. > james woodyatt > 22 August 2012 21:21 > On Aug 22, 2012, at 11:48 , Ray Hunter wrote: >> Dumb question: why would you have to take any (new) special action due to publication of 464xLAT? > > Stupid answer: now that I have been made properly aware of this reserved IID range, I suppose my technical concern is already addressed. > > Still, I remain unpersuaded on procedural grounds, because it seems to me that consumption of this reserved IID in a BCP is not well justified by the objective of accommodating the peculiar limitations of a certain platform architecture. Rather, I should think that best current practice would be to fix the platform to remove the limitation, no? > >> Presumably you already protect against manually assigning these accidentally? > > One might presume. I'll have to check. Separable problem, I guess. > > > -- > james woodyatt > member of technical staff, core os networking > > > > ------------------------------------------------------------------------ From despres.remi@laposte.net Wed Aug 22 23:58:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA03721F8468 for ; Wed, 22 Aug 2012 23:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmY4BfVvLali for ; Wed, 22 Aug 2012 23:58:41 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9F21F8464 for ; Wed, 22 Aug 2012 23:58:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 3021C700009D; Thu, 23 Aug 2012 08:58:39 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id CBF067000098; Thu, 23 Aug 2012 08:58:38 +0200 (CEST) X-SFR-UUID: 20120823065838835.CBF067000098@msfrf2218.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> Date: Thu, 23 Aug 2012 08:58:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <589090A2-594E-4F53-BA61-0EBB8B25818D@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <415A43BB-2 A17-4EC2-99D8-5D18D71DE7E8@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:58:41 -0000 Le 2012-08-22 =E0 19:54, james woodyatt a =E9crit : > On Aug 22, 2012, at 01:05 , R=E9mi Despr=E9s = wrote: >>=20 >> This permits your implementation to ignore the CLAT-assigned IID, if = you so wish, and permits implementations that take advantage of it. >=20 > Here's my concern. Do I need to modify all my host implementations = that don't know anything about 464XLAT=97- and hopefully will never need = to know anything about them-- so that they disallow manual configuration = of the IID reserved by IANA for this purpose? If so, then that's a = price that I think is far too high for this draft to ask to be paid by = every IPv6 host implementation in the world that might ever find itself = behind a 464XLAT router, and I would oppose publication for that reason. The fact is that, as noted by Ray and as you acknowledged, nothing needs = to be done in your host implementation. Other considerations will be addressed separately. Regards, RD =20 >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 From despres.remi@laposte.net Thu Aug 23 00:16:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E422711E808A for ; Thu, 23 Aug 2012 00:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebaeh70tvKRI for ; Thu, 23 Aug 2012 00:16:56 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2735921F8540 for ; Thu, 23 Aug 2012 00:16:55 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 64CAE70000BF; Thu, 23 Aug 2012 09:16:55 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id BA39570000BE; Thu, 23 Aug 2012 09:16:54 +0200 (CEST) X-SFR-UUID: 20120823071654762.BA39570000BE@msfrf2218.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3F09A058-1C74-4C14-AF3E-F68033972FD0@apple.com> Date: Thu, 23 Aug 2012 09:16:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <477FC4F7-6386-4AA4-909D-0BE481098FEC@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <415A43BB-2A17-4EC2-99D8-5D18D71DE7E8@apple.com> <5035296B.601 0201@glo> <3F09A058-1C74-4C14-AF3E-F68033972FD0@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 07:16:57 -0000 2012-08-22 =E0 21:21, james woodyatt: > On Aug 22, 2012, at 11:48 , Ray Hunter wrote: >>=20 >> Dumb question: why would you have to take any (new) special action = due to publication of 464xLAT? >=20 > Stupid answer: now that I have been made properly aware of this = reserved IID range, I suppose my technical concern is already addressed. >=20 > Still, I remain unpersuaded on procedural grounds, because it seems to = me that consumption of this reserved IID in a BCP is not well justified = by the objective of accommodating the peculiar limitations of a certain = platform architecture. Instead of being a solution for a platform-specific problem, it is a = general solution to make the 464XLAT solution simpler and more complete = (yet letting those who prefer the less complete solution to choose it). For those who take the complete solution, cost of supporting it is = negligible once IANA has registered the IETF requested IID (see in = particular www.ietf.org/mail-archive/web/v6ops/current/msg12679.html) > Rather, I should think that best current practice would be to fix the = platform to remove the limitation, no? >=20 >> Presumably you already protect against manually assigning these = accidentally? >=20 > One might presume. I'll have to check. Separable problem, I guess. AFAIK, you don't need a specific protection against this particular = manual misconfiguration, not more than, for example, another manual = misconfiguration where some host would use an EUI IID with a MAC address = that isn't its own. Regards, RD=20 >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 From despres.remi@laposte.net Thu Aug 23 02:04:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD78E21F85C7 for ; Thu, 23 Aug 2012 02:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBjCljoBLNht for ; Thu, 23 Aug 2012 02:04:43 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.120]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6821F85B4 for ; Thu, 23 Aug 2012 02:04:42 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2513.sfr.fr (SMTP Server) with ESMTP id 6C304700008C; Thu, 23 Aug 2012 11:04:41 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2513.sfr.fr (SMTP Server) with ESMTP id 5AB8E700008B; Thu, 23 Aug 2012 11:04:40 +0200 (CEST) X-SFR-UUID: 20120823090440371.5AB8E700008B@msfrf2513.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-42-185776261 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 23 Aug 2012 11:04:39 +0200 Message-Id: <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <88878424-914F-4BF9-AF53-6F1EB09874A1@lapost e.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 09:04:44 -0000 --Apple-Mail-42-185776261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Lorenzo, Le 2012-08-23 =E0 03:35, Lorenzo Colitti a =E9crit : > On Wed, Aug 22, 2012 at 11:06 PM, R=E9mi Despr=E9s = wrote: > here is a self contained answer explaining what we need: >=20 > Ok, so let me parse this out clearly so we're sure we're all = discussing the same thing. > =20 > 1. The draft itself explains, about the "IANA assigned EUI-64 ID": = "This will allow the CLAT to avoid possible IPv6 address duplication = issues between an IPv6 address for stateless translation [RFC6145] in = the CLAT and an IPv6 address assigned to native IPv6 nodes behind the = CLAT". >=20 > Ok. So this point is not an argument in support of the reserved IID = solution. It's a problem statement. What it says is, "we need to avoid = address duplication issues between the CLAT and its clients." It doesn't = advocate a particular solution. Both DAD and a reserved interface IDs = are solutions. (I would argue that a reserved IID is much more brittle, = and requires needless red tape, so it's a worse solution, but let's = ignore that point for now.) We all agree that this is a problem = statement; we only disagree on how to solve it. So there's no need to = discuss this point further. (a) This sentence you call a "problem statement" is placed as an = explanation of why "IANA assigned EUI-64 ID" is useful. As such it does identify how to solve the identified problem. =20 (b) IETF assigning one value in a range already "available for = allocation" shouldn't be a big deal. (What would be the purpose of such = a range in RFC5342 if using it would be considered such excessive "red = tape" that its use would be prevented.)=20 (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely without = waiting for IANA having completed its registration. Actually, it has = already been done, successfully AFAIK = (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html). > 2. The proposed alternative, i.e. using DAD to deal with these = duplications isn't a complete solution, in particular because a = conflicting local-scope IID may have been assigned before 464XLAT is = activated. Recommending to be on the safe side by using this IID is = therefore arguably the right approach. >=20 > Ok, so this is your argument #1. Right. Reserved IID provides a more complete protection against collisions, in = particular in this case. > 3. Secondarily, implementations using the CLAT-reserved IID can = arguably be considered simpler than without it. (There is apparently no = consensus on this, but no consensus to the opposite either.) >=20 > Ok. So this is your argument #2. The only point is that there is no implementation difficulty for those = who are interested in point 1. >=20 > In summary, you're arguing that a reserved ID is necessary for two = reasons: >=20 > 1. If you don't have a reserved IID, the CLAT might not be able to = provide service to a client, since that client might already have formed = an IPv6 address using that IID. > 2. If you use a reserved IID, it simplifies implementation. >=20 > Do you agree that this is a summary of your arguments for using a = reserved IID? If so: Point 1 is better expressed above =20 Point 2 is that just that there is no implementation difficulty. There are other considerations, but these are in my understanding = sufficient. Let's deal with them. > - I really don't think #1 makes sense. You might as well say, "we need = to reserve an IID range for routers, because otherwise, a router's IIDs = might already have been taken by a host on the link when the router is = switched on, and the router wouldn't be able to provide service to = hosts". We don't do that for routers. Why should we do it for the CLAT? 1. You criticize my point by suggesting that I might have made another = point which doesn't make sense. This isn't good logic AFAIAC. 2. Routers that use EUI IIDs have normally no collision problem because = appropriately-configured host cannot collide. (What they do in case of a = manually misconfigured host creating a collision on this IID with such = an address isn't clear, at last to me, but this isn't the subject.) Routers that use local-scope IID (are there many, I don't know) should = better prepared to finding a colliding host. They should then take = another value.=20 I therefore agree that there is no sense in what you say I "might as = well say". But the fact is that I don't say it. > - I don't think #2 makes much sense either. The CLAT already has a DAD = implementation, because it's an IPv6 node. I think it's not that hard to = make the CLAT respond to DAD for the other address as well - it's = probably just a matter of assigning it to the downstream interface and = letting the kernel handle DAD. In the standard tethering scenario, you = can also avoid this by simply configuring your address before you send = the RA. The DAD, indeed needs to be present, no problem here. But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side = interface, not only all its LAN-side addresses, but also its 464XLAT = WAN-side address. At a given interface, DAD normally excludes all = addresses that are configured on this interface, and only these. = Configuring the CLAT-WAN-side address on the LAN-side interface would be = a hack whose consequences haven't been analyzed AFAIK. Avoiding it by = using the reserved IID is IMHO good design. Regards, RD --Apple-Mail-42-185776261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 22, 2012 at 11:06 PM, R=E9mi Despr=E9s = <despres.remi@laposte.net> = wrote:
here is a self contained answer explaining what we = need:

Ok, so let me parse this out = clearly so we're sure we're all discussing the same = thing.
 
1. The draft itself explains, about the "IANA assigned EUI-64 ID": "This = will allow the CLAT to avoid possible IPv6 address duplication issues = between an IPv6 address for stateless translation [RFC6145] in the CLAT = and an IPv6 address assigned to native IPv6 nodes behind the CLAT".

Ok. So this point is not an argument in = support of the reserved IID solution. It's a problem statement. What it = says is, "we need to avoid address duplication issues between the = CLAT and its clients." It doesn't advocate a particular solution. Both = DAD and a reserved interface IDs are solutions. (I would argue that a = reserved IID is much more brittle, and requires needless red tape, so = it's a worse solution, but let's ignore that point for now.) We all = agree that this is a problem statement; we only disagree on how to solve = it. So there's no need to discuss this point = further.

(a) This sentence = you call a "problem statement" is placed as an explanation of why "IANA = assigned EUI-64 ID" is useful.
As such it does identify how to = solve the identified problem.
 
(b) IETF = assigning one value in a range already "available = for allocation" shouldn't be a big deal. = (What would be the purpose of such a range in RFC5342 if using it = would be considered such excessive "red tape" that its use would be = prevented.) 

(c) = http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html).


2. The proposed alternative, i.e. using DAD to = deal with these duplications isn't a complete solution, in particular = because a conflicting local-scope IID may have been assigned before = 464XLAT is activated. Recommending to be on the safe side by using this = IID is therefore arguably the right approach.

Ok, so this is your argument = #1.

Right.
Reserved IID = provides a more complete protection against collisions, in particular in = this case.


3. Secondarily, implementations using the = CLAT-reserved IID can arguably be considered simpler than without it. = (There is apparently no consensus on this, but no consensus to the = opposite either.)

Ok. So this is your argument = #2.

The only point is that = there is no implementation difficulty for those who are interested in = point 1.


In summary, you're arguing = that a reserved ID is necessary for two = reasons:

1. If you don't have a reserved IID, = the CLAT might not be able to provide service to a client, since that = client might already have formed an IPv6 address using that IID.
2. If you use a reserved IID, it simplifies = implementation.

Do you agree that this is a = summary of your arguments for using a reserved IID? If = so:

Point 1 is better = expressed above  
Point 2 is that just that there is no = implementation difficulty.

There are other = considerations, but these are in my understanding sufficient. Let's deal = with them.

- I really don't think #1 makes sense. You = might as well say, "we need to reserve an IID range for routers, because = otherwise, a router's IIDs might already have been taken by a host on = the link when the router is switched on, and the router wouldn't be able = to provide service to hosts". We don't do that for routers. Why should = we do it for the CLAT?

1. = You criticize my point by suggesting that I might have made another = point which doesn't make sense. This  isn't good logic = AFAIAC.

2. Routers that use EUI IIDs have = normally no collision problem because appropriately-configured host = cannot collide. (What they do in case of a manually misconfigured host = creating a collision on this IID with such an address isn't clear, at = last to me, but this isn't the subject.)
Routers that use = local-scope IID (are there many, I don't know) should better prepared to = finding a colliding host. They should then take another = value. 
I therefore agree that there is no sense in what = you say I "might as well say".  But the fact is that I don't say = it.


- I don't think #2 makes much sense either. The CLAT already = has a DAD implementation, because it's an IPv6 node. I think it's not = that hard to make the CLAT respond to DAD for the other address as well = - it's probably just a matter of assigning it to the downstream = interface and letting the kernel handle DAD. In the standard tethering = scenario, you can also avoid this by simply configuring your address = before you send the RA.

The DAD, indeed needs to be present, no = problem here.
But AFAIK you propose the CLAT-node DAD to = exclude, at its LAN-side interface, not only all its LAN-side addresses, = but also its 464XLAT WAN-side address. At a given interface, DAD = normally excludes all addresses that are configured on this interface, = and only these. Configuring the CLAT-WAN-side address on the LAN-side = interface would be a hack whose consequences haven't been analyzed = AFAIK. Avoiding it by using the reserved IID is IMHO good = design.


Regards,
RD


= --Apple-Mail-42-185776261-- From lorenzo@google.com Thu Aug 23 02:42:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96F21F85EA for ; Thu, 23 Aug 2012 02:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5MXJPa7PHAA for ; Thu, 23 Aug 2012 02:42:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4460221F854D for ; Thu, 23 Aug 2012 02:42:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1259758obb.31 for ; Thu, 23 Aug 2012 02:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KvAOPX5eFLcZgaWoXFF2xR7f2n1gMCLtW1WWhGq77wk=; b=PfEXo+yLgZ5yXEyc8uJNbjtPhx5QWqBQrgD66paPa84ROT0WS7YOYeGtPvP+R09JEs 6MScFEvKBsPk0qjRXqmsGfKd9XJJo8DN4A6vZUv3Xcl9+hFA/k7SM1bfMkbcpsobrY3P 20msHeHZmUYI3iiCHfCgYow7lpWwBRsMM/bD7eP1t63FlZMA0wN+y7PYhb+Q95Tc03QB b9ovyni2/uemRPqp9ozokiul6+acUidpeqoOdzGRPBTYEu7eTB1ZxDpE7w7NbeEqNvQx zS/yJUxGO44U7pzHQ+bQzYvJo7C4afsCGedFzePhBkDC94/qdWs26MrBU8C29BXyPsgG bZcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KvAOPX5eFLcZgaWoXFF2xR7f2n1gMCLtW1WWhGq77wk=; b=Kz8b2c9eJzsRDqr0QZLecQDTu5uTkqZfrDX58R+qgDo1ZKU4DbVwmh9m+Bmkj9+QIy 3yGoQsxJsF9+SUaxcWfp62qd/2VB3o7/6hHNpfEEnL3DesMS8yeAYK/Hx1pt3PF7b6Og Sdo+ume+9bE/s7WI1VkZRhiQd3lrhpiM3Mg/E04Uk8k4rQAJ8P+tQ+zF4UHjunWJCZAr TFo3fBrbqESSF8RoxmbUpGNyA1slPlvTEUqxLjZ7tQt01rZnTqo3VWlzTVdOpwngBt1h 0eXqP8cPYyD+396mudbH3whsaXVWR/0JULnaDiC1c/9a6Wwjf5EEW0D9nVlCUZpXzuB3 yumA== Received: by 10.60.10.6 with SMTP id e6mr597651oeb.45.1345714923895; Thu, 23 Aug 2012 02:42:03 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr597641oeb.45.1345714923769; Thu, 23 Aug 2012 02:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Thu, 23 Aug 2012 02:41:42 -0700 (PDT) In-Reply-To: <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> From: Lorenzo Colitti Date: Thu, 23 Aug 2012 18:41:42 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2028a000ff704c7ebac30 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlsg1GxUxaG0ieFX0Q21oyCggD0DXag9zvrQPUQTe88wdaRoz4q10uSEf1wWhWQ34eVwURWLUb8PD7NqO1C//3MryFNu/8aPZblH+Ml70x9vl3NKGMAr03UWfgUYUG9zsGlytNBLMw+27JYJGE0M5t9KrnvZDJ8xJcxxeKCt4nHCD+elnTzBprKtiI2KAehuqM+MHna Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 09:42:05 -0000 --e89a8fb2028a000ff704c7ebac30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi Despr=E9s wrote: > > (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely without > waiting for IANA having completed its registration. Actually, it has > already been done, successfully AFAIK ( > http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html > ). > Excuse me, but that's absurd. First you say that using an IID in the reserved range is useful because it guarantees collisions, and then you say that an implementation just picked a random number from this range and that's fine? What if that number is assigned and the implementation is not updated? You encounter the very problem that you want to solve by using a reserved IID. > - I really don't think #1 makes sense. You might as well say, "we need to > reserve an IID range for routers, because otherwise, a router's IIDs migh= t > already have been taken by a host on the link when the router is switched > on, and the router wouldn't be able to provide service to hosts". We don'= t > do that for routers. Why should we do it for the CLAT? > > > 1. You criticize my point by suggesting that I might have made another > point which doesn't make sense. This isn't good logic AFAIAC. > Nope. I criticise your point by pointing out that in a basically identical problem (a router is turned on and a host on the link has already picked an IPv6 address with the same IID), we chose to design DAD instead of using reserved interface IDs. > 2. Routers that use EUI IIDs have normally no collision problem because > appropriately-configured host cannot collide. (What they do in case of a > manually misconfigured host creating a collision on this IID with such an > address isn't clear, at last to me, but this isn't the subject.) > And the CLAT is not a router? I mean - what's different to the scenario above where the router is powered up? > Routers that use local-scope IID (are there many, I don't know) > Yes. On routers, people like to configure their interface IDs manually so they can do things like have router IP addresses that don't change when MAC addresses change (e.g., when interface cards are swapped). Then they can put them in DNS. > should better prepared to finding a colliding host. > And the CLAT is not a router? I mean - what's different to the scenario above where the router is powered up? > But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side > interface, not only all its LAN-side addresses, but also its 464XLAT > WAN-side address. At a given interface, DAD normally excludes all address= es > that are configured on this interface, and only these. Configuring the > CLAT-WAN-side address on the LAN-side interface would be a hack whose > consequences haven't been analyzed AFAIK. > I don't think it's a hack. It's no different than doing "interface clat0 unnumbered wlan0". And it's only one way of doing t --e89a8fb2028a000ff704c7ebac30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:=A0
(c)=A002-00-5E-10--00-00-00-00 can be used as reserved IID safely witho= ut waiting for IANA having completed its registration. Actually, it has alr= eady been done, successfully AFAIK (http://www.ietf.org= /mail-archive/web/v6ops/current/msg12901.html).

Excuse me, but that's absurd. Fi= rst you say that using an IID in the reserved range is useful because it gu= arantees collisions, and then you say that an implementation just picked a = random number from this range and that's fine?=A0What if that number is= assigned and the implementation is not updated? You encounter the very pro= blem that you want to solve by using a reserved IID.
=A0
- I really don't think #1 makes sense. You might as well say, &quo= t;we need to reserve an IID range for routers, because otherwise, a router&= #39;s IIDs might already have been taken by a host on the link when the rou= ter is switched on, and the router wouldn't be able to provide service = to hosts". We don't do that for routers. Why should we do it for t= he CLAT?

1. You criticize my point by s= uggesting that I might have made another point which doesn't make sense= . This =A0isn't=A0good logic AFAIAC.

Nope. I criticise your point by pointing out that in a = basically identical problem (a router is turned on and a host on the link h= as already picked an IPv6 address with the same IID), we chose to design DA= D instead of using reserved interface IDs.
=A0
2. Routers that use EUI IIDs have normally no collision pro= blem because appropriately-configured host cannot collide. (What they do in= case of a manually misconfigured host creating a collision on this IID wit= h such an address isn't clear, at last to me, but this isn't the su= bject.)

And the CLAT is not a router? = I mean - what's different to the scenario above where the router is pow= ered up?
=A0
Routers that use local-scope = IID (are there many, I don't know)
<= br>
Yes. On routers, people like to configure their interface IDs= manually so they can do things like have router IP addresses that don'= t change when MAC addresses change (e.g., when interface cards are swapped)= . Then they can put them in DNS.
=A0
should better prepared to finding a colliding host.
<= /div>

And the CLAT is not a router? I mean= - what's different to the scenario above where the router is powered u= p?
=A0
But AFAIK=A0you propose the CLAT-n= ode DAD to exclude, at its LAN-side interface, not only all its LAN-side ad= dresses, but also its 464XLAT WAN-side address. At a given interface, DAD n= ormally excludes all addresses that are configured on this interface, and o= nly these. Configuring the CLAT-WAN-side address on the LAN-side interface = would be a hack whose consequences haven't been analyzed AFAIK.

I don't think it's a hack.= =A0It's no different than doing "interface clat0 unnumbered wlan0&= quot;. And it's only one way of doing t
--e89a8fb2028a000ff704c7ebac30-- From despres.remi@laposte.net Thu Aug 23 03:00:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6D21F85C6 for ; Thu, 23 Aug 2012 03:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc2cvX3rZHgK for ; Thu, 23 Aug 2012 03:00:30 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5197421F853B for ; Thu, 23 Aug 2012 03:00:29 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2508.sfr.fr (SMTP Server) with ESMTP id EEAD470007E6; Thu, 23 Aug 2012 12:00:28 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2508.sfr.fr (SMTP Server) with ESMTP id 2BBB07000068; Thu, 23 Aug 2012 12:00:28 +0200 (CEST) X-SFR-UUID: 20120823100028179.2BBB07000068@msfrf2508.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-43-189123834 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 23 Aug 2012 12:00:27 +0200 Message-Id: <452CA979-356D-4838-99BD-E7364470A900@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 10:00:32 -0000 --Apple-Mail-43-189123834 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-23 =E0 11:41, Lorenzo Colitti a =E9crit : > On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi Despr=E9s = wrote:=20 > (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely = without waiting for IANA having completed its registration. Actually, it = has already been done, successfully AFAIK = (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html). >=20 > Excuse me, but that's absurd. First you say that using an IID in the = reserved range is useful because it guarantees collisions, and then you = say that an implementation just picked a random number from this range = and that's fine? What if that number is assigned and the implementation = is not updated? You encounter the very problem that you want to solve by = using a reserved IID. AFAIK, a value requested by IETF that doesn't conflict with anything in = IANA, is just accepted by IANA. Unless there would be somewhere in IETF a parallel request for the same = value (which isn't the case) theer is therefore no problem. > =20 >> - I really don't think #1 makes sense. You might as well say, "we = need to reserve an IID range for routers, because otherwise, a router's = IIDs might already have been taken by a host on the link when the router = is switched on, and the router wouldn't be able to provide service to = hosts". We don't do that for routers. Why should we do it for the CLAT? >=20 > 1. You criticize my point by suggesting that I might have made another = point which doesn't make sense. This isn't good logic AFAIAC. >=20 > Nope. I criticise your point by pointing out that in a basically = identical problem (a router is turned on and a host on the link has = already picked an IPv6 address with the same IID), we chose to design = DAD instead of using reserved interface IDs. > =20 > 2. Routers that use EUI IIDs have normally no collision problem = because appropriately-configured host cannot collide. (What they do in = case of a manually misconfigured host creating a collision on this IID = with such an address isn't clear, at last to me, but this isn't the = subject.) >=20 > And the CLAT is not a router? I mean - what's different to the = scenario above where the router is powered up? > =20 > Routers that use local-scope IID (are there many, I don't know) >=20 > Yes. On routers, people like to configure their interface IDs manually = so they can do things like have router IP addresses that don't change = when MAC addresses change (e.g., when interface cards are swapped). Then = they can put them in DNS. Unmanaged CPEs wouldn't be concerned I suppose. Anyway, but thanks for the useful info. > =20 > should better prepared to finding a colliding host. >=20 > And the CLAT is not a router? CLAT nodes can be routers, for sure, and this discussion is mainly about = them. > I mean - what's different to the scenario above where the router is = powered up? > =20 > But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side = interface, not only all its LAN-side addresses, but also its 464XLAT = WAN-side address. At a given interface, DAD normally excludes all = addresses that are configured on this interface, and only these. = Configuring the CLAT-WAN-side address on the LAN-side interface would be = a hack whose consequences haven't been analyzed AFAIK. >=20 > I don't think it's a hack. It's no different than doing "interface = clat0 unnumbered wlan0". And it's only one way of doing t Which way applies to which device, or may be difficult to apply, isn't a = concern if the reserved IID is used. RD --Apple-Mail-43-189123834 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Thu, Aug 23, 2012 at 6:04 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote: 
(c) 02-00-5E-10--00-00-00-00 can be used as = reserved IID safely without waiting for IANA having completed its = registration. Actually, it has already been done, successfully AFAIK (http://www.ietf.org/mail-archive/web/v6ops/current/msg12= 901.html).

Excuse me, but that's absurd. = First you say that using an IID in the reserved range is useful because = it guarantees collisions, and then you say that an implementation just = picked a random number from this range and that's fine? What if = that number is assigned and the implementation is not updated? You = encounter the very problem that you want to solve by using a reserved = IID.

AFAIK, a value requested by = IETF that doesn't conflict with anything in IANA, is just accepted by = IANA.
Unless there would be somewhere in IETF a parallel = request for the same value (which isn't the case) theer is therefore no = problem.


 
- I really don't think #1 makes sense. You might as well say, "we = need to reserve an IID range for routers, because otherwise, a router's = IIDs might already have been taken by a host on the link when the router = is switched on, and the router wouldn't be able to provide service to = hosts". We don't do that for routers. Why should we do it for the = CLAT?

1. You criticize my point = by suggesting that I might have made another point which doesn't make = sense. This  isn't good logic = AFAIAC.

Nope. I criticise your point by pointing out that in = a basically identical problem (a router is turned on and a host on the = link has already picked an IPv6 address with the same IID), we chose to = design DAD instead of using reserved interface IDs.
 
2. Routers that use EUI IIDs = have normally no collision problem because appropriately-configured host = cannot collide. (What they do in case of a manually misconfigured host = creating a collision on this IID with such an address isn't clear, at = last to me, but this isn't the subject.)

And the CLAT is not a = router? I mean - what's different to the scenario above where the router = is powered up?
 
Routers that use = local-scope IID (are there many, I don't = know)

Yes. On routers, = people like to configure their interface IDs manually so they can do = things like have router IP addresses that don't change when MAC = addresses change (e.g., when interface cards are swapped). Then they can = put them in = DNS.

Unmanaged CPEs = wouldn't be concerned I suppose.
Anyway, but thanks for the = useful info.

 
= should better prepared to finding a colliding host.

And the CLAT is not a router? =

CLAT nodes can be routers, = for sure, and this discussion is mainly about = them.


I mean - what's different to the scenario = above where the router is powered up?
 
But AFAIK you propose the = CLAT-node DAD to exclude, at its LAN-side interface, not only all its = LAN-side addresses, but also its 464XLAT WAN-side address. At a given = interface, DAD normally excludes all addresses that are configured on = this interface, and only these. Configuring the CLAT-WAN-side address on = the LAN-side interface would be a hack whose consequences haven't been = analyzed AFAIK.

I don't think it's a = hack. It's no different than doing "interface clat0 unnumbered = wlan0". And it's only one way of doing t

Which way applies to which device, or = may be difficult to apply, isn't a concern if the reserved IID is = used.

RD



<= /body>= --Apple-Mail-43-189123834-- From phdgang@gmail.com Thu Aug 23 03:54:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C71A21F8569 for ; Thu, 23 Aug 2012 03:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZRlh4O1iQMN for ; Thu, 23 Aug 2012 03:54:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0DC21F857D for ; Thu, 23 Aug 2012 03:54:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so680585vbb.31 for ; Thu, 23 Aug 2012 03:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Efg1Z1s/oUzegmkuO41rf1l0ePIdaPhf2kh2Ukv4epk=; b=zhQZoP6bDs1P235sBBROoqXb1bSHoF+rxIuuqvVjiC/pFJsfLgCMaUziubVSzjz0FE INROdQa3gBaqKBwlBFOpryqDVkPQ52EN8LK82dRTDs3i0RFt5xVpYQ/3yD3n8XxnEBeN +Hn0YqsxOXoMVwq3NSxRI4Oi6Mmj4n8cvHGPzEyf4F+us7VjoILez9r0tN0N2Yj32Ov4 mIM069atCmi6+1pca/UBPYs2u53ZDMKUZfDV6dy3s1L6f5X8W0ArIZyr84Pu06xEjmi0 1IF6KqGR6gy6CLHvVlVrmtxjgwiDBQ25byLVOKagXxHsws8j0rOhIxM5PGAFJrxqoxr5 qyQQ== MIME-Version: 1.0 Received: by 10.58.65.10 with SMTP id t10mr859758ves.48.1345719277645; Thu, 23 Aug 2012 03:54:37 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 23 Aug 2012 03:54:37 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> Date: Thu, 23 Aug 2012 18:54:37 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 10:54:39 -0000 2012/8/23, Lorenzo Colitti : > On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi Despr=E9s > wrote: >> >> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely without >> waiting for IANA having completed its registration. Actually, it has >> already been done, successfully AFAIK ( >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html >> ). >> > > Excuse me, but that's absurd. First you say that using an IID in the > reserved range is useful because it guarantees collisions, and then you s= ay > that an implementation just picked a random number from this range and > that's fine? What if that number is assigned and the implementation is no= t > updated? You encounter the very problem that you want to solve by using a > reserved IID. > > >> - I really don't think #1 makes sense. You might as well say, "we need t= o >> reserve an IID range for routers, because otherwise, a router's IIDs >> might >> already have been taken by a host on the link when the router is switche= d >> on, and the router wouldn't be able to provide service to hosts". We >> don't >> do that for routers. Why should we do it for the CLAT? >> >> >> 1. You criticize my point by suggesting that I might have made another >> point which doesn't make sense. This isn't good logic AFAIAC. >> > > Nope. I criticise your point by pointing out that in a basically identica= l > problem (a router is turned on and a host on the link has already picked = an > IPv6 address with the same IID), we chose to design DAD instead of using > reserved interface IDs. > > >> 2. Routers that use EUI IIDs have normally no collision problem because >> appropriately-configured host cannot collide. (What they do in case of a >> manually misconfigured host creating a collision on this IID with such a= n >> address isn't clear, at last to me, but this isn't the subject.) >> > > And the CLAT is not a router? I mean - what's different to the scenario > above where the router is powered up? > > >> Routers that use local-scope IID (are there many, I don't know) >> > > Yes. On routers, people like to configure their interface IDs manually so > they can do things like have router IP addresses that don't change when M= AC > addresses change (e.g., when interface cards are swapped). Then they can > put them in DNS. > > >> should better prepared to finding a colliding host. >> > > And the CLAT is not a router? I mean - what's different to the scenario > above where the router is powered up? > > >> But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side >> interface, not only all its LAN-side addresses, but also its 464XLAT >> WAN-side address. At a given interface, DAD normally excludes all >> addresses >> that are configured on this interface, and only these. Configuring the >> CLAT-WAN-side address on the LAN-side interface would be a hack whose >> consequences haven't been analyzed AFAIK. >> > > I don't think it's a hack. It's no different than doing "interface clat0 > unnumbered wlan0". And it's only one way of doing t ip unnumbered only makes sense for point-to-point interface AFAIK. But the borrowed IP address is used to a tun device. Not sure your recommendation could be used in 464xlat implementation. From lorenzo@google.com Thu Aug 23 03:59:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4704B21F8597 for ; Thu, 23 Aug 2012 03:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvCJkWHB+k+1 for ; Thu, 23 Aug 2012 03:59:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C32D21F858A for ; Thu, 23 Aug 2012 03:59:08 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1417008obb.31 for ; Thu, 23 Aug 2012 03:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qw/DyZZrfaGcQVxYqt7A+CBTbep5b031JACd4vOwCwU=; b=Q6cmfxD3PpTSJN00UXXs4x/KpSKhW/lXcC3kDKQ9S4Ga2PjixeVEYhQiX2jQfhnBR4 9nuw+F8DZlmAQFGwbewGVd7tHfFDMVBak1IcMGmtJWrAIIQ+mCTRgImqULHyxsD8LDwa nCX5urMCC7g/2J1+squDkXYPJfq0bPvcSRdrkiT0Qs/l18fWRcXeSMa2Rzl59DoyKbyP VjWeooIMA3vWnI+/QjbB4aBRZWcqER+SjRzQ09VccuDJbtMQss8HzJOB0NA98xygP2Jz ZX/m2MBfV1Ew9Po6q/Se18sOqwfHo/P/yfmed35FgCt5qL6NYNg3+hYVDEwzuh3iQCHj I7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=qw/DyZZrfaGcQVxYqt7A+CBTbep5b031JACd4vOwCwU=; b=mRl1Jlh55cvL+qzPh2gtCS7iXy0v6sWeiSfWvxH88Pps4p90fFV8MDzAeNhnY7EL85 nP2lA48Vt/kcCi3jm1gxdZ05j20+0cIjXIi6hmqVqedUDgVus3xZw3KgjKXvMSGf8lh0 SsiU+kZqDzlSq4YagaKr1itSgLOTfZLE6/aCD3YdGrPyklpcW87kyspIqnqSoEYC2xWM dmOiq4dB/kRmDWG5xmkpL8jNuANuM6+L/F6JbLO+7FrnI4PFlNjD2iE3X4rbOZhtCwvC 7QvTZdiVfXVVSncGXMy4UQ/yxNSROFVQhvRq26Ux+JMnd09r/HZcxYB2686ngTsGjkKE /vcg== Received: by 10.60.6.73 with SMTP id y9mr762607oey.17.1345719548034; Thu, 23 Aug 2012 03:59:08 -0700 (PDT) Received: by 10.60.6.73 with SMTP id y9mr762600oey.17.1345719547945; Thu, 23 Aug 2012 03:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Thu, 23 Aug 2012 03:58:47 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> From: Lorenzo Colitti Date: Thu, 23 Aug 2012 19:58:47 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=e89a8ff250149f646704c7ecbfa1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm2MZgOcUmXx74fxwB52nyG+20kJRpdsRWdSB9T3SDfyD8o6Y8s88XOtqsJakvu0hKc8vqFo5By610zH7k5mRO5D6gc4hCnNSDT3miB1hB4ldTbQhXu+g95yszEZPkDMxQa9mYkNctH+tvTpAYwU6hwRmXMwxy4hP13ooJSlr6AdmKGdTODBmrOd9EphwA57Ihl/8Dd Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 10:59:09 -0000 --e89a8ff250149f646704c7ecbfa1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 23, 2012 at 7:54 PM, GangChen wrote: > > I don't think it's a hack. It's no different than doing "interface clat0 > > unnumbered wlan0". And it's only one way of doing t > > ip unnumbered only makes sense for point-to-point interface AFAIK. > But the borrowed IP address is used to a tun device. > Not sure your recommendation could be used in 464xlat implementation. > But a tun device *is* a point-to-point interface, right? --e89a8ff250149f646704c7ecbfa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 23, 2012 at 7:54 PM, GangChen <phdg= ang@gmail.com> wrote:
> I don't think it's a hack. It's no = different than doing "interface clat0
> unnumbered wlan0". And it's only one way of doing t

ip unnumbered only makes sense for point-to-point interface AFA= IK.
But the borrowed IP address is used to a tun device.
Not sure your recommendation could be used in 464xlat implementation.

But a tun device *is* a point-to-point interfac= e, right?
--e89a8ff250149f646704c7ecbfa1-- From phdgang@gmail.com Thu Aug 23 08:55:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B9421F859B for ; Thu, 23 Aug 2012 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6pGfUTavV7F for ; Thu, 23 Aug 2012 08:55:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14C7421F8569 for ; Thu, 23 Aug 2012 08:55:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1072054vbb.31 for ; Thu, 23 Aug 2012 08:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TGdpnh8XFrFuulcIi8lI7Dv20m5+vex41ESgq6Rt9Mw=; b=BkiRAfxqmLSi+fuhU95gQ628phQb6g7lPTqzYgfOhb0mhJHFXLOws7GTotjGxXJRp4 hiXPrEKFqpuJJ55yV/Dv/5/DkCwI6GU70twND9+A2qJUEjsuOgMojL2hcGycKJ18EJdA H2d6KBog3BTIFNI8qqaSFp7u1Aml0CVSQP0rtz4/M/tkQxKmOJ6l4yDU5nXeKS1n3P9F IUndlbMy37tO07mW9Bfa+888/68sSht3NG9Y/jzO9/DjQ7JPkwx7fja8QU7mDkmOJGD2 O+/ZO5ek7iFxlp6GZoPXzRqnZTa4Co/39dFwA5UEJR7a9J518yLW9hM90VXKttoa9IW5 UPlg== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr1898487ved.13.1345737353569; Thu, 23 Aug 2012 08:55:53 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 23 Aug 2012 08:55:53 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> Date: Thu, 23 Aug 2012 23:55:53 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:55:54 -0000 2012/8/23, Lorenzo Colitti : > On Thu, Aug 23, 2012 at 7:54 PM, GangChen wrote: > >> > I don't think it's a hack. It's no different than doing "interface >> > clat0 >> > unnumbered wlan0". And it's only one way of doing t >> >> ip unnumbered only makes sense for point-to-point interface AFAIK. >> But the borrowed IP address is used to a tun device. >> Not sure your recommendation could be used in 464xlat implementation. >> > > But a tun device *is* a point-to-point interface, right? Right Assuming the borrowed IP address used to a tun device, I'm just trying to figure out how to implement If the CLAT's upstream is 3GPP access, there are two point-to-point interfaces on CLAT if I understood correctly. One is the Tun device(virtual interface) and another is 3GPP interface(physical interface). "interface clat0 unnumbered wlan0" lets ip address on wlan0 assigned to a tun interface. However, I guess 3GPP interface needs its own IP address in that case Afterall, it is unavoidable there will be an address needs ND proxy. From v6ops@globis.net Thu Aug 23 09:21:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3406A21F85B8 for ; Thu, 23 Aug 2012 09:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtW36jRfujOv for ; Thu, 23 Aug 2012 09:21:00 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C054321F85B1 for ; Thu, 23 Aug 2012 09:20:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 51A678700E6; Thu, 23 Aug 2012 18:20:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC08cwf1zhdf; Thu, 23 Aug 2012 18:20:15 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E7958870067; Thu, 23 Aug 2012 18:20:14 +0200 (CEST) Message-ID: <50365833.6050605@globis.net> Date: Thu, 23 Aug 2012 18:20:03 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> In-Reply-To: <452CA979-356D-4838-99BD-E7364470A900@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:21:01 -0000 inline Rémi Després wrote: > > Le 2012-08-23 à 11:41, Lorenzo Colitti a écrit : > >> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després >> > wrote: >> >> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely >> without waiting for IANA having completed its registration. >> Actually, it has already been done, successfully AFAIK >> (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html >> ). >> >> >> Excuse me, but that's absurd. First you say that using an IID in the >> reserved range is useful because it guarantees collisions, and then >> you say that an implementation just picked a random number from this >> range and that's fine? What if that number is assigned and the >> implementation is not updated? You encounter the very problem that >> you want to solve by using a reserved IID. > > AFAIK, a value requested by IETF that doesn't conflict with anything > in IANA, is just accepted by IANA. > Unless there would be somewhere in IETF a parallel request for the > same value (which isn't the case) theer is therefore no problem. > > Are you saying that there can only be ONE CLAT active on any given L2 link (whether virtual or otherwise) when the reserved IID is used? Seems to me 2 CLATs using a single reserved IID address with manual configuration are guaranteed to generate duplicate IPv6 addresses if they are connected to the same L2 link. So in a high availability situation of 2 CLATs running in parallel (active active mode) using the reserved IID would be a problem? Are you also saying that 2 CLAT's cannot be cascaded when using the reserved IID? [because as I read it, the downlink IID has to be disjoint from any IID used on the upstream interface when attempting to share a single /64 across 2 interfaces, and the upstream CLAT would have already claimed the reserved IID that the downstream CLAT wanted to use on its downstream interface] How would inappropriate cascading or parallel connections be detected and the downstream/parallel CLAT disabled? [I'm especially thinking VM's and virtual networks] IMHO If these restrictions with the reserved IID are correct, then the draft should say also note this, and also any requirements on the implementation on what action to take in these situations. I think that's one of Lorenzo's basic points, and I can't say reading your answer above how I can disagree with him. >> >>> - I really don't think #1 makes sense. You might as well say, >>> "we need to reserve an IID range for routers, because otherwise, >>> a router's IIDs might already have been taken by a host on the >>> link when the router is switched on, and the router wouldn't be >>> able to provide service to hosts". We don't do that for routers. >>> Why should we do it for the CLAT? >> >> 1. You criticize my point by suggesting that I might have made >> another point which doesn't make sense. This isn't good logic >> AFAIAC. >> >> >> Nope. I criticise your point by pointing out that in a basically >> identical problem (a router is turned on and a host on the link has >> already picked an IPv6 address with the same IID), we chose to design >> DAD instead of using reserved interface IDs. >> >> 2. Routers that use EUI IIDs have normally no collision problem >> because appropriately-configured host cannot collide. (What they >> do in case of a manually misconfigured host creating a collision >> on this IID with such an address isn't clear, at last to me, but >> this isn't the subject.) >> >> >> And the CLAT is not a router? I mean - what's different to the >> scenario above where the router is powered up? >> >> Routers that use local-scope IID (are there many, I don't know) >> >> >> Yes. On routers, people like to configure their interface IDs >> manually so they can do things like have router IP addresses that >> don't change when MAC addresses change (e.g., when interface cards >> are swapped). Then they can put them in DNS. > > Unmanaged CPEs wouldn't be concerned I suppose. > Anyway, but thanks for the useful info. > >> should better prepared to finding a colliding host. >> >> >> And the CLAT is not a router? > > CLAT nodes can be routers, for sure, and this discussion is mainly > about them. > > >> I mean - what's different to the scenario above where the router is >> powered up? >> >> But AFAIK you propose the CLAT-node DAD to exclude, at its >> LAN-side interface, not only all its LAN-side addresses, but also >> its 464XLAT WAN-side address. At a given interface, DAD normally >> excludes all addresses that are configured on this interface, and >> only these. Configuring the CLAT-WAN-side address on the LAN-side >> interface would be a hack whose consequences haven't been >> analyzed AFAIK. >> >> >> I don't think it's a hack. It's no different than doing "interface >> clat0 unnumbered wlan0". And it's only one way of doing t > > Which way applies to which device, or may be difficult to apply, isn't > a concern if the reserved IID is used. > > RD > > > From despres.remi@laposte.net Thu Aug 23 10:19:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308A421F8535 for ; Thu, 23 Aug 2012 10:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZhNkYKTTaOz for ; Thu, 23 Aug 2012 10:19:22 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0612121F852C for ; Thu, 23 Aug 2012 10:19:20 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7854F94016E; Thu, 23 Aug 2012 19:19:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <50365833.6050605@globis.net> Date: Thu, 23 Aug 2012 19:19:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> <50365833.6050605@glo bis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:19:23 -0000 Hi, Ray, 2012-08-23 18:20, Ray Hunter : > inline >=20 > R=E9mi Despr=E9s wrote: >>=20 >> Le 2012-08-23 =E0 11:41, Lorenzo Colitti a =E9crit : >>=20 >>> On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi Despr=E9s = > wrote: >>>=20 >>> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely >>> without waiting for IANA having completed its registration. >>> Actually, it has already been done, successfully AFAIK >>> (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html >>> = ). >>>=20 >>>=20 >>> Excuse me, but that's absurd. First you say that using an IID in the = reserved range is useful because it guarantees collisions, and then you = say that an implementation just picked a random number from this range = and that's fine? What if that number is assigned and the implementation = is not updated? You encounter the very problem that you want to solve by = using a reserved IID. >>=20 >> AFAIK, a value requested by IETF that doesn't conflict with anything = in IANA, is just accepted by IANA. >> Unless there would be somewhere in IETF a parallel request for the = same value (which isn't the case) theer is therefore no problem. >>=20 > Are you saying that there can only be ONE CLAT active on any given L2 = link (whether virtual or otherwise) when the reserved IID is used? NO. Two CLAT nodes connected to a common WAN link will be delegated = different IPv6 prefixes. Their CLAT IPv6 addresses will have the same = IID but will be different. Two CLAT nodes connected to a common LAN-side link would have CLAT IPv6 = addresses also based on different IPv6 prefixes.=20 > Seems to me 2 CLATs using a single reserved IID address with manual = configuration are guaranteed to generate duplicate IPv6 addresses if = they are connected to the same L2 link. A single reserved IID doesn't mean a single reserved address. > So in a high availability situation of 2 CLATs running in parallel = (active active mode) using the reserved IID would be a problem? No address problem AFAIK (but OTOH need to continuously synchronize the = two NAT44s)=20 > Are you also saying that 2 CLAT's cannot be cascaded when using the = reserved IID? >=20 > [because as I read it, the downlink IID has to be disjoint from any = IID used on the upstream interface when attempting to share a single /64 = across 2 interfaces, and the upstream CLAT would have already claimed = the reserved IID that the downstream CLAT wanted to use on its = downstream interface] >=20 > How would inappropriate cascading or parallel connections be detected = and the downstream/parallel CLAT disabled? > [I'm especially thinking VM's and virtual networks] >=20 > IMHO If these restrictions with the reserved IID are correct, then the = draft should say also note this, and also any requirements on the = implementation on what action to take in these situations. Well, cascaded CLATs are clearly out of scope for this draft. (CLATs are = v6-only WAN side, and v6+v4p LAN side). Even if the scope would be extended to support cascaded 464XLAT domains = (in a way to be defined), any problem that exists with a reserved IID = can also exist with IIDs in which the NAT44 external address is embedded = (the proposal if no reserved IID is used). Without administratively = configured parameters, these external addresses can typically be the = same in various CLAT implementations. > I think that's one of Lorenzo's basic points, and I can't say reading = your answer above how I can disagree with him. My answer above only concerned Lorenzo's objection that the supposed = "red tape" that an IID reservation would need makes it impracticable. Let me then add, about his objection above, that: - The considered implementation (which apparently he would be happy to = ignore) didn't take a value "at random" in the available range. It just = took the first value, as one usually does. - There is no risk that this value would need to be changed later on, = because no other WG currently envisages such a reservation. First come = first served. Regards, RD >>>=20 >>>> - I really don't think #1 makes sense. You might as well say, >>>> "we need to reserve an IID range for routers, because otherwise, >>>> a router's IIDs might already have been taken by a host on the >>>> link when the router is switched on, and the router wouldn't be >>>> able to provide service to hosts". We don't do that for routers. >>>> Why should we do it for the CLAT? >>>=20 >>> 1. You criticize my point by suggesting that I might have made >>> another point which doesn't make sense. This isn't good logic >>> AFAIAC. >>>=20 >>>=20 >>> Nope. I criticise your point by pointing out that in a basically = identical problem (a router is turned on and a host on the link has = already picked an IPv6 address with the same IID), we chose to design = DAD instead of using reserved interface IDs. >>>=20 >>> 2. Routers that use EUI IIDs have normally no collision problem >>> because appropriately-configured host cannot collide. (What they >>> do in case of a manually misconfigured host creating a collision >>> on this IID with such an address isn't clear, at last to me, but >>> this isn't the subject.) >>>=20 >>>=20 >>> And the CLAT is not a router? I mean - what's different to the = scenario above where the router is powered up? >>>=20 >>> Routers that use local-scope IID (are there many, I don't know) >>>=20 >>>=20 >>> Yes. On routers, people like to configure their interface IDs = manually so they can do things like have router IP addresses that don't = change when MAC addresses change (e.g., when interface cards are = swapped). Then they can put them in DNS. >>=20 >> Unmanaged CPEs wouldn't be concerned I suppose. >> Anyway, but thanks for the useful info. >>=20 >>> should better prepared to finding a colliding host. >>>=20 >>>=20 >>> And the CLAT is not a router?=20 >>=20 >> CLAT nodes can be routers, for sure, and this discussion is mainly = about them. >>=20 >>=20 >>> I mean - what's different to the scenario above where the router is = powered up? >>>=20 >>> But AFAIK you propose the CLAT-node DAD to exclude, at its >>> LAN-side interface, not only all its LAN-side addresses, but also >>> its 464XLAT WAN-side address. At a given interface, DAD normally >>> excludes all addresses that are configured on this interface, and >>> only these. Configuring the CLAT-WAN-side address on the LAN-side >>> interface would be a hack whose consequences haven't been >>> analyzed AFAIK. >>>=20 >>>=20 >>> I don't think it's a hack. It's no different than doing "interface = clat0 unnumbered wlan0". And it's only one way of doing t >>=20 >> Which way applies to which device, or may be difficult to apply, = isn't a concern if the reserved IID is used. >>=20 >> RD >>=20 >>=20 >>=20 From v6ops@globis.net Thu Aug 23 10:51:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13D821F855D for ; Thu, 23 Aug 2012 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOblqTfF0MSz for ; Thu, 23 Aug 2012 10:51:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECCC421F855A for ; Thu, 23 Aug 2012 10:51:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AB3A58700E2; Thu, 23 Aug 2012 19:51:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxmIB3G7zINx; Thu, 23 Aug 2012 19:50:41 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0FD42870081; Thu, 23 Aug 2012 19:50:41 +0200 (CEST) Message-ID: <50366D64.30609@globis.net> Date: Thu, 23 Aug 2012 19:50:28 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> <50365833.6050605@glo bis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:51:33 -0000 Thanks. So to be clear: the reserved IID would NOT be used for any L2 addressing: just generating an IPv6 address (from the delegated prefix that is unique per CLAT)? Otherwise L2 bridges and other devices might get confused (with side changes and duplicate EUI64 addresses appearing on multiple ports) Thinking wireless LTE phone (with built in CLAT) connected to a L2 switch in parallel with Homenet wired router (with built in CLAT) > Rémi Després > 23 August 2012 19:19 > Hi, Ray, > > 2012-08-23 18:20, Ray Hunter : > >> inline >> >> Rémi Després wrote: >>> Le 2012-08-23 à 11:41, Lorenzo Colitti a écrit : >>> >>>> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després> wrote: >>>> >>>> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely >>>> without waiting for IANA having completed its registration. >>>> Actually, it has already been done, successfully AFAIK >>>> (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html >>>> ). >>>> >>>> >>>> Excuse me, but that's absurd. First you say that using an IID in the reserved range is useful because it guarantees collisions, and then you say that an implementation just picked a random number from this range and that's fine? What if that number is assigned and the implementation is not updated? You encounter the very problem that you want to solve by using a reserved IID. >>> AFAIK, a value requested by IETF that doesn't conflict with anything in IANA, is just accepted by IANA. >>> Unless there would be somewhere in IETF a parallel request for the same value (which isn't the case) theer is therefore no problem. >>> > >> Are you saying that there can only be ONE CLAT active on any given L2 link (whether virtual or otherwise) when the reserved IID is used? > > NO. > > Two CLAT nodes connected to a common WAN link will be delegated different IPv6 prefixes. Their CLAT IPv6 addresses will have the same IID but will be different. > > Two CLAT nodes connected to a common LAN-side link would have CLAT IPv6 addresses also based on different IPv6 prefixes. > > >> Seems to me 2 CLATs using a single reserved IID address with manual configuration are guaranteed to generate duplicate IPv6 addresses if they are connected to the same L2 link. > > A single reserved IID doesn't mean a single reserved address. > >> So in a high availability situation of 2 CLATs running in parallel (active active mode) using the reserved IID would be a problem? > > No address problem AFAIK (but OTOH need to continuously synchronize the two NAT44s) > > >> Are you also saying that 2 CLAT's cannot be cascaded when using the reserved IID? >> >> [because as I read it, the downlink IID has to be disjoint from any IID used on the upstream interface when attempting to share a single /64 across 2 interfaces, and the upstream CLAT would have already claimed the reserved IID that the downstream CLAT wanted to use on its downstream interface] >> >> How would inappropriate cascading or parallel connections be detected and the downstream/parallel CLAT disabled? >> [I'm especially thinking VM's and virtual networks] >> >> IMHO If these restrictions with the reserved IID are correct, then the draft should say also note this, and also any requirements on the implementation on what action to take in these situations. > > Well, cascaded CLATs are clearly out of scope for this draft. (CLATs are v6-only WAN side, and v6+v4p LAN side). > > Even if the scope would be extended to support cascaded 464XLAT domains (in a way to be defined), any problem that exists with a reserved IID can also exist with IIDs in which the NAT44 external address is embedded (the proposal if no reserved IID is used). Without administratively configured parameters, these external addresses can typically be the same in various CLAT implementations. > > >> I think that's one of Lorenzo's basic points, and I can't say reading your answer above how I can disagree with him. > > My answer above only concerned Lorenzo's objection that the supposed "red tape" that an IID reservation would need makes it impracticable. > > Let me then add, about his objection above, that: > - The considered implementation (which apparently he would be happy to ignore) didn't take a value "at random" in the available range. It just took the first value, as one usually does. > - There is no risk that this value would need to be changed later on, because no other WG currently envisages such a reservation. First come first served. > > Regards, > RD > > > > > >>>>> - I really don't think #1 makes sense. You might as well say, >>>>> "we need to reserve an IID range for routers, because otherwise, >>>>> a router's IIDs might already have been taken by a host on the >>>>> link when the router is switched on, and the router wouldn't be >>>>> able to provide service to hosts". We don't do that for routers. >>>>> Why should we do it for the CLAT? >>>> 1. You criticize my point by suggesting that I might have made >>>> another point which doesn't make sense. This isn't good logic >>>> AFAIAC. >>>> >>>> >>>> Nope. I criticise your point by pointing out that in a basically identical problem (a router is turned on and a host on the link has already picked an IPv6 address with the same IID), we chose to design DAD instead of using reserved interface IDs. >>>> >>>> 2. Routers that use EUI IIDs have normally no collision problem >>>> because appropriately-configured host cannot collide. (What they >>>> do in case of a manually misconfigured host creating a collision >>>> on this IID with such an address isn't clear, at last to me, but >>>> this isn't the subject.) >>>> >>>> >>>> And the CLAT is not a router? I mean - what's different to the scenario above where the router is powered up? >>>> >>>> Routers that use local-scope IID (are there many, I don't know) >>>> >>>> >>>> Yes. On routers, people like to configure their interface IDs manually so they can do things like have router IP addresses that don't change when MAC addresses change (e.g., when interface cards are swapped). Then they can put them in DNS. >>> Unmanaged CPEs wouldn't be concerned I suppose. >>> Anyway, but thanks for the useful info. >>> >>>> should better prepared to finding a colliding host. >>>> >>>> >>>> And the CLAT is not a router? >>> CLAT nodes can be routers, for sure, and this discussion is mainly about them. >>> >>> >>>> I mean - what's different to the scenario above where the router is powered up? >>>> >>>> But AFAIK you propose the CLAT-node DAD to exclude, at its >>>> LAN-side interface, not only all its LAN-side addresses, but also >>>> its 464XLAT WAN-side address. At a given interface, DAD normally >>>> excludes all addresses that are configured on this interface, and >>>> only these. Configuring the CLAT-WAN-side address on the LAN-side >>>> interface would be a hack whose consequences haven't been >>>> analyzed AFAIK. >>>> >>>> >>>> I don't think it's a hack. It's no different than doing "interface clat0 unnumbered wlan0". And it's only one way of doing t >>> Which way applies to which device, or may be difficult to apply, isn't a concern if the reserved IID is used. >>> >>> RD >>> >>> >>> > > ------------------------------------------------------------------------ From jouni.nospam@gmail.com Thu Aug 23 14:56:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4257721F85C0 for ; Thu, 23 Aug 2012 14:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khhxS87QlEJu for ; Thu, 23 Aug 2012 14:56:11 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8723521F8577 for ; Thu, 23 Aug 2012 14:56:11 -0700 (PDT) Received: by eekb45 with SMTP id b45so464241eek.31 for ; Thu, 23 Aug 2012 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OoXGhKXYwjFQHA1MxJqhOx1kNeOVd6x/0h5G2+lNYpE=; b=IthosCIty27zcN063IGgeKVqH0G2g/9oInbcPBwLd36PZckc78XnxuKDGs0HwaWY+l dH26xTpvfmQ7gz6EPlcrDzeR7exTyssTbg3QIxQYn6WN3gOv2U3mNBm6Th+GONpO4Qru NmeFlAfyzxU8pas+Ns+9uLHSl7HBtyWOGL0q7VdnFla8UGLHFXaLwOj5TzV2/lZzf8sD rKfh2hggRUFe1FNvkQCana3FvI1UPUxgHBWwQ7c/iDTXeiPrff/eIqajJx/Ck6pYhlE4 DtV5E/u0XudAKB3N5msT84Fjdy9euJAub6uAMwAXe2qX44+3k2umGqw4kAq6irenUz0E MGsg== Received: by 10.14.175.7 with SMTP id y7mr4188873eel.29.1345758970682; Thu, 23 Aug 2012 14:56:10 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id l42sm24722502eep.1.2012.08.23.14.56.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 14:56:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 24 Aug 2012 00:56:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@lap oste.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:56:12 -0000 On Aug 22, 2012, at 1:30 PM, Lorenzo Colitti wrote: > I think this text is incorrect for the reasons I listed above: if you = have a p2p upstream link you don't need to perform ND proxying, Just for my understanding how this in cellular uplink case would be = different from RFC4389 scenario 2 (where the upstream is PPP)? - Jouni > and if you don't have a p2p upstream link, either you perform ND = proxying or things break pretty badly. Therefore, I think it should be = removed. >=20 > If that text is removed, is there any other reason to reserve an IID? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Aug 23 18:12:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538BE21F8652 for ; Thu, 23 Aug 2012 18:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGCtwtAPQX+N for ; Thu, 23 Aug 2012 18:12:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5537321F8645 for ; Thu, 23 Aug 2012 18:12:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3644614obb.31 for ; Thu, 23 Aug 2012 18:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=QgEx10kes5+u0iUUXkzSR0PaDbn/3mtPS5uUyNSkinU=; b=XaIM4Af9a934QjZiMqYxz1kk6KCMQO2KJamP3117+4jnXmhLE6aozlrXSMDNUOqY4o InPYGwmDrcwZ5A5OBUiIpkExcDyaQRnR6cXQgVot0DKC64Fb2yJxBFksKfMzgC/I1lKb 050sYl0l4hhRTiUENUbp2q3SslrAvjmfQyod9pKIH10NH9F85OEZBmBaj9gZPvIGJ/5j 68hEki60LiOiaAodzx0ls1Zw35s1btYorUpZ4rCMgVm2laF1N4a7u1KM7Z7Q9NxyNh7A OBonIYlrTNsKkFaHOiTpichnugR6a0PvWh5O8I95JljoQgfip3hQjUxqLPnJasmYvAHc 3nUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QgEx10kes5+u0iUUXkzSR0PaDbn/3mtPS5uUyNSkinU=; b=c1lWyeMFbgOT7e0L0STvLlAkvctf96Msis3bqkBdHnlCKCEAyRdCH2zVqwGYiSJswY IIoND/29xG90egkt0KL3XepIJtu92vNgZKHWLzvsjXAKzWY6REVAtfuOCx/I61wNGCAy kQAV2rz4KNad2C1sCnRZg81EiqYNdwMoB7HMUr+pMDs0iBKZkO+FAHIZ5akaCKy0dVau 4gJ+hrChyZWE6/CYSYM3xlwMQDIA7gSOh044T+CXRyBKFuOvzqcSLuSVjKYUhTFdMy3E cejHgeS/okQDa/lg3fATqyYNp9T0TImXjmXobqUiJxJla/+6quS34RBYyMorKfSDQ6uk vsRw== Received: by 10.60.10.6 with SMTP id e6mr2713809oeb.45.1345770752731; Thu, 23 Aug 2012 18:12:32 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr2713797oeb.45.1345770752536; Thu, 23 Aug 2012 18:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Thu, 23 Aug 2012 18:12:12 -0700 (PDT) In-Reply-To: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> <50365833.6050605@globis.net> From: Lorenzo Colitti Date: Fri, 24 Aug 2012 10:12:12 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2028aa7717a04c7f8ab1a X-System-Of-Record: true X-Gm-Message-State: ALoCoQma4dlSHuIWBgqrfIhBxAGV1o3eC/X4xV/fkH4Qa5xyPsrewyemq4jvz/D3NktJNgFyc0Yn+UyY7IDiAEC7DZ2ZpyzBf4KuqawiuC7RGS7tL99hRuZzqJhZF9jkkCfDoy3JIH6og5XMGGE5fNFMloXWO+7WygShxQznRPq81CGpsGh9h2BZY9uDywV/I6+kKMTASzQk Cc: Ray Hunter , v6ops WG , Bjoern Zeeb Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:12:34 -0000 --e89a8fb2028aa7717a04c7f8ab1a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 24, 2012 at 2:19 AM, R=E9mi Despr=E9s wrote: > Let me then add, about his objection above, that: > - The considered implementation (which apparently he would be happy to > ignore) didn't take a value "at random" in the available range. It just > took the first value, as one usually does. > - There is no risk that this value would need to be changed later on, > because no other WG currently envisages such a reservation. First come > first served. > Remi, you can't say "these numbers are reserved by IANA", and then say "first come first served". If they are assigned by IANA, you *can't use them* until IANA reserves them, period. If you put one of these numbers in an implementation, you're squatting on a number that IANA has the freedom to assign whenever it wants. As soon as assigns it (which it can and will do with no obligation to tell you), you are in violation of that assignment. --e89a8fb2028aa7717a04c7f8ab1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 24, 2012 at 2:19 AM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
Let me then add, about his objection above, that:
- The considered implementation (which apparently he would be happy to igno= re) didn't take a value "at random" in the available range. I= t just took the first value, as one usually does.
- There is no risk that this value would need to be changed later on, becau= se no other WG currently envisages such a reservation. First come first ser= ved.

Remi,=A0you can't say "th= ese numbers are reserved by IANA", and then say "first come first= served". If they are assigned by IANA, you *can't use them* until= IANA reserves them, period.

If you put one of these numbers in an implementation, y= ou're squatting on a number that IANA has the freedom to assign wheneve= r it wants. As soon as assigns it (which it can and will do with no obligat= ion to tell you), you are in violation of that assignment.
--e89a8fb2028aa7717a04c7f8ab1a-- From despres.remi@laposte.net Thu Aug 23 23:02:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4221F8441 for ; Thu, 23 Aug 2012 23:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo-PMiRb9sy7 for ; Thu, 23 Aug 2012 23:02:42 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1709821F843C for ; Thu, 23 Aug 2012 23:02:41 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 99A11700013A; Fri, 24 Aug 2012 08:02:40 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 0EF8F7000132; Fri, 24 Aug 2012 08:02:40 +0200 (CEST) X-SFR-UUID: 20120824060240614.0EF8F7000132@msfrf2314.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-44-261256071 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 24 Aug 2012 08:02:39 +0200 Message-Id: <685A5F9F-9E5D-47E1-A754-C58C604E5694@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@laposte.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> <50365833.6050605@globis.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , v6ops WG , Bjoern Zeeb Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 06:02:43 -0000 --Apple-Mail-44-261256071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-08-24 03:12, Lorenzo Colitti : > On Fri, Aug 24, 2012 at 2:19 AM, R=E9mi Despr=E9s = wrote: > Let me then add, about his objection above, that: > - The considered implementation (which apparently he would be happy to = ignore) didn't take a value "at random" in the available range. It just = took the first value, as one usually does. > - There is no risk that this value would need to be changed later on, = because no other WG currently envisages such a reservation. First come = first served. >=20 > Remi, you can't say "these numbers are reserved by IANA", and then say = "first come first served". If they are assigned by IANA, you *can't use = them* until IANA reserves them, period. AFAIK, when the RFC is published, IANA acceptance of documented values = has been checked. Anticipating on RFC publication is each-one's responsibility.=20 Since using the CLAT-specific IID is optional, which it will be with the = proposed MAY, any vendor remains free not to use it before RFC = publication more than ever. > If you put one of these numbers in an implementation, you're squatting = on a number that IANA has the freedom to assign whenever it wants. As = soon as assigns it (which it can and will do with no obligation to tell = you), you are in violation of that assignment. AFAIK, IANA doesn't assign any value without prior IETF request to do = it.=20 If you have indication of the contrary, thanks for sharing this = information. RD --Apple-Mail-44-261256071 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Aug 24, 2012 at 2:19 AM, R=E9mi Despr=E9s = <despres.remi@laposte.net> = wrote:
Let me then add, about his objection above, that:
- The considered implementation (which apparently he would be happy to = ignore) didn't take a value "at random" in the available range. It just = took the first value, as one usually does.
- There is no risk that this value would need to be changed later on, = because no other WG currently envisages such a reservation. First come = first served.

Remi, you can't = say "these numbers are reserved by IANA", and then say "first come first = served". If they are assigned by IANA, you *can't use them* until IANA = reserves them, = period.

AFAIK, when the RFC = is published, IANA acceptance of documented values has been = checked.
Anticipating on RFC publication is each-one's = responsibility. 
Since using the CLAT-specific IID = is optional, which it will be with the proposed MAY, any vendor remains = free not to use it before RFC publication more than = ever.

If you put one of these numbers in an = implementation, you're squatting on a number that IANA has the freedom = to assign whenever it wants. As soon as assigns it (which it can and = will do with no obligation to tell you), you are in violation of that = assignment.

AFAIK, IANA doesn't assign any value = without prior IETF request to do it. 
If you have = indication of the contrary, thanks for sharing this = information.


RD

= --Apple-Mail-44-261256071-- From despres.remi@laposte.net Thu Aug 23 23:02:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84E21F847F for ; Thu, 23 Aug 2012 23:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wSmgV5INUlK for ; Thu, 23 Aug 2012 23:02:51 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id B470621F847D for ; Thu, 23 Aug 2012 23:02:50 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 1CCA97000137; Fri, 24 Aug 2012 08:02:50 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id BA2477000132; Fri, 24 Aug 2012 08:02:49 +0200 (CEST) X-SFR-UUID: 20120824060249762.BA2477000132@msfrf2314.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <50366D64.30609@globis.net> Date: Fri, 24 Aug 2012 08:02:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1ED8183D-F08D-4D69-A8E7-0AFD9431F1DC@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <5034DA3F.8010302@bogus.com> <7220E4A3-10A3-4E86-951D-ED2743A0B072@laposte.net> <452CA979-356D-4838-99BD-E7364470A900@laposte.net> <50365833.6050605@glo bis.net> <50366D64.30609@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: Bjoern Zeeb , v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 06:02:52 -0000 2012-08-23 19:50, Ray Hunter : > Thanks. So to be clear: the reserved IID would NOT be used for any L2 = addressing: just generating an IPv6 address (from the delegated prefix = that is unique per CLAT)? Right. RD >=20 > Otherwise L2 bridges and other devices might get confused (with side = changes and duplicate EUI64 addresses appearing on multiple ports) >=20 > Thinking wireless LTE phone (with built in CLAT) connected to a L2 = switch in parallel with Homenet wired router (with built in CLAT) >=20 >> R=E9mi Despr=E9s >> 23 August 2012 19:19 >> Hi, Ray, >>=20 >> 2012-08-23 18:20, Ray Hunter : >>=20 >>> inline >>>=20 >>> R=E9mi Despr=E9s wrote: >>>> Le 2012-08-23 =E0 11:41, Lorenzo Colitti a =E9crit : >>>>=20 >>>>> On Thu, Aug 23, 2012 at 6:04 PM, R=E9mi = Despr=E9s> = wrote: >>>>>=20 >>>>> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely >>>>> without waiting for IANA having completed its registration. >>>>> Actually, it has already been done, successfully AFAIK >>>>> = (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html >>>>> = ). >>>>>=20 >>>>>=20 >>>>> Excuse me, but that's absurd. First you say that using an IID in = the reserved range is useful because it guarantees collisions, and then = you say that an implementation just picked a random number from this = range and that's fine? What if that number is assigned and the = implementation is not updated? You encounter the very problem that you = want to solve by using a reserved IID. >>>> AFAIK, a value requested by IETF that doesn't conflict with = anything in IANA, is just accepted by IANA. >>>> Unless there would be somewhere in IETF a parallel request for the = same value (which isn't the case) theer is therefore no problem. >>>>=20 >>=20 >>> Are you saying that there can only be ONE CLAT active on any given = L2 link (whether virtual or otherwise) when the reserved IID is used? >>=20 >> NO. >>=20 >> Two CLAT nodes connected to a common WAN link will be delegated = different IPv6 prefixes. Their CLAT IPv6 addresses will have the same = IID but will be different. >>=20 >> Two CLAT nodes connected to a common LAN-side link would have CLAT = IPv6 addresses also based on different IPv6 prefixes. >>=20 >>=20 >>> Seems to me 2 CLATs using a single reserved IID address with manual = configuration are guaranteed to generate duplicate IPv6 addresses if = they are connected to the same L2 link. >>=20 >> A single reserved IID doesn't mean a single reserved address. >>=20 >>> So in a high availability situation of 2 CLATs running in parallel = (active active mode) using the reserved IID would be a problem? >>=20 >> No address problem AFAIK (but OTOH need to continuously synchronize = the two NAT44s) >>=20 >>=20 >>> Are you also saying that 2 CLAT's cannot be cascaded when using the = reserved IID? >>>=20 >>> [because as I read it, the downlink IID has to be disjoint from any = IID used on the upstream interface when attempting to share a single /64 = across 2 interfaces, and the upstream CLAT would have already claimed = the reserved IID that the downstream CLAT wanted to use on its = downstream interface] >>>=20 >>> How would inappropriate cascading or parallel connections be = detected and the downstream/parallel CLAT disabled? >>> [I'm especially thinking VM's and virtual networks] >>>=20 >>> IMHO If these restrictions with the reserved IID are correct, then = the draft should say also note this, and also any requirements on the = implementation on what action to take in these situations. >>=20 >> Well, cascaded CLATs are clearly out of scope for this draft. (CLATs = are v6-only WAN side, and v6+v4p LAN side). >>=20 >> Even if the scope would be extended to support cascaded 464XLAT = domains (in a way to be defined), any problem that exists with a = reserved IID can also exist with IIDs in which the NAT44 external = address is embedded (the proposal if no reserved IID is used). Without = administratively configured parameters, these external addresses can = typically be the same in various CLAT implementations. >>=20 >>=20 >>> I think that's one of Lorenzo's basic points, and I can't say = reading your answer above how I can disagree with him. >>=20 >> My answer above only concerned Lorenzo's objection that the supposed = "red tape" that an IID reservation would need makes it impracticable. >>=20 >> Let me then add, about his objection above, that: >> - The considered implementation (which apparently he would be happy = to ignore) didn't take a value "at random" in the available range. It = just took the first value, as one usually does. >> - There is no risk that this value would need to be changed later on, = because no other WG currently envisages such a reservation. First come = first served. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>>>>> - I really don't think #1 makes sense. You might as well say, >>>>>> "we need to reserve an IID range for routers, because = otherwise, >>>>>> a router's IIDs might already have been taken by a host on the >>>>>> link when the router is switched on, and the router wouldn't = be >>>>>> able to provide service to hosts". We don't do that for = routers. >>>>>> Why should we do it for the CLAT? >>>>> 1. You criticize my point by suggesting that I might have made >>>>> another point which doesn't make sense. This isn't good logic >>>>> AFAIAC. >>>>>=20 >>>>>=20 >>>>> Nope. I criticise your point by pointing out that in a basically = identical problem (a router is turned on and a host on the link has = already picked an IPv6 address with the same IID), we chose to design = DAD instead of using reserved interface IDs. >>>>>=20 >>>>> 2. Routers that use EUI IIDs have normally no collision problem >>>>> because appropriately-configured host cannot collide. (What = they >>>>> do in case of a manually misconfigured host creating a = collision >>>>> on this IID with such an address isn't clear, at last to me, = but >>>>> this isn't the subject.) >>>>>=20 >>>>>=20 >>>>> And the CLAT is not a router? I mean - what's different to the = scenario above where the router is powered up? >>>>>=20 >>>>> Routers that use local-scope IID (are there many, I don't know) >>>>>=20 >>>>>=20 >>>>> Yes. On routers, people like to configure their interface IDs = manually so they can do things like have router IP addresses that don't = change when MAC addresses change (e.g., when interface cards are = swapped). Then they can put them in DNS. >>>> Unmanaged CPEs wouldn't be concerned I suppose. >>>> Anyway, but thanks for the useful info. >>>>=20 >>>>> should better prepared to finding a colliding host. >>>>>=20 >>>>>=20 >>>>> And the CLAT is not a router? >>>> CLAT nodes can be routers, for sure, and this discussion is mainly = about them. >>>>=20 >>>>=20 >>>>> I mean - what's different to the scenario above where the router = is powered up? >>>>>=20 >>>>> But AFAIK you propose the CLAT-node DAD to exclude, at its >>>>> LAN-side interface, not only all its LAN-side addresses, but = also >>>>> its 464XLAT WAN-side address. At a given interface, DAD = normally >>>>> excludes all addresses that are configured on this interface, = and >>>>> only these. Configuring the CLAT-WAN-side address on the = LAN-side >>>>> interface would be a hack whose consequences haven't been >>>>> analyzed AFAIK. >>>>>=20 >>>>>=20 >>>>> I don't think it's a hack. It's no different than doing "interface = clat0 unnumbered wlan0". And it's only one way of doing t >>>> Which way applies to which device, or may be difficult to apply, = isn't a concern if the reserved IID is used. >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>=20 >> = ------------------------------------------------------------------------ >=20 From randy@psg.com Fri Aug 24 03:30:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633A321F86C7 for ; Fri, 24 Aug 2012 03:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHELK6-lcy3b for ; Fri, 24 Aug 2012 03:30:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 09FEA21F86C6 for ; Fri, 24 Aug 2012 03:30:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T4r9d-000BDt-3Q; Fri, 24 Aug 2012 10:30:17 +0000 Date: Fri, 24 Aug 2012 17:30:53 +0700 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20120820152248.GA20997@puck.nether.net> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 10:30:19 -0000 for your amusement, today in the routing worshop in phom penh, the lecture includes rfc 2770 and using only one asn for a large number of customers multi-homed to my network. aside from the benefits i remembered, i was reminded that it even makes peer groups sexier. randy From marc.lampo.ietf@gmail.com Fri Aug 24 04:15:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E906921F86B1 for ; Fri, 24 Aug 2012 04:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4tieleiK3UG for ; Fri, 24 Aug 2012 04:15:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62D4C21F86AF for ; Fri, 24 Aug 2012 04:15:52 -0700 (PDT) Received: by qcac10 with SMTP id c10so1285775qca.31 for ; Fri, 24 Aug 2012 04:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qnKCrrmRjcED9mMdbC1t8BV9T5Ie8DKN3AFlvRZF1b8=; b=fk+f9cMU9I3ebHUmiXQzQk7nX+8XiY4yJa8Pr05cziVEskU+85jFj64HE37testjQc VFG0ot62eVMYmy8QMr8kDihtgTrpdzaFj/vtVRfvzzvig15a0BwHH/e4Wsqj9gpZWs0D mm0kDjp48XpVC3EV7YUzub3VLh5GnBZp96A36wBSDd0e1usjS4rsJmE9VRYs3wK96OLb /TLwDWgdG8OtXIcVA0oz8fgrmoUVUB/1hDIMqgRl/qX8JFvXKen+AsnKthskmSdDJ29Z 92K9/iYy7WZDP5S7w6uYWa4nTuStDSsL8/Y4rWbewixFF++nQlkbTqvtt78Xkvo8Z+cb m6vQ== MIME-Version: 1.0 Received: by 10.224.173.206 with SMTP id q14mr8187326qaz.31.1345806951758; Fri, 24 Aug 2012 04:15:51 -0700 (PDT) Received: by 10.49.133.195 with HTTP; Fri, 24 Aug 2012 04:15:51 -0700 (PDT) Date: Fri, 24 Aug 2012 13:15:51 +0200 Message-ID: From: Marc Lampo To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 11:15:53 -0000 Hello group, now read and reread both RFC's, but I feel not everything is said with respect to ULA. Please clarify, suggest, advice considering the following : - 6092, REC-7 states : "by default, packets with ULA source ... should not be forwarded to ... exterior network." - 6204 recommends customer edge routers implement 6092 (in 4.4, Security Requirement #1) --> (implied) customer edge routers should not forward ULA sources to the Internet. - 6204 also recommends the use of ULA, internally ! (cfr ULA-... requirements, and states (4.1 General Requirements) not to forward ULA over external inteface.) So, how do I interpret this : - ULA internally and NAT (network prefix rewriting) towards the external interface (which would satisfy the requirement of not forwarding ULA source IP over external interface) ((and which offers the benefit of ISP independancy for internal equipment)) or - ULA is for communication between internal devices exclusively. A device that needs Internet connectivity must have public IP (and ULA for internal communication). --> is the (so far : static) address selection table capable of supporting this ? (I understand making address selection table configurable via SLAAC/DHCPv6 are draft's only ?) ((and if I interpret address selection RFC correctly, preference to ULA would be given only if within the same /64 (if "label", in RFC3484 == /64). )) Thanks for positive feedback on this ! Kind regards, Marc Lampo From farmer@umn.edu Fri Aug 24 05:25:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24E21F8668 for ; Fri, 24 Aug 2012 05:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+pX0HKMTmGm for ; Fri, 24 Aug 2012 05:25:11 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2008421F8627 for ; Fri, 24 Aug 2012 05:25:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 24 Aug 2012 07:25:02 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f172.google.com [209.85.210.172] #+LO+TR X-Umn-Classification: local Received: by iabz21 with SMTP id z21so3675395iab.31 for ; Fri, 24 Aug 2012 05:25:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=h2fC3ICNW0dnPrcCK0OQNa3OmT/fH0EMrl2DdcS7bnw=; b=OtAfY6akWqTsh0tp+OyPA+H0m0gZFHa48xaZ7lpyZUmKAbKNHp+hKrg+Q/gnat1fZ1 kawjMgabCgDUu4FLaTnX553TKV/UGsiz4NPGs+b3kUhD+5ZsKzEy6J96xnp/4D99nllV Y2zeLktsniQJMEBqwyElUoOy0GiEiYvaL9eY6tKojEz4UoeTWTyDImejl/ixOi0ENULM Ll0pwnciD2tUXklK/GU/IfqXf+ACP+v9Ab9OlEE7Z+8QXbvY3bb74wGqCEHb7S6xTYwd Xv6QOuHuXR1wjJjY8M42X/XVtGxxy6Hj6rNvTIpk4rWrKFNnmG7eGKtcTQfwA7pXwtEM eZKw== Received: by 10.50.217.201 with SMTP id pa9mr1923565igc.54.1345811102324; Fri, 24 Aug 2012 05:25:02 -0700 (PDT) Received: from oit200959392-2.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id ch4sm2060849igb.2.2012.08.24.05.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 05:25:01 -0700 (PDT) Message-ID: <5037729C.5010705@umn.edu> Date: Fri, 24 Aug 2012 07:25:00 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Bush References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlNRHetlw0Gs498T7dFGIl1SqBSdZwco0CbbM2BEn9OkeE2TfRqrct7Sp4w9JP1ZE3D3gMp Cc: v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:25:11 -0000 On 8/24/12 05:30 CDT, Randy Bush wrote: > for your amusement, today in the routing worshop in phom penh, the > lecture includes rfc 2770 and using only one asn for a large number > of customers multi-homed to my network. aside from the benefits i > remembered, i was reminded that it even makes peer groups sexier. Sorry but I'm confused, RFC 2770 is about GLOP Multicast Addressing, which was obsoleted by RFC 3180, how does that apply to this discussion? Did you mean RFC 5065 - Autonomous System Confederations for BGP or RFC 2796 - BGP Route Reflection - An Alternative to Full Mesh IBGP obsoleted by RFC 4456, or maybe something else? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From randy@psg.com Fri Aug 24 05:45:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B933421F86C2 for ; Fri, 24 Aug 2012 05:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CvjZVuuheig for ; Fri, 24 Aug 2012 05:45:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD221F86C6 for ; Fri, 24 Aug 2012 05:45:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T4tGq-000Bkg-Ev; Fri, 24 Aug 2012 12:45:53 +0000 Date: Fri, 24 Aug 2012 19:46:27 +0700 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <5037729C.5010705@umn.edu> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:45:56 -0000 >> for your amusement, today in the routing worshop in phom penh, the >> lecture includes rfc 2770 and using only one asn for a large number >> of customers multi-homed to my network. aside from the benefits i >> remembered, i was reminded that it even makes peer groups sexier. sorry, 2270 From ichiroumakino@gmail.com Fri Aug 24 05:58:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC5B21F855E for ; Fri, 24 Aug 2012 05:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC3T-WLEeavJ for ; Fri, 24 Aug 2012 05:58:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75BA821F8581 for ; Fri, 24 Aug 2012 05:58:19 -0700 (PDT) Received: by eaai11 with SMTP id i11so547870eaa.31 for ; Fri, 24 Aug 2012 05:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=FECeDWuUH/g0aG/74xrolzSmg0hONy7lirwBpm35quQ=; b=T++r5aGKyVYFRogo+HXb6mYoUXffJCydDjPrVawBcyfRIUC1e+2rYu4Xtdg/EphF2w ruM4he3SwE1sKcSZ3FBiw9RCdVWUt5wZkoArlmN5pe2UKIXi8WCSMYqE9ciRrQju3NhT PbQZIdu07u4GsRsRKumTGh7X5P38uCIR4QVtuf4P72lnhIjlAmmMgUIyBmBwqjGgjRVZ 7cA+Oaa82MHSm1gOLT5wsAQ84KCcfX1bLxM34+k4mxk3wmM19IMqXfMLugr+P7EMv+OY iWjaykU0MTtVqKL46gNf0dcYLeyfvib+j3Qww5eScOvaSpbwOKuKYcOJySI+m0Pd4Re3 mQIw== Received: by 10.14.172.129 with SMTP id t1mr7326781eel.34.1345813098607; Fri, 24 Aug 2012 05:58:18 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:226:bbff:fe6a:c21a? ([2001:420:44ff:fd17:226:bbff:fe6a:c21a]) by mx.google.com with ESMTPS id z6sm29724770eeo.6.2012.08.24.05.58.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 05:58:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_11E35AAB-5818-43F1-B3A6-0E29ED5CFB4A"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 24 Aug 2012 14:58:11 +0200 Message-Id: <4ADE47EE-AE6E-436C-B54E-C5C0327AAE30@employees.org> References: To: Marc Lampo X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:58:20 -0000 --Apple-Mail=_11E35AAB-5818-43F1-B3A6-0E29ED5CFB4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Marc, > now read and reread both RFC's, but I feel not everything is said with > respect to ULA. > Please clarify, suggest, advice considering the following : > - 6092, REC-7 states : > "by default, packets with ULA source ... should not be forwarded to > ... exterior network." >=20 > - 6204 recommends customer edge routers implement 6092 > (in 4.4, Security Requirement #1) > --> (implied) customer edge routers should not forward ULA sources > to the Internet. >=20 > - 6204 also recommends the use of ULA, internally ! > (cfr ULA-... requirements, and states (4.1 General Requirements) > not to forward ULA over external inteface.) >=20 >=20 > So, how do I interpret this : > - ULA internally and NAT (network prefix rewriting) towards the > external interface > (which would satisfy the requirement of not forwarding ULA source IP > over external interface) > ((and which offers the benefit of ISP independancy for internal = equipment)) no. > or > - ULA is for communication between internal devices exclusively. > A device that needs Internet connectivity must have public IP (and > ULA for internal communication). correct. > --> is the (so far : static) address selection table capable of > supporting this ? yes, see http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-06 > (I understand making address selection table configurable via > SLAAC/DHCPv6 are draft's only ?) > ((and if I interpret address selection RFC correctly, preference to > ULA would be given > only if within the same /64 (if "label", in RFC3484 =3D=3D /64). )) within the same /48. cheers, Ole --Apple-Mail=_11E35AAB-5818-43F1-B3A6-0E29ED5CFB4A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODI0MTI1ODEyWjAjBgkqhkiG9w0BCQQxFgQUVKFHxjbR9CD7Sy1F vXxr/6uufZ0wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAZXnhNZuT3d8XC9DOvH6a ogjGw8thbvRSxOoGE3i5Y5s+YFPvZLZkHLVnXF20J7Iz+hKXvDiD9DDJ7Ygo7d8IjHgz0JpnINKt oNme8AfDerTT/rr4vMYZc2LCnyCejp89IIoMZa2912+abaj1T/T97/YPfdQEgjOqdkAFfmB7NHoo zS2Wf0xcjokZ2nCuQXDDksJRyHl03oGd24YKS+6HzTtm09nv8l73IhK+fKgzIZrc2jrNQIBo4EeR p0DbGWw1RK2Kn9CLR5cD2cO67gm55t/HzMUVNltw5ArDrvNZvBvjcUlAOdzY99zIwhpLuWnpEq8g kUsIwWWzJ9S+JtsA/wAAAAAAAA== --Apple-Mail=_11E35AAB-5818-43F1-B3A6-0E29ED5CFB4A-- From farmer@umn.edu Fri Aug 24 06:44:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FE021F86E1 for ; Fri, 24 Aug 2012 06:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRjtv3Ym+ssj for ; Fri, 24 Aug 2012 06:44:15 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD9521F865B for ; Fri, 24 Aug 2012 06:44:15 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 24 Aug 2012 08:44:04 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by mail-iy0-f171.google.com with SMTP id z25so7051900iab.16 for ; Fri, 24 Aug 2012 06:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=eKpbkKpxO40z3CQ1gP7PWAkdFJ5O8r+VmVn94TQEdRc=; b=FBhwc0XrnNRof1VZo24yYR7KhRQFJ3MYJ0a5z9kd7bVe2EZnk8O2kQEpQQSWkYLsNQ QfiEK9BS44Al7Fa7mfUDDtJ5iYNh5Vs1tABuSuwSOt0InJUlLA01UsCA8QWuDKbM5w4b AonTaFHADlOHM5NZXZS/21KVZ4yJ74kakmNlL2JKpHU1IyWevsr/A6hjSULjnlyAEpnd LB3KtBKXEpTHp2tI8r0pwZTky7K/hJOUiOlOckPKe38LJbwYPuEV6/7m4oBaf/MpwqN+ ZkNtUn9UuK7l5KcoQqThmSPWn7jQLh0a56vQHzkFdXnzPo0QQbOOtA3kLbh5bovqv+Ic qJtg== Received: by 10.50.186.196 with SMTP id fm4mr2269517igc.1.1345815844113; Fri, 24 Aug 2012 06:44:04 -0700 (PDT) Received: from oit200959392-2.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id nh1sm2202221igc.11.2012.08.24.06.44.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 06:44:03 -0700 (PDT) Message-ID: <50378521.5060504@umn.edu> Date: Fri, 24 Aug 2012 08:44:01 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Bush References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkUoBrC4OgwB41B43fQnOBUOzHLGVSedryv6BHdjD3ji9YxG3tDWpWs1buNrRqXZyGsD4Ho Cc: v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:44:15 -0000 On 8/24/12 07:46 CDT, Randy Bush wrote: >>> for your amusement, today in the routing worshop in phom penh, the >>> lecture includes rfc 2770 and using only one asn for a large number >>> of customers multi-homed to my network. aside from the benefits i >>> remembered, i was reminded that it even makes peer groups sexier. > > sorry, 2270 Thanks for the correction, I guess my RFC Index searching foo wasn't good enough to catch that one. :( So in the workshop were they suggesting using a private ASN or a public registered ASN for this purpose? Both options are discussed in RFC 2270. Would you suggest the RIRs have policy to allow a separate public registered ASN for this purpose? Are the slides available? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From brian.e.carpenter@gmail.com Fri Aug 24 07:00:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79F21F86C4 for ; Fri, 24 Aug 2012 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.512 X-Spam-Level: X-Spam-Status: No, score=-101.512 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zkHmITfFZpo for ; Fri, 24 Aug 2012 07:00:42 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F241421F8686 for ; Fri, 24 Aug 2012 07:00:41 -0700 (PDT) Received: by eekb45 with SMTP id b45so718674eek.31 for ; Fri, 24 Aug 2012 07:00:40 -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=SJpcKvh/DWZ08SLpRUSbHB6r+g4eSS9bYfhG+c4R0bY=; b=v0IVbpgcrsAI3K1+nSmjRfJBn67EylLhful4JoPQ71zHrctOMAkKdJEjWHr/zUE7wV /JrsA6dQ4zLiiLbciksXldbchLeumacAOIGYoMVsUFKrtYgFDIcnHd5zX4qYtEw2LuKj eSfxLECBrkZLcKAOLxyjQzyF8Ad5W7RLXJsagIXe/FJdQ4W5/zTRGOEbqHWSG/7mNyZa fS1SU0Yl7ZbBkcPyBGJM60cKsONdl6Gh6doJD0I7+mHRFbV/wnwEYwRRA4ro5TuVSYH9 Zw+ki495nawM2pblC/OWvpbmPK67cGC0TzLQBM+KES6sWFd5VS5H2TS3Eu8cxAY9eK5K pvuQ== Received: by 10.14.204.200 with SMTP id h48mr7691824eeo.7.1345816840873; Fri, 24 Aug 2012 07:00:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-59.as13285.net. [2.102.217.59]) by mx.google.com with ESMTPS id e7sm30183350eep.2.2012.08.24.07.00.24 (version=SSLv3 cipher=OTHER); Fri, 24 Aug 2012 07:00:30 -0700 (PDT) Message-ID: <503788FA.8050709@gmail.com> Date: Fri, 24 Aug 2012 15:00:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo References: <4ADE47EE-AE6E-436C-B54E-C5C0327AAE30@employees.org> In-Reply-To: <4ADE47EE-AE6E-436C-B54E-C5C0327AAE30@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:00:43 -0000 Marc, ... >> - ULA is for communication between internal devices exclusively. >> A device that needs Internet connectivity must have public IP (and >> ULA for internal communication). > > correct. You might also want to read draft-liu-v6ops-ula-usage-analysis for more discussion. Brian From randy@psg.com Fri Aug 24 07:54:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432E21F86DB for ; Fri, 24 Aug 2012 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kplbtnK0c73t for ; Fri, 24 Aug 2012 07:54:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 871E821F86CB for ; Fri, 24 Aug 2012 07:54:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T4vHO-000CDC-7T; Fri, 24 Aug 2012 14:54:34 +0000 Date: Fri, 24 Aug 2012 21:55:10 +0700 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <50378521.5060504@umn.edu> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> <50378521.5060504@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:54:39 -0000 > So in the workshop were they suggesting using a private ASN or a > public registered ASN for this purpose? the example used is private, but we try to teach principles. this is common practice in the ops world. > Would you suggest the RIRs have policy to allow a separate public > registered ASN for this purpose? i would hope we would be getting past micromanaging at that level of detail. see http://www.apnic.net/policy/proposals/prop-103 > Are the slides available? well, there is a long trail of this slide set, as pfs has been teaching the bgp workshops for a decade or so. randy From farmer@umn.edu Fri Aug 24 08:19:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49CD21F8683 for ; Fri, 24 Aug 2012 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjzPsSKZdVO0 for ; Fri, 24 Aug 2012 08:19:23 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7221F8469 for ; Fri, 24 Aug 2012 08:19:22 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 24 Aug 2012 10:19:17 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f171.google.com [209.85.214.171] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f171.google.com with SMTP id v19so5090853obq.16 for ; Fri, 24 Aug 2012 08:19:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=A3Ct1C/3RuilzQW4JFdTJkedUsxj3alalWlVNGpyyQg=; b=ET2bS2YI6v0Wl6j+c5VDoYrej7Wh+KqNs/Hn0RBKyToaEDsnzFJk4mJvPt7tTyabwe Jf0SxoQW40B5SXqVYkoEvtCO6+1ZhgvObuzQDE6mjJtBYHyDzhAe3s5vvC3ub0+vCRnu VcN/mvBYAy7MlS4qUh7Bw3qpS0EGk4Bb9NMoxQq3Ox5uO2HOxj8YDx5dMfHFMmJKTiRA bFAXzz5aB9daG2NNvr3UkjlADG8q6/04Ub0aO9zPJSBeKBeyUKhNu/NCxj4IQKzoZNhF 2hgvY0BSA71mG/B87xCbBmrnusJFb66yASc034KVAjlEeAMGvdXtcuEfIKfR2x/7Ecli lqVw== Received: by 10.50.57.194 with SMTP id k2mr2572075igq.32.1345821557070; Fri, 24 Aug 2012 08:19:17 -0700 (PDT) Received: from oit200959392-2.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id i2sm65775igl.8.2012.08.24.08.19.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 08:19:16 -0700 (PDT) Message-ID: <50379B72.3020401@umn.edu> Date: Fri, 24 Aug 2012 10:19:14 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Bush References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> <50378521.5060504@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmYi88xXEmoVaCOmz7bbanjLtZ8ml1wWFnkpS7Axh2hH6w39aZD95yS7H98AUKSJJO20mPt Cc: v6ops list , Jon Mitchell , idr@ietf.org Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:19:23 -0000 On 8/24/12 09:55 CDT, Randy Bush wrote: >> So in the workshop were they suggesting using a private ASN or a >> public registered ASN for this purpose? > > the example used is private, but we try to teach principles. this is > common practice in the ops world. I understand, but I thought you we advocating that people shouldn't use private ASNs and therefore we don't need an additional 4-byte ASN block. Did I misunderstand you? Using Private ASNs relies on the Private ASN filtering many implementations have. If you use a Public ASN are there common tools to filter a Public ASN as the RFC suggests you do? I'm not aware of them, so I'm asking. >> Would you suggest the RIRs have policy to allow a separate public >> registered ASN for this purpose? > > i would hope we would be getting past micromanaging at that level of > detail. see http://www.apnic.net/policy/proposals/prop-103 Well APNIC requires multihoming to receive and ASN as do all of the other RIRs as far as I know. From: http://www.apnic.net/policy/asn-policy ; ----- 5. Eligibility for ASN assignment An organization is eligible for an ASN assignment if it: a. is multihomed; and b. has a single, clearly defined routing policy that is different from its providers' routing policies. An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter). ----- So the problem is ASNs are already micro-manged by the RIRs, should we relieve some of the micro-management? Maybe go back to the only requiring a unique routing policy with or without multihoming, before discontinuing any policy changes. :) We really shouldn't pollute the IETF list with RIR policy discussions, but I believe if we don't provide a bigger 4-byte Private ASN range then we need to reform the RIR ASN policy regime. Personally, I prefer both, but I'm trying to understand what you suggest the right thing to do is. >> Are the slides available? > > well, there is a long trail of this slide set, as pfs has been teaching > the bgp workshops for a decade or so. The PFS pointer is enough Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From dan-v6ops@drown.org Fri Aug 24 08:36:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3221F86DB for ; Fri, 24 Aug 2012 08:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oimPyGy9+cmj for ; Fri, 24 Aug 2012 08:36:56 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23921F86CB for ; Fri, 24 Aug 2012 08:36:56 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id E3E47C0F2; Fri, 24 Aug 2012 11:36:55 -0400 (EDT) Received: from 2001:470:b9fd:2:7aac:c0ff:fe97:ce69 ([2001:470:b9fd:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Fri, 24 Aug 2012 10:36:55 -0500 Message-ID: <20120824103655.20726nu28uh3osws@mail.drown.org> Date: Fri, 24 Aug 2012 10:36:55 -0500 From: Dan Drown To: jouni korhonen References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@lap oste.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:36:57 -0000 Quoting jouni korhonen : > Just for my understanding how this in cellular uplink case would be > different from RFC4389 scenario 2 (where the upstream is PPP)? RFC4389 scenario 2 is built on the assumption that the same /64 is on both sides of the ppp link. Cell network p2p case is the entire /64 is routed to the handset, and there is no "rest of network" accross the cell uplink to proxy NDs from tethered clients. From dan-v6ops@drown.org Fri Aug 24 09:03:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6918E21F859A for ; Fri, 24 Aug 2012 09:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBilX4c9-Jiv for ; Fri, 24 Aug 2012 09:03:06 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25921F8575 for ; Fri, 24 Aug 2012 09:03:06 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id D9921C0F2; Fri, 24 Aug 2012 12:02:58 -0400 (EDT) Received: from 2001:470:b9fd:2:7aac:c0ff:fe97:ce69 ([2001:470:b9fd:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Fri, 24 Aug 2012 11:02:58 -0500 Message-ID: <20120824110258.119063h58njifr8k@mail.drown.org> Date: Fri, 24 Aug 2012 11:02:58 -0500 From: Dan Drown To: Lorenzo Colitti References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:03:06 -0000 Quoting Lorenzo Colitti : > Fair enough. But that doesn't require a special EUI-64 to be allocated, > right? All you need is an IPv6 address that can be defended against DAD. > Can we then just say "if the CLAT picks an IPv6 address to use on the LAN > side, then it must make sure to reply to DAD on that address"? You are correct that a EUI-64 isn't required to make 464xlat possible. Responding to DAD (using proxy ND) is another way to solve this problem. From despres.remi@laposte.net Fri Aug 24 10:12:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75E21F86EC for ; Fri, 24 Aug 2012 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvVPkJSX2uhJ for ; Fri, 24 Aug 2012 10:12:38 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86421F86B7 for ; Fri, 24 Aug 2012 10:12:35 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8CF89940189; Fri, 24 Aug 2012 19:12:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120824110258.119063h58njifr8k@mail.drown.org> Date: Fri, 24 Aug 2012 19:12:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56F3DA56-891C-40A5-841D-D60AD14D318B@laposte.net> References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <20120817094953.10350hmgauyyi9e8@mail.drown.org> <20120824110258.119063h58njifr8k@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:12:38 -0000 2012-08-24 18:02, Dan Drown : > Quoting Lorenzo Colitti : >> Fair enough. But that doesn't require a special EUI-64 to be = allocated, >> right? All you need is an IPv6 address that can be defended against = DAD. >> Can we then just say "if the CLAT picks an IPv6 address to use on the = LAN >> side, then it must make sure to reply to DAD on that address"? >=20 > You are correct that a EUI-64 isn't required to make 464xlat possible. = Responding to DAD (using proxy ND) is another way to solve this = problem. Note that your proposal (with proxy ND) differs Lorenzo's who said "the = CLAT does not need to perform ND proxying".=20 One can try, as you suggest, to avoid limitations of DAD alone by adding = ND proxy.=20 However: 1. ND proxy if for link-layer bridges (RFC 4389). Addresses that are = refused by the DAD of an ND proxy at an interface are accepted as = destinations through that interface, while the CLAT IPv6 address MUST = NOT be an accepted destination bridged to the CLAT. Using ND proxy to = exclude this address is therefore out of ND-proxy scope. Some hack would = need to be added for its use in 464XLAT. (Besides, this doesn't solve = the issue of a host having the CLAT IPv6 address before 464XLAT is = activated). 2. With a CLAT-specific EUI-64 there is no such problem(. DAD works as = usual; no ND proxy is needed; no host may have the CLAT IPv6 address.=20 All what is necessary is reserving a value in in a range already = available for such reservations (a trivial thing to do once decided). =20 =3D> The CLAT EUI-64 is required to permit those who prefer a simple and = safe implementation to have it. Anything missed? Regards, RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Fri Aug 24 10:36:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58B221F871E for ; Fri, 24 Aug 2012 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8QHIHO-zOgU for ; Fri, 24 Aug 2012 10:36:33 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0942721F86AD for ; Fri, 24 Aug 2012 10:36:32 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C3809F8C95 for ; Fri, 24 Aug 2012 19:36:30 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 87863F8C93 for ; Fri, 24 Aug 2012 19:36:30 +0200 (CEST) Received: (qmail 1522 invoked by uid 1007); 24 Aug 2012 19:36:30 +0200 Date: Fri, 24 Aug 2012 19:36:30 +0200 From: Gert Doering To: David Farmer Message-ID: <20120824173630.GQ13776@Space.Net> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> <50378521.5060504@umn.edu> <50379B72.3020401@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50379B72.3020401@umn.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org, v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:36:34 -0000 Hi, On Fri, Aug 24, 2012 at 10:19:14AM -0500, David Farmer wrote: > So the problem is ASNs are already micro-manged by the RIRs, should we > relieve some of the micro-management? Maybe go back to the only > requiring a unique routing policy with or without multihoming, before > discontinuing any policy changes. :) How can you have a unique routing policy without multihoming? (Well, technically you could single-home, and null-route some prefixes to make your routing different from that of your single upstream, but I wouldn't count that as "unique routing policy" in the spirit of the policy) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From randy@psg.com Fri Aug 24 18:14:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19421F851E; Fri, 24 Aug 2012 18:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdYOpoICt7A5; Fri, 24 Aug 2012 18:14:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6807021F8518; Fri, 24 Aug 2012 18:14:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T54xP-000FDM-Nv; Sat, 25 Aug 2012 01:14:36 +0000 Date: Sat, 25 Aug 2012 08:15:14 +0700 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <50379B72.3020401@umn.edu> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <5037729C.5010705@umn.edu> <50378521.5060504@umn.edu> <50379B72.3020401@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 01:14:38 -0000 >>> So in the workshop were they suggesting using a private ASN or a >>> public registered ASN for this purpose? >> >> the example used is private, but we try to teach principles. this is >> common practice in the ops world. > > I understand, but I thought you we advocating that people shouldn't use > private ASNs and therefore we don't need an additional 4-byte ASN > block. > Did I misunderstand you? yes, you misunderstand me the point of my post is that one asn is sufficient randy From jouni.nospam@gmail.com Sat Aug 25 02:21:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C982721F84F9 for ; Sat, 25 Aug 2012 02:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbQy6W2-aJDQ for ; Sat, 25 Aug 2012 02:21:01 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67221F84F5 for ; Sat, 25 Aug 2012 02:21:00 -0700 (PDT) Received: by eaai11 with SMTP id i11so754456eaa.31 for ; Sat, 25 Aug 2012 02:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rVrTo3P8XjbDIHwgqmYSRjWQl64/9x8S74LddRHRHKk=; b=YXXJcpCuh+o4Qd9P2HNLJLRGolY0VaetYo769SUqiTeVSurhYEf5F7PW2YrdTnQWbG aWBs7ZjbTtJUeMPJXj3KqwmvrvkzWzlSLNGrtX8G4r07M3OoLBn8sOq0ETAYrSGeEG4z fiEq9uWGRCnrlzdr9TJevU/DHH24WuqFhtLFSD8AL/LOuCEVKWXxDFpJeE5YR9HaJz/9 3KnSIgBxo637xZSSjcz3nFmjZ/5lB/ak+FQHlyjDnCq9bIKY1aUk6qa15ET3izrHUXCd A0P9bP/99ihmIqvDzoDYQYxLwkvrC474klm3MVvfQWwXFdPu0jyrNTW504Lvt7OUDX3I mgqg== Received: by 10.14.218.134 with SMTP id k6mr10717732eep.14.1345886460200; Sat, 25 Aug 2012 02:21:00 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 9sm36084959eei.12.2012.08.25.02.20.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Aug 2012 02:20:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120824103655.20726nu28uh3osws@mail.drown.org> Date: Sat, 25 Aug 2012 12:20:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807043532.13992.49901.idtracker@ietfa.amsl.com> <7B9C405E-A3AA-4245-BB95-8999644E9345@laposte.net> <90D1540F-7FE8-418A-9D0E-C6032CA68E50@laposte.net> <992AEE52-C5AC-4781-AAF2-6591D564AC70@laposte.net> <841FB780-66DE-4008-9699-89FEDBA53EA7@cisco.com> <502A5E4E.6060004@gmail.com> <44236D46-E857-4DA4-AE4F-87FD280073B0@laposte.net> <20120815102859.94085azox3126tc0@mail.drown.org> <20120816090542.15476bo43zcr7aww@mail.drown.org> <9D1E0BE7-1EC6-4A58-8D54-C8D2263C0308@lap oste.net> <2DF8CB76-7D3B-4845-B359-1A3D860B69C7@employees.org> <24DA9ABC-51DF-409A-B193-287C7C87FDC9@laposte.net> <7A9163EE-66E2-4F8B-97B0-4D94C2D2D72C@laposte.net> <85C84E75-21DA-4CBC-AB83-4376B32A35EB@laposte.net> <8644DD6F-CC48-476C-938C-01CA2F372BE4@laposte.net> <20120824103655.20726nu28uh3osws@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 09:21:02 -0000 On Aug 24, 2012, at 6:36 PM, Dan Drown wrote: > Quoting jouni korhonen : >> Just for my understanding how this in cellular uplink case would be = different from RFC4389 scenario 2 (where the upstream is PPP)? >=20 > RFC4389 scenario 2 is built on the assumption that the same /64 is on = both sides of the ppp link. Cell Ok. that clarifies. thanks, - jouni > network p2p case is the entire /64 is routed to the handset, and = there is no "rest of network" accross the cell uplink to proxy NDs from = tethered clients. From shemant@cisco.com Sat Aug 25 08:54:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9E21F84CE for ; Sat, 25 Aug 2012 08:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy7WvUl3hlkL for ; Sat, 25 Aug 2012 08:54:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C89EE21F8463 for ; Sat, 25 Aug 2012 08:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6193; q=dns/txt; s=iport; t=1345910065; x=1347119665; h=from:to:subject:date:message-id:mime-version; bh=+ZNvI+KiJ3RwLRvCvPRu5VPx3hWnj62Ein1TpDrCLcQ=; b=f6nFZGEuW3EQJzKTdW+r2yHjulpGHqteceYUt4B/wS/xALf4Q92iPchZ G7nnA14Nu5J7Qob5dBzK8cc4/jMwUu0Y2t0OTbDmGMtjWSfdtTgN3h3l7 8fd+XB6Iw8wuH3+xOppzUMgeuv90ZN9NsoUY6Qeq0PCAZMvxUuUIQ7hhc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAF30OFCtJV2Y/2dsb2JhbABFgkq4IYEHgiIBBBIBGl4BKlYmAQQbDA6Ha5pGgSifXZE5YAOkA4FngmM X-IronPort-AV: E=Sophos;i="4.80,311,1344211200"; d="scan'208,217";a="115232030" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 25 Aug 2012 15:54:24 +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 q7PFsOqp026730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 25 Aug 2012 15:54:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Sat, 25 Aug 2012 10:54:24 -0500 From: "Hemant Singh (shemant)" To: "v6ops@ietf.org" Thread-Topic: single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2C2eT6WUBzFQYeRdSnitTvYLhR+Q== Date: Sat, 25 Aug 2012 15:54:23 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19136.006 x-tm-as-result: No--35.029700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B890779FBxmbrcdx06ciscocom_" MIME-Version: 1.0 Subject: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 15:54:26 -0000 --_000_75B6FA9F576969419E42BECB86CB1B890779FBxmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do have to start a new thread to focus this ND Proxy discussion with 464x= lat. Elide the use case of a single /64 from the document and then the fo= llowing go away too. 1. ND Proxy 2. RFC 4389 3. Single /64 allocated to the CLAT During the IPv6 CPE router specification development, for a long time, some= folks from the 3GPPP community asked us to add a use case for a single /64= and ND Proxy to rfc6204. However, after more careful study, a consensus w= as reached to remove the single /64 use case from rfc6204 and rfc6204bis. = Additionally, I am told the IETF endorses the DHCPv6 PD model over a sin= gle /64. A single /64 cannot be supported on a CPE/CLAT because then the CPE has to = proxy the RA to hosts in the LAN or tethered segment. There is no document= on a Standards Track in the IETF that defines how to proxy an RA. I am as= suming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in the = wireless service provider domain. If the cellular network does not issue = an RA to the CLAT/UE/CPE, how does the UE know it's ipv6 default router? = How is the /64 assigned to the CLAT? Hemant --_000_75B6FA9F576969419E42BECB86CB1B890779FBxmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do have to start a new thread to focus this ND Pro= xy discussion with 464xlat.   Elide the use case of a single /64 = from the document and then the following go away too.

 

1.      ND Proxy

2.      RFC 4389

3.      Single /64 allocated to the CLAT

 

During the IPv6 CPE router specification development= , for a long time, some folks from the 3GPPP community asked us to add a us= e case for a single /64 and ND Proxy to rfc6204.  However, after more = careful study, a consensus was reached to remove the single /64 use case from rfc6204 and rfc6204bis.  = Additionally, I am told the IETF  endorses the  DHCPv6 PD model = over a single /64. 

 

A single /64 cannot be supported on a CPE/CLAT becau= se then the CPE has to proxy the RA to hosts in the LAN or tethered segment= .  There is no document on a Standards Track in the IETF that defines = how to proxy an RA.  I am assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in the wireless s= ervice provider domain.   If the cellular network does not issue = an RA to the CLAT/UE/CPE, how does the UE know it’s ipv6 default rout= er?   How is the /64 assigned to the CLAT? 

 

Hemant

--_000_75B6FA9F576969419E42BECB86CB1B890779FBxmbrcdx06ciscocom_-- From cb.list6@gmail.com Sat Aug 25 09:48:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75621F84C8 for ; Sat, 25 Aug 2012 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTsMU0OCkT9X for ; Sat, 25 Aug 2012 09:48:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEFD21F84C2 for ; Sat, 25 Aug 2012 09:48:11 -0700 (PDT) Received: by lbky2 with SMTP id y2so1011332lbk.31 for ; Sat, 25 Aug 2012 09:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cII3yQSIVIz2BIdkSfpSGS1u/PMECwP6Zuo2N7CZxUg=; b=dxQGXk5i2BzRCR25ag0VRgKKOrLlHzk3NTApTCC95JZrfKpBXPQ8SZNOFBWDdbEKsI cdnfkJw14EOu9M9ZguOYf9M70txabFeuIPsuKHg/fvPfGS4nXPzMokPxm3Lg/fe5ZDEY ta3JbUKSRRZ8tYHbUz71G1NGQUuKQ+m2RZC/xfQGhKEE14cXXtfX3faOu1f4lTEdaPeA Mi7mZ+VsCM4uJtlV9u6NRzhEHdbZvi1a972KhdQN8DVfvh2ZHAURWatC6j1CTbwHPF+z I02lliak17GzYaR6KQrJ5PYTVp8qizqYI1meItY/JzFHT3gIjjFTXhkKw5AXB2eiOnKX wPVg== MIME-Version: 1.0 Received: by 10.152.110.46 with SMTP id hx14mr9259212lab.21.1345913290410; Sat, 25 Aug 2012 09:48:10 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sat, 25 Aug 2012 09:48:10 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> Date: Sat, 25 Aug 2012 09:48:10 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 16:48:12 -0000 On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant) wrote: > I do have to start a new thread to focus this ND Proxy discussion with > 464xlat. Elide the use case of a single /64 from the document and then = the > following go away too. > > > > 1. ND Proxy > > 2. RFC 4389 > > 3. Single /64 allocated to the CLAT > > Single /64 is the reality of many of today's access networks, and specifically important is all deployed 3GPP networks work this way for IPv6. Note, there are no known Release 10 networks deployed or any known support of 3GPP DHCP-PD, AFAIK. It is known that IPv4 resources are exhausted in APNIC, and soon to be so in RIPE and then ARIN. So, there is no point in waiting for perfect. A single /64 is the only reality we know in 3GPP, and is therefore the most concrete thing we have for this BCP, which includes running code / running network. http://tools.ietf.org/html/rfc6459#section-5.3 5.3. Prefix Delegation IPv6 prefix delegation is a part of Release-10 and is not covered by any earlier releases. However, the /64 prefix allocated for each default bearer (and to the UE) may be shared to the local area network by the UE implementing Neighbor Discovery proxy (ND proxy) [RFC4389] functionality. > > During the IPv6 CPE router specification development, for a long time, so= me > folks from the 3GPPP community asked us to add a use case for a single /6= 4 > and ND Proxy to rfc6204. However, after more careful study, a consensus = was > reached to remove the single /64 use case from rfc6204 and rfc6204bis. > Additionally, I am told the IETF endorses the DHCPv6 PD model over a > single /64. > > I am also told the IETF endorses dual-stack > > A single /64 cannot be supported on a CPE/CLAT because then the CPE has t= o > proxy the RA to hosts in the LAN or tethered segment. There is no docume= nt > on a Standards Track in the IETF that defines how to proxy an RA. I am Is a standard tack document required? I assume the point you are trying to make is that rfc4389 is experimental status. > assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in = the > wireless service provider domain. If the cellular network does not issu= e > an RA to the CLAT/UE/CPE, how does the UE know it=92s ipv6 default router= ? > How is the /64 assigned to the CLAT? > > If you are wondering how 3GPP side works, start here rfc6459 CB > > Hemant > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From v6ops@globis.net Sat Aug 25 12:28:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595A221F84A6 for ; Sat, 25 Aug 2012 12:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtmq-CXD5D08 for ; Sat, 25 Aug 2012 12:28:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13C21F847C for ; Sat, 25 Aug 2012 12:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 232B58700AB; Sat, 25 Aug 2012 21:28:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqILBgySZYWi; Sat, 25 Aug 2012 21:27:42 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A057C87005C; Sat, 25 Aug 2012 21:27:42 +0200 (CEST) Message-ID: <50392728.6020002@globis.net> Date: Sat, 25 Aug 2012 21:27:36 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Cameron Byrne References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 19:28:29 -0000 The single /64 deployment model conflicts with previous approved IETF BCP. I was also vocal in the discussion on 6204bis. Specifically: According to BCP 157 RFC6177 "A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months." The single /64 deployment model may be reality of Release-9 3gpp, but should we be producing a new (xlat) BCP that potentially condones bad practice forever? Especially as future releases of 3gpp seem to be moving away from the single /64 deployment model. I'm worried that we'll create issues for Homenet, because an IPv6 wireless LTE mobile phone acting as a CPE router (with built in CLAT and special processing for single /64 working) is pretty likely to connect into a Homenet in parallel to a domestic wired CPE router (with built in CLAT). Can you remove that worry? Does the WG think Lorenzo's and Hemant's vision of a tethered mobile phone as "just another CPE router" the more correct model? regards, Cameron Byrne wrote: > On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant) > wrote: >> I do have to start a new thread to focus this ND Proxy discussion with >> 464xlat. Elide the use case of a single /64 from the document and then the >> following go away too. >> >> >> >> 1. ND Proxy >> >> 2. RFC 4389 >> >> 3. Single /64 allocated to the CLAT >> >> > > Single /64 is the reality of many of today's access networks, and > specifically important is all deployed 3GPP networks work this way for > IPv6. Note, there are no known Release 10 networks deployed or any > known support of 3GPP DHCP-PD, AFAIK. It is known that IPv4 resources > are exhausted in APNIC, and soon to be so in RIPE and then ARIN. So, > there is no point in waiting for perfect. A single /64 is the only > reality we know in 3GPP, and is therefore the most concrete thing we > have for this BCP, which includes running code / running network. > > http://tools.ietf.org/html/rfc6459#section-5.3 > > 5.3. Prefix Delegation > > IPv6 prefix delegation is a part of Release-10 and is not covered by > any earlier releases. However, the /64 prefix allocated for each > default bearer (and to the UE) may be shared to the local area > network by the UE implementing Neighbor Discovery proxy (ND proxy) > [RFC4389] functionality. > >> During the IPv6 CPE router specification development, for a long time, some >> folks from the 3GPPP community asked us to add a use case for a single /64 >> and ND Proxy to rfc6204. However, after more careful study, a consensus was >> reached to remove the single /64 use case from rfc6204 and rfc6204bis. >> Additionally, I am told the IETF endorses the DHCPv6 PD model over a >> single /64. >> >> > > I am also told the IETF endorses dual-stack > >> A single /64 cannot be supported on a CPE/CLAT because then the CPE has to >> proxy the RA to hosts in the LAN or tethered segment. There is no document >> on a Standards Track in the IETF that defines how to proxy an RA. I am > > Is a standard tack document required? I assume the point you are > trying to make is that rfc4389 is experimental status. > >> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in the >> wireless service provider domain. If the cellular network does not issue >> an RA to the CLAT/UE/CPE, how does the UE know it’s ipv6 default router? >> How is the /64 assigned to the CLAT? >> >> > > If you are wondering how 3GPP side works, start here rfc6459 > > CB > >> Hemant >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From shemant@cisco.com Sat Aug 25 12:54:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9921F84A5 for ; Sat, 25 Aug 2012 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqGPxNETXCye for ; Sat, 25 Aug 2012 12:54:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD321F848F for ; Sat, 25 Aug 2012 12:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1337; q=dns/txt; s=iport; t=1345924472; x=1347134072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3fPI+MTDxdNfrzRyUCSVkJLMGeLyEkLMvEWqiMBPjKU=; b=NfzN2HKQXXdx4P9kfFJn9MEwgOP52R5LQJzJWpqK7BjUmoZCusrZo84M nkS60nbPiIt6cw2kIQpn2PGf2qjWFz+rQL8VTyq0mHdmmS8PgyC3tQSbn Nf7Ifatly2U8YaBdShjDJzSpLSssC4cFi3ns+gxZ3shl+xL3BvMwHY56B Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC4sOVCtJXG9/2dsb2JhbABFumuBB4IgAQEBBBIBJz8MBAIBCA4DBAEBCxQJByERFAkIAQEEDgUIARmHXAMMC5wklV8NiU6KJWMahhdgA5QCjGGDIIFngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,311,1344211200"; d="scan'208";a="112251770" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 25 Aug 2012 19:54:32 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7PJsWcu012538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Aug 2012 19:54:32 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Sat, 25 Aug 2012 14:54:32 -0500 From: "Hemant Singh (shemant)" To: Cameron Byrne Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2C2eT6WUBzFQYeRdSnitTvYLhR+QAMWyUAAAUNL6A= Date: Sat, 25 Aug 2012 19:54:31 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89077A7E@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.44] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19136.004 x-tm-as-result: No--34.342700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 19:54:35 -0000 -----Original Message----- From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Saturday, August 25, 2012 12:48 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >I am also told the IETF endorses dual-stack It's comparing apples to oranges. Dual-stack works. The DHCPv6 PD is reco= mmended by the IETF (at least for the IPv6 CPE router document) over a sing= le /64 because a single /64 has issues supporting tethered clients while th= e DHCPv6 PD does not. >Is a standard tack document required? No. >I assume the point you are trying to make is that rfc4389 is experimental = status. Not quite. rfc4389 is experimental because the protocol specified by the d= ocument has issues. The issues were pointed out recently by me to v6ops. = See http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html If one deploys a single /64 to a UE and the UE has to support tethered clie= nts, the UE will have to proxy the RA. How is the proxy RA implemented? N= ote also, that is why the IPv6 protocol WG in 6man is standardizing a DAD p= roxy (draft-ietf-6man-dad-proxy) on standards track but not any ND Proxy wh= ich still stays as experimental. =20 Thanks for the rfc6459 reference.=20 Hemant From cb.list6@gmail.com Sat Aug 25 13:40:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8945421F84F9 for ; Sat, 25 Aug 2012 13:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq-4nEXXoFBt for ; Sat, 25 Aug 2012 13:40:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3830521F84F1 for ; Sat, 25 Aug 2012 13:40:52 -0700 (PDT) Received: by lahm15 with SMTP id m15so1880584lah.31 for ; Sat, 25 Aug 2012 13:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I/f3SvUudfo2/nsy/iHsfaFxP6+FIgHAOyUyiy3itWE=; b=L3AefvirWab90oRwWI1/ZlTeBxlPAh+o0Zr/XuexxJCrCjndxicYzCOfXcTLNF/Om8 1UEMUHM71BiIwhP6jwxp8OwUEhs1sO+1Uf0sdl5KSKjfAv9uh8Bl3JZV0DJ6GOUC70jV ji49gxLjD1tDxQqFnmuUCn+DDMdvWS28/JccRXWxjqash6pvf+lSbnRRLmg+lJ3MtP5G 0Vs5gjBO8RT3rLfLtrrKpH+iN+PiICGUJZ2BMqN/dno1+VAh6NWLU6ziiZGjLlxntJGH ni1FnSPWnA7cTu1nflORZ4umq6Xj6x+cJnYMmFku1vQ4rZoxo89OdxfZ9gBIXrEo1GS9 IScQ== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr9641414lab.31.1345927250933; Sat, 25 Aug 2012 13:40:50 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sat, 25 Aug 2012 13:40:50 -0700 (PDT) In-Reply-To: <50392728.6020002@globis.net> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> Date: Sat, 25 Aug 2012 13:40:50 -0700 Message-ID: From: Cameron Byrne To: Ray Hunter Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 20:40:53 -0000 Hi Ray, On Sat, Aug 25, 2012 at 12:27 PM, Ray Hunter wrote > The single /64 deployment model conflicts with previous approved IETF BCP= . I > was also vocal in the discussion on 6204bis. > > Specifically: According to BCP 157 RFC6177 "A key principle for address > management is that end sites always be able to obtain a reasonable amount= of > address space for their actual and planned usage, and over time ranges > specified in years rather than just months." > Without ND proxy, the amount of address you have is exactly zero for a tethered device in all of today's 3GPP networks. So the question is do we do allow tethering on IPv6 today or do we say "no, IPv6 is future exercise for someone else". Failing to engineer for it now makes yet another chicken-and-egg issue. No customers, no demand, no spec, no gear, no code, ... On my 3GPP Release 7 network, you may tether today with NDproxy and have access to the WAN /64 on your LAN. As soon as kit arrives that can do DHCP-PD, that will be the preferred mechanism. I believe that is clearly documented here: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 IF DHCP-PD available, then use DHCP-PD to grab as much address space as nee= ded Else if NDproxy available, do that Else if EUI-64 reserved address available, do that. > The single /64 deployment model may be reality of Release-9 3gpp, but sho= uld > we be producing a new (xlat) BCP that potentially condones bad practice > forever? Especially as future releases of 3gpp seem to be moving away fro= m > the single /64 deployment model. >e It does not condone NDproxy forever, i believe the current text is clear that DHCP-PD is the preferred path. Given that that the preferred path is only available in vaporware on 3GPP networks and this is a BCP, we documented what we know to work in a 3GPP network for real .. with real code .. .real customers .... real production network. While, at the same time, saying DHCP-PD is the best path when available > I'm worried that we'll create issues for Homenet, because an IPv6 wireles= s > LTE mobile phone acting as a CPE router (with built in CLAT and special > processing for single /64 working) is pretty likely to connect into a > Homenet in parallel to a domestic wired CPE router (with built in CLAT). > Homenet has a lot of work to do on many fronts, and finding network boundaries is one of their most active areas of research > Can you remove that worry? > I hope i already have. > Does the WG think Lorenzo's and Hemant's vision of a tethered mobile phon= e > as "just another CPE router" the more correct model? I have my reservations about the commercial reality of multi-homing for residential use, but i think it is viable. CB > regards, > > > Cameron Byrne wrote: >> >> On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant) >> wrote: >>> >>> I do have to start a new thread to focus this ND Proxy discussion with >>> 464xlat. Elide the use case of a single /64 from the document and the= n >>> the >>> following go away too. >>> >>> >>> >>> 1. ND Proxy >>> >>> 2. RFC 4389 >>> >>> 3. Single /64 allocated to the CLAT >>> >>> >> >> Single /64 is the reality of many of today's access networks, and >> specifically important is all deployed 3GPP networks work this way for >> IPv6. Note, there are no known Release 10 networks deployed or any >> known support of 3GPP DHCP-PD, AFAIK. It is known that IPv4 resources >> are exhausted in APNIC, and soon to be so in RIPE and then ARIN. So, >> there is no point in waiting for perfect. A single /64 is the only >> reality we know in 3GPP, and is therefore the most concrete thing we >> have for this BCP, which includes running code / running network. >> >> http://tools.ietf.org/html/rfc6459#section-5.3 >> >> 5.3. Prefix Delegation >> >> IPv6 prefix delegation is a part of Release-10 and is not covered by >> any earlier releases. However, the /64 prefix allocated for each >> default bearer (and to the UE) may be shared to the local area >> network by the UE implementing Neighbor Discovery proxy (ND proxy) >> [RFC4389] functionality. >> >>> During the IPv6 CPE router specification development, for a long time, >>> some >>> folks from the 3GPPP community asked us to add a use case for a single >>> /64 >>> and ND Proxy to rfc6204. However, after more careful study, a consensu= s >>> was >>> reached to remove the single /64 use case from rfc6204 and rfc6204bis. >>> Additionally, I am told the IETF endorses the DHCPv6 PD model over a >>> single /64. >>> >>> >> >> I am also told the IETF endorses dual-stack >> >>> A single /64 cannot be supported on a CPE/CLAT because then the CPE has >>> to >>> proxy the RA to hosts in the LAN or tethered segment. There is no >>> document >>> on a Standards Track in the IETF that defines how to proxy an RA. I am >> >> >> Is a standard tack document required? I assume the point you are >> trying to make is that rfc4389 is experimental status. >> >>> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router i= n >>> the >>> wireless service provider domain. If the cellular network does not >>> issue >>> an RA to the CLAT/UE/CPE, how does the UE know it=92s ipv6 default rout= er? >>> How is the /64 assigned to the CLAT? >>> >>> >> >> If you are wondering how 3GPP side works, start here rfc6459 >> >> CB >> >>> Hemant >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> > From markzzzsmith@yahoo.com.au Sat Aug 25 15:32:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAFE21F8469 for ; Sat, 25 Aug 2012 15:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XInstPLSOtH0 for ; Sat, 25 Aug 2012 15:31:59 -0700 (PDT) Received: from nm24-vm1.bullet.mail.ne1.yahoo.com (nm24-vm1.bullet.mail.ne1.yahoo.com [98.138.90.45]) by ietfa.amsl.com (Postfix) with SMTP id 5A91121F8466 for ; Sat, 25 Aug 2012 15:31:59 -0700 (PDT) Received: from [98.138.90.50] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 22:31:54 -0000 Received: from [98.138.87.8] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 22:31:54 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 25 Aug 2012 22:31:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 784415.26180.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 99834 invoked by uid 60001); 25 Aug 2012 22:31:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1345933914; bh=7VMwk/UTe5S7EWGCbE3e/JDnswFZc8sxEAfPa7dSn7k=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AFlbBnF79Ite4SQIDLru1PskN1Ixi6MpudAN1r2nT7HfraSRQgt99T85Taqy9DMC7L0g3RciI1HZlR68VEtzJPcrORzcMxK3yNhHcggMTZYZaGX9JftDBBTUUyFrRTg/evv5/wBiJK3bPcsi/jzJrGcviyyQiWFIQoAX2P/fI6g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pPmdzXS1Huqh8MK28lFyf4jc1rPJyQ9HodVy/5FMKa8NPBv/TJuOM+1z9zquh6j9JxihK9mcqrnzVS7Zf3SHUJE1cFCPom5k2YvrbJVwdlQvZMUgm69C55x+/4SLPYgrHR33MkOlqYnddAV5ZqHYnLS+2HkdgNyTVBEjbvul9QU=; X-YMail-OSG: 4fOorWsVM1lvQiYRArSUMc7SRLFa2GrnsOfXKLitsug7ztt XO_f5QeT7qwl3DltvSMbT5CvwAv56S1MSiSy1w09ZmPvF8pvGwPlsb_ok08M gH9k0zcf.Y2IMy5zhvcwcOlKtNn7NsdrvWADn9n8_2l.GUO2Ky8_hwi42lDo qNApftJyQrAdnzwugq7yc0b4uavyKDokqBNeuhU344IeT0O5q1oGfRvv_ojH oSanhrOLC3SCsM5TnykyVzmYjFhNaeiY9DWOKxLfWWdxjh4BNl.21oeNX1Hx cgJl2SCGGmU7b6tj3QYDD6qZCPOX77k7rHNsI6ATxAflk2FonmqA7D97XTW_ OD8Mp.QUs.KCCk8GfYLRAt5VQH7NQsLjBCHrREE3MZljZr5ITfmvF9afLTR0 q8F8Znmby5Jz0l0RZXjO_DGXaupR3spSAy6Gklbpw1D2PpXwYxuZfF613Huf GiFDuQfLplQAyS5kYzHPevN32ta5RGK7mFuUKygqXpbnI Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Sat, 25 Aug 2012 15:31:53 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> Message-ID: <1345933913.99269.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Sat, 25 Aug 2012 15:31:53 -0700 (PDT) From: Mark ZZZ Smith To: Ray Hunter , Cameron Byrne In-Reply-To: <50392728.6020002@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 22:32:00 -0000 ----- Original Message -----=0A=0A> From: Ray Hunter =0A>= To: Cameron Byrne =0A> Cc: "v6ops@ietf.org" =0A> Sent: Sunday, 26 August 2012 5:27 AM=0A> Subject: Re: [v6ops] si= ngle /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt=0A>=C2=A0=0A=0A=0A=0A> =0A> Does the WG think Lorenzo's and Hemant's vision of a tethere= d mobile =0A> phone as "just another CPE router" the more correct model?=0A= >=C2=A0=0A=0AI think it is. A "Smartphone" isn't really a "phone", it is a = portable personal computer that can make phone calls. With multiple network= interfaces (*G, Wifi, bluetooth) they can easily become multi-homed hosts = or routers just with a bit of the right software.=0A=0AWhen we re-redid the= RADIUS authentication and accounting systems at Internode to support IPv6 = we allowed for the DHCPv6-PD transaction to occur at any time after the ses= sion had started. This was to allow for a mobile device to change from havi= ng a host role at the start of the session to a router role later in the se= ssion (and allowed for it to change back). The use case was tethering. (And= to make IPv4/IPv6 support more robust, during the development of this "occ= asional" DHCPv6-PD support, we also allowed for IPv4 and IPv6 to appear and= disappear during the life of the PPP session, because PPP supports that to= o).=0A=0AThe GUA SLAAC on the link to the customer's device + DHCPv6-PD GUA= prefix method of address assignment supports direct attachment of hosts (l= aptops, smartphones, desktops), routers (e.g. ADSL CPE) and hosts that migh= t turn into routers and then turn back into hosts (smartphones).=0A=0ARegar= ds,=0AMark.=0A=0A> regards,=0A> =0A> Cameron Byrne wrote:=0A>> On Sat, Aug= 25, 2012 at 8:54 AM, Hemant Singh (shemant)=0A>> =C2= =A0 wrote:=0A>>> I do have to start a new thread to focus this ND Proxy di= scussion with=0A>>> 464xlat.=C2=A0 Elide the use case of a single /64 fro= m the document and =0A> then the=0A>>> following go away too.=0A>>> =0A>>>= =0A>>> =0A>>> 1.=C2=A0 =C2=A0 =C2=A0 ND Proxy=0A>>> =0A>>> 2.=C2=A0 =C2= =A0 =C2=A0 RFC 4389=0A>>> =0A>>> 3.=C2=A0 =C2=A0 =C2=A0 Single /64 allocat= ed to the CLAT=0A>>> =0A>>> =0A>> =0A>> Single /64 is the reality of many = of today's access networks, and=0A>> specifically important is all deploye= d 3GPP networks work this way for=0A>> IPv6.=C2=A0 Note, there are no know= n Release 10 networks deployed or any=0A>> known support of 3GPP DHCP-PD, = AFAIK.=C2=A0 It is known that IPv4 resources=0A>> are exhausted in APNIC, = and soon to be so in RIPE and then ARIN.=C2=A0 So,=0A>> there is no point = in waiting for perfect. A single /64 is the only=0A>> reality we know in 3= GPP, and is therefore the most concrete thing we=0A>> have for this BCP, w= hich includes running code / running network.=0A>> =0A>> http://tools.ietf= .org/html/rfc6459#section-5.3=0A>> =0A>> 5.3.=C2=A0 Prefix Delegation=0A>>= =0A>> =C2=A0 =C2=A0 IPv6 prefix delegation is a part of Release-10 and is= not covered by=0A>> =C2=A0 =C2=A0 any earlier releases.=C2=A0 However, th= e /64 prefix allocated for each=0A>> =C2=A0 =C2=A0 default bearer (and to = the UE) may be shared to the local area=0A>> =C2=A0 =C2=A0 network by the = UE implementing Neighbor Discovery proxy (ND proxy)=0A>> =C2=A0 =C2=A0 [RF= C4389] functionality.=0A>> =0A>>> During the IPv6 CPE router specification= development, for a long time, =0A> some=0A>>> folks from the 3GPPP commun= ity asked us to add a use case for a single =0A> /64=0A>>> and ND Proxy to= rfc6204.=C2=A0 However, after more careful study, a =0A> consensus was=0A>= >> reached to remove the single /64 use case from rfc6204 and rfc6204bis.= =0A>>> Additionally, I am told the IETF=C2=A0 endorses the=C2=A0 DHCPv6 PD= model over a=0A>>> single /64.=0A>>> =0A>>> =0A>> =0A>> I am also told t= he IETF endorses dual-stack=0A>> =0A>>> A single /64 cannot be supported o= n a CPE/CLAT because then the CPE has =0A> to=0A>>> proxy the RA to hosts = in the LAN or tethered segment.=C2=A0 There is no =0A> document=0A>>> on a= Standards Track in the IETF that defines how to proxy an RA.=C2=A0 I am=0A= >> =0A>> Is a standard tack document required?=C2=A0 I assume the point yo= u are=0A>> trying to make is that rfc4389 is experimental status.=0A>> =0A= >>> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router = =0A> in the=0A>>> wireless service provider domain.=C2=A0 If the cellular= network does not =0A> issue=0A>>> an RA to the CLAT/UE/CPE, how does the = UE know it=E2=80=99s ipv6 default =0A> router?=0A>>> How is the /64 assign= ed to the CLAT?=0A>>> =0A>>> =0A>> =0A>> If you are wondering how 3GPP sid= e works, start here rfc6459=0A>> =0A>> CB=0A>> =0A>>> Hemant=0A>>> =0A>>>= =0A>>> _______________________________________________=0A>>> v6ops maili= ng list=0A>>> v6ops@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/= v6ops=0A>>> =0A>> =0A> _______________________________________________=0A> = v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/list= info/v6ops=0A> From markzzzsmith@yahoo.com.au Sat Aug 25 18:38:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845EB21F84CE for ; Sat, 25 Aug 2012 18:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akj3ZdqK3Dj2 for ; Sat, 25 Aug 2012 18:38:33 -0700 (PDT) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id EDC5F21F8497 for ; Sat, 25 Aug 2012 18:38:30 -0700 (PDT) Received: from [98.139.91.64] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 01:38:25 -0000 Received: from [98.139.91.58] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 01:38:25 -0000 Received: from [127.0.0.1] by omp1058.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 01:38:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 139600.36025.bm@omp1058.mail.sp2.yahoo.com Received: (qmail 62805 invoked by uid 60001); 26 Aug 2012 01:38:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1345945104; bh=bH+px5dFeu/sorQeBEpOnzdh5PigOYzr25egy6rOz2Y=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PJ7SXx5GQht+2l2xIorfeZz3fFsMe1R/m7jfV+RJvwL08TQVovXoTOw2nO12J709BZkTjdoM40d6uvpkQ4ZkFIPFElohJOQLgVsedsoYwrbo2mzn62khJwHJ+Hfu/VABY5UZvM36iqCgCnUVgzmIKhNaCnPud436XSoDi4vgDH8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QG40K0BkpR2NEvf4IKAn1iIxcRGa/YnVlbaWD3BuvYRcmtxsW9+p8j88jRYj9td2PM9YWPl6V5dYtwC8P3CgDByVgMELbt11+wRg21AysUMsBAQ9eARwzZkMT0asTNENHrQ6VBBR+fCf94V4gPDE5UrzFfT83H1wArMP+rmPJrc=; X-YMail-OSG: E._nnn8VM1neHaYwLTpYfJTpfXd5lahcedbSxXm8wD1OC5C TLSRKCuHH_6V.zoszezSoEHV3jYbCsXOt8ed8RzT_X2V63FKCQaoeG9NhyK. f.t_R2N0HKAQgh8HeurgXJMdW6yiF0jld3N2iQrXGzKWsWeAczlsTzEDp67a Nf6v8F1PdiNLmW8DVvJ172BhWJUtPZ7U8.38EnmeWBjSCmQ8EPsEgUWHS4oE v7v1RLu_P_KsfC2Tk7qkEwtCZhH.NoVapTxRkDwsmhFoefdq1RBuoD3wCAlO ..evkOZ.j9YbxrMemajnU8r5761ItE03e89835LgpnrbTbi8KxEwuMHUl1lr Ln7J32P0JVdyd9cW3PBdckJiZBtmEm73CaEz9D9yJQQo67P_MhUmQoJzMAN_ DTigh5xY9XHCkUeukHNoBgUV7MXI5Aoe5W1MzQtygo8L8pyBrKMaOwxD6WDX TYn8LdQpWTDrHZC.uiYwrq1aAJPONAlj8D6s4SUGnJ77FEw-- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Sat, 25 Aug 2012 18:38:24 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> Message-ID: <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Sat, 25 Aug 2012 18:38:24 -0700 (PDT) From: Mark ZZZ Smith To: Cameron Byrne , Ray Hunter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 01:38:33 -0000 ----- Original Message -----=0A=0A> From: Cameron Byrne =0A=0A>=A0=0A=0AI think the problem is that if the following sort of= thing happens and becomes popular,=A0=0A=0A> On my 3GPP Release 7 network,= you may tether today with NDproxy and=0A> have access to the WAN /64 on yo= ur LAN.=0A>=A0=0A=0Athen this probably won't, because it "won't be necessar= y", despite it's drawbacks:=0A=0A> As soon as kit arrives that can do DHCP-= PD, that will be the preferred=0A> mechanism.=0A> =0A=0A=0ATemporary work-a= rounds have a horrible habit of becoming permanent work-arounds, and their = temporary disadvantages then become permanent ones. If DHCPv6-PD is the pro= per solution, then I don't think anything else should be acceptable. The re= quirement for DHCPv6-PD support will create the demand for DHCPv6-PD to the= n be widely implemented.=0A=0A=0ARegards,=0AMark.=0A From cb.list6@gmail.com Sat Aug 25 18:49:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B8421F8491 for ; Sat, 25 Aug 2012 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKbOCPXkC4Ju for ; Sat, 25 Aug 2012 18:49:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6850021F848F for ; Sat, 25 Aug 2012 18:49:58 -0700 (PDT) Received: by lbky2 with SMTP id y2so1139833lbk.31 for ; Sat, 25 Aug 2012 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IvN+DSnn1e+E3nOPJxHlgWjxKadnzaxUx7pwdqt24zQ=; b=l+5kRrc14DIKkN7fAOwdm3tSOZE1YU0uYZWmoayDMGOd56o9AypYoebww2JbQtn6Hn T/ODu3ydaIi34fGjJRXWTmsDTHSJDCwiuPNMyHEtqoFctv5Vgv7cb0HEB46bQ7lwhsII ybzFWgtCgJxuK8mznqMqas8wcasqpzhRY4i8uhDHK+wigPV9+7yxYKnRyxCTSloUjlDf 7oy/BiTc7oAQqQZ5YtV8B06CFoC8ySpAJ0T8/1MnxRi9jA53YtrrRt22Gfzdy8tO1Jn3 1i/zET88ZPJssBm12c8Kq1BrTuY/4zqH/2vYtBAUDebk8iVhJqr4I+p6vpyQMUUlyyMv P81g== MIME-Version: 1.0 Received: by 10.112.101.104 with SMTP id ff8mr4695389lbb.45.1345945797327; Sat, 25 Aug 2012 18:49:57 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sat, 25 Aug 2012 18:49:57 -0700 (PDT) In-Reply-To: <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Sat, 25 Aug 2012 18:49:57 -0700 Message-ID: From: Cameron Byrne To: Mark ZZZ Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 01:49:59 -0000 On Sat, Aug 25, 2012 at 6:38 PM, Mark ZZZ Smith wrote: > ----- Original Message ----- > >> From: Cameron Byrne > >> > > I think the problem is that if the following sort of thing happens and be= comes popular, > >> On my 3GPP Release 7 network, you may tether today with NDproxy and >> have access to the WAN /64 on your LAN. >> > > then this probably won't, because it "won't be necessary", despite it's d= rawbacks: > >> As soon as kit arrives that can do DHCP-PD, that will be the preferred >> mechanism. >> > > > Temporary work-arounds have a horrible habit of becoming permanent work-a= rounds, and their temporary disadvantages then become permanent ones. If DH= CPv6-PD is the proper solution, then I don't think anything else should be = acceptable. The requirement for DHCPv6-PD support will create the demand fo= r DHCPv6-PD to then be widely implemented. > Market demand for IPv6? I seen that movie. In any event, the draft describes one thing. What you have described is FUD, and you suggest that because of FUD "we cannot have nice things" CB > > Regards, > Mark. > From markzzzsmith@yahoo.com.au Sun Aug 26 01:05:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AF121F847B for ; Sun, 26 Aug 2012 01:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lAaXAQ17OlZ for ; Sun, 26 Aug 2012 01:05:16 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id B04F621F847D for ; Sun, 26 Aug 2012 01:05:15 -0700 (PDT) Received: from [98.139.91.63] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 08:05:10 -0000 Received: from [98.139.91.13] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 08:05:10 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 26 Aug 2012 08:05:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 471333.7902.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 60351 invoked by uid 60001); 26 Aug 2012 08:05:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1345968309; bh=U0G4x9ydcZOBfRzpftSu4HUf9k7oy6xoh7/X74R5+f8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZD4cPDtOhtNoSxwXQ6QsGOja4LMhtchnEK6wWItHOLalNesC6PbNuRzdZ06fSjFuD9Q6DMJDQstA2UWG/BWMjmw1VfvUji3nxNwJ+hIVAJ6oRLR6CwO3JP2WJQEfeYdW1Gzmb3IZX+RRGSbLDpWxxcBsN4InMID7bZpSwoyg6gI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tXB6qNA/9x15uv0ZLLkSitpMpjlMytmhUJOBqFYLwDfQsMDYTLPh146rPzD3/FXA3PsBXonsoP+dRroeS0ySEnN9blfgfVQGynFS2rLq3D5PG4NANK7RKpasaomeHVqPW9BGLdC9n28xVseQG+X+qljSmBE+0FNAM/u0uapoVp0=; X-YMail-OSG: rm2t0HoVM1lYfAVPR9Ln9eCbxKkfksxsSVwaXf5L3lL1y3J DCfYkNyfu Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Sun, 26 Aug 2012 01:05:09 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> Message-ID: <1345968309.96684.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Sun, 26 Aug 2012 01:05:09 -0700 (PDT) From: Mark ZZZ Smith To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 08:05:16 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Cameron Byrne =0A> To: Mark ZZZ Smith =0A> Cc: Ray H= unter ; "v6ops@ietf.org" =0A> Sent: Sunda= y, 26 August 2012 11:49 AM=0A> Subject: Re: [v6ops] single /64, ND Proxy, a= nd draft-ietf-v6ops-464xlat-07.txt=0A> =0A> On Sat, Aug 25, 2012 at 6:38 PM= , Mark ZZZ Smith=0A> wrote:=0A>> ----- Origina= l Message -----=0A>> =0A>>> From: Cameron Byrne =0A>> = =0A>>> =0A>> =0A>> I think the problem is that if the following sor= t of thing happens and =0A> becomes popular,=0A>> =0A>>> On my 3GPP Releas= e 7 network, you may tether today with NDproxy and=0A>>> have access to th= e WAN /64 on your LAN.=0A>>> =0A>> =0A>> then this probably won't, because= it "won't be =0A> necessary", despite it's drawbacks:=0A>> =0A>>> As soon= as kit arrives that can do DHCP-PD, that will be the preferred=0A>>> mech= anism.=0A>>> =0A>> =0A>> =0A>> Temporary work-arounds have a horrible habi= t of becoming permanent =0A> work-arounds, and their temporary disadvantage= s then become permanent ones. If =0A> DHCPv6-PD is the proper solution, the= n I don't think anything else should be =0A> acceptable. The requirement fo= r DHCPv6-PD support will create the demand for =0A> DHCPv6-PD to then be wi= dely implemented.=0A>> =0A> =0A> Market demand for IPv6?=A0 I seen that mov= ie.=0A>=A0=0A=0AWho said anything about market demand? The demand I'm talki= ng about is compliance with standards.=0A=0A> In any event, the draft descr= ibes one thing.=A0 What you have described=0A> is FUD, and you suggest that= because of FUD "we cannot have nice=0A> things"=0A>=A0=0A=0ASo wanting the= best and proper solution from the outset, rather than a work around that h= as known disadvantages is FUD? That doesn't make sense to me. From v6ops@globis.net Sun Aug 26 04:40:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D69B21F84F2 for ; Sun, 26 Aug 2012 04:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2-YU2bO7WRG for ; Sun, 26 Aug 2012 04:40:05 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57D21F84B2 for ; Sun, 26 Aug 2012 04:40:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E1A48870067; Sun, 26 Aug 2012 13:39:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mVP4rPpIqLw; Sun, 26 Aug 2012 13:39:18 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E695487005C; Sun, 26 Aug 2012 13:39:17 +0200 (CEST) Message-ID: <503A0ADF.5070303@globis.net> Date: Sun, 26 Aug 2012 13:39:11 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Cameron Byrne References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 11:40:06 -0000 Inline. Thanks! > Cameron Byrne > 25 August 2012 22:40 > Hi Ray, > > On Sat, Aug 25, 2012 at 12:27 PM, Ray Hunter wrote >> The single /64 deployment model conflicts with previous approved IETF BCP. I >> was also vocal in the discussion on 6204bis. >> >> Specifically: According to BCP 157 RFC6177 "A key principle for address >> management is that end sites always be able to obtain a reasonable amount of >> address space for their actual and planned usage, and over time ranges >> specified in years rather than just months." >> > > Without ND proxy, the amount of address you have is exactly zero for a > tethered device in all of today's 3GPP networks. So the question is > do we do allow tethering on IPv6 today or do we say "no, IPv6 is > future exercise for someone else". Failing to engineer for it now > makes yet another chicken-and-egg issue. No customers, no demand, no > spec, no gear, no code, ... Understand that. No problem with a phone using xlat for it's own internal mono-stack apps. Or in a stand alone LAN where the phone is the only router. I'm just trying to understand interoperability when there's more than one device present: either in parallel or cascaded. When asked what happens when CLAT's are cascaded I got an answer back that this was out of scope of the draft. If I read ND Proxy I think that this case is illegal and that ND proxy processing will be disabled [ 2nd CLAT will receive an RA message with the P bit set on its upstream interface] But there's no such explicit protection or detection of cascaded IANA assigned EUI-64 ID addresses in XLAT, which would definitely cause an IPv6 address conflict with the upstream CLAT. It strikes me as odd that ND Proxy goes to the trouble of detecting and shutting down the 2nd ND proxy if there's cascading, but XLAT BCP doesn't. Why not explicitly shut down the affected functions of the downstream CLAT if it detects a duplicate IANA assigned EUI-64 address on it's upstream interface? Wouldn't that protect existing service from the upstream CLAT? > On my 3GPP Release 7 network, you may tether today with NDproxy and > have access to the WAN /64 on your LAN. > > As soon as kit arrives that can do DHCP-PD, that will be the preferred > mechanism. > > I believe that is clearly documented here: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 > IF DHCP-PD available, then use DHCP-PD to grab as much address space as needed > > Else if NDproxy available, do that > > Else if EUI-64 reserved address available, do that. > I have read 8.3.2 and it does not seem to be worded exactly as you suggest. Currently it's worded in the negative "if cannot X then can Y", and in some places it doesn't even use reserved keywords in capitals. That to me does not express a preference for good behaviour of an "if X then SHOULD Y else MAY Z ....." clause. I'd prefer this section to be worded in the positive (this is Best Current Practice) to give the preferred translation order (exactly as you state, using if then else... ), and thus avoid perpetuating bad practice of single /64 working, and ensure interoperability if devices are swapped out. Here's my (non expert) version of the text: In the case that DHCPv6-PD [RFC3633] is available, the CLAT SHOULD use a dedicated IPv6 prefix for stateless translation [RFC6145]. ND Proxy andIANA assigned EUI-64 ID based addresses SHOULD NOT be used. If the CLAT does not have a dedicated IPv6 prefix available for translation, the CLAT SHOULD attempt to perform NAT44 and stateless translation [RFC6145] as detailed in the following paragraph. IPv4 packets from the LAN SHOULD be translated using NAT44 to the private IPv4 host address of the CLAT that is not included in LAN segment of CLAT. Then, the CLAT SHOULD perform a stateless translation [RFC6145] so that the IPv4 packets from the CLAT IPv4 host address are translated to the CLAT WAN IPv6 address as described in [RFC6145]. ND Proxy MAY be used. EUI-64 ID based addresses SHOULD NOT be used. Please note that RFC 4389 section 4.1.3.3 http://tools.ietf.org/html/rfc4389#section-4.1.3.3 prohibits a CLAT from performing ND Proxy if RA packets are received on the downstream interface. When both DHCPv6-PD and ND proxy are not available a CLAT MAY use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]. This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT. This document describes an example for this case in Example 2. of the Appendix A. The IANA assigned EUI-64 ID SHOULD NOT be used for L2 link addressing. Network operators SHOULD ensure that the upstream interface of each CLAT is connected to an unique upstream IPv6 prefix, to prevent potential problems with duplicate IPv6 addressing of downstream interfaces of two CLAT's connected in parallel, I'm relying on you xlat experts to get the preference order right..... >> The single /64 deployment model may be reality of Release-9 3gpp, but should >> we be producing a new (xlat) BCP that potentially condones bad practice >> forever? Especially as future releases of 3gpp seem to be moving away from >> the single /64 deployment model. >> e > > It does not condone NDproxy forever, i believe the current text is > clear that DHCP-PD is the preferred path. Given that that the > preferred path is only available in vaporware on 3GPP networks and > this is a BCP, we documented what we know to work in a 3GPP network > for real .. with real code .. .real customers .... real production > network. While, at the same time, saying DHCP-PD is the best path > when available I appreciate the intention but I think the text could be improved. >> I'm worried that we'll create issues for Homenet, because an IPv6 wireless >> LTE mobile phone acting as a CPE router (with built in CLAT and special >> processing for single /64 working) is pretty likely to connect into a >> Homenet in parallel to a domestic wired CPE router (with built in CLAT). >> > > Homenet has a lot of work to do on many fronts, and finding network > boundaries is one of their most active areas of research As stated above I now think ND proxy should shut down when a phone using ND proxy is connected to Homenet. However, if two wireless devices are using CLAT + single /64 + ND Proxy at the moment one phone is tethered, wouldn't they both detect RA packets on their downstream interfaces, causing both to fail over to a different translation scheme (based on fixed IANA address)? This isn't such a crazy scenario: I know of places that deliver "fixed" domestic Internet links via wireless; as well as some friends who own more than one mobile device per household. Wouldn't this cause some interesting oscillation effects, as well as killing existing sessions? >> Can you remove that worry? >> > > I hope i already have. > >> Does the WG think Lorenzo's and Hemant's vision of a tethered mobile phone >> as "just another CPE router" the more correct model? > > I have my reservations about the commercial reality of multi-homing > for residential use, but i think it is viable. > > CB >> regards, >> >> >> Cameron Byrne wrote: >>> On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant) >>> wrote: >>>> I do have to start a new thread to focus this ND Proxy discussion with >>>> 464xlat. Elide the use case of a single /64 from the document and then >>>> the >>>> following go away too. >>>> >>>> >>>> >>>> 1. ND Proxy >>>> >>>> 2. RFC 4389 >>>> >>>> 3. Single /64 allocated to the CLAT >>>> >>>> >>> Single /64 is the reality of many of today's access networks, and >>> specifically important is all deployed 3GPP networks work this way for >>> IPv6. Note, there are no known Release 10 networks deployed or any >>> known support of 3GPP DHCP-PD, AFAIK. It is known that IPv4 resources >>> are exhausted in APNIC, and soon to be so in RIPE and then ARIN. So, >>> there is no point in waiting for perfect. A single /64 is the only >>> reality we know in 3GPP, and is therefore the most concrete thing we >>> have for this BCP, which includes running code / running network. >>> >>> http://tools.ietf.org/html/rfc6459#section-5.3 >>> >>> 5.3. Prefix Delegation >>> >>> IPv6 prefix delegation is a part of Release-10 and is not covered by >>> any earlier releases. However, the /64 prefix allocated for each >>> default bearer (and to the UE) may be shared to the local area >>> network by the UE implementing Neighbor Discovery proxy (ND proxy) >>> [RFC4389] functionality. >>> >>>> During the IPv6 CPE router specification development, for a long time, >>>> some >>>> folks from the 3GPPP community asked us to add a use case for a single >>>> /64 >>>> and ND Proxy to rfc6204. However, after more careful study, a consensus >>>> was >>>> reached to remove the single /64 use case from rfc6204 and rfc6204bis. >>>> Additionally, I am told the IETF endorses the DHCPv6 PD model over a >>>> single /64. >>>> >>>> >>> I am also told the IETF endorses dual-stack >>> >>>> A single /64 cannot be supported on a CPE/CLAT because then the CPE has >>>> to >>>> proxy the RA to hosts in the LAN or tethered segment. There is no >>>> document >>>> on a Standards Track in the IETF that defines how to proxy an RA. I am >>> Is a standard tack document required? I assume the point you are >>> trying to make is that rfc4389 is experimental status. >>> >>>> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in >>>> the >>>> wireless service provider domain. If the cellular network does not >>>> issue >>>> an RA to the CLAT/UE/CPE, how does the UE know it’s ipv6 default router? >>>> How is the /64 assigned to the CLAT? >>>> >>>> >>> If you are wondering how 3GPP side works, start here rfc6459 >>> >>> CB >>> >>>> Hemant >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> > Ray Hunter > 25 August 2012 21:27 > The single /64 deployment model conflicts with previous approved IETF > BCP. I was also vocal in the discussion on 6204bis. > > Specifically: According to BCP 157 RFC6177 "A key principle for > address management is that end sites always be able to obtain a > reasonable amount of address space for their actual and planned usage, > and over time ranges specified in years rather than just months." > > The single /64 deployment model may be reality of Release-9 3gpp, but > should we be producing a new (xlat) BCP that potentially condones bad > practice forever? Especially as future releases of 3gpp seem to be > moving away from the single /64 deployment model. > > I'm worried that we'll create issues for Homenet, because an IPv6 > wireless LTE mobile phone acting as a CPE router (with built in CLAT > and special processing for single /64 working) is pretty likely to > connect into a Homenet in parallel to a domestic wired CPE router > (with built in CLAT). > > Can you remove that worry? > > Does the WG think Lorenzo's and Hemant's vision of a tethered mobile > phone as "just another CPE router" the more correct model? > > regards, > > > ------------------------------------------------------------------------ From rajiva@cisco.com Sun Aug 26 13:05:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47A21F8528 for ; Sun, 26 Aug 2012 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqKYzcB5d7rD for ; Sun, 26 Aug 2012 13:05:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3025721F8513 for ; Sun, 26 Aug 2012 13:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1839; q=dns/txt; s=iport; t=1346011524; x=1347221124; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zEERcLcwgcjpwNQQs2F+Np1vU1Ab9Fxr32c70QqaG4w=; b=g9W8HvfS78GDE1KzWQKNp0V2Nz2sa0wh/B7UgICCeX12p/y8x6mSuh95 +JWPWEGPi3uGW06DFT7TIBtaTQXc9cgkhV+eW5xsg/JETSwpwnc5r7c+n aKnOFUASXdQMloWjfzIXlJayDkaj0w0VlUXIwevoBBq9xuab1MsoVr7qX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACuBOlCtJXG+/2dsb2JhbABFumuBB4IgAQEBBAEBAQ8BJzQLDAQCAQgVIRAhBgslAgQOBRsHhW+BbQMMC5tAlVUNiUoEiiVjCoYnYAOUAgOBUIsOgyCBZ4JjgVgJGg X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115386646" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2012 20:05:23 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7QK5N0F029994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 20:05:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 15:05:22 -0500 From: "Rajiv Asati (rajiva)" To: Mark ZZZ Smith Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNguFy/B01HxK8aEed4WwQTzN/j5drPWsAgAAUdgCAAFMkAIAA4XfM Date: Sun, 26 Aug 2012 20:05:22 +0000 Message-ID: <24B4A515-CC91-4EBD-BA36-D39538D07FA9@cisco.com> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> , <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.004 x-tm-as-result: No--43.211700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 20:05:25 -0000 I appreciate the downsides of ND proxy (and RA proxy or lack thereof), but = it's usage is MUST for cellular networks until they move to rel 10, to carr= y on with the business without relying on IPv4 clutches.=20 And it is ok for us protocol zealots to discount any sub-optimal/imperfect= approach because a better/optimal approach (e.g. PD) is on the way, but it= is impractical for us to expect 'business' to wait until that happens.=20 If we can't find an alternative solution that is deemed better in the _imme= diate _future, then let's proceed with what we have so far (and document ap= propriate gotchas).=20 Cheers, Rajiv Sent from my Phone On Aug 25, 2012, at 9:38 PM, "Mark ZZZ Smith" w= rote: > ----- Original Message ----- >=20 >> From: Cameron Byrne > >> =20 >=20 > I think the problem is that if the following sort of thing happens and be= comes popular,=20 >=20 >> On my 3GPP Release 7 network, you may tether today with NDproxy and >> have access to the WAN /64 on your LAN. >> =20 >=20 > then this probably won't, because it "won't be necessary", despite it's d= rawbacks: >=20 >> As soon as kit arrives that can do DHCP-PD, that will be the preferred >> mechanism. >>=20 >=20 >=20 > Temporary work-arounds have a horrible habit of becoming permanent work-a= rounds, and their temporary disadvantages then become permanent ones. If DH= CPv6-PD is the proper solution, then I don't think anything else should be = acceptable. The requirement for DHCPv6-PD support will create the demand fo= r DHCPv6-PD to then be widely implemented. >=20 >=20 > Regards, > Mark. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Sun Aug 26 13:13:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7A21F854D for ; Sun, 26 Aug 2012 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZb26WvRNyWV for ; Sun, 26 Aug 2012 13:13:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 46E1621F853B for ; Sun, 26 Aug 2012 13:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2428; q=dns/txt; s=iport; t=1346012034; x=1347221634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/zSXMsIEMkHA1eqGl7MATwLI8f6qImWyXPbHWTg+C40=; b=Na74xDz//8UWcYaAn+/9A6pOfFpIdD21k24vAG2WUIiZCPWg8bV6bJb8 +/F96H+PKUmwG7TZ8XIADi15o5/8n3YjBN+I/9UkBKouppcBUdWi7W1+D d9P0MHyRzMGFljJQy+jYiYTL+/aHDaQ6DLSaGPnmaxVvCPSFn72VNY8cq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADGCOlCtJXG//2dsb2JhbABFumuBB4IgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAR4QIQYLHQgCBA4FGweFb4FtAwwLmy6VVQ2JSgSKJWMKhidgA5QCA4FQiw6DIIFngmOBWAka X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115193887" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2012 20:13:53 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7QKDr1e017117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 20:13:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 15:13:53 -0500 From: "Rajiv Asati (rajiva)" To: Mark ZZZ Smith Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNguFy/B01HxK8aEed4WwQTzN/j5drPWsAgAAUdgCAAFMkAIAAAzqAgABo1YCAAHfHxA== Date: Sun, 26 Aug 2012 20:13:51 +0000 Message-ID: References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> , <1345968309.96684.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1345968309.96684.YahooMailNeo@web32503.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.001 x-tm-as-result: No--40.793700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 20:13:55 -0000 I agree to the intention of doing things right from the outset, but what if= 'outset' is far off in the future (with a much bigger dependency) and the = problem needs to be solved now in the current paradigm/networks ? Cheers, Rajiv Sent from my Phone On Aug 26, 2012, at 4:05 AM, "Mark ZZZ Smith" w= rote: >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Cameron Byrne >> To: Mark ZZZ Smith >> Cc: Ray Hunter ; "v6ops@ietf.org" >> Sent: Sunday, 26 August 2012 11:49 AM >> Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-= 07.txt >>=20 >> On Sat, Aug 25, 2012 at 6:38 PM, Mark ZZZ Smith >> wrote: >>> ----- Original Message ----- >>>=20 >>>> From: Cameron Byrne >>> >>>>=20 >>>=20 >>> I think the problem is that if the following sort of thing happens and= =20 >> becomes popular, >>>=20 >>>> On my 3GPP Release 7 network, you may tether today with NDproxy and >>>> have access to the WAN /64 on your LAN. >>>>=20 >>>=20 >>> then this probably won't, because it "won't be=20 >> necessary", despite it's drawbacks: >>>=20 >>>> As soon as kit arrives that can do DHCP-PD, that will be the preferred >>>> mechanism. >>>>=20 >>>=20 >>>=20 >>> Temporary work-arounds have a horrible habit of becoming permanent=20 >> work-arounds, and their temporary disadvantages then become permanent on= es. If=20 >> DHCPv6-PD is the proper solution, then I don't think anything else shoul= d be=20 >> acceptable. The requirement for DHCPv6-PD support will create the demand= for=20 >> DHCPv6-PD to then be widely implemented. >>>=20 >>=20 >> Market demand for IPv6? I seen that movie. >> =20 >=20 > Who said anything about market demand? The demand I'm talking about is co= mpliance with standards. >=20 >> In any event, the draft describes one thing. What you have described >> is FUD, and you suggest that because of FUD "we cannot have nice >> things" >> =20 >=20 > So wanting the best and proper solution from the outset, rather than a wo= rk around that has known disadvantages is FUD? That doesn't make sense to m= e. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Sun Aug 26 14:11:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D2921F8578 for ; Sun, 26 Aug 2012 14:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEjcQtpOi0oS for ; Sun, 26 Aug 2012 14:11:29 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92521F8577 for ; Sun, 26 Aug 2012 14:11:29 -0700 (PDT) Received: by iabz21 with SMTP id z21so7715131iab.31 for ; Sun, 26 Aug 2012 14:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=OGXwR/LaJkZJ5AyrtO4CSM/eziLuEOI29OTofrITaq4=; b=ANqbrUPtqd2nYezo0vHEfktflkhGdMmnu1/mdCBLPVoZpW4UI/qYIINage+88IaX+a FuR9BNn8O5WIY4GuZ+CH1J86xCqNcDH/YIptOhwLqzd6sCDTv02MVYk0XLZn6zQjsDZF JG2t4Jl6YVZPmIxBv3U9HVPBb6a+AHirV6M17iUZexXWw5nBo877Qj59QBF1ttFgk++1 vryKMZuD67dJccurO6IKECkefdgAEsQCOqpKgd2/Xh2jZK8MwXsKlJPjIy2lY9bkUcAW qpu9hDRf1vfqrJh0QDvOFv+F7LV5YDiLD2gm5INF+Mmdaygy1wH4sy55TpTXJrcUitLK UoVw== Received: by 10.50.41.199 with SMTP id h7mr8028013igl.67.1346015489142; Sun, 26 Aug 2012 14:11:29 -0700 (PDT) Received: from [192.168.100.235] ([67.224.83.162]) by mx.google.com with ESMTPS id z7sm4734958igb.3.2012.08.26.14.11.25 (version=SSLv3 cipher=OTHER); Sun, 26 Aug 2012 14:11:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 26 Aug 2012 17:11:24 -0400 From: Victor Kuarsingh To: "Rajiv Asati (rajiva)" , Mark ZZZ Smith Message-ID: Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 21:11:30 -0000 On 12-08-26 4:13 PM, "Rajiv Asati (rajiva)" wrote: >I agree to the intention of doing things right from the outset, but what >if 'outset' is far off in the future (with a much bigger dependency) and >the problem needs to be solved now in the current paradigm/networks ? The big issue now (my opinion) is getting IPv6 onto mobile networks- in production. Delays in getting it there will be a major setback for IPv6. Right now, many mobile operators are faced with technical constraints on what can be supported on the network. To get IPv6 into production, we need to use what we have. Cameron B noted something important. With NDProxy, we can change a tethered attachment form no-IPv6 to IPv6 capable. This is very important to getting things moving in production networks. I think waiting will insight operators to go down paths (out of necessity) which may dial us back on the progress wheel. I have many devices which tether in my network, along with many gateway like devices. It would be a shame to not get IPv6 moving on this front while we wait for DHCP-PD to be commercially ready. Regards, Victor Kuarsingh > >Cheers, >Rajiv > From rajiva@cisco.com Sun Aug 26 14:38:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3EB21F8565 for ; Sun, 26 Aug 2012 14:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxRdhB-+7CsP for ; Sun, 26 Aug 2012 14:38:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7C21F855A for ; Sun, 26 Aug 2012 14:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2293; q=dns/txt; s=iport; t=1346017096; x=1347226696; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ky9ilfjLyICiIZDJct7ntjwpBgT0O6uiH5A4JKie/rk=; b=fYMyDqzRzX8UirO3hw7mLCuhvSvPa+0Cf0nVQcTcI/YpO8e6yRm3ambd k38t8d8lkzR016hJJfHZrWAAySjArYe+fk0AYYYNsrkGJSP6BKS4Hzhdv mbEOvH9ZoarVgQmarE3XKwWgiBMT+ivuOAlMay6czslQ0M2uJF3zzyfrq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAWWOlCtJXHA/2dsb2JhbABFum2BB4IgAQEBBAEBAQ8BJzQLDAYBCBEDAQEBHwkoBgsUCQgCBAENBQkSB4dcAwwLmw2VUQ2JToolYxqGdwOUAoFTiw6DIIFngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="112392756" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 26 Aug 2012 21:38:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7QLcFtb026268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 21:38:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 16:38:15 -0500 From: "Rajiv Asati (rajiva)" To: "Hemant Singh (shemant)" , Cameron Byrne Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNgvt7rWnC89AZ1ECWwOcKeKxvn5dssP+A Date: Sun, 26 Aug 2012 21:38:14 +0000 Message-ID: In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077A7E@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.211.237] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.004 x-tm-as-result: No--46.328100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7D9E9A6FE034814380D0566A0037C029@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 21:38:17 -0000 Hi Hemant, I must be missing something. Could you please clarify why RFC4389 is not good enough wrt the expected behavior of handling the RAs by the proxy ? I understand why RA proxy by itself is not the full-proof solution (hence, discounted early on), but that's why RFC4389 was put in place. I am looking at the following sections and I am not seeing any technical issue: - Section 4.1.3.3 ICMPv6 Router Advertisements - section-4.1.2 Proxying Packets - section 6 Loop Prevention Cheers, Rajiv -----Original Message----- From: "Hemant Singh (shemant)" Date: Saturday, August 25, 2012 3:54 PM To: Cameron Byrne Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt > >-----Original Message----- >From: Cameron Byrne [mailto:cb.list6@gmail.com] >Sent: Saturday, August 25, 2012 12:48 PM >To: Hemant Singh (shemant) >Cc: v6ops@ietf.org >Subject: Re: [v6ops] single /64, ND Proxy, and >draft-ietf-v6ops-464xlat-07.txt > > >>I am also told the IETF endorses dual-stack > >It's comparing apples to oranges. Dual-stack works. The DHCPv6 PD is >recommended by the IETF (at least for the IPv6 CPE router document) over >a single /64 because a single /64 has issues supporting tethered clients >while the DHCPv6 PD does not. > > >>Is a standard tack document required? > >No. > >>I assume the point you are trying to make is that rfc4389 is >>experimental status. > >Not quite. rfc4389 is experimental because the protocol specified by the >document has issues. The issues were pointed out recently by me to >v6ops. See > >http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html > >If one deploys a single /64 to a UE and the UE has to support tethered >clients, the UE will have to proxy the RA. How is the proxy RA >implemented? Note also, that is why the IPv6 protocol WG in 6man is >standardizing a DAD proxy (draft-ietf-6man-dad-proxy) on standards track >but not any ND Proxy which still stays as experimental. > >Thanks for the rfc6459 reference. > >Hemant > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Sun Aug 26 15:41:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0321F857A for ; Sun, 26 Aug 2012 15:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-bDi0ZGoPUV for ; Sun, 26 Aug 2012 15:41:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0023021F8574 for ; Sun, 26 Aug 2012 15:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3130; q=dns/txt; s=iport; t=1346020914; x=1347230514; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VKl8cccp/nGb825jYWfjsb2vu6ZtIa6JAIFI8dTU1PM=; b=dgwa86yCLa0V3enLXiW6h88G/++lWFia3Qb/3DPTYONtrR4tx+2jd7VL SVJEeYfWLWuaWR8lP+xhRI7zxlV86qbUphYlIIWHIWnh4lOMYzlLked/3 b5tIYAbpCx+NWhNvv09ODNI4Lz0qzh497pOax2wXQ0PhkDZ7Yxpy0Slk9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAESlOlCtJXG//2dsb2JhbABFum6BB4IgAQEBBAEBAQ8BJzQLDAQCAQgRAwEBAQsUCQchBgsUCQgBAQQBDQUIARIHh1wDDAuaeZVPDYlOiiVjGoYXYAOUAoxhgyCBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115397710" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2012 22:41:53 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7QMfrVe005202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 22:41:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 17:41:52 -0500 From: "Hemant Singh (shemant)" To: "Rajiv Asati (rajiva)" , Cameron Byrne Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2C2eT6WUBzFQYeRdSnitTvYLhR+QAMWyUAAAUNL6AAN17SAAAIjNaA Date: Sun, 26 Aug 2012 22:41:51 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89077D90@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077A7E@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.004 x-tm-as-result: No--44.855300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 22:41:54 -0000 See http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html Specifically see this text in my statements. "Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in essen= ce forwards IP (ND) packets without decrementing ttl, which can lead to cat= astrophic loops. The RFC tries to ameliorate that by detecting loops. Howev= er, the loop detection is based on receiving RAs (with the P-bit) which han= dles some cases. But it isn't robust against somebody connecting what was t= wo Ethernet segments after ND proxy has sent its two P-bit RAs." Hemant -----Original Message----- From: Rajiv Asati (rajiva)=20 Sent: Sunday, August 26, 2012 5:38 PM To: Hemant Singh (shemant); Cameron Byrne Cc: v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt Hi Hemant, I must be missing something. Could you please clarify why RFC4389 is not good enough wrt the expected behavior of handling the RAs by the proxy ? I understand why RA proxy by itself is not the full-proof solution (hence, discounted early on), but that's why RFC4389 was put in place. I am looking at the following sections and I am not seeing any technical issue: - Section 4.1.3.3 ICMPv6 Router Advertisements - section-4.1.2 Proxying Packets - section 6 Loop Prevention Cheers, Rajiv -----Original Message----- From: "Hemant Singh (shemant)" Date: Saturday, August 25, 2012 3:54 PM To: Cameron Byrne Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt > >-----Original Message----- >From: Cameron Byrne [mailto:cb.list6@gmail.com] >Sent: Saturday, August 25, 2012 12:48 PM >To: Hemant Singh (shemant) >Cc: v6ops@ietf.org >Subject: Re: [v6ops] single /64, ND Proxy, and >draft-ietf-v6ops-464xlat-07.txt > > >>I am also told the IETF endorses dual-stack > >It's comparing apples to oranges. Dual-stack works. The DHCPv6 PD is >recommended by the IETF (at least for the IPv6 CPE router document) over >a single /64 because a single /64 has issues supporting tethered clients >while the DHCPv6 PD does not. > > >>Is a standard tack document required? > >No. > >>I assume the point you are trying to make is that rfc4389 is >>experimental status. > >Not quite. rfc4389 is experimental because the protocol specified by the >document has issues. The issues were pointed out recently by me to >v6ops. See > >http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html > >If one deploys a single /64 to a UE and the UE has to support tethered >clients, the UE will have to proxy the RA. How is the proxy RA >implemented? Note also, that is why the IPv6 protocol WG in 6man is >standardizing a DAD proxy (draft-ietf-6man-dad-proxy) on standards track >but not any ND Proxy which still stays as experimental. > >Thanks for the rfc6459 reference. > >Hemant > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Sun Aug 26 16:16:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2C521F8597 for ; Sun, 26 Aug 2012 16:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKjDCgKJ2sUX for ; Sun, 26 Aug 2012 16:16:50 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAF9821F856D for ; Sun, 26 Aug 2012 16:16:49 -0700 (PDT) Received: by lahm15 with SMTP id m15so2284313lah.31 for ; Sun, 26 Aug 2012 16:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lvWUzlNpuLdD7yBlbs/0O9oVx+C98pWoAE+DpFfRJ1Q=; b=UnrjGoaafRBMzwyvCJQvKF1KV32N5wAbMoQkthXROHoS+chL4VgAy3UHfXOZfrA2B1 82s6VGqsc8nmHuyz3E4rYMFbNz5c0ek4S6SFsJteo9fNHCRS82nvjw376U4NvpL1UKFd jrw6kBMB5GnZsyEI1uOyyKO8+qqJf0AX3iodONrW32HID0qJiDvfV2TTvCz3ZeIJS0uo Xp/QZvMITWw2hD6YwlLP02yoToGtCvcRBf9J6STXJRoDxFeZO/g6g3WZO3PUOoFjzduP TgoXPInKHPH1M+b4mBg/wiQWzBGlIa2PoqGPcuV8s0Xj5FVItU3WRmj4OzPbcbnO4WZH lP9A== MIME-Version: 1.0 Received: by 10.112.82.66 with SMTP id g2mr5775449lby.15.1346023008723; Sun, 26 Aug 2012 16:16:48 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sun, 26 Aug 2012 16:16:48 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077D90@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077A7E@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077D90@xmb-rcd-x06.cisco.com> Date: Sun, 26 Aug 2012 16:16:48 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 23:16:50 -0000 On Sun, Aug 26, 2012 at 3:41 PM, Hemant Singh (shemant) wrote: > See > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html > > Specifically see this text in my statements. > > "Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in ess= ence forwards IP (ND) packets without decrementing ttl, which can lead to c= atastrophic loops. The RFC tries to ameliorate that by detecting loops. How= ever, the loop detection is based on receiving RAs (with the P-bit) which h= andles some cases. But it isn't robust against somebody connecting what was= two Ethernet segments after ND proxy has sent its two P-bit RAs." > This last sentence does not make sense to me, it is unclear exactly what the problem is. Are you going to deprecate ND Proxy in the IETF? As it is not yet deprecated, it is a valid tool. If there is a problem with ND Proxy, take it to 6man and hopefully it can be fixed. Nonetheless, i believe the concerns with ND Proxy are out of scope for 464XLAT. 464XLAT has diagrams and scenarios about 3GPP and wireline residential networks with a single router, the CLAT. Without better terms, these are "residential" or "consumer" services. And, specifically, ND Proxy is only used in the scenario where DHCP-PD is not available. We have documented what does work (running code blah blah blah...). Yet, i see concerns about undefined scenarios not working. CB From shemant@cisco.com Sun Aug 26 16:28:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262C521F8574 for ; Sun, 26 Aug 2012 16:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+DRNOKbIvpC for ; Sun, 26 Aug 2012 16:28:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4552C21F84F3 for ; Sun, 26 Aug 2012 16:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3548; q=dns/txt; s=iport; t=1346023706; x=1347233306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pD/YQmKkJ9gAfjpkfAtuqeMwFEzUR+RqnxtDsi/zLNs=; b=LFiZFzflVCFBjZK0Se/Z61ZkxjRQbnm2CAZIsH7kPsGL4j9/Rs0bIiZv C8i11ivJYpxjv/CH4QSfBaIZ6ymdQz0S9/DZStNkOUug6RPLuIZ3j6IYZ p0bO3Y+qftmtF55lX+DfHQwbtkLx90KQe64Lsjd/1Aks0dlX0WpJJWcEj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+wOlCtJV2d/2dsb2JhbABFum6BB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBMHh2ubAp8piwiGMWADpAOBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115446578" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 26 Aug 2012 23:28:25 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7QNSPHw002993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 23:28:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 18:28:24 -0500 From: "Hemant Singh (shemant)" To: Victor Kuarsingh , "Rajiv Asati (rajiva)" , Mark ZZZ Smith Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg89nYKrmcQ5WEk+/0eJcYchFCpdssXJw Date: Sun, 26 Aug 2012 23:28:24 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.001 x-tm-as-result: No--25.941300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 23:28:27 -0000 Victor, I agree with your sentiment. However, I don't think the ND Proxy is a work= able solution. Have you or Cameron tested specifically for ND Proxy loops?= Just switch on and off, a few ND Proxy nodes and you will see the loops. = I for one, in wireline network, have already seen a catastrophic ND Proxy = loop one year back where an IPv6 CPE router was using DHCPv6 PD and also su= pported an ND Proxy in the LAN segment of the CPE. The CPE looped Proxied = ND packets upstream to the SP which is catastrophic.=20 As for the tethered service, I think, there are still large cellular operat= ors in the U.S. who support the IPhone and not any tethering. So why is a = hack such as the ND Proxy being pushed for tethering? Why not just add DHC= Pv6 PD to the UE and then the CLAT also uses a prefix from the DHCPv6 PD? = For IPv6, I think, it takes at least a few years for any service provider t= o shake out deployment testing. We want to go down a ND Proxy path for few= years and then support the DHCPv6 PD and disable ND Proxy on the UE? Addi= tionally, how is the CLAT UE going to sunset a single /64 and ND Proxy with= DHCPv6 PD? Is the UE hardware replaced totally or the UE undergoes a soft= ware upgrade? What if the service provider has a mis-configuration in the = DHCPv6 provisioning and the DHCPv6 PD fails and we know DHCPv6 tries foreve= r? Does the UE now move to enabling ND Proxy? =20 Note, the additional benefit of adding the DHCPv6 PD to the UE is that a co= mmon testing body exists (the UNH) to test wireline IPv6 CPE routers and al= so a cellular UE that supports the DHCPv6 PD and an IPv6 CPE router. Open = WRT already exists as a Linux implementation for the UE vendors to leverage= .=20 The IETF has already endorsed the DHCPv6 PD over a single /64 and ND Proxy = for rfc6205bis. So why should the IETF even bother with a ND Proxy solutio= n or block any operator from deploying the ND Proxy solution? Go ahead and= deploy the ND Proxy. However remove the /64 section in section 8.3.2 from= the xlat document and let's push the xlat document through the IETF with t= he DHCPv6 PD solution. Removing section 8.3.2 also removes reserving an II= D for use by CLAT. I don't think we have any consensus on using reserved I= ID. Regards back, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of V= ictor Kuarsingh Sent: Sunday, August 26, 2012 5:11 PM To: Rajiv Asati (rajiva); Mark ZZZ Smith Cc: Ray Hunter; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt The big issue now (my opinion) is getting IPv6 onto mobile networks- in production. Delays in getting it there will be a major setback for IPv6. Right now, many mobile operators are faced with technical constraints on what can be supported on the network. To get IPv6 into production, we need to use what we have. Cameron B noted something important. With NDProxy, we can change a tethered attachment form no-IPv6 to IPv6 capable. This is very important to getting things moving in production networks. I think waiting will insight operators to go down paths (out of necessity) which may dial us back on the progress wheel. I have many devices which tether in my network, along with many gateway like devices. It would be a shame to not get IPv6 moving on this front while we wait for DHCP-PD to be commercially ready. Regards, Victor Kuarsingh From victor.kuarsingh@gmail.com Sun Aug 26 17:04:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66D21F85A5 for ; Sun, 26 Aug 2012 17:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4w3oXBNtSDQ for ; Sun, 26 Aug 2012 17:04:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4F9921F85A1 for ; Sun, 26 Aug 2012 17:04:28 -0700 (PDT) Received: by iabz21 with SMTP id z21so7902178iab.31 for ; Sun, 26 Aug 2012 17:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=WexYp+pysLS/nQ3cnfufPF2smVxdiESwaigOSsMWMSM=; b=0hIDx4dY2G1/WB9zbVvRoqIZBR607UifzlKRboDcYhPttJruji+o+TR2YdIrDhX0cI 3pSBS47XodT84jxdItYTp8YMnteR9zYtKOzZwDUxhjXnT5WEeXzzyYaEqFaAWy0X0bDS GjomSbb11RkXpl95mGqQZlQ0bILrQ7T9ByXNN0PvDUedinZfScofA2XuBXBsbZdS5hjM LMc8v3KmxOGOwMm07J1Hw35MWi4vNTrsb7jeJRqcADyqzC4ung4UUTlRhPm8CeCJ1yWy uUThhduK0O6PT4tFNV9ZjlX3bO55xTkUE1E1oALKMelE1DZ/WThQN+xznLW+3vTGqwAS SMfw== Received: by 10.50.17.133 with SMTP id o5mr8480200igd.41.1346025868287; Sun, 26 Aug 2012 17:04:28 -0700 (PDT) Received: from [192.168.100.235] ([67.224.83.162]) by mx.google.com with ESMTPS id ut5sm17229757igc.13.2012.08.26.17.04.25 (version=SSLv3 cipher=OTHER); Sun, 26 Aug 2012 17:04:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 26 Aug 2012 20:04:26 -0400 From: Victor Kuarsingh To: "Hemant Singh (shemant)" Message-ID: Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 00:04:29 -0000 Hamant, On 12-08-26 7:28 PM, "Hemant Singh (shemant)" wrote: > > >As for the tethered service, I think, there are still large cellular >operators in the U.S. who support the IPhone and not any tethering. So >why is a hack such as the ND Proxy being pushed for tethering? I cannot speak for every operator, but for some of us trying to deploy IPv6, if I cannot do it with tethering, I cannot deploy it (part of the service). Not supporting tethering would inhibit my ability to deploy (in my case - perhaps for others). >Why not just add DHCPv6 PD to the UE and then the CLAT also uses a prefix >from the DHCPv6 PD? I don't think anyone has said we don't want or agree with the use of DHCP-PD. The sentiment was related to the readiness of DHCP-PD in the mobile environment. This is related to when it was put into spec (3GPP side) and then how long it took/takes to get it into production code, then deployed. >Additionally, how is the CLAT UE going to sunset a single /64 and ND >Proxy with DHCPv6 PD? Is the UE hardware replaced totally or the UE >undergoes a software upgrade? What if the service provider has a >mis-configuration in the DHCPv6 provisioning and the DHCPv6 PD fails and >we know DHCPv6 tries forever? Does the UE now move to enabling ND Proxy? > Sunsetting of the ND-Proxy is a concern. I am not sure if this ranks higher or lower then delaying IPv6 deployment. > > >Note, the additional benefit of adding the DHCPv6 PD to the UE is that a >common testing body exists (the UNH) to test wireline IPv6 CPE routers >and also a cellular UE that supports the DHCPv6 PD and an IPv6 CPE >router. Open WRT already exists as a Linux implementation for the UE >vendors to leverage. > > I agree that DHCP-PD is preferential overall, but again, timing may be an issue. Also, many of us need to deal with challenges on the mobile side which are above and beyond what I need to deal with on the wireline side. I would have loved nothing less then to have my attachment capabilities and timelines to be the same for both, but as the standards where written and implemented, there was/is a gap. At the end of the day, we will do what we need to do to get IPv6 service up - whether or not is shows up in the document specifically. Having it in there however may be a better reflection [opinion alert] of what operators will need to do to get the service into there networks (given I don't think I am the only one with these challenges - albeit not every mobile operation as you have noted) Regards, Victor K > From rajiva@cisco.com Sun Aug 26 17:42:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5891121F859C for ; Sun, 26 Aug 2012 17:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55GojfXYHQQi for ; Sun, 26 Aug 2012 17:42:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8004321F853F for ; Sun, 26 Aug 2012 17:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3921; q=dns/txt; s=iport; t=1346028127; x=1347237727; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YETzzJj0WjUPwLQKKUHKGGrvhFTU9AGETCJgdchuxQk=; b=KP+tB5qrDIAMYzMNTXKpCKg3QZK7DY6JeFjNHn8pP0+mlc4grmJLtIsE hvB8jz5/Q0C5lhxibOtOdHB1kEt9EhbYYVCzhx7Tsw5xTR3PLqqFGRJuU DUk5d+FB2F8d3vKpR8igyaUveUIAXx6ghyKonLlTtTirDVqDKnpYCOyvd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMzAOlCtJV2a/2dsb2JhbABFum+BB4IgAQEBBAEBAQ8BWwsMBgEIEQMBAQEoKAYLFAkIAgQBDQUJEgeHXAMMC5prlVkNiU6KJWMahncDiBqLaIFTiw6DIIFngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115426905" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2012 00:42:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7R0g6M0008301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 00:42:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 19:42:06 -0500 From: "Rajiv Asati (rajiva)" To: "Hemant Singh (shemant)" , Cameron Byrne Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNgvt7rWnC89AZ1ECWwOcKeKxvn5dssP+AgABU04D//94JgA== Date: Mon, 27 Aug 2012 00:42:05 +0000 Message-ID: In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077D90@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.242.161] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.001 x-tm-as-result: No--50.238000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 00:42:08 -0000 Hemant, Thanks for the pointer, but it is still not clear 1) how the loop gets formed in a wireless network. Could you please help me understand the 'loop' in this topology (UE1 has a p2p interface to R1, and is configured for ND-proxy functionality): ue11--LAN--_UE1_--WAN----R1 ue12--/ 2) whether there are other issues besides loop possibility? Cheers, Rajiv -----Original Message----- From: "Hemant Singh (shemant)" Date: Sunday, August 26, 2012 6:41 PM To: Rajiv Asati , Cameron Byrne Cc: "v6ops@ietf.org" Subject: RE: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt >See > >http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html > >Specifically see this text in my statements. > >=B3Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in >essence forwards IP (ND) packets without decrementing ttl, which can lead >to catastrophic loops. The RFC tries to ameliorate that by detecting >loops. However, the loop detection is based on receiving RAs (with the >P-bit) which handles some cases. But it isn't robust against somebody >connecting what was two Ethernet segments after ND proxy has sent its two >P-bit RAs.=B2 > >Hemant > >-----Original Message----- >From: Rajiv Asati (rajiva) >Sent: Sunday, August 26, 2012 5:38 PM >To: Hemant Singh (shemant); Cameron Byrne >Cc: v6ops@ietf.org >Subject: Re: [v6ops] single /64, ND Proxy, and >draft-ietf-v6ops-464xlat-07.txt > >Hi Hemant, > >I must be missing something. Could you please clarify why RFC4389 is not >good enough wrt the expected behavior of handling the RAs by the proxy ? > >I understand why RA proxy by itself is not the full-proof solution (hence, >discounted early on), but that's why RFC4389 was put in place. > >I am looking at the following sections and I am not seeing any technical >issue: > - Section 4.1.3.3 ICMPv6 Router Advertisements > - section-4.1.2 Proxying Packets > - section 6 Loop Prevention > >Cheers, >Rajiv > >-----Original Message----- >From: "Hemant Singh (shemant)" >Date: Saturday, August 25, 2012 3:54 PM >To: Cameron Byrne >Cc: "v6ops@ietf.org" >Subject: Re: [v6ops] single /64, ND Proxy, and >draft-ietf-v6ops-464xlat-07.txt > >> >>-----Original Message----- >>From: Cameron Byrne [mailto:cb.list6@gmail.com] >>Sent: Saturday, August 25, 2012 12:48 PM >>To: Hemant Singh (shemant) >>Cc: v6ops@ietf.org >>Subject: Re: [v6ops] single /64, ND Proxy, and >>draft-ietf-v6ops-464xlat-07.txt >> >> >>>I am also told the IETF endorses dual-stack >> >>It's comparing apples to oranges. Dual-stack works. The DHCPv6 PD is >>recommended by the IETF (at least for the IPv6 CPE router document) over >>a single /64 because a single /64 has issues supporting tethered clients >>while the DHCPv6 PD does not. >> >> >>>Is a standard tack document required? >> >>No. >> >>>I assume the point you are trying to make is that rfc4389 is >>>experimental status. >> >>Not quite. rfc4389 is experimental because the protocol specified by the >>document has issues. The issues were pointed out recently by me to >>v6ops. See >> >>http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html >> >>If one deploys a single /64 to a UE and the UE has to support tethered >>clients, the UE will have to proxy the RA. How is the proxy RA >>implemented? Note also, that is why the IPv6 protocol WG in 6man is >>standardizing a DAD proxy (draft-ietf-6man-dad-proxy) on standards track >>but not any ND Proxy which still stays as experimental. >> >>Thanks for the rfc6459 reference. >> >>Hemant >> >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Sun Aug 26 18:09:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB2621F8593 for ; Sun, 26 Aug 2012 18:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KochvrOuJX9 for ; Sun, 26 Aug 2012 18:09:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1F821F8568 for ; Sun, 26 Aug 2012 18:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1851; q=dns/txt; s=iport; t=1346029794; x=1347239394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=crmlB5frFCbK+RlMzQNfeYsgXkI/Vv3q09/AmyW2iIo=; b=QeHtiUCvFHXokYRpldsR9IWp/VQorCBlmxt7bjAw3UOjjCCahXKAXv6R iNRFbPacUl9qIEu5Xw1EmaZbH2NI35LjNTZc1wHs8Dms9D52uxyzd18bB ii9YpQsDRw0KWucE04ZBJ70ivo34MqMEXyjWSOOZgGLnbBNpEMured4iU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJHIOlCtJV2Z/2dsb2JhbABFum+BB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHIREUCQgCBA4FCAEZh1wDDAuaY5VYDYlOiiVjGoYXYAOUAoxhgyCBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115432991" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 27 Aug 2012 01:09:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7R19rOK025079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 01:09:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 20:09:53 -0500 From: "Hemant Singh (shemant)" To: Victor Kuarsingh Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepqw== Date: Mon, 27 Aug 2012 01:09:52 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.001 x-tm-as-result: No--29.120400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 01:09:55 -0000 Victor (and also replying to Rajiv in one email), -----Original Message----- From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]=20 Sent: Sunday, August 26, 2012 8:04 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >I cannot speak for every operator, but for some of us trying to deploy >IPv6, if I cannot do it with tethering, I cannot deploy it (part of the >service). Not supporting tethering would inhibit my ability to deploy (in >my case - perhaps for others). Got it - you need tethering immediately. Ok, back to the ND Proxy issues t= hen. =20 My wife turns on her cell phone and this CLAT phone uses the reserved IID a= nd thus does not issue any RA with the ND Proxy P-bit. A tethered client i= n a home IPv6 router uses the RA to get a SLAAC IPv6 address. Behind the I= Pv6 CPE router is a network bridge. Subsequently, I turn on my cell phone t= hat supports only an ND Proxy and a single /64. Before my phone is able to= send an RA with the P-bit set, the bridged behind home router looped my wi= fe's phone RA to my phone and my phone loops the RA back to the SP. Additi= onally, what does my tethered client do if the client receives two differen= t RA's as described above and specifically how is proxying of NA's done? I= s the NA sent to the ND Proxy phone or the reserved IID phone when the teth= ered node has only one interface to receive an NS on? =20 Soon as one says tethering, testing for what is working code is very broad = because there could be whole network behind one tethered client. This is t= he same point Ray Hunter is making and it would be good to reply to his ema= il at the URL below. http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html Regards, Hemant From cb.list6@gmail.com Sun Aug 26 20:26:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C12721F8527 for ; Sun, 26 Aug 2012 20:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06g5LDx4VnY6 for ; Sun, 26 Aug 2012 20:26:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1182521F84A6 for ; Sun, 26 Aug 2012 20:26:48 -0700 (PDT) Received: by lahm15 with SMTP id m15so2364602lah.31 for ; Sun, 26 Aug 2012 20:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d6bqJfu/fXoPddIxsWPdFypswT6/5E+VU3evCuAJ0+0=; b=vLZyB8Ct3MBM6NUjqw4si6z+OIP5LTlPFdo7q5UgOu3PCUewvez0PYR67iJ3HTPyJA G75OjtA5Y/QHpwiuLzz+dioGNGjdkfG0XBpNiDonhWuy8jxRlSZx1/gyImItorrmZcSn ofI5M7nCZCUzf9y4DRSt2zqfH1/Zghq3h7GrW/cZvPRzlTSV5WY17EsQGlQwHNWnFt/c y5Lf/ai0EXMg4Z7YFpwtw9A+8zc2hLM2kclDPgQA9k5pOaShc3JdUAII3QtU8UN7DFlX FpcfilVkUaQCxTCvp3fPAQDfze4AVe1cZlTD/eQ+72h2Ycu91WW0WrZQ0clgpHXmmwO6 LOJQ== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr13109728lab.19.1346038007873; Sun, 26 Aug 2012 20:26:47 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sun, 26 Aug 2012 20:26:47 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Date: Sun, 26 Aug 2012 20:26:47 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 03:26:50 -0000 Hemant, On Sun, Aug 26, 2012 at 6:09 PM, Hemant Singh (shemant) wrote: > Victor (and also replying to Rajiv in one email), > > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt > >>I cannot speak for every operator, but for some of us trying to deploy >>IPv6, if I cannot do it with tethering, I cannot deploy it (part of the >>service). Not supporting tethering would inhibit my ability to deploy (in >>my case - perhaps for others). > > Got it - you need tethering immediately. Ok, back to the ND Proxy issues= then. > > My wife turns on her cell phone and this CLAT phone uses the reserved IID= and thus does not issue any RA with the ND Proxy P-bit. A tethered client= in a home IPv6 router uses the RA to get a SLAAC IPv6 address. Behind the= IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone= that supports only an ND Proxy and a single /64. Before my phone is able = to send an RA with the P-bit set, the bridged behind home router looped my = wife's phone RA to my phone and my phone loops the RA back to the SP. Addi= tionally, what does my tethered client do if the client receives two differ= ent RA's as described above and specifically how is proxying of NA's done? = Is the NA sent to the ND Proxy phone or the reserved IID phone when the te= thered node has only one interface to receive an NS on? > So let me get the facts of your scenario correct: There is a phone CLAT using reserved IID (the wife) There is a home IPv6 router There is a network bridge There is a cell phone that support only ND Proxy with a /64 There is a race condition: "Before my phone is able to send an RA with the P-bit set, the bridged behind home router looped my wife's phone RA to my phone and my phone loops the RA back to the SP." My response is this: 1. The 464XLAT I-D neither explicitly nor implicitly supports such a network. The 464XLAT service is "limited" and the scenarios described in the text and diagrams of the I-D are simple and known to work without harm. 2. As a Mobile service provider, i do not support such a topology. If a customer calls our call center and explains this setup ... it will not get support. 3. ND Proxy does not support this setup explicitly http://tools.ietf.org/html/rfc4389#section-1.3 4. I don't think it is possible to instrument such a network as you have described. Phones that i am aware of are either "wifi router" or "wifi client", but the scenario you described requires both phones to be a "wifi router" since they are providing access to a mobile network and at the same time "wifi clients" since they are joined to the home router and home bridge. 5. FYI, at an implementation level, I believe the CLAT implementation that is implemented today for Android (submitted code) will never proxy an RA received on the LAN to the mobile network on the WAN. The WAN interface is defined and it is the WAN address that is shared to the LAN, not the other way around. > Soon as one says tethering, testing for what is working code is very broa= d because there could be whole network behind one tethered client. This is= the same point Ray Hunter is making and it would be good to reply to his e= mail at the URL below. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html > > Regards, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Sun Aug 26 21:12:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52F021F85C0 for ; Sun, 26 Aug 2012 21:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkbtXgwgJMoN for ; Sun, 26 Aug 2012 21:12:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3B21F85B1 for ; Sun, 26 Aug 2012 21:12:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3BC9A9C; Mon, 27 Aug 2012 06:11:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 351D59A; Mon, 27 Aug 2012 06:11:59 +0200 (CEST) Date: Mon, 27 Aug 2012 06:11:59 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> Message-ID: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 04:12:02 -0000 On Sun, 26 Aug 2012, Hemant Singh (shemant) wrote: > why is a hack such as the ND Proxy being pushed for tethering? Why not > just add DHCPv6 PD to the UE and then the CLAT also uses a prefix from That's easier said than done. We also need support in GGSN/PGW, which as Cameron said is a release 10 feature which I would imagine is 1-2 years off into the future (at least). -- Mikael Abrahamsson email: swmike@swm.pp.se From jouni.nospam@gmail.com Sun Aug 26 23:36:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC15C21F854B for ; Sun, 26 Aug 2012 23:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5sDt+oXNsvb for ; Sun, 26 Aug 2012 23:36:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D527221F84F9 for ; Sun, 26 Aug 2012 23:36:29 -0700 (PDT) Received: by eaai11 with SMTP id i11so1051123eaa.31 for ; Sun, 26 Aug 2012 23:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SHEdG9zG7luMrtDOn0GUbY31njGdC1qHLGUuK2l3XHg=; b=hpnt86X6vPp5Cn6bQyU3Lnj/TU4avoBzExP2O90Z44rGyK2uzkYJSCM57LIr1jFO6d q74660rJQ6pBZBVQKiczQXiiKDgCiZa1krt5wM0QwxC63bL92QxYTHlhiLhK8SVk47Tu ryXaSfzr7QsMINCIVhCJC+kmADgroneGClVwE1NwLcCfR3vKsmr2HM8X3mrhJ8BIUe0h H6ry8PMLmGyEg9oLp5jfE3oePJSYMa8iRx0XoiuM05wIRkZOaOPOfYVhCwp5Rnjjvumv ZrZNTdtdGhp3mQtD3tZ6d4c30owvxLBE2f5qxtOnMJW0Ykp/TkvuXnh3WYuoVvpewBde FQ3Q== Received: by 10.14.5.67 with SMTP id 43mr16234480eek.15.1346049388948; Sun, 26 Aug 2012 23:36:28 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id c6sm49478688eep.7.2012.08.26.23.36.26 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Aug 2012 23:36:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Date: Mon, 27 Aug 2012 09:36:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:36:30 -0000 On Aug 27, 2012, at 4:09 AM, Hemant Singh (shemant) wrote: > Victor (and also replying to Rajiv in one email), >=20 > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]=20 > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 >> I cannot speak for every operator, but for some of us trying to = deploy >> IPv6, if I cannot do it with tethering, I cannot deploy it (part of = the >> service). Not supporting tethering would inhibit my ability to deploy = (in >> my case - perhaps for others). >=20 > Got it - you need tethering immediately. Ok, back to the ND Proxy = issues then. =20 >=20 > My wife turns on her cell phone and this CLAT phone uses the reserved = IID and thus does not issue any RA with the ND Proxy P-bit. A tethered = client in a home IPv6 router uses the RA to get a SLAAC IPv6 address. = Behind the IPv6 CPE router is a network bridge. Subsequently, I turn on = my cell phone that supports only an ND Proxy and a single /64. Before = my phone is able to send an RA with the P-bit set, the bridged behind = home router looped my wife's phone RA to my phone and my phone loops the = RA back to the SP. Additionally, what does my Your phone should then disable the proxy behavior according to 4.1.3.3 = of RFC4389 (the second last para). Anyway, the topology described here is out of scope of RFC4389 as far as = I understand. Also, with the current mobiles, I don't think being a STA and AP at the same time is = possible, which seems to a prerequisite for the above topology. - Jouni > tethered client do if the client receives two different RA's as = described above and specifically how is proxying of NA's done? Is the = NA sent to the ND Proxy phone or the reserved IID phone when the = tethered node has only one interface to receive an NS on? =20 >=20 > Soon as one says tethering, testing for what is working code is very = broad because there could be whole network behind one tethered client. = This is the same point Ray Hunter is making and it would be good to = reply to his email at the URL below. >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html >=20 > Regards, >=20 > Hemant >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Mon Aug 27 00:10:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8921A21F847F for ; Mon, 27 Aug 2012 00:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUJ2LPHFjmdY for ; Mon, 27 Aug 2012 00:10:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4621F8319 for ; Mon, 27 Aug 2012 00:10:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4502734vbb.31 for ; Mon, 27 Aug 2012 00:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PskigUxHfolk30Wejm+WDxch+w8HgpYN3I6K6PfvXzA=; b=g/yJxC19yWsY5oibjBWSYayiA7hjEmINdIZxSeyVAD9PSWuJFnJXMbMM5QiQ605nLv RlpHpMpqCiUFh0YPoQqSR8r+4LYuVWjmvT7mZTcUaNqIDP0aIDRqR3ppb+qckUbqpLfe H6UzDwzRhTifPzUmbloT4NWviUS4eSHfzWXis2i9wYeFAshDbRwZzTNAcLdWwcC6py7j h0IMUF2r6SjB9DlViSEQqYWrUKf0IbevWGRD8UMFIFS+XP92xQZG1FuwnqYt4EAWnmwc K8fSdODzmK8gd6++gR0CAQ04G5qZPuVL/zQ95P6yOCUyyHfHgouRY9ZQXJBN6rB0XOya wFMQ== MIME-Version: 1.0 Received: by 10.52.37.100 with SMTP id x4mr9143652vdj.56.1346051404953; Mon, 27 Aug 2012 00:10:04 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 27 Aug 2012 00:10:04 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Date: Mon, 27 Aug 2012 15:10:04 +0800 Message-ID: From: GangChen To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 07:10:06 -0000 2012/8/27, Hemant Singh (shemant) : > Victor (and also replying to Rajiv in one email), > > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt > >>I cannot speak for every operator, but for some of us trying to deploy >>IPv6, if I cannot do it with tethering, I cannot deploy it (part of the >>service). Not supporting tethering would inhibit my ability to deploy (in >>my case - perhaps for others). > > Got it - you need tethering immediately. Ok, back to the ND Proxy issues > then. > > My wife turns on her cell phone and this CLAT phone uses the reserved IID > and thus does not issue any RA with the ND Proxy P-bit. A tethered client > in a home IPv6 router uses the RA to get a SLAAC IPv6 address. Behind the > IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone > that supports only an ND Proxy and a single /64. Before my phone is able to > send an RA with the P-bit set, the bridged behind home router looped my > wife's phone RA to my phone and my phone loops the RA back to the SP. I guess the scenairo is not "464xlat". You are entrying to another topic(maybe call it nested-xlat more properly), which I believe is going beyond current scope. the traget scenario is well described in "BCP Scenario" and Figure1/2. Including the nested scenario would be not draft's intention. FWIW, replying to the comment "I don't think we have any consensus on using reserved IID.", I think we are trying to figure out the potential solution if single /64 allocated & No ND-proxy for almost a half of month. But the outcome is nothing apart from Reserved IID (If you have another one, please identify). Therefore, It's worth to confirm CB's proposal for the sake of progress. i.e. http://www.ietf.org/mail-archive/web/v6ops/current/msg13955.html Especially >IF DHCP-PD available, then use DHCP-PD to grab as much address space as needed >Else if NDproxy available, do that >Else if EUI-64 reserved address available, do that. BRs Gang > Additionally, what does my tethered client do if the client receives two > different RA's as described above and specifically how is proxying of NA's > done? Is the NA sent to the ND Proxy phone or the reserved IID phone when > the tethered node has only one interface to receive an NS on? > Soon as one says tethering, testing for what is working code is very broad > because there could be whole network behind one tethered client. This is > the same point Ray Hunter is making and it would be good to reply to his > email at the URL below. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html > > Regards, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tore.anderson@redpill-linpro.com Mon Aug 27 00:32:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70821F8582 for ; Mon, 27 Aug 2012 00:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMnwxTcRVuhW for ; Mon, 27 Aug 2012 00:32:00 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id C392221F8581 for ; Mon, 27 Aug 2012 00:31:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 64851182011A; Mon, 27 Aug 2012 09:31:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Ly1SGzCSKo; Mon, 27 Aug 2012 09:31:57 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id D4B8D1820117; Mon, 27 Aug 2012 09:31:57 +0200 (CEST) Message-ID: <503B226D.3020205@redpill-linpro.com> Date: Mon, 27 Aug 2012 09:31:57 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 07:32:00 -0000 * Fred Baker (fred) > This is to open a two week Working Group last Call on > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", > Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > > Please read it now. We are interested in, among other things, > technical commentary on the draft and the working group's perception > on its usefulness to its target audience. I've voluntarily used IPv6+NAT64/DNS64 as my primary mobile data connection for well over a year, and while most things work just fine, there is a small, but significant, percentage of apps and services which fails to function correctly. Because of these, I can fully understand that deploying IPv6 as a default connectivity method to «ordinary» users in current 3G networks is simply not feasible. That said, there is a pressing need to get IPv6 more widely deployed, perhaps especially in mobile networks. In my opinion, 464XLAT appears to allow those problematic apps and services to function correctly on IPv6-only mobile networks, thus making IPv6-only service a commercially viable strategy for the operators. That, I feel, is extremely valuable, and not to mention urgent. As to the current bickering going on about ND-Proxy and IANA-reserved IID...we need a bike shed like 464XLAT *now*, regardless of hue. It doesn't even have to be perfect and able fit all weird sorts of velocipedes, trikes and future inventions - after all, its function is only to support a small and diminishing number of legacy apps and services that cannot make use of native IPv6 themselves. It's a stop-gap measure, not the future of mobile networking. I therefore support this document wholeheartedly, and hope I'll get an implementation of it delivered to my phone «over the air» in the near future. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From despres.remi@laposte.net Mon Aug 27 01:21:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1BD21F8581 for ; Mon, 27 Aug 2012 01:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo8m4MR0RBym for ; Mon, 27 Aug 2012 01:21:32 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3195721F85A4 for ; Mon, 27 Aug 2012 01:21:31 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 00F6B70000A4; Mon, 27 Aug 2012 10:21:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 337CF700009B; Mon, 27 Aug 2012 10:21:29 +0200 (CEST) X-SFR-UUID: 20120827082129211.337CF700009B@msfrf2309.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 27 Aug 2012 10:21:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC3B959-8A7B-4477-B9A7-5030AEE57545@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:21:33 -0000 2012-08-25 22:40, Cameron Byrne : ... > Without ND proxy, the amount of address you have is exactly zero for a > tethered device in all of today's 3GPP networks. So the question is > do we do allow tethering on IPv6 today or do we say "no, IPv6 is > future exercise for someone else". Failing to engineer for it now > makes yet another chicken-and-egg issue. No customers, no demand, no > spec, no gear, no code, ... >=20 > On my 3GPP Release 7 network, you may tether today with NDproxy and > have access to the WAN /64 on your LAN. >=20 > As soon as kit arrives that can do DHCP-PD, that will be the preferred > mechanism. >=20 > I believe that is clearly documented here: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 >=20 > IF DHCP-PD available, then use DHCP-PD to grab as much address space = as needed >=20 > Else if NDproxy available, do that >=20 > Else if EUI-64 reserved address available, do that. 1. DHCP-PD, if used with a /64, isn't exclusive of of the need to avoid = Collision between the CLAT IID and host IIDs. (Independently of whether = this avoidance is done with ND proxy or reserved EUI-64). 2. If ND proxy is used: (1) it has to be modified to exclude the CLAT = IPv6 address although it isn't on any bridged link (RFC 4389, is for = bridged links); (2) the problem remains of a host reserving the = colliding IID before 464XLAT activation. Thus, using ND proxy isn't = exclusive either of using the reserved EUI-64.=20 These are reasons why, to keep independence of functions, section 8.3.2 = can and should in my understanding be improved: before "the CLAT MAY use = a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 = address to be used in stateless translation [RFC6145]", the restrictive = condition should be deleted (that which says "if the CLAT cannot perform = ND Proxy [RFC4389] due to the restriction of the implementation"). With this small amendment (which just avoids an artificial limitation of = reserved EUI-64 applicability), time has come, IMHO, to publish the = 464XLAT BCP, and deploy. Best regards, RD=20 >=20 >> The single /64 deployment model may be reality of Release-9 3gpp, but = should >> we be producing a new (xlat) BCP that potentially condones bad = practice >> forever? Especially as future releases of 3gpp seem to be moving away = from >> the single /64 deployment model. >> e >=20 > It does not condone NDproxy forever, i believe the current text is > clear that DHCP-PD is the preferred path. Given that that the > preferred path is only available in vaporware on 3GPP networks and > this is a BCP, we documented what we know to work in a 3GPP network > for real .. with real code .. .real customers .... real production > network. While, at the same time, saying DHCP-PD is the best path > when available >=20 >> I'm worried that we'll create issues for Homenet, because an IPv6 = wireless >> LTE mobile phone acting as a CPE router (with built in CLAT and = special >> processing for single /64 working) is pretty likely to connect into a >> Homenet in parallel to a domestic wired CPE router (with built in = CLAT). >>=20 >=20 > Homenet has a lot of work to do on many fronts, and finding network > boundaries is one of their most active areas of research >=20 >> Can you remove that worry? >>=20 >=20 > I hope i already have. >=20 >> Does the WG think Lorenzo's and Hemant's vision of a tethered mobile = phone >> as "just another CPE router" the more correct model? >=20 > I have my reservations about the commercial reality of multi-homing > for residential use, but i think it is viable. >=20 > CB >> regards, >>=20 >>=20 >> Cameron Byrne wrote: >>>=20 >>> On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant) >>> wrote: >>>>=20 >>>> I do have to start a new thread to focus this ND Proxy discussion = with >>>> 464xlat. Elide the use case of a single /64 from the document and = then >>>> the >>>> following go away too. >>>>=20 >>>>=20 >>>>=20 >>>> 1. ND Proxy >>>>=20 >>>> 2. RFC 4389 >>>>=20 >>>> 3. Single /64 allocated to the CLAT >>>>=20 >>>>=20 >>>=20 >>> Single /64 is the reality of many of today's access networks, and >>> specifically important is all deployed 3GPP networks work this way = for >>> IPv6. Note, there are no known Release 10 networks deployed or any >>> known support of 3GPP DHCP-PD, AFAIK. It is known that IPv4 = resources >>> are exhausted in APNIC, and soon to be so in RIPE and then ARIN. = So, >>> there is no point in waiting for perfect. A single /64 is the only >>> reality we know in 3GPP, and is therefore the most concrete thing we >>> have for this BCP, which includes running code / running network. >>>=20 >>> http://tools.ietf.org/html/rfc6459#section-5.3 >>>=20 >>> 5.3. Prefix Delegation >>>=20 >>> IPv6 prefix delegation is a part of Release-10 and is not covered = by >>> any earlier releases. However, the /64 prefix allocated for each >>> default bearer (and to the UE) may be shared to the local area >>> network by the UE implementing Neighbor Discovery proxy (ND = proxy) >>> [RFC4389] functionality. >>>=20 >>>> During the IPv6 CPE router specification development, for a long = time, >>>> some >>>> folks from the 3GPPP community asked us to add a use case for a = single >>>> /64 >>>> and ND Proxy to rfc6204. However, after more careful study, a = consensus >>>> was >>>> reached to remove the single /64 use case from rfc6204 and = rfc6204bis. >>>> Additionally, I am told the IETF endorses the DHCPv6 PD model = over a >>>> single /64. >>>>=20 >>>>=20 >>>=20 >>> I am also told the IETF endorses dual-stack >>>=20 >>>> A single /64 cannot be supported on a CPE/CLAT because then the CPE = has >>>> to >>>> proxy the RA to hosts in the LAN or tethered segment. There is no >>>> document >>>> on a Standards Track in the IETF that defines how to proxy an RA. = I am >>>=20 >>>=20 >>> Is a standard tack document required? I assume the point you are >>> trying to make is that rfc4389 is experimental status. >>>=20 >>>> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 = router in >>>> the >>>> wireless service provider domain. If the cellular network does = not >>>> issue >>>> an RA to the CLAT/UE/CPE, how does the UE know it=92s ipv6 default = router? >>>> How is the /64 assigned to the CLAT? >>>>=20 >>>>=20 >>>=20 >>> If you are wondering how 3GPP side works, start here rfc6459 >>>=20 >>> CB >>>=20 >>>> Hemant >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Mon Aug 27 01:55:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C532021F85F3 for ; Mon, 27 Aug 2012 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4StyENdc4Iza for ; Mon, 27 Aug 2012 01:55:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B538C21F85C3 for ; Mon, 27 Aug 2012 01:55:10 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8773965obb.31 for ; Mon, 27 Aug 2012 01:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4O1aZYwmh+8l59yFfdONIor1EwnmKX3gR05d/0jmqw0=; b=HldfCSzzb7/il/iW9PI8VvAmMKkx4PkCMV5GV15qkzTu3jsbxVYKrj1RmHUIKrQdKj aEtJ9Ss7rWckiTuD0JsJ2dJVB3w0EVERYIREbfSE1osHN3sOsKqM0tcxlVB/aKCU2AVg YM/4EL0tZGDzBtDT1glq20oWbNT2VvfQcyHx8uOH0Bp8qpq8fRFtHRZd9PPvqP1ozuef iy6f4rMHnphYmbRk741NUJFVFfpC1rmTXUeFlsbQJq1vIj4z6J1V/JbhZox8VzeKWIjq yNRcTblUYr/svS5oc1QA62Rv/GMQjrsxRAJcG00dAPJgFBKDwX57pnYsndFlnewYxcP+ wIDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4O1aZYwmh+8l59yFfdONIor1EwnmKX3gR05d/0jmqw0=; b=pHWPZEp364OHgm1NeLexG0QD+ltvnms6K6ImQ+RBgzP6mpAs0rPd3gTRXP0nJ6NepP N6zLbzZo+UKX/Tdp6FZiOYDkKzZXcgvLh1bBXHuh/cQTMMLNpDNnrR3evRuDFwsaVJfN KFYzuwFyy9rK45p51UII30ZGiSCK08VUTSi9fAllj9GQf5xtY0vHPxdSZxppicxSDOkG Ji5wp4aXf0RU1aoS5ki/gP7rPd/6OYZP0UufGC2RRLZ/BIR0GKMmtUVbdjQon0ihy6v3 5NxcWVO+v/kJ3ZTK/EUA8daCBJbDwMxoX2FC2vHeq5zwxX4T1g9bBIcVwFYbh9UG/6m7 IzTw== Received: by 10.60.10.6 with SMTP id e6mr9667256oeb.45.1346057710271; Mon, 27 Aug 2012 01:55:10 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr9667248oeb.45.1346057710054; Mon, 27 Aug 2012 01:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 27 Aug 2012 01:54:49 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Mon, 27 Aug 2012 17:54:49 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=e89a8fb2028aa7abe804c83b7bbb X-System-Of-Record: true X-Gm-Message-State: ALoCoQk7l5aQCLUOlWtjV8ukg66LrKFN1uBzYWz8HKrkSW9TdvJv9WB1t9RyX907dAOm04xM1uYmxmlFevgqQKorPNEgbj2RyId7JWlCq1yh+PguxKRDw/1XyjjvCyv6cQyqqTaGT3i0oL98xOk4mmU/eLceMN+9CRZa9R3RgyIIvz5zqwyw8bmuz5p+mzGQ+NqBPIkdW9aG Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:55:11 -0000 --e89a8fb2028aa7abe804c83b7bbb Content-Type: text/plain; charset=ISO-8859-1 Ok, so how about the following? Comments welcome. 0. If you get a DHCPv6 prefix delegation: congratulations. You live in the glorious future. Your carrier has a release 10 network, and is providing you with tethering (either because they're a just that nice, or because you paid extra for the privilege). The CLAT simply behaves like an RFC 6204 router. Done. Now for the rest of us. Since we're still here, it means we only have a single /64. If you don't want to implement tethering, do nothing. If you do want to implement tethering, proceed as follows (cell0 is the upstream interface, wlan0 is the downstream): 1. Enable tethering only when cell0 is a point-to-point interface (e.g., 3G, LTE, ...). 2. When enabling tethering, take the IPv6 address of cell0 (which you were already using, and need to continue to use because you have open connections to it), and assign it to wlan0 instead of cell0 3. Treat cell0 as unnumbered; when sending out packets, use the IP address assigned to wlan0. 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like a standard IPv6 router (decrement TTL, etc.) 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like a standard IPv6 multicast router (But I don't know anything about multicast, so I'll shut up now.) 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, they will fail DAD. So far so good. There is no bridging, and since the upstream is a point-to-point interface, there are no loops. Note that this is *not* RFC 4389. But it does not need to be. We haven't talked about CLAT yet. There are two cases here: 1. The CLAT implementation can use the same IPv6 address as the phone. In this case, no problem. 2. The CLAT implementation cannot use the same IPv6 address as the phone. In this case, either: a) the CLAT does DAD for that other address as well, or: b) picks an address that "shouldn't collide" (remi's reserved IID) It's as simple as that. So, as far as I can see, the only issue left to discuss is "do we do 2a or 2b"? On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) wrote: > Victor (and also replying to Rajiv in one email), > > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt > > >I cannot speak for every operator, but for some of us trying to deploy > >IPv6, if I cannot do it with tethering, I cannot deploy it (part of the > >service). Not supporting tethering would inhibit my ability to deploy (in > >my case - perhaps for others). > > Got it - you need tethering immediately. Ok, back to the ND Proxy issues > then. > > My wife turns on her cell phone and this CLAT phone uses the reserved IID > and thus does not issue any RA with the ND Proxy P-bit. A tethered client > in a home IPv6 router uses the RA to get a SLAAC IPv6 address. Behind the > IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone > that supports only an ND Proxy and a single /64. Before my phone is able > to send an RA with the P-bit set, the bridged behind home router looped my > wife's phone RA to my phone and my phone loops the RA back to the SP. > Additionally, what does my tethered client do if the client receives two > different RA's as described above and specifically how is proxying of NA's > done? Is the NA sent to the ND Proxy phone or the reserved IID phone when > the tethered node has only one interface to receive an NS on? > > Soon as one says tethering, testing for what is working code is very broad > because there could be whole network behind one tethered client. This is > the same point Ray Hunter is making and it would be good to reply to his > email at the URL below. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html > > Regards, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8fb2028aa7abe804c83b7bbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, so how about the following? Comments welcome.

0. If = you get a DHCPv6 prefix delegation: congratulations. You live in the glorio= us future. Your carrier has a release 10 network, and is providing you with= tethering (either because they're a just that nice, or=A0because you p= aid extra for the privilege). The CLAT simply behaves like an RFC 6204 rout= er. Done.

Now for the rest of us. Since we're still here, it = means we only have a single /64. If you don't want to implement tetheri= ng, do nothing. If you do want to implement tethering, proceed as follows (= cell0 is the upstream interface, wlan0 is the downstream):

1. Enable tethering only when cell0 is a point-to-point= interface (e.g., 3G, LTE, ...).
2. When enabling tethering, take= the IPv6 address of cell0 (which you were already using, and need to conti= nue to use because you have open connections to it), and assign it to wlan0= instead of cell0
3. Treat cell0 as unnumbered; when sending out packets, use the IP add= ress assigned to wlan0.
4. Forward IPv6 unicast packets from wlan= 0 to cell0 and vice versa like a standard IPv6 router (decrement TTL, etc.)=
5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa l= ike a standard IPv6 multicast router (But I don't know anything about m= ulticast, so I'll shut up now.)
6. Send an RA for the /64 to = wlan0. If hosts pick the same IID as you, they will fail DAD.

So far so good. There is no bridging, and since the ups= tream is a point-to-point interface, there are no loops. Note that this is = *not* RFC 4389. But it does not need to be.

We hav= en't talked about CLAT yet. There are two cases here:

1. The CLAT implementation can use the same IPv6 addres= s as the phone. In this case, no problem.
2. The CLAT implementat= ion cannot use the same IPv6 address as the phone. In this case, either:=A0=
=A0 a) the CLAT does DAD for that other address as well, or:
=A0 b) picks an address that "shouldn't collide" (remi's= reserved IID)

It's as simple as that. So, as = far as I can see, the only issue left to discuss is "do we do 2a or 2b= "?

On Mon, Aug 27, 2012 at 10:0= 9 AM, Hemant Singh (shemant) <shemant@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Victor (and also replying to Rajiv in one email),

-----Original Message-----
From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]
Sent: Sunday, August 26, 2012 8:04 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.or= g
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt

>I cannot speak for every operator, but for some= of us trying to deploy
>IPv6, if I cannot do it with tethering, I cannot deploy it (part of the=
>service). Not supporting tethering would inhibit my ability to deploy (= in
>my case - perhaps for others).

Got it - you need tethering immediately. =A0Ok, back to the ND Proxy = issues then.

My wife turns on her cell phone and this CLAT phone uses the reserved IID a= nd thus does not issue any RA with the ND Proxy P-bit. =A0A tethered client= in a home IPv6 router uses the RA to get a SLAAC IPv6 address. =A0Behind t= he IPv6 CPE router is a network bridge. Subsequently, I turn on my cell pho= ne that supports only an ND Proxy and a single /64. =A0Before my phone is a= ble to send an RA with the P-bit set, the bridged behind home router looped= my wife's phone RA to my phone and my phone loops the RA back to the S= P. =A0Additionally, what does my tethered client do if the client receives = two different RA's as described above and specifically how is proxying = of NA's done? =A0Is the NA sent to the ND Proxy phone or the reserved I= ID phone when the tethered node has only one interface to receive an NS on?=

Soon as one says tethering, testing for what is working code is very broad = because there could be whole network behind one tethered client. =A0This is= the same point Ray Hunter is making and it would be good to reply to his e= mail at the URL below.

http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 3960.html

Regards,

Hemant



_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8fb2028aa7abe804c83b7bbb-- From alexandru.petrescu@gmail.com Mon Aug 27 02:14:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A638821F8605 for ; Mon, 27 Aug 2012 02:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.197 X-Spam-Level: X-Spam-Status: No, score=-9.197 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhycs45XxYG4 for ; Mon, 27 Aug 2012 02:14:07 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46921F858F for ; Mon, 27 Aug 2012 02:14:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q7R9E53a008164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Aug 2012 11:14:05 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q7R9E5Y8010748 for ; Mon, 27 Aug 2012 11:14:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q7R9E1Tj012477 for ; Mon, 27 Aug 2012 11:14:05 +0200 Message-ID: <503B3A59.6040607@gmail.com> Date: Mon, 27 Aug 2012 11:14:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:14:08 -0000 Le 27/08/2012 10:54, Lorenzo Colitti a écrit : > Ok, so how about the following? Comments welcome. > > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in > the glorious future. Your carrier has a release 10 network, and is > providing you with tethering (either because they're a just that nice, > or because you paid extra for the privilege). The CLAT simply behaves > like an RFC 6204 router. Done. > > Now for the rest of us. Since we're still here, it means we only have a > single /64. If you don't want to implement tethering, do nothing. If you > do want to implement tethering, proceed as follows (cell0 is the > upstream interface, wlan0 is the downstream): > > 1. Enable tethering only when cell0 is a point-to-point interface (e.g., > 3G, LTE, ...). > 2. When enabling tethering, take the IPv6 address of cell0 (which you > were already using, and need to continue to use because you have open > connections to it), and assign it to wlan0 instead of cell0 I wonder what breaks if one assigns the same address to two different interfaces (be them of same machine). > 3. Treat cell0 as unnumbered; when sending out packets, use the IP > address assigned to wlan0. > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like > a standard IPv6 router (decrement TTL, etc.) > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa > like a standard IPv6 multicast router (But I don't know anything about > multicast, so I'll shut up now.) > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, > they will fail DAD. Sounds logic. Alex > > So far so good. There is no bridging, and since the upstream is a > point-to-point interface, there are no loops. Note that this is *not* > RFC 4389. But it does not need to be. > > We haven't talked about CLAT yet. There are two cases here: > > 1. The CLAT implementation can use the same IPv6 address as the phone. > In this case, no problem. > 2. The CLAT implementation cannot use the same IPv6 address as the > phone. In this case, either: > a) the CLAT does DAD for that other address as well, or: > b) picks an address that "shouldn't collide" (remi's reserved IID) > > It's as simple as that. So, as far as I can see, the only issue left to > discuss is "do we do 2a or 2b"? > > On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) > > wrote: > > Victor (and also replying to Rajiv in one email), > > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com > ] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt > > >I cannot speak for every operator, but for some of us trying to deploy > >IPv6, if I cannot do it with tethering, I cannot deploy it (part > of the > >service). Not supporting tethering would inhibit my ability to > deploy (in > >my case - perhaps for others). > > Got it - you need tethering immediately. Ok, back to the ND Proxy > issues then. > > My wife turns on her cell phone and this CLAT phone uses the > reserved IID and thus does not issue any RA with the ND Proxy P-bit. > A tethered client in a home IPv6 router uses the RA to get a SLAAC > IPv6 address. Behind the IPv6 CPE router is a network bridge. > Subsequently, I turn on my cell phone that supports only an ND Proxy > and a single /64. Before my phone is able to send an RA with the > P-bit set, the bridged behind home router looped my wife's phone RA > to my phone and my phone loops the RA back to the SP. Additionally, > what does my tethered client do if the client receives two different > RA's as described above and specifically how is proxying of NA's > done? Is the NA sent to the ND Proxy phone or the reserved IID > phone when the tethered node has only one interface to receive an NS on? > > Soon as one says tethering, testing for what is working code is very > broad because there could be whole network behind one tethered > client. This is the same point Ray Hunter is making and it would be > good to reply to his email at the URL below. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html > > Regards, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Mon Aug 27 02:28:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8068F21F8604 for ; Mon, 27 Aug 2012 02:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daYLElNVtmv7 for ; Mon, 27 Aug 2012 02:28:40 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 099B921F858F for ; Mon, 27 Aug 2012 02:28:39 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 5781D700009C; Mon, 27 Aug 2012 11:28:38 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id C7744700006C; Mon, 27 Aug 2012 11:28:37 +0200 (CEST) X-SFR-UUID: 20120827092837817.C7744700006C@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-45-532815799 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 27 Aug 2012 11:28:39 +0200 Message-Id: <9E53F4E6-BF3C-4E2B-8F66-040C0ECE6494@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:28:41 -0000 --Apple-Mail-45-532815799 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-27 =E0 10:54, Lorenzo Colitti a =E9crit : > Ok, so how about the following? Comments welcome. >=20 > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in = the glorious future. Your carrier has a release 10 network, and is = providing you with tethering (either because they're a just that nice, = or because you paid extra for the privilege). The CLAT simply behaves = like an RFC 6204 router. Done. >=20 > Now for the rest of us. Since we're still here, it means we only have = a single /64. If you don't want to implement tethering, do nothing. If = you do want to implement tethering, proceed as follows (cell0 is the = upstream interface, wlan0 is the downstream): >=20 > 1. Enable tethering only when cell0 is a point-to-point interface = (e.g., 3G, LTE, ...). > 2. When enabling tethering, take the IPv6 address of cell0 (which you = were already using, and need to continue to use because you have open = connections to it), and assign it to wlan0 instead of cell0 > 3. Treat cell0 as unnumbered; when sending out packets, use the IP = address assigned to wlan0. > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa = like a standard IPv6 router (decrement TTL, etc.) > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa = like a standard IPv6 multicast router (But I don't know anything about = multicast, so I'll shut up now.) > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, = they will fail DAD. >=20 > So far so good. There is no bridging, and since the upstream is a = point-to-point interface, there are no loops. Note that this is *not* = RFC 4389. But it does not need to be. >=20 > We haven't talked about CLAT yet. There are two cases here: >=20 > 1. The CLAT implementation can use the same IPv6 address as the phone. = In this case, no problem. > 2. The CLAT implementation cannot use the same IPv6 address as the = phone. In this case, either:=20 > a) the CLAT does DAD for that other address as well, or: > b) picks an address that "shouldn't collide" (remi's reserved IID) >=20 > It's as simple as that. So, as far as I can see, the only issue left = to discuss is "do we do 2a or 2b"? Although I may not follow all details, this seems clear enough. Now, 2b has the advantage that it solves the problem of hosts whose IIDs = are assigned before CLAT activation. Since it can be combined with the = extended DAD above, or with ND proxy if used, it is clear that nothing = is lost with it. This IMHO justifies to at least let vendors use 2b if they want, and = even 2a and 2b simultaneously if they prefer . (The proposed amendment = for this is in my last email to Cameron.) By leaving the market decide which combination to use, this BCP can be = published, at last. And 464XLAT can be deployed. Regards, RD =20 >=20 > On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) = wrote: > Victor (and also replying to Rajiv in one email), >=20 > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 > >I cannot speak for every operator, but for some of us trying to = deploy > >IPv6, if I cannot do it with tethering, I cannot deploy it (part of = the > >service). Not supporting tethering would inhibit my ability to deploy = (in > >my case - perhaps for others). >=20 > Got it - you need tethering immediately. Ok, back to the ND Proxy = issues then. >=20 > My wife turns on her cell phone and this CLAT phone uses the reserved = IID and thus does not issue any RA with the ND Proxy P-bit. A tethered = client in a home IPv6 router uses the RA to get a SLAAC IPv6 address. = Behind the IPv6 CPE router is a network bridge. Subsequently, I turn on = my cell phone that supports only an ND Proxy and a single /64. Before = my phone is able to send an RA with the P-bit set, the bridged behind = home router looped my wife's phone RA to my phone and my phone loops the = RA back to the SP. Additionally, what does my tethered client do if the = client receives two different RA's as described above and specifically = how is proxying of NA's done? Is the NA sent to the ND Proxy phone or = the reserved IID phone when the tethered node has only one interface to = receive an NS on? >=20 > Soon as one says tethering, testing for what is working code is very = broad because there could be whole network behind one tethered client. = This is the same point Ray Hunter is making and it would be good to = reply to his email at the URL below. >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html >=20 > Regards, >=20 > Hemant >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-45-532815799 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Ok, so how about the following? Comments = welcome.

0. If you get a DHCPv6 prefix delegation: = congratulations. You live in the glorious future. Your carrier has a = release 10 network, and is providing you with tethering (either because = they're a just that nice, or because you paid extra for the = privilege). The CLAT simply behaves like an RFC 6204 router. Done.

Now for the rest of us. Since we're still here, it = means we only have a single /64. If you don't want to implement = tethering, do nothing. If you do want to implement tethering, proceed as = follows (cell0 is the upstream interface, wlan0 is the = downstream):

1. Enable tethering only when cell0 is a = point-to-point interface (e.g., 3G, LTE, ...).
2. When = enabling tethering, take the IPv6 address of cell0 (which you were = already using, and need to continue to use because you have open = connections to it), and assign it to wlan0 instead of cell0
3. Treat cell0 as unnumbered; when sending out packets, use the IP = address assigned to wlan0.
4. Forward IPv6 unicast packets = from wlan0 to cell0 and vice versa like a standard IPv6 router = (decrement TTL, etc.)
5. Forward IPv6 multicast packets from wlan0 to cell0 and vice = versa like a standard IPv6 multicast router (But I don't know anything = about multicast, so I'll shut up now.)
6. Send an RA for the = /64 to wlan0. If hosts pick the same IID as you, they will fail = DAD.

So far so good. There is no bridging, and since the = upstream is a point-to-point interface, there are no loops. Note that = this is *not* RFC 4389. But it does not need to = be.

We haven't talked about CLAT yet. There are = two cases here:

1. The CLAT implementation can use the same IPv6 = address as the phone. In this case, no problem.
2. The CLAT = implementation cannot use the same IPv6 address as the phone. In this = case, either: 
  a) the CLAT does DAD for that other address as well, = or:
  b) picks an address that "shouldn't collide" = (remi's reserved IID)

It's as simple as that. = So, as far as I can see, the only issue left to discuss is "do we do 2a = or 2b"?

Although I may not follow = all details, this seems clear enough.

Now, 2b = has the advantage that it solves the problem of hosts whose IIDs are = assigned before CLAT activation.  Since it can be combined with the = extended DAD above, or with ND proxy if used, it is clear that nothing = is lost with it.

This IMHO justifies to at = least let vendors use 2b if they want, and even 2a and 2b = simultaneously if they prefer . (The proposed amendment for this is in = my last email to Cameron.)
By leaving the market decide which = combination to use, this BCP can be published, at last. And 464XLAT = can be = deployed.

Regards,
RD




 


On Mon, Aug 27, 2012 at = 10:09 AM, Hemant Singh (shemant) <shemant@cisco.com> wrote:
Victor (and also replying to Rajiv in one email),

-----Original Message-----
From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]=
Sent: Sunday, August 26, 2012 8:04 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt

>I cannot speak for every operator, but for = some of us trying to deploy
>IPv6, if I cannot do it with tethering, I cannot deploy it (part of = the
>service). Not supporting tethering would inhibit my ability to = deploy (in
>my case - perhaps for others).

Got it - you need tethering immediately.  Ok, back to the ND = Proxy issues then.

My wife turns on her cell phone and this CLAT phone uses the reserved = IID and thus does not issue any RA with the ND Proxy P-bit.  A = tethered client in a home IPv6 router uses the RA to get a SLAAC IPv6 = address.  Behind the IPv6 CPE router is a network bridge. = Subsequently, I turn on my cell phone that supports only an ND Proxy and = a single /64.  Before my phone is able to send an RA with the P-bit = set, the bridged behind home router looped my wife's phone RA to my = phone and my phone loops the RA back to the SP.  Additionally, what = does my tethered client do if the client receives two different RA's as = described above and specifically how is proxying of NA's done?  Is = the NA sent to the ND Proxy phone or the reserved IID phone when the = tethered node has only one interface to receive an NS on?

Soon as one says tethering, testing for what is working code is very = broad because there could be whole network behind one tethered client. =  This is the same point Ray Hunter is making and it would be good = to reply to his email at the URL below.

http://www.ietf.org/mail-archive/web/v6ops/current/msg13= 960.html

Regards,

Hemant



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-45-532815799-- From gert@space.net Mon Aug 27 02:50:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CA621F85F4 for ; Mon, 27 Aug 2012 02:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DS41Ex4cA0p for ; Mon, 27 Aug 2012 02:50:04 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC82F21F857D for ; Mon, 27 Aug 2012 02:50:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 25E73F8C9C for ; Mon, 27 Aug 2012 11:50:02 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E93CDF8C89 for ; Mon, 27 Aug 2012 11:50:01 +0200 (CEST) Received: (qmail 30061 invoked by uid 1007); 27 Aug 2012 11:50:01 +0200 Date: Mon, 27 Aug 2012 11:50:01 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20120827095001.GB13776@Space.Net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:50:05 -0000 Hi, On Sun, Aug 26, 2012 at 11:28:24PM +0000, Hemant Singh (shemant) wrote: > The CPE looped Proxied ND packets upstream to the SP which is catastrophic. If that is "catastrophic", something in the SP network is horribly wrong. You have to expect all sort of funny and broken packets from the customer side. If anything coming from the customer is breaking the SP network, it was broken before, you just didn't notice it yet. (Like: missing customer-to-customer isolation, or accepting RAs from customers) > As for the tethered service, I think, there are still large > cellular operators in the U.S. who support the IPhone and not any > tethering. As the iPhone does not support any IPv6 on the 3G side, this is fully irrelevant for a discussion about code that exists *today*. To repeat: Cameron is presenting a solution for *todays* networks that works with *todays* UEs. Don't delay this much needed solutions by worrying about that it might not work in completely different circumstances. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From markzzzsmith@yahoo.com.au Mon Aug 27 02:50:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1B21F8615 for ; Mon, 27 Aug 2012 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6z6xwZVWJcf for ; Mon, 27 Aug 2012 02:50:24 -0700 (PDT) Received: from nm2.bullet.mail.ac4.yahoo.com (nm2.bullet.mail.ac4.yahoo.com [98.139.52.199]) by ietfa.amsl.com (Postfix) with SMTP id 0AAD221F8613 for ; Mon, 27 Aug 2012 02:50:23 -0700 (PDT) Received: from [98.139.52.190] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 09:50:20 -0000 Received: from [98.139.52.153] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 09:50:20 -0000 Received: from [127.0.0.1] by omp1036.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 09:50:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 669207.87224.bm@omp1036.mail.ac4.yahoo.com Received: (qmail 85234 invoked by uid 60001); 27 Aug 2012 09:50:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1346061020; bh=2orhrWLOyAE1l5+IQ6eEFldNXUoGomKzrFPEAWlMpec=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OFwFk8HLHELDNv4jPtmDWOVkCOSTEcj/53UEYK2SxQAyOiTqihoO6be4tlosoHrKKyNqOV0nIraWBguaKdaBMa73rELdMjl4J28Y3LvQwdGU+U1EO2kVOdtMVF0tqRfMdUnyO5IMkAznJGOtZnvQ9AD/KEvQcCc7Fyfz9ITddaI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AToDqS6ULu7NsHOd9bwfS3WPIhIN9OAD1Fk3GLRrZnEwY/5wgr8QOgKKeML+w7HmiSnoCJDLvbZd18wenSN1emCj9f/Im8568HiYoKW0VVVwIXf4aLEPrqLEZirHcB3A3aLlJfWNvKa7rZSVSXj9X30pFAZQrXv2wNwD4suomug=; X-YMail-OSG: s.A_3w0VM1nQ_rAU8fwWnO0UXnk_DIvNbnRKaZQnsh4novx MxXT3jeui28MWEEgzCa9CXDUZpZilPjXEZxmIzyZpRB5qej4kkML2tnqLRb8 rylmJfqZhAbT1sLbBPvaqFXh7pyPrBPgZUNKfAejDfL2iYlQdbaPR1n9qr7x 5wU0xUhG67JS2ue5pkl2fdRDy3VtOpgZF3jnjZ7Lz3nIXFjxvAQO.jrjHDbz lmUIrRcBcFcPvO.hr4CZJC6xEyUAu4w.UlS5PisYve3vRNLFAq4HesMczC3C nSn26JXedlbtO2DmRtAr6xiwAuxPGkdayeDpDSO5BQJV4eYlVLyjjYmhddYv 9VHVj7Cdfc17rpdKhccBYyfISmjhOUYLmQ.1018uWQ_u4criwRAU7AhL_TJY dpw3L1G4ePI6h.l38Ebv7wsB_I3VqS6MbCQAdS5RunqOHy8AMgrqhGivsyWB WmwzvmbnLMAqZKUEEoTGrIB7uNaiROBFIfmP32LrN7kU4oA-- Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 02:50:20 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Message-ID: <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 02:50:20 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , "Hemant Singh \(shemant\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:50:25 -0000 =0A=0A=0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Hemant Singh (shemant) =0A>Cc: "v= 6ops@ietf.org" =0A>Sent: Monday, 27 August 2012 6:54 PM=0A= >Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07= .txt=0A> =0A>=0A>Ok, so how about the following? Comments welcome.=0A>=0A>= =0A>Now for the rest of us. Since we're still here, it means we only have a= single /64. If you don't want to implement tethering, do nothing. If you d= o want to implement tethering, proceed as follows (cell0 is the upstream in= terface, wlan0 is the downstream):=0A>=0A>=0A>1. Enable tethering only when= cell0 is a point-to-point interface (e.g., 3G, LTE, ...).=0A>2. When enabl= ing tethering, take the IPv6 address of cell0 (which you were already using= , and need to continue to use because you have open connections to it), and= assign it to wlan0 instead of cell0=0A>3. Treat cell0 as unnumbered; when = sending out packets, use the IP address assigned to wlan0.=0A>4. Forward IP= v6 unicast packets from wlan0 to cell0 and vice versa like a standard IPv6 = router (decrement TTL, etc.)=0A>5. Forward IPv6 multicast packets from wlan= 0 to cell0 and vice versa like a standard IPv6 multicast router (But I don'= t know anything about multicast, so I'll shut up now.)=0A>6. Send an RA for= the /64 to wlan0. If hosts pick the same IID as you, they will fail DAD.= =0A>=0A=0AI think the above is a good idea. Perhaps rather than moving the = address from the cell0 to wlan0 interface, the cell0 interface could be per= manently unnumbered, and loopback or similar virtual interface is assigned = an address from within the /64, and is a member of a bridge. The wlan0 inte= rface is added or removed from the bridge as tethering is enabled and disab= led.=0A=0A>=0A>So far so good. There is no bridging, and since the upstream= is a point-to-point interface, there are no loops. Note that this is *not*= RFC 4389. But it does not need to be.=0A>=0A>=0A>We haven't talked about C= LAT yet. There are two cases here:=0A>=0A>=0A>1. The CLAT implementation ca= n use the same IPv6 address as the phone. In this case, no problem.=0A>2. T= he CLAT implementation cannot use the same IPv6 address as the phone. In th= is case, either:=A0=0A>=A0 a) the CLAT does DAD for that other address as w= ell, or:=0A>=A0 b) picks an address that "shouldn't collide" (remi's reserv= ed IID)=0A>=0A>=0A>It's as simple as that. So, as far as I can see, the onl= y issue left to discuss is "do we do 2a or 2b"?=0A>=0A>=0A>On Mon, Aug 27, = 2012 at 10:09 AM, Hemant Singh (shemant) wrote:=0A>=0A>= Victor (and also replying to Rajiv in one email),=0A>>=0A>>=0A>>-----Origin= al Message-----=0A>>From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.c= om]=0A>>Sent: Sunday, August 26, 2012 8:04 PM=0A>>To: Hemant Singh (shemant= )=0A>>=0A>>Cc: v6ops@ietf.org=0A>>Subject: Re: [v6ops] single /64, ND Proxy= , and draft-ietf-v6ops-464xlat-07.txt=0A>>=0A>>=0A>>>I cannot speak for eve= ry operator, but for some of us trying to deploy=0A>>>IPv6, if I cannot do = it with tethering, I cannot deploy it (part of the=0A>>>service). Not suppo= rting tethering would inhibit my ability to deploy (in=0A>>>my case - perha= ps for others).=0A>>=0A>>Got it - you need tethering immediately. =A0Ok, ba= ck to the ND Proxy issues then.=0A>>=0A>>My wife turns on her cell phone an= d this CLAT phone uses the reserved IID and thus does not issue any RA with= the ND Proxy P-bit. =A0A tethered client in a home IPv6 router uses the RA= to get a SLAAC IPv6 address. =A0Behind the IPv6 CPE router is a network br= idge. Subsequently, I turn on my cell phone that supports only an ND Proxy = and a single /64. =A0Before my phone is able to send an RA with the P-bit s= et, the bridged behind home router looped my wife's phone RA to my phone an= d my phone loops the RA back to the SP. =A0Additionally, what does my tethe= red client do if the client receives two different RA's as described above = and specifically how is proxying of NA's done? =A0Is the NA sent to the ND = Proxy phone or the reserved IID phone when the tethered node has only one i= nterface to receive an NS on?=0A>>=0A>>Soon as one says tethering, testing = for what is working code is very broad because there could be whole network= behind one tethered client. =A0This is the same point Ray Hunter is making= and it would be good to reply to his email at the URL below.=0A>>=0A>>http= ://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html=0A>>=0A>>Regar= ds,=0A>>=0A>>Hemant=0A>>=0A>>=0A>>=0A>>=0A>>_______________________________= ________________=0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>https://www.= ietf.org/mailman/listinfo/v6ops=0A>>=0A>=0A>_______________________________= ________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.iet= f.org/mailman/listinfo/v6ops=0A>=0A>=0A> From lorenzo@google.com Mon Aug 27 02:51:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1921F861D for ; Mon, 27 Aug 2012 02:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.729 X-Spam-Level: X-Spam-Status: No, score=-102.729 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ38ij1hsiyu for ; Mon, 27 Aug 2012 02:50:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 987E721F861B for ; Mon, 27 Aug 2012 02:50:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8853031obb.31 for ; Mon, 27 Aug 2012 02:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pYV4qugGKP4p9m6/Yv7Dk9zR7Mp5jvBseRhqEcFnhGk=; b=NBJ4yhlPi6nH7PsnFHCtlCWoSjNRGXcgZHV3ewWfDHDmoR+PJjshuLH/5Xq+zTpDaf e6YWvIykRyVWI0YyRjaKOUwBxx5KD7bQkc55gFe0nrAVcmUpu7HE0fmgsZXTpGKHe5px 0s+l/JHeBx0OwH6nSnGM6q63dZo7cKWWKMbCM8UxZE7/wrl6duXR3SUEKFn8Lx7CK4lp mxxq0Zza6qNo3SbzHZxH/KB/suNFThiG9FRMp4bHfZ0GLimdBS9xG0B8JW61cprL4ecB SE5c8YovcPTaSsfsop9NsktES4as8l6GhayY9mDsUbwiiMdjS3orYHaZdcOAiJ7CXMAt GU8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pYV4qugGKP4p9m6/Yv7Dk9zR7Mp5jvBseRhqEcFnhGk=; b=kngh+0/CVCwY2BhxT0JdvSG5+cQXK8iZJzWb3Tef7aKTv1cWlWK1a0Q9ySJB4IYhaR hDzyVe8Ijo3ZV7dUqXTdwHXg6rDQItJnXXP96HXqVdoUTSuWMaNm/9jNbZH1aS5lmO05 bdKR/mgkFt7FQBVErG457EBAsFvj6V928Iu2S/+RSYSLl4jdUH6vnHFvFw1XSfMrKNry T/HDIIz/gnQpIzHShASyCcRZG+RFql1Hllv/8+g1ayKh5AkJ1Sfxx4OpSWIIHluwFr4P vJ48Q9v1mi4z1Zxj+UgKxYv4DaUi5rCiU6fUx6nh71GtSyEo/ZgoCvqE2sT+bFca7Fuy gXPA== Received: by 10.60.10.6 with SMTP id e6mr9759221oeb.45.1346061057183; Mon, 27 Aug 2012 02:50:57 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr9759215oeb.45.1346061056994; Mon, 27 Aug 2012 02:50:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 27 Aug 2012 02:50:36 -0700 (PDT) In-Reply-To: <9E53F4E6-BF3C-4E2B-8F66-040C0ECE6494@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <9E53F4E6-BF3C-4E2B-8F66-040C0ECE6494@laposte.net> From: Lorenzo Colitti Date: Mon, 27 Aug 2012 18:50:36 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2028a25ec7604c83c4303 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmA7ka4WAWE9FwcpgbBLAmo8cA/aq/Jxz1GBtH1VAB7G2Pvc+fUkDlTAdxIscIk7OgiudQUgpGgFxYUX0C39g8wthmJY9CIyou+zRJ3wopvSj6jbydae3Ph40tG0ymuo7YMpsaQ/ITYhHpIb4AIKN9ymS1ZxpUnK255HUdtKEycZjQUlxZI8oohMT51x4TBpkXFK2vE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:51:00 -0000 --e89a8fb2028a25ec7604c83c4303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2012 at 6:28 PM, R=E9mi Despr=E9s wrote: > > Le 2012-08-27 =E0 10:54, Lorenzo Colitti a =E9crit : > > Ok, so how about the following? Comments welcome. > > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in th= e > glorious future. Your carrier has a release 10 network, and is providing > you with tethering (either because they're a just that nice, or because y= ou > paid extra for the privilege). The CLAT simply behaves like an RFC 6204 > router. Done. > > Now for the rest of us. Since we're still here, it means we only have a > single /64. If you don't want to implement tethering, do nothing. If you = do > want to implement tethering, proceed as follows (cell0 is the upstream > interface, wlan0 is the downstream): > > 1. Enable tethering only when cell0 is a point-to-point interface (e.g., > 3G, LTE, ...). > 2. When enabling tethering, take the IPv6 address of cell0 (which you wer= e > already using, and need to continue to use because you have open > connections to it), and assign it to wlan0 instead of cell0 > 3. Treat cell0 as unnumbered; when sending out packets, use the IP addres= s > assigned to wlan0. > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like a > standard IPv6 router (decrement TTL, etc.) > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like > a standard IPv6 multicast router (But I don't know anything about > multicast, so I'll shut up now.) > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, > they will fail DAD. > > So far so good. There is no bridging, and since the upstream is a > point-to-point interface, there are no loops. Note that this is *not* RFC > 4389. But it does not need to be. > > We haven't talked about CLAT yet. There are two cases here: > > 1. The CLAT implementation can use the same IPv6 address as the phone. In > this case, no problem. > 2. The CLAT implementation cannot use the same IPv6 address as the phone. > In this case, either: > a) the CLAT does DAD for that other address as well, or: > b) picks an address that "shouldn't collide" (remi's reserved IID) > > It's as simple as that. So, as far as I can see, the only issue left to > discuss is "do we do 2a or 2b"? > > > Although I may not follow all details, this seems clear enough. > > Now, 2b has the advantage that it solves the problem of hosts whose IIDs > are assigned before CLAT activation. Since it can be combined with the > extended DAD above, or with ND proxy if used, it is clear that nothing is > lost with it. > > This IMHO justifies to at least let vendors use 2b if they want, and even > 2a and 2b simultaneously if they prefer . (The proposed amendment for thi= s > is in my last email to Cameron.) > By leaving the market decide which combination to use, this BCP can be > published, at last. And 464XLAT can be deployed. > > Regards, > RD > Remi, we already know you think 2b is better.But I don't want to get into whether to do 2a or 2b; we are discussing that in another thread. This thread is about whether to support tethering using a single /64, and how to do it. Cheers, Lorenzo --e89a8fb2028a25ec7604c83c4303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 27, 2012 at 6:28 PM, R=E9mi = Despr=E9s <despres.remi@laposte.net> wrote:

Le 2012-08-27 =E0 10:54, = Lorenzo Colitti a =E9crit :

Ok, so how about the following? Comments welcome.

= 0. If you get a DHCPv6 prefix delegation: congratulations. You live in the = glorious future. Your carrier has a release 10 network, and is providing yo= u with tethering (either because they're a just that nice, or=A0because= you paid extra for the privilege). The CLAT simply behaves like an RFC 620= 4 router. Done.

Now for the rest of us. Since we're still here, it = means we only have a single /64. If you don't want to implement tetheri= ng, do nothing. If you do want to implement tethering, proceed as follows (= cell0 is the upstream interface, wlan0 is the downstream):

1. Enable tethering only when cell0 is a point-to-point= interface (e.g., 3G, LTE, ...).
2. When enabling tethering, take= the IPv6 address of cell0 (which you were already using, and need to conti= nue to use because you have open connections to it), and assign it to wlan0= instead of cell0
3. Treat cell0 as unnumbered; when sending out packets, use the IP add= ress assigned to wlan0.
4. Forward IPv6 unicast packets from wlan= 0 to cell0 and vice versa like a standard IPv6 router (decrement TTL, etc.)=
5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa l= ike a standard IPv6 multicast router (But I don't know anything about m= ulticast, so I'll shut up now.)
6. Send an RA for the /64 to = wlan0. If hosts pick the same IID as you, they will fail DAD.

So far so good. There is no bridging, and since the ups= tream is a point-to-point interface, there are no loops. Note that this is = *not* RFC 4389. But it does not need to be.

We hav= en't talked about CLAT yet. There are two cases here:

1. The CLAT implementation can use the same IPv6 addres= s as the phone. In this case, no problem.
2. The CLAT implementat= ion cannot use the same IPv6 address as the phone. In this case, either:=A0=
=A0 a) the CLAT does DAD for that other address as well, or:
=A0 b) picks an address that "shouldn't collide" (remi's= reserved IID)

It's as simple as that. So, as = far as I can see, the only issue left to discuss is "do we do 2a or 2b= "?

Although I may not follow all detail= s, this seems clear enough.

Now, 2b has the advant= age that it solves the problem of hosts whose IIDs are assigned before CLAT= activation. =A0Since it can be combined with the extended DAD above, or wi= th ND proxy if used, it is clear that nothing is lost with it.

This IMHO justifies to at least let vendors use 2b=A0if= they want, and even 2a and 2b simultaneously if they prefer . (The propose= d amendment for this is in my last email to Cameron.)
By leaving = the market decide which combination to use,=A0this BCP can be published, at= last. And 464XLAT can be deployed.

Regards,
RD

Remi,

we already know you think 2= b is better.But=A0I don't want to get into whether to do 2a or 2b; we a= re discussing that in another thread.=A0This thread is about whether to sup= port tethering using a single /64, and how to do it.

Cheers,
Lorenzo
--e89a8fb2028a25ec7604c83c4303-- From alexandru.petrescu@gmail.com Mon Aug 27 02:59:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E565821F8518 for ; Mon, 27 Aug 2012 02:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.207 X-Spam-Level: X-Spam-Status: No, score=-9.207 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFliW+2Qk53S for ; Mon, 27 Aug 2012 02:59:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B591621F8462 for ; Mon, 27 Aug 2012 02:59:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q7R9x0xo015371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Aug 2012 11:59:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q7R9wxwr031455 for ; Mon, 27 Aug 2012 11:58:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q7R9wsZj025031 for ; Mon, 27 Aug 2012 11:58:59 +0200 Message-ID: <503B44DE.1060709@gmail.com> Date: Mon, 27 Aug 2012 11:58:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <9E53F4E6-BF3C-4E2B-8F66-040C0ECE6494@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:59:03 -0000 Le 27/08/2012 11:50, Lorenzo Colitti a écrit : > > > On Mon, Aug 27, 2012 at 6:28 PM, Rémi Després > wrote: > > > Le 2012-08-27 à 10:54, Lorenzo Colitti a écrit : > >> Ok, so how about the following? Comments welcome. >> >> 0. If you get a DHCPv6 prefix delegation: congratulations. You >> live in the glorious future. Your carrier has a release 10 >> network, and is providing you with tethering (either because >> they're a just that nice, or because you paid extra for the >> privilege). The CLAT simply behaves like an RFC 6204 router. Done. >> >> Now for the rest of us. Since we're still here, it means we only >> have a single /64. If you don't want to implement tethering, do >> nothing. If you do want to implement tethering, proceed as follows >> (cell0 is the upstream interface, wlan0 is the downstream): >> >> 1. Enable tethering only when cell0 is a point-to-point interface >> (e.g., 3G, LTE, ...). >> 2. When enabling tethering, take the IPv6 address of cell0 (which >> you were already using, and need to continue to use because you >> have open connections to it), and assign it to wlan0 instead of cell0 >> 3. Treat cell0 as unnumbered; when sending out packets, use the IP >> address assigned to wlan0. >> 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa >> like a standard IPv6 router (decrement TTL, etc.) >> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice >> versa like a standard IPv6 multicast router (But I don't know >> anything about multicast, so I'll shut up now.) >> 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as >> you, they will fail DAD. >> >> So far so good. There is no bridging, and since the upstream is a >> point-to-point interface, there are no loops. Note that this is >> *not* RFC 4389. But it does not need to be. >> >> We haven't talked about CLAT yet. There are two cases here: >> >> 1. The CLAT implementation can use the same IPv6 address as the >> phone. In this case, no problem. >> 2. The CLAT implementation cannot use the same IPv6 address as the >> phone. In this case, either: >> a) the CLAT does DAD for that other address as well, or: >> b) picks an address that "shouldn't collide" (remi's reserved IID) >> >> It's as simple as that. So, as far as I can see, the only issue >> left to discuss is "do we do 2a or 2b"? > > Although I may not follow all details, this seems clear enough. > > Now, 2b has the advantage that it solves the problem of hosts whose > IIDs are assigned before CLAT activation. Since it can be combined > with the extended DAD above, or with ND proxy if used, it is clear > that nothing is lost with it. > > This IMHO justifies to at least let vendors use 2b if they want, and > even 2a and 2b simultaneously if they prefer . (The proposed > amendment for this is in my last email to Cameron.) > By leaving the market decide which combination to use, this BCP can > be published, at last. And 464XLAT can be deployed. > > Regards, > RD > > > Remi, > > we already know you think 2b is better.But I don't want to get into > whether to do 2a or 2b; we are discussing that in another thread. This > thread is about whether to support tethering using a single /64, and how > to do it. There is an alternate possibility where one extracts two different prefixes out of the /64 (a /65 and a /66) and uses DHCP to configure the clients behind. Alex > > Cheers, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Mon Aug 27 03:00:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B86C21F8629 for ; Mon, 27 Aug 2012 03:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-qpTKGXdSPp for ; Mon, 27 Aug 2012 03:00:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7021F8625 for ; Mon, 27 Aug 2012 03:00:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8866576obb.31 for ; Mon, 27 Aug 2012 03:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AwbXsggM/nJFjRfOyu/jyw9Xa4GD3Brv8lr5dowXCcQ=; b=m0FJiye9HoDPJEsxaD7aDWweY27GYM4D2HJLKjwj6qpgFVjTr3fC7kOA7Ywfz5SGjK nmSCiEO6PO8GHi0QbpDlXhfTvFff1HAF0u2m1mK/ojttXLOtw6u6Yby8PC9irHqVuHAt 5cy45I8r5R6Hnmyk96DNOnCbZMkphCDnR403DxeGdPs0/26DcfpOWdk7EhQrmKkKYa8s J18zU2zgBLGXccTLyZmmFHYeTb5mNJcShCHeO6Op3o4N3dNBRTU2ZVyiHFH4MxPiUMPD S3gNps/FjtHHZibXWzCOeZXWYYSg9eTCrFaz29yiRDCqBKAViNZjG/gIU1Dx2Bxr0sv3 1Cng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AwbXsggM/nJFjRfOyu/jyw9Xa4GD3Brv8lr5dowXCcQ=; b=QiBwIIWOwDAuuqR8ZSMGGsMZ6jVmmwOpTz2uEfunR7jQOb2Az/vQmVkuptb+KSRCQa ADlR+BzyLM1n3CLh0rESETl/oMW05TQ6oddXWwBZTyTE/H9w2SKGjdFxs6f1/w+lxkIN kD/1jH52kzY8jPX4T/FMRExY6yk3OM5Na/lfifsFgo3aZCB4hSlYzvK6Jal35O8QtNC1 4/znkjwqR45rnfAe0vHvbRRgqZOx9nRFaKmYsgs6Y9NU8FidD3pmiWk0KHM/LzHs8CB5 zR/xXYtyAhSujg1WwnLuQ78SwA3gMmDFGIHx8H9vPzU3kypowiy+avUqnqE6cJh/DT+2 nIsg== Received: by 10.60.170.229 with SMTP id ap5mr9418989oec.101.1346061646213; Mon, 27 Aug 2012 03:00:46 -0700 (PDT) Received: by 10.60.170.229 with SMTP id ap5mr9418979oec.101.1346061646071; Mon, 27 Aug 2012 03:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 27 Aug 2012 03:00:25 -0700 (PDT) In-Reply-To: <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> From: Lorenzo Colitti Date: Mon, 27 Aug 2012 19:00:25 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=bcaec54b4ac042899104c83c66d2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmvjZf4U3+F73LADCsBvpVj5859mmS2NkkeSlVt+Xl6dvU9bKna63tbcxCgVFSl+H5tYHayEX7t+Uxys20Ez7OGbyjCeO5s4gQJ7v0pKQwdkkuxCaBkCsJHp2YYhZwP9rFbnTsL4xFhwkrlITzzzXfdRAqIksJawvvtUb4HBDbO8vGO+TKaHB4Xe1ci+rQVHMPdlyTs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:00:47 -0000 --bcaec54b4ac042899104c83c66d2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith wrote: > >6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, > they will fail DAD. > > I think the above is a good idea. Perhaps rather than moving the address > from the cell0 to wlan0 interface, the cell0 interface could be permanently > unnumbered, and loopback or similar virtual interface is assigned an > address from within the /64, and is a member of a bridge. The wlan0 > interface is added or removed from the bridge as tethering is enabled and > disabled. One of the reasons I suggest we don't do bridging is that bridges forward broadcasts and ND packets, and that can cause various nastiness. I think routing is much simpler, and if you don't want to move the IPv6 address from cell0 to wlan0 all you need to do is send proxy NAs for your own address (note - this *is different* from ND proxy as defined in RFC 4389). --bcaec54b4ac042899104c83c66d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith <markzzzsmith@yaho= o.com.au> wrote:
>6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, = they will fail DAD.

I think the above is a good idea. Perhaps rather than moving the addr= ess from the cell0 to wlan0 interface, the cell0 interface could be permane= ntly unnumbered, and loopback or similar virtual interface is assigned an a= ddress from within the /64, and is a member of a bridge. The wlan0 interfac= e is added or removed from the bridge as tethering is enabled and disabled.=

One of the reasons I suggest we don't do bridging i= s that bridges forward broadcasts and ND packets, and that can cause variou= s nastiness. I think routing is much simpler, and if you don't want to = move the IPv6 address from cell0 to wlan0 all you need to do is send proxy = NAs for your own address (note - this *is different* from ND proxy as defin= ed in RFC 4389).
--bcaec54b4ac042899104c83c66d2-- From despres.remi@laposte.net Mon Aug 27 03:13:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9FA21F84DD for ; Mon, 27 Aug 2012 03:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hst4cBJ2dv3 for ; Mon, 27 Aug 2012 03:13:43 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 021DB21F8526 for ; Mon, 27 Aug 2012 03:13:42 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 8D600700009A; Mon, 27 Aug 2012 12:13:41 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 1FCFD70000AD; Mon, 27 Aug 2012 12:13:41 +0200 (CEST) X-SFR-UUID: 20120827101341130.1FCFD70000AD@msfrf2401.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-50-535515450 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 27 Aug 2012 12:13:39 +0200 Message-Id: <1E0B3B58-4145-4DD5-B7A8-DA494C3501EB@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <9E53F4E6-BF3C-4E2B-8F66-040C0ECE6494@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:13:44 -0000 --Apple-Mail-50-535515450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-27 =E0 11:50, Lorenzo Colitti a =E9crit : >=20 >=20 > On Mon, Aug 27, 2012 at 6:28 PM, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-08-27 =E0 10:54, Lorenzo Colitti a =E9crit : >=20 >> Ok, so how about the following? Comments welcome. >>=20 >> 0. If you get a DHCPv6 prefix delegation: congratulations. You live = in the glorious future. Your carrier has a release 10 network, and is = providing you with tethering (either because they're a just that nice, = or because you paid extra for the privilege). The CLAT simply behaves = like an RFC 6204 router. Done. >>=20 >> Now for the rest of us. Since we're still here, it means we only have = a single /64. If you don't want to implement tethering, do nothing. If = you do want to implement tethering, proceed as follows (cell0 is the = upstream interface, wlan0 is the downstream): >>=20 >> 1. Enable tethering only when cell0 is a point-to-point interface = (e.g., 3G, LTE, ...). >> 2. When enabling tethering, take the IPv6 address of cell0 (which you = were already using, and need to continue to use because you have open = connections to it), and assign it to wlan0 instead of cell0 >> 3. Treat cell0 as unnumbered; when sending out packets, use the IP = address assigned to wlan0. >> 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa = like a standard IPv6 router (decrement TTL, etc.) >> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa = like a standard IPv6 multicast router (But I don't know anything about = multicast, so I'll shut up now.) >> 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as = you, they will fail DAD. >>=20 >> So far so good. There is no bridging, and since the upstream is a = point-to-point interface, there are no loops. Note that this is *not* = RFC 4389. But it does not need to be. >>=20 >> We haven't talked about CLAT yet. There are two cases here: >>=20 >> 1. The CLAT implementation can use the same IPv6 address as the = phone. In this case, no problem. >> 2. The CLAT implementation cannot use the same IPv6 address as the = phone. In this case, either:=20 >> a) the CLAT does DAD for that other address as well, or: >> b) picks an address that "shouldn't collide" (remi's reserved IID) >>=20 >> It's as simple as that. So, as far as I can see, the only issue left = to discuss is "do we do 2a or 2b"? >=20 > Although I may not follow all details, this seems clear enough. >=20 > Now, 2b has the advantage that it solves the problem of hosts whose = IIDs are assigned before CLAT activation. Since it can be combined with = the extended DAD above, or with ND proxy if used, it is clear that = nothing is lost with it. >=20 > This IMHO justifies to at least let vendors use 2b if they want, and = even 2a and 2b simultaneously if they prefer . (The proposed amendment = for this is in my last email to Cameron.) > By leaving the market decide which combination to use, this BCP can be = published, at last. And 464XLAT can be deployed. >=20 > Regards, > RD >=20 > Remi, >=20 > we already know you think 2b is better.But I don't want to get into = whether to do 2a or 2b; we are discussing that in another thread.=20 > This thread is about whether to support tethering using a single /64, = and how to do it. Fair enough. /64 tethering support? YES, it can work, and therefore must be a = possible deployment scenario where UEs are assigned /64s. Note however that saying "the only issue left to discuss is 'do we do 2a = or 2b'" is more restrictive than needed: they can be used = simultaneously. RD >=20 > Cheers, > Lorenzo --Apple-Mail-50-535515450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Mon, Aug 27, 2012 at = 6:28 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

Le 2012-08-27 =E0 = 10:54, Lorenzo Colitti a =E9crit :

Ok, so how about the following? Comments = welcome.

0. If you get a DHCPv6 prefix delegation: = congratulations. You live in the glorious future. Your carrier has a = release 10 network, and is providing you with tethering (either because = they're a just that nice, or because you paid extra for the = privilege). The CLAT simply behaves like an RFC 6204 router. Done.

Now for the rest of us. Since we're still here, it = means we only have a single /64. If you don't want to implement = tethering, do nothing. If you do want to implement tethering, proceed as = follows (cell0 is the upstream interface, wlan0 is the = downstream):

1. Enable tethering only when cell0 is a = point-to-point interface (e.g., 3G, LTE, ...).
2. When = enabling tethering, take the IPv6 address of cell0 (which you were = already using, and need to continue to use because you have open = connections to it), and assign it to wlan0 instead of cell0
3. Treat cell0 as unnumbered; when sending out packets, use the IP = address assigned to wlan0.
4. Forward IPv6 unicast packets = from wlan0 to cell0 and vice versa like a standard IPv6 router = (decrement TTL, etc.)
5. Forward IPv6 multicast packets from wlan0 to cell0 and vice = versa like a standard IPv6 multicast router (But I don't know anything = about multicast, so I'll shut up now.)
6. Send an RA for the = /64 to wlan0. If hosts pick the same IID as you, they will fail = DAD.

So far so good. There is no bridging, and since the = upstream is a point-to-point interface, there are no loops. Note that = this is *not* RFC 4389. But it does not need to = be.

We haven't talked about CLAT yet. There are = two cases here:

1. The CLAT implementation can use the same IPv6 = address as the phone. In this case, no problem.
2. The CLAT = implementation cannot use the same IPv6 address as the phone. In this = case, either: 
  a) the CLAT does DAD for that other address as well, = or:
  b) picks an address that "shouldn't collide" = (remi's reserved IID)

It's as simple as that. = So, as far as I can see, the only issue left to discuss is "do we do 2a = or 2b"?

Although I may not follow all = details, this seems clear enough.

Now, 2b has = the advantage that it solves the problem of hosts whose IIDs are = assigned before CLAT activation.  Since it can be combined with the = extended DAD above, or with ND proxy if used, it is clear that nothing = is lost with it.

This IMHO justifies to at least let vendors use = 2b if they want, and even 2a and 2b simultaneously if they prefer . = (The proposed amendment for this is in my last email to = Cameron.)
By leaving the market decide which combination to = use, this BCP can be published, at last. And 464XLAT can be = deployed.
=

Regards,
RD

Remi,

we already know you = think 2b is better.But I don't want to get into whether to do 2a or = 2b; we are discussing that in another = thread. 

This thread is about whether to support = tethering using a single /64, and how to do = it.

Fair enough.
/64 = tethering support? YES, it can work, and therefore must be a possible = deployment scenario where UEs are assigned = /64s.

Note however that saying "the only issue = left to discuss is 'do we do 2a or 2b'" is more restrictive than needed: = they can be used = simultaneously.

RD


<= /div>





Cheers,
Lorenzo

= --Apple-Mail-50-535515450-- From ales.vizdal@t-mobile.cz Mon Aug 27 04:23:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C72921F8554 for ; Mon, 27 Aug 2012 04:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[AWL=2.212, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abi3Cb0zjYHf for ; Mon, 27 Aug 2012 04:23:19 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59E21F853B for ; Mon, 27 Aug 2012 04:23:19 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 7523B28580B; Mon, 27 Aug 2012 13:23:17 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Mon, 27 Aug 2012 13:23:17 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Mon, 27 Aug 2012 13:23:17 +0200 Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2ENGI0N1XuIrFSQ1mnQ3w4WYYesQAET9xA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D92BC4@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <503B3A59.6040607@gmail.com> In-Reply-To: <503B3A59.6040607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:23:20 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Monday, August 27, 2012 11:14 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 > Le 27/08/2012 10:54, Lorenzo Colitti a =E9crit : > > Ok, so how about the following? Comments welcome. > > > > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in > > the glorious future. Your carrier has a release 10 network, and is > > providing you with tethering (either because they're a just that nice, > > or because you paid extra for the privilege). The CLAT simply behaves > > like an RFC 6204 router. Done. > > > > Now for the rest of us. Since we're still here, it means we only have a > > single /64. If you don't want to implement tethering, do nothing. If yo= u > > do want to implement tethering, proceed as follows (cell0 is the > > upstream interface, wlan0 is the downstream): > > > > 1. Enable tethering only when cell0 is a point-to-point interface (e.g.= , > > 3G, LTE, ...). > > 2. When enabling tethering, take the IPv6 address of cell0 (which you > > were already using, and need to continue to use because you have open > > connections to it), and assign it to wlan0 instead of cell0 >=20 > I wonder what breaks if one assigns the same address to two different > interfaces (be them of same machine). As I understood it, Lorenzo is proposing to move the IPv6 address from cell0 to wlan0 and leave cell0 with LLA only and rely on rfc3484 to pick the right source address. SLAAC would need to be disabled on cell0=20 (for the time tethering is ON) as the packet core gw will be sending RAs. fyi. the packet core gw is not allowed to use any ip address out of /64 for its interface, so the /64 is fully owned by the UE =20 > > 3. Treat cell0 as unnumbered; when sending out packets, use the IP > > address assigned to wlan0. > > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like > > a standard IPv6 router (decrement TTL, etc.) > > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa > > like a standard IPv6 multicast router (But I don't know anything about > > multicast, so I'll shut up now.) > > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, > > they will fail DAD. >=20 > Sounds logic. >=20 > Alex >=20 > > > > So far so good. There is no bridging, and since the upstream is a > > point-to-point interface, there are no loops. Note that this is *not* > > RFC 4389. But it does not need to be. > > > > We haven't talked about CLAT yet. There are two cases here: > > > > 1. The CLAT implementation can use the same IPv6 address as the phone. > > In this case, no problem. > > 2. The CLAT implementation cannot use the same IPv6 address as the > > phone. In this case, either: > > a) the CLAT does DAD for that other address as well, or: > > b) picks an address that "shouldn't collide" (remi's reserved IID) > > > > It's as simple as that. So, as far as I can see, the only issue left to > > discuss is "do we do 2a or 2b"? Cheers, Ales From alexandru.petrescu@gmail.com Mon Aug 27 04:56:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749B321F8647 for ; Mon, 27 Aug 2012 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.368 X-Spam-Level: X-Spam-Status: No, score=-9.368 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o1Yi2-8tRRa for ; Mon, 27 Aug 2012 04:56:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF3F21F8639 for ; Mon, 27 Aug 2012 04:56:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q7RBuojj026336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Aug 2012 13:56:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q7RBuoEJ029842; Mon, 27 Aug 2012 13:56:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q7RBujY6019521; Mon, 27 Aug 2012 13:56:49 +0200 Message-ID: <503B607E.8020900@gmail.com> Date: Mon, 27 Aug 2012 13:56:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <503B3A59.6040607@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC681D92BC4@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC681D92BC4@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:56:56 -0000 Le 27/08/2012 13:23, Vízdal Ale¹ a écrit : >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, August 27, 2012 11:14 AM To: v6ops@ietf.org Subject: >> Re: [v6ops] single /64, ND Proxy, and >> draft-ietf-v6ops-464xlat-07.txt >> >> Le 27/08/2012 10:54, Lorenzo Colitti a écrit : >>> Ok, so how about the following? Comments welcome. >>> >>> 0. If you get a DHCPv6 prefix delegation: congratulations. You >>> live in the glorious future. Your carrier has a release 10 >>> network, and is providing you with tethering (either because >>> they're a just that nice, or because you paid extra for the >>> privilege). The CLAT simply behaves like an RFC 6204 router. >>> Done. >>> >>> Now for the rest of us. Since we're still here, it means we only >>> have a single /64. If you don't want to implement tethering, do >>> nothing. If you do want to implement tethering, proceed as >>> follows (cell0 is the upstream interface, wlan0 is the >>> downstream): >>> >>> 1. Enable tethering only when cell0 is a point-to-point interface >>> (e.g., 3G, LTE, ...). 2. When enabling tethering, take the IPv6 >>> address of cell0 (which you were already using, and need to >>> continue to use because you have open connections to it), and >>> assign it to wlan0 instead of cell0 >> >> I wonder what breaks if one assigns the same address to two >> different interfaces (be them of same machine). > > As I understood it, Lorenzo is proposing to move the IPv6 address > from cell0 to wlan0 and leave cell0 with LLA only and rely on rfc3484 > to pick the right source address. This looks advantageous for the common case of a UE with one wlan0 and a single subnet behind it. I wonder whether this would work when there is bt0 in addition to wlan0 and cell0. Put the operator-assigned address on both wlan0 and bt0? > SLAAC would need to be disabled on cell0 (for the time tethering is > ON) as the packet core gw will be sending RAs. Ok, makes sense. (but in my setting the packet core gw is not sending RAs although it does negotiate an IPv6 address with UE, and works as default router). > fyi. the packet core gw is not allowed to use any ip address out of > /64 for its interface, so the /64 is fully owned by the UE Is one sure that the packet core gw is not allowed to use any IP address out of that /64? (I mean there may exist some spec saying so?) Yours, Alex >>> 3. Treat cell0 as unnumbered; when sending out packets, use the >>> IP address assigned to wlan0. 4. Forward IPv6 unicast packets >>> from wlan0 to cell0 and vice versa like a standard IPv6 router >>> (decrement TTL, etc.) 5. Forward IPv6 multicast packets from >>> wlan0 to cell0 and vice versa like a standard IPv6 multicast >>> router (But I don't know anything about multicast, so I'll shut >>> up now.) 6. Send an RA for the /64 to wlan0. If hosts pick the >>> same IID as you, they will fail DAD. >> >> Sounds logic. >> >> Alex >> >>> >>> So far so good. There is no bridging, and since the upstream is >>> a point-to-point interface, there are no loops. Note that this is >>> *not* RFC 4389. But it does not need to be. >>> >>> We haven't talked about CLAT yet. There are two cases here: >>> >>> 1. The CLAT implementation can use the same IPv6 address as the >>> phone. In this case, no problem. 2. The CLAT implementation >>> cannot use the same IPv6 address as the phone. In this case, >>> either: a) the CLAT does DAD for that other address as well, or: >>> b) picks an address that "shouldn't collide" (remi's reserved >>> IID) >>> >>> It's as simple as that. So, as far as I can see, the only issue >>> left to discuss is "do we do 2a or 2b"? > > Cheers, Ales > > From gert@space.net Mon Aug 27 05:11:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9F21F863F for ; Mon, 27 Aug 2012 05:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVwlysmnIKG0 for ; Mon, 27 Aug 2012 05:11:45 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 768A021F8621 for ; Mon, 27 Aug 2012 05:11:41 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C653AF8C72 for ; Mon, 27 Aug 2012 14:11:40 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 93E0BF8C6A for ; Mon, 27 Aug 2012 14:11:40 +0200 (CEST) Received: (qmail 68735 invoked by uid 1007); 27 Aug 2012 14:11:40 +0200 Date: Mon, 27 Aug 2012 14:11:40 +0200 From: Gert Doering To: Tore Anderson Message-ID: <20120827121140.GF13776@Space.Net> References: <503B226D.3020205@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503B226D.3020205@redpill-linpro.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:11:46 -0000 Hi, On Mon, Aug 27, 2012 at 09:31:57AM +0200, Tore Anderson wrote: > As to the current bickering going on about ND-Proxy and IANA-reserved > IID...we need a bike shed like 464XLAT *now*, regardless of hue. Amen. Or "+1". Gert Doering -- Operator. -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Mon Aug 27 05:25:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8621F84F7 for ; Mon, 27 Aug 2012 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sRpXo5P8h+J for ; Mon, 27 Aug 2012 05:25:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F04B521F84C5 for ; Mon, 27 Aug 2012 05:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5551; q=dns/txt; s=iport; t=1346070358; x=1347279958; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=raxGzytMXMB+8XTx/F/qo8fXhJ5fpqwtRDhnk86TAkI=; b=eZKcPYRCMVFZ8zqIN/n6k2yt/2Xpq0pvRxVo/O03/1sBRuOPJ6lTEqbV z7DcX4G1xpvvqpqe39LmVXNoT3LKovd+JdccrWOc5VCcF1jOZRHxEa3PK f54ptFVrfr9waSNiZul050tOLVsDEIjgUQjH54XwYehzDHPeLiXinGw0q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPRmO1CtJV2d/2dsb2JhbABFgkq4LIEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBqHa5oan36LCIYxYAOkA4FngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,320,1344211200"; d="scan'208,217";a="112567754" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 27 Aug 2012 12:25:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7RCPaFn027293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 12:25:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 07:25:36 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti , Mark ZZZ Smith Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtryqAgAAPgwCAAALRgP//0K+w Date: Mon, 27 Aug 2012 12:25:35 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006 x-tm-as-result: No--32.793800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B890782C0xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:25:59 -0000 --_000_75B6FA9F576969419E42BECB86CB1B890782C0xmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Monday, August 27, 2012 6:00 AM To: Mark ZZZ Smith Cc: Hemant Singh (shemant); v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >One of the reasons I suggest we don't do bridging is that bridges forward = broadcasts and ND packets, and that can cause various nastiness. I think ro= uting is much simpler, and if you don't want to >move the IPv6 address from= cell0 to wlan0 all you need to do is send proxy NAs for your own address (= note - this *is different* from ND proxy as defined in RFC 4389). Thanks for the details in your other email. The UE will still need to prox= y the RA from the service provider to the wlan0 segment of the UE. Further= an NS arrives at cell0 from the service provider. The UE will also have = to proxy this NS. Thus there is no getting around the ND Proxy. Hemant --_000_75B6FA9F576969419E42BECB86CB1B890782C0xmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo=

 <= /p>

From: Lorenzo = Colitti [mailto:lorenzo@google.com]
Sent: Monday, August 27, 2012 6:00 AM
To: Mark ZZZ Smith
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464x= lat-07.txt

 

>One of the = reasons I suggest we don't do bridging is that bridges forward broadcasts a= nd ND packets, and that can cause various nastiness. I think routing is muc= h simpler, and if you don't want to >move the IPv6 address from cell0 t= o wlan0 all you need to do is send proxy NAs for your own address (note - t= his *is different* from ND proxy as defined in RFC 4389).

 <= /p>

Thanks for the details in= your other email.  The UE will still need to proxy the RA from the se= rvice provider to the wlan0 segment of the UE.  Further an NS arrives at cell0 from the service provider.   The UE will also h= ave to proxy this NS.  Thus there is no getting around the ND Proxy.&n= bsp;

 <= /p>

Hemant<= /p>

--_000_75B6FA9F576969419E42BECB86CB1B890782C0xmbrcdx06ciscocom_-- From jouni.nospam@gmail.com Mon Aug 27 05:34:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1917821F8497 for ; Mon, 27 Aug 2012 05:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+mfey9RoVlo for ; Mon, 27 Aug 2012 05:34:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0221F8494 for ; Mon, 27 Aug 2012 05:34:51 -0700 (PDT) Received: by eekb45 with SMTP id b45so1418553eek.31 for ; Mon, 27 Aug 2012 05:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=b59QpQ9jHPez7wXS9h552mHyskqQ5bcTEa9txq5vI7I=; b=mQSLDeLieZ+igtyk6xqU4R1OdZ01ZVqH82Gr9CrCUsNd/3nnjxHVl6FfUovYPZ5fas Z1bJONKAvonlVRTOGwLIzozI5EAD3ZkTMuqfFAAT5Epy3YwBecWMCAHT6T9UH2O/U7iG fu9PGC6wMaYqp/g+rOI6If2PDlqqHrh0Fj+oSVSB9i796It71pY+BXpWpZDhjxWqtFYn N+sL+RvLIyX+OKpj4NNYoOwZ1lBVH78BwO4dh2XXdsrv1X353o1u2Pon9mP500Vfekh6 0LeFayJJzuq8rzoCYIfUWn790eVbe2bOs9qlzDncFmcwFCdeqF/2x8R902xlGJe3POeU uHhw== Received: by 10.14.225.200 with SMTP id z48mr17290904eep.39.1346070890208; Mon, 27 Aug 2012 05:34:50 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 45sm52000553eed.17.2012.08.27.05.34.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 05:34:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <503B607E.8020900@gmail.com> Date: Mon, 27 Aug 2012 15:34:41 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <503B3A59.6040607@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC681D92BC4@SRVHKE02.rdm.cz> <503B607E.8020900@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:34:52 -0000 On Aug 27, 2012, at 2:56 PM, Alexandru Petrescu wrote: > >> fyi. the packet core gw is not allowed to use any ip address out of >> /64 for its interface, so the /64 is fully owned by the UE > > Is one sure that the packet core gw is not allowed to use any IP address > out of that /64? (I mean there may exist some spec saying so?) Ales refers here to 3GPP GGSN/PGW, which has this restriction. See RFC6459 Section 5.2 (paragraph 3). - Jouni From tsavo.stds@gmail.com Mon Aug 27 05:53:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9FF21F851B for ; Mon, 27 Aug 2012 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3MwDFfJ654Y for ; Mon, 27 Aug 2012 05:53:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57B21F8505 for ; Mon, 27 Aug 2012 05:53:04 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so7274395pbb.31 for ; Mon, 27 Aug 2012 05:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2BWCGMn6EgwbZMVeY/PIAUKkQnFaIAqFFjYlf1rYLN0=; b=OHWb5AuNb4j4ZxfNC0Qz8EuIN5iov1zyYQx5oC/Of0NptDiumCJZtnDF+dQ0bsItvF zkcJti+6HFi7NZ+0dscQk4Fnn5SiJxoc/aLT/vxKzt3mXx7MC/FJawPVcdL12TdglPEU a/JWlr4NfTk6W6VYZX3Mcx4FET8QG9DOjEFkG3ohGDtFoAodojuLumrSERgHCZoxujSB kr4OJnVUCQ9TfhaMwHjDdCtHtEIQq20l2rFdjG4NsD1nltvmIqVf4qH/aoC11WkLn8KP 5woy8RWcYagqZ/HZLyLtb18dw6CPa4eEskbroXjEjVs8EILE/87uWkMpnj/WsZoyK9Lq e/HA== MIME-Version: 1.0 Received: by 10.66.73.69 with SMTP id j5mr30104418pav.8.1346071984181; Mon, 27 Aug 2012 05:53:04 -0700 (PDT) Received: by 10.68.58.162 with HTTP; Mon, 27 Aug 2012 05:53:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Aug 2012 15:53:04 +0300 Message-ID: From: Teemu Savolainen To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=f46d042ef65f7592f104c83ece81 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:53:08 -0000 --f46d042ef65f7592f104c83ece81 Content-Type: text/plain; charset=ISO-8859-1 Draft says (almost the same text in two places, here only once): The CLAT MAY discover the Pref64::/n of the PLAT via some method such as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or [I-D.ietf-behave-nat64-discovery-heuristic]. The heuristic is on Standard Track at Behave WG, while RFC3123 is experimental and for DHCPv6 option afaik there are no proposals on the table. About TR-069 I have no idea if it touches this topic (reference missing at least). Furthermore, the http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03 (RFC Editor's queue) determined the heuristic as way to go, so should the text in draft say instead something like this: -- The CLAT MAY discover the Pref64::/n of the PLAT via [I-D.ietf-behave-nat64-discovery-heuristic]. In the future some other mechanisms, such as one using DNS APL RR [RFC3123] or a new DHCPv6 option, will possibly be defined. -- If you want for some reason list undefined options (I'd rather drop them and just say): -- The CLAT MAY discover the Pref64::/n of the PLAT via [I-D.ietf-behave-nat64-discovery-heuristic]. -- ? Best regards, Teemu 2012/8/21 Fred Baker (fred) > This is to open a two week Working Group last Call on > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > > Please read it now. We are interested in, among other things, technical > commentary on the draft and the working group's perception on its > usefulness to its target audience. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d042ef65f7592f104c83ece81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Draft says (almost the same text in two places, here only once):

=A0= =A0 The CLAT MAY discover the Pref64::/n of the PLAT via some method such=A0=A0 as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or
=A0=A0 [I-D.i= etf-behave-nat64-discovery-heuristic].

The heuristic is on Standard Track at Behave WG, while RFC3123 is exper= imental and for DHCPv6 option afaik there are no proposals on the table. Ab= out TR-069 I have no idea if it touches this topic (reference missing at le= ast).

Furthermore, the http://tools.ietf.org/html/draft-ietf-behave-nat= 64-learn-analysis-03 (RFC Editor's queue) determined the heuristic = as way to go, so should the text in draft say instead something like this:<= br>
--
The CLAT MAY discover the Pref64::/n of the PLAT via [I-D.ietf-be= have-nat64-discovery-heuristic]. In the future some other mechanisms, such = as one using DNS APL RR [RFC3123] or a new DHCPv6 option, will possibly be = defined.
--

If you want for some reason list undefined options (I'd rathe= r drop them and just say):
--
The CLAT MAY discover the Pref64::/n of= the PLAT via [I-D.ietf-behave-nat64-discovery-heuristic].
--

?

Best regards,

Teemu


2= 012/8/21 Fred Baker (fred) <fred@cisco.com>
This is to open a two week Working Group last Call on

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
=A0 "464XLAT: Combination of Stateful and Stateless Translation",= Masataka
=A0 Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12

Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulne= ss to its target audience.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d042ef65f7592f104c83ece81-- From ales.vizdal@t-mobile.cz Mon Aug 27 05:56:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2C21F8653 for ; Mon, 27 Aug 2012 05:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=1.896, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sljOQ5FvG1dA for ; Mon, 27 Aug 2012 05:55:59 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83C21F860B for ; Mon, 27 Aug 2012 05:55:59 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 517B1285817; Mon, 27 Aug 2012 14:55:58 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Mon, 27 Aug 2012 14:55:57 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Hemant Singh (shemant)" , Lorenzo Colitti , Mark ZZZ Smith Date: Mon, 27 Aug 2012 14:55:56 +0200 Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtryqAgAAPgwCAAALRgP//0K+wgAAK1pA= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D92C44@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC681D92C44SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:56:00 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC681D92C44SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Monday, August 27, 2012 2:26 PM To: Lorenzo Colitti; Mark ZZZ Smith Cc: v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Monday, August 27, 2012 6:00 AM To: Mark ZZZ Smith Cc: Hemant Singh (shemant); v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >One of the reasons I suggest we don't do bridging is that bridges forward = broadcasts and ND packets, and that can cause various nastiness. I think ro= uting is much simpler, and if you don't want to >move the IPv6 address from= cell0 to wlan0 all you need to do is send proxy NAs for your own address (= note - this *is different* from ND proxy as defined in RFC 4389). Thanks for the details in your other email. The UE will still need to prox= y the RA from the service provider to the wlan0 segment of the UE. Further= an NS arrives at cell0 from the service provider. The UE will also have = to proxy this NS. Thus there is no getting around the ND Proxy. The UE might need to proxy the RS from the LAN to the 3GPP link as the 3GPP= specs are proposing tuning the RA interval to ~4hrs after few initial mess= ages. Or the UE would need to be sending the RA on behalf of the SP. Speaki= ng about the 3GPP GGSN/PDN-GW I wonder if the GGSN/PDN-GW needs to do NS/NA as the 3GPP link is a p2p lin= k, so the GGSN/PDN-GW will send anything that belongs to /64 down to the UE= . (but I might need to think more about it) Hemant Ales --_000_1808340F7EC362469DDFFB112B37E2FCC681D92C44SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

=

From: v6o= ps-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hem= ant Singh (shemant)
Sent: Monday, August 27, 2012 2:26 PM
T= o: Lorenzo Colitti; Mark ZZZ Smith
Cc: v6ops@ietf.org
S= ubject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-= 07.txt

 

Lorenzo

 

From: Lorenzo Colitti [<= a href=3D"mailto:lorenzo@google.com">mailto:lorenzo@google.com]
= Sent: Monday, August 27, 2012 6:00 AM
To: Mark ZZZ Smith
<= b>Cc: Hemant Singh (shemant); v6ops@i= etf.org
Subject: Re: [v6ops] single /64, ND Proxy, and draft-= ietf-v6ops-464xlat-07.txt

<= span lang=3DEN-US> 

>= One of the reasons I suggest we don't do bridging is that bridges forward b= roadcasts and ND packets, and that can cause various nastiness. I think rou= ting is much simpler, and if you don't want to >move the IPv6 address from cell0 to wlan0 all you need to do i= s send proxy NAs for your own address (note - this *is different* from ND p= roxy as defined in RFC 4389).

 

Thanks for the details in y= our other email.  The UE will still need to proxy the RA from the serv= ice provider to the wlan0 segment of the UE.  Further an NS arrives at= cell0 from the service provider.   The UE will also have to prox= y this NS.  Thus there is no getting around the ND Proxy.  <= /o:p>

 <= /span>

The UE might need to pro= xy the RS from the LAN to the 3GPP link as the 3GPP specs are proposing tun= ing the RA interval to ~4hrs after few initial messages. Or the UE would ne= ed to be sending the RA on behalf of the SP. Speaking about the 3GPP GGSN/P= DN-GW

I wonde= r if the GGSN/PDN-GW needs to do NS/NA as the 3GPP link is a p2p link, so t= he GGSN/PDN-GW will send anything that belongs to /64 down to the UE. (but = I might need to think more about it)

 

Hemant

 

Ales

 

= --_000_1808340F7EC362469DDFFB112B37E2FCC681D92C44SRVHKE02rdmcz_-- From ales.vizdal@t-mobile.cz Mon Aug 27 06:22:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3543321F8625 for ; Mon, 27 Aug 2012 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[AWL=1.659, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S5grRapF+As for ; Mon, 27 Aug 2012 06:22:22 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2745521F8427 for ; Mon, 27 Aug 2012 06:22:22 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 2B43B285827; Mon, 27 Aug 2012 15:22:21 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 27 Aug 2012 15:21:27 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mark ZZZ Smith , Ray Hunter , "Hemant Singh (shemant)" Date: Mon, 27 Aug 2012 15:21:26 +0200 Thread-Topic: ND Proxy in Mobile [was: RE: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt] Thread-Index: Ac2DK5t/qHtvuL+zSD2HnnoYduhOhgBBbGgA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D92C6E@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: <1345945104.5164.YahooMailNeo@web32504.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: [v6ops] ND Proxy in Mobile [was: RE: single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:22:23 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mark > ZZZ Smith > Sent: Sunday, August 26, 2012 3:38 AM > To: Cameron Byrne; Ray Hunter > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 > ----- Original Message ----- >=20 > > From: Cameron Byrne > > > >=20 > I think the problem is that if the following sort of thing happens and be= comes popular, >=20 > > On my 3GPP Release 7 network, you may tether today with NDproxy and > > have access to the WAN /64 on your LAN. > > >=20 > then this probably won't, because it "won't be necessary", despite it's d= rawbacks: >=20 > > As soon as kit arrives that can do DHCP-PD, that will be the preferred > > mechanism. >=20 > Temporary work-arounds have a horrible habit of becoming permanent work-a= rounds, > and their temporary disadvantages then become permanent ones. If DHCPv6-P= D is the > proper solution, then I don't think anything else should be acceptable. T= he requirement > for DHCPv6-PD support will create the demand for DHCPv6-PD to then be wid= ely > implemented. It seems to me that the discussion is no longer about XLAT, but about the u= sage of the ND Proxy feature. Let me respond as a mobile operator. The benefit (I see) the ND Pr= oxy can provide is=20 decoupling of a Prefix Delegation readiness of a Mobile Network and a UE. S= o a customer can do=20 tethering using IPv6 before the Prefix Delegation will be widely available = using the Mobile Network=20 that can provide him/her with IPv6 connectivity. Cheers, Ales > Regards, > Mark. From lorenzo@google.com Mon Aug 27 06:29:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519B621F8643 for ; Mon, 27 Aug 2012 06:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71PoZSw7ADTW for ; Mon, 27 Aug 2012 06:29:20 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5942421F863C for ; Mon, 27 Aug 2012 06:29:20 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9251493obb.31 for ; Mon, 27 Aug 2012 06:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AuPeHampmhNBs+/sIPbNPcZpY92sfmeA/MtK2GEoqoE=; b=b5XCm0IHT/52o/A0oVY0e+H1mnhDnLprOJBzNu4mfmQtjH9KSFWJngw4a3ppILN2cR HOzAUYcIQ+97YiZXiKi01Y/ByvPLGDDWXm2yDG6B8DWXq4IPO9BFtiVc2uy3I3AOxejI iW1JNmA8QU0b1+pQQwsRLBJ5BW66AW3sExm2Kb+XM26RIf11Mt+X8ndA6DpFCVXeP3TI P2agNqRrbI+0YwfH+U6Rh18h67/Dt+rDRvcBkWqos/rKd+HHvBB6JuokYTXCYN6+xA0P xO1R6jn6BHxMn7/yX3aNlWGIgu1eO84QkckA6rKmAZWOZfUuMf9RLV5FLxorPlRKY+Ox s3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AuPeHampmhNBs+/sIPbNPcZpY92sfmeA/MtK2GEoqoE=; b=D44td3qM27IAOk9n7WdRr1AqeAuJiWfbUQapR7QztoeppaHzljbnt3OG7LeE80YsAR 6jj2dHjVgj+zzi0ouCjjft3buBrlm4OMwpjSah7OrirTVdAxVvHnd7Mpp/68TD6DgSob AfqC4m7VtgiLDST/kDSuz2+0BEMgc9K8xJgl0cbxyJF5j75NwMIVWvwo9xMol4RvGGv9 Dd2AJcP/06MwT5+KI+WrddAii56/zZBgm3D0kQPYoAcWJM0y3Dc4fJlYD2h3P25Lenev mGeifwY0diwQGHYy7t/9/LQjH9qfd5eKsz0DyHkkO9l824M1n5PUtN6kPcP5WGDUOKfQ /QHA== Received: by 10.182.131.98 with SMTP id ol2mr9845955obb.69.1346074159947; Mon, 27 Aug 2012 06:29:19 -0700 (PDT) Received: by 10.182.131.98 with SMTP id ol2mr9845945obb.69.1346074159830; Mon, 27 Aug 2012 06:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 27 Aug 2012 06:28:58 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Mon, 27 Aug 2012 22:28:58 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=e89a8f5028be23571904c83f5057 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn6Zn+DdY6LHV2DrUciUajeeIOFRCivXhnYf17tV7Vv0qtT4TU/A1dqLBw9DvvVMOvPKfYrExF3Xn6otkQC5aJLgjYcKeoL2VqMI+/9lusSwngcCYiY1YQK1mebhqRgXfV9qPReOrIvZai40KcwFftKBd4MM+pZJ/5+Vd10A3mAcvO1WcdgF+WGODndVFWuIIFE9xCJ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:29:21 -0000 --e89a8f5028be23571904c83f5057 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 9:25 PM, Hemant Singh (shemant) wrote: > Lorenzo**** > > ** ** > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Monday, August 27, 2012 6:00 AM > *To:* Mark ZZZ Smith > *Cc:* Hemant Singh (shemant); v6ops@ietf.org > > *Subject:* Re: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt**** > > ** ** > > >One of the reasons I suggest we don't do bridging is that bridges > forward broadcasts and ND packets, and that can cause various nastiness. I > think routing is much simpler, and if you don't want to >move the IPv6 > address from cell0 to wlan0 all you need to do is send proxy NAs for your > own address (note - this *is different* from ND proxy as defined in RFC > 4389).**** > > ** ** > > Thanks for the details in your other email. The UE will still need to > proxy the RA from the service provider to the wlan0 segment of the UE. > No, the UE needs to *send* an RA to its clients. It doesn't have to proxy the one that comes from upstream. > Further an NS arrives at cell0 from the service provider. The UE will > also have to proxy this NS. Thus there is no getting around the ND Proxy. > The network should not send NS packets to the UE. The 3GPP specs are very clear that the handset is allowed to pick any IID on the link that it wants. The only sane way to do this without blowing up state in the network is to route the whole /64 to the handset. --e89a8f5028be23571904c83f5057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2012 at 9:25 PM, Hemant Singh (shemant) <shemant@cisc= o.com> wrote:

Lorenzo

=A0<= /p>

From: Lorenzo = Colitti [mailto:lor= enzo@google.com]
Sent: Monday, August 27, 2012 6:00 AM
To: Mark ZZZ Smith
Cc: Hemant Singh (shemant); v6ops@ietf.org


Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464x= lat-07.txt

=A0

>One of the = reasons I suggest we don't do bridging is that bridges forward broadcas= ts and ND packets, and that can cause various nastiness. I think routing is= much simpler, and if you don't want to >move the IPv6 address from cell0 t= o wlan0 all you need to do is send proxy NAs for your own address (note - t= his *is different* from ND proxy as defined in RFC 4389).

=A0<= /p>

Thanks for the details in= your other email.=A0 The UE will still need to proxy the RA from the servi= ce provider to the wlan0 segment of the UE.


No, the UE needs t= o *send* an RA to its clients. It doesn't have to proxy the one that co= mes from upstream.

=A0

=A0 Further an NS arrives at cell0 from the service provider.=A0=A0 The UE will also have to= proxy this NS.=A0 Thus there is no getting around the ND Proxy.=A0<= /p>


The network sho= uld not send NS packets to the UE. The 3GPP specs are very clear that the h= andset is allowed to pick any IID on the link that it wants. The only sane = way to do this without blowing up state in the network is to route the whol= e /64 to the handset.
--e89a8f5028be23571904c83f5057-- From lorenzo@google.com Mon Aug 27 06:32:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1504A21F8661 for ; Mon, 27 Aug 2012 06:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8mrm5sgn9w5 for ; Mon, 27 Aug 2012 06:32:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC921F865B for ; Mon, 27 Aug 2012 06:32:22 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9258939obb.31 for ; Mon, 27 Aug 2012 06:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wrT2xDvgU8TxLe5DBdbCdmenh9Sr3oUYsoTHGDeHOJE=; b=UvaTxYAwzKQy/u7He9lB8Iz0PgW3WZzMdKoJBvogiWhY0wfItKL3tSa0I6QOeeDnXm Bzg1CVLf/lryESn23h+SCDs1snUNkk2Zo2UI3nOVLMfX/u+5zjU2OeVEAXK8dN1tZOQr emtSI6OCoaRkcudAW+IkAANJ8Lol0dXqN/BXeYTODugXkvIflLS396uYx1xmkjTgju5U ANXisY3r/G683kFLFrxGImeLYCewscRQzDMAeYIHgQxdDaiVQdw7Mczk1oTdV170R086 Yy2GqhzZBu6QnjbbgakCz0jvaJP4XMiAh7AfHI99u6AgHG/kdLuqdcc1TbK5zbswaYyz q/Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wrT2xDvgU8TxLe5DBdbCdmenh9Sr3oUYsoTHGDeHOJE=; b=N8s7NvS/oKhYav8HkgaoLx7YGVa5a2GFA6CzXwfsZ2KpxL7qEghOVzgdxtght8fruS 7iZRc6GemTvjGJnc3FXe9yN0Z7DvVEvYVP/PkRzy+WgGVNjYMU8IVDVY6KtxyKvnqVak AvZ9s1z+eafcOGaPITqY1EbVm7tC2xRcYHgbu0AcULpyEgFiLPzdp2FO1ZgQ20y3Skk0 2Vqu9zWvTUPh9Q+GVA0lyJdx7IjX0SdMT/FF9ERWBOkFdwc+snE08BO/LP1R234P6Ja0 VaLF0c66a6DOYB/alToNHyE31AcoH2rN4xDRomUqOS3A3x4FWD0wWl4hRsNkjbN0jLGU SNJg== Received: by 10.60.170.47 with SMTP id aj15mr6701264oec.29.1346074339714; Mon, 27 Aug 2012 06:32:19 -0700 (PDT) Received: by 10.60.170.47 with SMTP id aj15mr6701250oec.29.1346074339614; Mon, 27 Aug 2012 06:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.65 with HTTP; Mon, 27 Aug 2012 06:31:57 -0700 (PDT) In-Reply-To: <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> From: Lorenzo Colitti Date: Mon, 27 Aug 2012 22:31:57 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=bcaec54c5228daa15a04c83f5a6d X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCHiDl8XnVxbgEO1HKic8zh2mebcx4uy+P46QAO7BWGCCvVZZ35/Sy0pSpzcE3i9hoOLVIUVRzthOLRKeVGz0QP4TfYXCT2m+xtki1zVdIfHH6iyPbUjEAyOEww3v2nhbsFM5KGOiQ0nsnUoGTpLPiLWPPWS+SDSh5CTgc4FfBDn7DD8+M2ti777omr4qMoU47787E Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:32:23 -0000 --bcaec54c5228daa15a04c83f5a6d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith wrote: > I think the above is a good idea. Perhaps rather than moving the address > from the cell0 to wlan0 interface, the cell0 interface could be permanently > unnumbered, and loopback or similar virtual interface is assigned an > address from within the /64, and is a member of a bridge. The wlan0 > interface is added or removed from the bridge as tethering is enabled and > disabled. You don't need to move it. You can assign it to both interfaces if you want (at least, you can do that on Linux). --bcaec54c5228daa15a04c83f5a6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith = <markzzzsmith@yahoo.com.au> wrote:
I think the above is a good idea. Perhaps rather than moving the address fr= om the cell0 to wlan0 interface, the cell0 interface could be permanently u= nnumbered, and loopback or similar virtual interface is assigned an address= from within the /64, and is a member of a bridge. The wlan0 interface is a= dded or removed from the bridge as tethering is enabled and disabled.

You don't need to move it. You can assign it to bot= h interfaces if you want (at least, you can do that on Linux). =A0
--bcaec54c5228daa15a04c83f5a6d-- From jouni.nospam@gmail.com Mon Aug 27 06:40:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02A21F84A1 for ; Mon, 27 Aug 2012 06:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL3Xut2E90d5 for ; Mon, 27 Aug 2012 06:40:37 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A979421F8667 for ; Mon, 27 Aug 2012 06:40:36 -0700 (PDT) Received: by eaai11 with SMTP id i11so1198557eaa.31 for ; Mon, 27 Aug 2012 06:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PSGxG9aAHIaIUWZIZ4N2BE6ZZz9vLDxhxltCofiMPDE=; b=J4ZyPzNlltH3W9Ta3BjX2uGhLlMKHCbbp/RXcCIe1HBrpdXSYvT9oWxVdEZPXeS0uk HiW7+2uN1KRSGoIz1ZzwJrAs/HirNXsDXCGeHrQNpFdbbI5t4N4FK6Yt4AK3W+qw3kJn Mr8I6Npqv/+qkO7nJYwCf7f0VanC7kHIdAH9o06HBn34bvK/T0NAZAm1jVlOJgcJVHAL DKUkkOrsVhdAJyONXvyuUX2c635H89eqUFhw+mqNyFDTvqHjm4VGk7dk1kkLslTaJVn5 QAaVHqydVrqzldIsfcFSR1aOOvrgocGt3AUKcl1HHnzsxv6zDcd8inkNYY/YEGPKuYJ1 eXUg== Received: by 10.14.198.129 with SMTP id v1mr17308355een.42.1346074835668; Mon, 27 Aug 2012 06:40:35 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id h42sm52547571eem.5.2012.08.27.06.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 06:40:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC681D92C44@SRVHKE02.rdm.cz> Date: Mon, 27 Aug 2012 16:40:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC681D92C44@SRVHKE02.rdm.cz> To: =?windows-1252?Q?V=EDzdal_Ale=9A?= , "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:40:37 -0000 On Aug 27, 2012, at 3:55 PM, V=EDzdal Ale=9A wrote: > =20 > The UE might need to proxy the RS from the LAN to the 3GPP link as the = 3GPP specs are proposing tuning the RA interval to ~4hrs after few = initial messages. Or the UE would need to be sending the RA on behalf of = the SP. Speaking about the 3GPP GGSN/PDN-GW > I wonder if the GGSN/PDN-GW needs to do NS/NA as the 3GPP link is a = p2p link, so the GGSN/PDN-GW will send anything that belongs to /64 down = to the UE. (but I might need to think more about it) I have never seen a NS coming from GGSN/PGW, though I cannot speak for = all possible boxes out there. Anyway, since 3GPP has no link-layer addresses and generally there is no need for DAD, the only good reason for NS/NA = would be NUD. 3GPP specs are rather clear that the GGSN/PGW (or the rest of = the system) does not care about the IID for GUAs, thus the GGSN/PGW just = pumps always the whole /64 to the UE without any further ND procedures.. at = least the implementations I know of. - Jouni > =20 > Ales From jrmitche@puck.nether.net Mon Aug 27 06:28:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3489121F863C; Mon, 27 Aug 2012 06:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENsgQvUEdg8q; Mon, 27 Aug 2012 06:28:19 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8B53221F861F; Mon, 27 Aug 2012 06:28:19 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q7RDSJCZ022696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 09:28:19 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q7RDSIhg022693; Mon, 27 Aug 2012 09:28:18 -0400 Date: Mon, 27 Aug 2012 09:28:18 -0400 From: Jon Mitchell To: Randy Bush Message-ID: <20120827132818.GA17806@puck.nether.net> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 27 Aug 2012 09:28:19 -0400 (EDT) X-Mailman-Approved-At: Mon, 27 Aug 2012 06:42:21 -0700 Cc: idr@ietf.org, v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:28:20 -0000 On Fri, Aug 24, 2012 at 05:30:53PM +0700, Randy Bush wrote: > for your amusement, today in the routing worshop in phom penh, the > lecture includes rfc 2770 and using only one asn for a large number > of customers multi-homed to my network. aside from the benefits i > remembered, i was reminded that it even makes peer groups sexier. Randy - Sure, RFC2270 seems to be one reasonable solution for the use case of an ISP providing ASNs to single homed customers that do not require route connectivity to each other except via default, and yes, I'm aware of it and seen it deployed at multiple places I've worked. Of course, the unsaid thing in this draft is that using a seperate (private) ASN per customer site was not viable due to limited private use ASN space (which ISP in 1998 when this was published was not anticipating endless growth!). Although this would require one more line in your configs per peer (but in modern BGP implementations not necessarily provide better update generation which can occur based on same policy applied rather than peer-groups), but may have some operational/troubleshooting benefits. That said, let's assume that you are correct that the benefits outweigh the cons for using a dedicated ASN for this scenario in every operators mind. In other situations, I've seen a similiar approach implemented with seperate private ASNs to get rid of the implications of section 3.1, not for Internet table routes, but for routes to be leaked that are internal to the larger network. What are "customers of an ISP" in this RFC may be seperate engineering groups who run regions, DCs, sites, or sub-organizations... in a large organization. In these cases, using seperate (typically private) ASN's allows arbitrary connections between sites, the use of multiple backbone options (all from internal networks again which may or may not utilize a public ASN, not Internet backbones), and the entire organizations routes to be able to be received from all sites (which is useful when default lies in another direction than where you want to send traffic). I believe using multiple private ASNs in these scenarios is less a hack than trying to achieve the same with disabling loop detection, arbitrarily mandating no connectivity between these sub(orgs/sites) and/or requiring them to merge BGP everytime they bring up a backend connection. Depending on the function of said network, there may or may not be an Internet connectivity requirement for any of these networks at all. I personally don't see the use of private ASNs in these cases as an end run around the RIR's, as Internet connectivity is not a primary function of these ASNs and if they do have to send some routes to the Internet (which is not the case for every network) then these would likely come from a public "boundary" ASN between them and other ISPs, that provides the private AS stripping function. Now we've covered a couple of use cases, but my overall position is that private use ASNs are used in many situations with various routing requirements, likely a number of which we will not have properly identified even if we continue to go back and forth on every current and possible future use case of BGP in networks. I personally don't feel the need to debate whether or not all these use cases are valid, as I think that is orthogonal to whether having a large range is useful. After all, this is not a draft about keeping or getting rid of private ASNs. Jon From shemant@cisco.com Mon Aug 27 06:59:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA98421F846C for ; Mon, 27 Aug 2012 06:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdoKfLSRUJL3 for ; Mon, 27 Aug 2012 06:59:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D45F21F8534 for ; Mon, 27 Aug 2012 06:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=832; q=dns/txt; s=iport; t=1346075948; x=1347285548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JdQLCWIcati/JzpgP77BSU9vdr1/0StKH39L84W1i28=; b=AQrjLUKNhHYzfQ8pIizkfRpyrKJ6+/LtPBQ+OmBYcIblFPRkYvm0QutY auD3fw15ccHItJn3L+0NqQO8PJ1Qor83GXhWSFP05te1Fo41EHE88m2hg S4U/1GbCvdVIE4K4CNm/ea80ihYYgJ9NgZ4aPhP1zA6FMVmap4oD9Mues o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAGB8O1CtJXG//2dsb2JhbABFhTy1OoEHgiABAQEEEgFmEAIBCBEEAQELHQcyFAkIAgQOBQgah2uaM595iwiGMWADiBqbaYFngmM X-IronPort-AV: E=Sophos;i="4.80,320,1344211200"; d="scan'208";a="115404927" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 27 Aug 2012 13:59:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7RDx7jH018034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 13:59:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 08:59:07 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtryqAgAAPgwCAAALRgP//0K+wgABplgD//7AxUA== Date: Mon, 27 Aug 2012 13:59:06 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890783C6@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006 x-tm-as-result: No--28.129900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:59:08 -0000 Lorenzo, From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Monday, August 27, 2012 9:29 AM To: Hemant Singh (shemant) Cc: Mark ZZZ Smith; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >No, the UE needs to *send* an RA to its clients. It doesn't have to proxy = the one that comes from upstream. =A0*send* totally involves an RA proxy operation. Here is why. The UE ha= s received an RA on cell0 from the SP. This RA causes the UE to *send* an= d RA on the wlan0 link. The RA issued on the wlan0 link has to use a diffe= rent link-layer header and copy all the SP RA parameters such a Router Life= time to transmit the RA on the wlan0. Using a different link-layer header= on an ND message is the guts of any ND Proxy operation.=20 Hemant From shemant@cisco.com Mon Aug 27 07:00:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB7521F868A for ; Mon, 27 Aug 2012 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPD8KmvIwuLG for ; Mon, 27 Aug 2012 07:00:49 -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 0160A21F8600 for ; Mon, 27 Aug 2012 07:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1546; q=dns/txt; s=iport; t=1346076049; x=1347285649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eRO2iaKBsbjxgU1/qRG7MKebfv1fdjjNDkrf+KQzpeM=; b=K/Hp4aQvZ6cIY4WGL3ETxKxiw0hJg0UxX0vIel7OmYbFU3HC3Ecomd1+ LKD8HmD+RpyzAEsLAr+sck4Bv+qfHAZLcnqG8GQuZFSdoBeN8ZNJyGqZp 4l0KgxS6S1GgjVmZeLoUhyTR/vjwtZg1x2J4fXjIKOsVyeNSk/cwf9h8e k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABt8O1CtJXHA/2dsb2JhbABFunaBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHIREUCQgCBA4FCBqHXAMMmjOWHg2JToolY4YxYAOUAoxhgyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,320,1344211200"; d="scan'208";a="115596806" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2012 14:00:48 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7RE0mtD019436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 14:00:48 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 09:00:48 -0500 From: "Hemant Singh (shemant)" To: jouni korhonen Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtiH+AgAARL+A= Date: Mon, 27 Aug 2012 14:00:47 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> In-Reply-To: <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006 x-tm-as-result: No--35.626700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:00:49 -0000 Jouni & Cameron, -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, August 27, 2012 2:36 AM To: Hemant Singh (shemant) Cc: Victor Kuarsingh; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Your phone should then disable the proxy behavior according to 4.1.3.3 of = RFC4389 (the second last para). In 60 minutes (as per RFC 4389) my phone disables ND Proxy when the phone n= eeds ND Proxy with a /64 assigned to the phone. My phone tethering support= is not available any more. Now I have an attack vector to shutdown the ND= Proxy of the phone and disable the tethering support of the phone.=20 >Anyway, the topology described here is out of scope of RFC4389 as far as I= understand. Also, with the >current mobiles, I don't think being a STA and AP at the same time is poss= ible, which seems to a >prerequisite for the above topology. Each of the two phones in my example, by itself, complies to the xlat docum= ent and also the RFC 4389. It is perfectly reasonable to have both phones = enabled at the same time but powered on at different times. Then any mis-c= onfigured tethered network can disrupt network services of one of the phone= s or both. We should caution use of the ND Proxy. Here is some proposed t= ext to add to section 8.3.2 of the xlat document "Note any loop in the tethered network may cause the ND Proxy on the UE to = be disabled."=20 Thanks and regards, Hemant =20 From cb.list6@gmail.com Mon Aug 27 07:04:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DF321F861F for ; Mon, 27 Aug 2012 07:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDQiZhRtOTh5 for ; Mon, 27 Aug 2012 07:04:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E032521F852E for ; Mon, 27 Aug 2012 07:04:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so2712151lah.31 for ; Mon, 27 Aug 2012 07:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V4Ain12K9Ab69523jLsXlw3czPNhgem7SfjLNeFj3Ag=; b=AZkM/U9rJopAJBikbj+UTZRoiICdbzsePt0zRIDwA0NgWFlvCjAwfEl8ygCh4LXTtP mcdMlHS2SbrrtunPBxNSI0LT2BQaIIliYFmz6XVe7VTrTVBS3hocl4jkhT4ffH5L4tfL hjSoyKkFYEjXkEEc4BVy3Xw1Wo1bpQQ8NyLk4DDcl3E1PzDSjiuj2VlTqUSNq68zWwZ1 k/raMK4UL8CtpsCmQBsTdOockeOmls3wMpvBZANIQ5FPrbt3dYZzXFURLM6MWq2Krrf5 4BIMV8z7O1ZjDHbHQ4KwLwa6GtXyC5w4qfFitQO4mR84XyKi47whAPIdg2ZQU41KwIQi htAQ== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr15073224lab.11.1346076272398; Mon, 27 Aug 2012 07:04:32 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 27 Aug 2012 07:04:31 -0700 (PDT) In-Reply-To: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Date: Mon, 27 Aug 2012 07:04:31 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:04:35 -0000 On Mon, Aug 27, 2012 at 1:54 AM, Lorenzo Colitti wrote: > Ok, so how about the following? Comments welcome. > > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in the > glorious future. Your carrier has a release 10 network, and is providing you > with tethering (either because they're a just that nice, or because you paid > extra for the privilege). The CLAT simply behaves like an RFC 6204 router. > Done. > > Now for the rest of us. Since we're still here, it means we only have a > single /64. If you don't want to implement tethering, do nothing. If you do > want to implement tethering, proceed as follows (cell0 is the upstream > interface, wlan0 is the downstream): > > 1. Enable tethering only when cell0 is a point-to-point interface (e.g., 3G, > LTE, ...). > 2. When enabling tethering, take the IPv6 address of cell0 (which you were > already using, and need to continue to use because you have open connections > to it), and assign it to wlan0 instead of cell0 > 3. Treat cell0 as unnumbered; when sending out packets, use the IP address > assigned to wlan0. > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like a > standard IPv6 router (decrement TTL, etc.) > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like a > standard IPv6 multicast router (But I don't know anything about multicast, > so I'll shut up now.) > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, they > will fail DAD. > > So far so good. There is no bridging, and since the upstream is a > point-to-point interface, there are no loops. Note that this is *not* RFC > 4389. But it does not need to be. > > We haven't talked about CLAT yet. There are two cases here: > > 1. The CLAT implementation can use the same IPv6 address as the phone. In > this case, no problem. > 2. The CLAT implementation cannot use the same IPv6 address as the phone. In > this case, either: > a) the CLAT does DAD for that other address as well, or: > b) picks an address that "shouldn't collide" (remi's reserved IID) > > It's as simple as that. So, as far as I can see, the only issue left to > discuss is "do we do 2a or 2b"? > This is all fine, but this is not a draft about how to make tethering work on a mobile network. One of the assumption is that tethering does work and that ND Proxy or similar mechanisms for /64 WAN interface sharing exists (they do), and consequently how does the CLAT work in this environment? That said, i like what you wrote, but it seems like implementation details that are not needed for this draft. Perhaps the draft should not just refer to ND Proxy but "ND Proxy and other /64 sharing approaches" CB > On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) > wrote: >> >> Victor (and also replying to Rajiv in one email), >> >> -----Original Message----- >> From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] >> Sent: Sunday, August 26, 2012 8:04 PM >> To: Hemant Singh (shemant) >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] single /64, ND Proxy, and >> draft-ietf-v6ops-464xlat-07.txt >> >> >I cannot speak for every operator, but for some of us trying to deploy >> >IPv6, if I cannot do it with tethering, I cannot deploy it (part of the >> >service). Not supporting tethering would inhibit my ability to deploy (in >> >my case - perhaps for others). >> >> Got it - you need tethering immediately. Ok, back to the ND Proxy issues >> then. >> >> My wife turns on her cell phone and this CLAT phone uses the reserved IID >> and thus does not issue any RA with the ND Proxy P-bit. A tethered client >> in a home IPv6 router uses the RA to get a SLAAC IPv6 address. Behind the >> IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone >> that supports only an ND Proxy and a single /64. Before my phone is able to >> send an RA with the P-bit set, the bridged behind home router looped my >> wife's phone RA to my phone and my phone loops the RA back to the SP. >> Additionally, what does my tethered client do if the client receives two >> different RA's as described above and specifically how is proxying of NA's >> done? Is the NA sent to the ND Proxy phone or the reserved IID phone when >> the tethered node has only one interface to receive an NS on? >> >> Soon as one says tethering, testing for what is working code is very broad >> because there could be whole network behind one tethered client. This is >> the same point Ray Hunter is making and it would be good to reply to his >> email at the URL below. >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html >> >> Regards, >> >> Hemant >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Mon Aug 27 08:03:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8458221F865B for ; Mon, 27 Aug 2012 08:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TKMI7HY9vIi for ; Mon, 27 Aug 2012 08:03:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 300A421F8470 for ; Mon, 27 Aug 2012 08:03:08 -0700 (PDT) Received: by iabz21 with SMTP id z21so9468410iab.31 for ; Mon, 27 Aug 2012 08:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MXfaVqJ9GiWXULZl5BVnpDjc/PAMCDTiYVKi2qVzRH4=; b=nJCufhZk/raxnwz+HHUBWrE6I+vvv0AGzNDFPs/LxOm401w9+zZrCSbgC9KLiwaQAf NjeobzLagPn3Y/FrQPWtjDYH7CxWfmM7ahxyhYlMrWDJpYrNqVD81qPOIJPlI28xKmPh LX0gOgLex7cuDroT8Ucj5LqFyvoAHHWctVrdsvHGtVmlKudVxrttujeMrb2m8oW3R6Eq DYa845dfaa0xU+IQe6osFd/kDjkeyfIAXHI9574eHR9Blsx7x/MJZiRnRyXcikrGpqsk bA99Rfz03SJFfm5oTJ643QuN/DZlaS4mtEsPcNJfvwneIdLDwGUb1i/uMbEuxqQ8mZdZ yAEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=MXfaVqJ9GiWXULZl5BVnpDjc/PAMCDTiYVKi2qVzRH4=; b=F0e5Z9zBddKEyhfeJd5slrizAtp0eQoiQ/brL+VTCBgw9DNC7cRVePbdZETUIwxea9 ISNi1bmfL7mex/zBckkbzybuDoTRo6rP0ogLdH8DL9JN+dr19d14nu6+XrWHy5m4ID02 IzxFR5RNXqPMTeVZ+O4pG7PKmCp3lm/w6u4VnW6nLuBVlAiPyl19ZbL5IvdMba39uy2I JSu0k0Jv978xCng5XO8IdTm85oFTGj4bGHg8QkMRBgdROSz3JHTdzC8TflTcNMeclE4s 7nWetLDSPl2h1DPJesH0oGUmrpERpkOr2hgPJNt1m8NYVswbEo5iR4Kxt5CUiAT8tZj+ 5xFA== Received: by 10.50.57.168 with SMTP id j8mr10458423igq.16.1346079787347; Mon, 27 Aug 2012 08:03:07 -0700 (PDT) Received: by 10.50.57.168 with SMTP id j8mr10458365igq.16.1346079786863; Mon, 27 Aug 2012 08:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Mon, 27 Aug 2012 08:02:45 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890783C6@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B890783C6@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Tue, 28 Aug 2012 00:02:45 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=14dae9340ee7890d4104c8409f60 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk3MdO9qu52hTEVVLId9brKCn3Arfsi3yblHE/g/rW2TQRGt66jMiN/mKnQ/43JfNN9XONWJbfszmvXP2A6MlEh3r7nlF3ryiw51uaJAJiSGhN+ZygN+BHShorvB0WetiFVuuwHOD97G8QY5syo4wXXTbZd+SUQzCuyN/t87kekKhD3qk3TPcJobWaQ+LsCNsC0Cc8l Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:03:13 -0000 --14dae9340ee7890d4104c8409f60 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 10:59 PM, Hemant Singh (shemant) wrote: > >No, the UE needs to *send* an RA to its clients. It doesn't have to proxy > the one that comes from upstream. > > *send* totally involves an RA proxy operation. Here is why. The UE has > received an RA on cell0 from the SP. This RA causes the UE to *send* and > RA on the wlan0 link. The RA issued on the wlan0 link has to use a > different link-layer header and copy all the SP RA parameters such a Router > Lifetime to transmit the RA on the wlan0. Using a different link-layer > header on an ND message is the guts of any ND Proxy operation. > Nope. It doesn't need to preserve the parameters. In fact, things really wouldn't work well if it did. For example, the CLAT will almost certainly want to change the interval between RAs (the default in the 3GPP spec is one RA every 4.5 hours). It will probably want to include a the link-layer address option. It might want to set the M bit if it has a DHCPv6 server. And so on. --14dae9340ee7890d4104c8409f60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2012 at 10:59 PM, Hemant Singh (= shemant) <shemant@cisco.com> wrote:
>No, the UE needs to *send* an RA to its clients. It d= oesn't have to proxy the one that comes from upstream.

=A0*send* totally involves an RA proxy operation. =A0 Here is why. = =A0The UE has received an RA on cell0 from the SP. =A0 This RA causes the U= E to *send* and RA on the wlan0 link. =A0The RA issued on the wlan0 link ha= s to use a different link-layer header and copy all the SP RA parameters su= ch a Router Lifetime to transmit the RA on the wlan0. =A0 Using a different= link-layer header on an ND message is the guts of any ND Proxy operation.<= br>

Nope. It doesn't need to preserve the = parameters.=A0In fact,=A0things really wouldn't work well if it did.=A0= For example, the CLAT will almost certainly want to change the interval bet= ween RAs (the default in the 3GPP spec is one RA every 4.5 hours). It will= =A0probably want to include a the link-layer address option. It might want = to set the M bit if it has a DHCPv6 server. And so on.
--14dae9340ee7890d4104c8409f60-- From lorenzo@google.com Mon Aug 27 08:05:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93121F86C8 for ; Mon, 27 Aug 2012 08:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KruNK8RRWkYB for ; Mon, 27 Aug 2012 08:05:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA61F21F86BA for ; Mon, 27 Aug 2012 08:05:05 -0700 (PDT) Received: by iabz21 with SMTP id z21so9473237iab.31 for ; Mon, 27 Aug 2012 08:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fjY+X4n+WKpYsT0wrG+U+LBHZRdhxOS9v/Pkl3WqATc=; b=BwQg6ahSfTf3XVDvP4iZkV5iNfKxHrMRoFCf74+i7C0jTl7h73ameU5c6x1biHXG4E 7QVV7NLE9UHozbUikNCNAQTWNSpNMSbDpZt97m7T/B/NNGtNNTaukbJrYdYynCS4Cao2 rSE3nI6SJAWDPQMBekr9bq3ndHbtJRUdYq/UwxFWaFUCkDew9GHUvGA2xLWRrRFJS4lE RdDKvQ5yFI8X7ARBmEYSSnXjk6ccaZhUTUd1BO9lkVoeula3SJ5WWNR3CsN0TQsPR9BW WKr8RToleSSl2wmYhk8NPNeiPnqqThhM3WLo9jjffWDGU1jNI8HP6v7a44X5WgjNdoZv 84dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fjY+X4n+WKpYsT0wrG+U+LBHZRdhxOS9v/Pkl3WqATc=; b=bmNSJLm7H6MNoUt0NwlfDG97PnSW/CS6r+165ZynvgBgLPwWDhaQaQP5ZZoMY0gp5/ OaO//jQKEJSIOZkQnXKfcXDULdQbC5VrtILO7UJRDw2CU5+Ew0J/IEki7jn8XMvYvI79 CKBZTqd2FgTSB5dx1ZdFyI8AEV+mKxrSsc3I+jEGEf0xIv3D4QUWvFvWYTGgQV0lpar9 k3BeVac35/LAdl644yOKepbr44isti3r5yQpK6B2BvACU4GOh6O0BGg8ti/KLUo/1V67 4JhnruL3m2771HUkJRejVIT912yKlccxmzz+ZgG8TVMh1TaeI0qVMAUjF4HgBaXdsZyE 9JvA== Received: by 10.50.12.168 with SMTP id z8mr10487334igb.74.1346079905324; Mon, 27 Aug 2012 08:05:05 -0700 (PDT) Received: by 10.50.12.168 with SMTP id z8mr10487317igb.74.1346079905114; Mon, 27 Aug 2012 08:05:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Mon, 27 Aug 2012 08:04:44 -0700 (PDT) In-Reply-To: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Tue, 28 Aug 2012 00:04:44 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=14dae93409b3956b5b04c840a6b9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk7aPqaJGliw6kJFqD0wos7Pp6mZ7+1bkb3u1HycM082VjDN0F74XQmC8DvAAUxFsT9EKCIdOLamUWLQyyhZRE7638JjzPRefZj1qRUwdsO6mDJD761nR8P/q013mL5Hj955wHdqKia8DqxJ4pyvynHhSnhXEAzXZqL9YGryHpuVwEyu2pWmnOhCPCFg3Y8xW4jJNB0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:05:06 -0000 --14dae93409b3956b5b04c840a6b9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 11:04 PM, Cameron Byrne wrote: > Perhaps the draft should not just refer to ND Proxy but "ND Proxy and > other /64 sharing approaches" > ND proxy a) is experimental b) doesn't solve the problem completely and c) has issues with loops and the like. If the upstream is a p2p interface, you can do tethering in other ways, like I described above. Does ND proxy need to be specified at all in this doc? Can we get away with just removing it? --14dae93409b3956b5b04c840a6b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2012 at 11:04 PM, Cameron Byrne = <cb.list6@gmail.com> wrote:
Perhaps the draft should not just r= efer to ND Proxy but "ND Proxy and
other /64 sharing approaches"

ND p= roxy a) is experimental b) doesn't solve the problem completely and c) = has issues with loops and the like. If the upstream is a p2p interface, you= can do tethering in other ways, like I described above.

Does ND proxy need to be specified at all in this doc? = Can we get away with just removing it?
--14dae93409b3956b5b04c840a6b9-- From cb.list6@gmail.com Mon Aug 27 08:16:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BE221F8665 for ; Mon, 27 Aug 2012 08:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h9-YGffUkjH for ; Mon, 27 Aug 2012 08:16:48 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C906D21F86B6 for ; Mon, 27 Aug 2012 08:16:47 -0700 (PDT) Received: by lbky2 with SMTP id y2so1959560lbk.31 for ; Mon, 27 Aug 2012 08:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=icz9syFrHka9o8mt0JJXp2ZmerHk15daFPFaWh6+kfU=; b=r2tFwvb+z1jI9Xif9xxW2gtvNJK+01JBkZaey7+4CCK2fP3OB/d6F0Pz1oN4heJyzk lZUBn8Y0+BLDu7EHUMOJAWoNR4kr4dmR8CGgCGVBIIIjStZVb23jxTtcMK5lUXWC60eU 7MawQ7X1vFvdLE7VXJcveJBaJhaM0jTlB4Aiv2FnYceq25vFnxGKKpuzmRxJuCT8aRBN uweLA2o38wExD1I6n6TiYcSUTlhqrErFCU0OvrqWGic2cpIyaK2H3QGbnRvQyOUvZh/t ZBDJsCObjOdl58LBEyZKSlFuxA29kItMEMRjZE3eVgjU4OxM3EG6WXC3L6A1gJ+xCR/u 1o8Q== MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr6727150lbz.6.1346080606731; Mon, 27 Aug 2012 08:16:46 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 27 Aug 2012 08:16:46 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 27 Aug 2012 08:16:46 -0700 (PDT) In-Reply-To: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> Date: Mon, 27 Aug 2012 08:16:46 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d0401faed673d6a04c840d090 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:16:49 -0000 --f46d0401faed673d6a04c840d090 Content-Type: text/plain; charset=ISO-8859-1 On Aug 27, 2012 8:05 AM, "Lorenzo Colitti" wrote: > > On Mon, Aug 27, 2012 at 11:04 PM, Cameron Byrne wrote: >> >> Perhaps the draft should not just refer to ND Proxy but "ND Proxy and >> other /64 sharing approaches" > > > ND proxy a) is experimental b) doesn't solve the problem completely and c) has issues with loops and the like. If the upstream is a p2p interface, you can do tethering in other ways, like I described above. > > Does ND proxy need to be specified at all in this doc? Can we get away with just removing it? I thinking about it, i think we can leave out ND Proxy if we can describe generically solutions that extend the /64 from WAN to LAN and leave the details to the implementers. Saying dhcp-pd only is not acceptable. CB --f46d0401faed673d6a04c840d090 Content-Type: text/html; charset=ISO-8859-1


On Aug 27, 2012 8:05 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Mon, Aug 27, 2012 at 11:04 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Perhaps the draft should not just refer to ND Proxy but "ND Proxy and
>> other /64 sharing approaches"
>
>
> ND proxy a) is experimental b) doesn't solve the problem completely and c) has issues with loops and the like. If the upstream is a p2p interface, you can do tethering in other ways, like I described above.
>
> Does ND proxy need to be specified at all in this doc? Can we get away with just removing it?

I thinking about it, i think we can leave out ND Proxy if we can describe generically solutions that extend the /64 from WAN to LAN and leave the details to the implementers.

Saying dhcp-pd only is not acceptable.

CB

--f46d0401faed673d6a04c840d090-- From shemant@cisco.com Mon Aug 27 08:17:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A521F86B6 for ; Mon, 27 Aug 2012 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9j3MxErKb-h for ; Mon, 27 Aug 2012 08:17:18 -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 1A83921F86BA for ; Mon, 27 Aug 2012 08:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2655; q=dns/txt; s=iport; t=1346080638; x=1347290238; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t3obbFWkjrSXU3Vdiku3rXvTeaTyLbx/+HspaaQR8V8=; b=KTjASHgy+jw4aDN99oEPJBHEH/6I5slE1JdMDTGf9Z5Mld3VuNCt6Ylw zi2TGIv6tJefSW44bllqsoO0THaSvnG/5eTC0LcqR3ac+rzdTRG/cnUON O5oSj0hgQO/fFv4VGW0HhNwYyJf0FLYzkPBBlITYDowQ2y1NaI5J8lbzT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKuOO1CtJV2Y/2dsb2JhbABFuneBB4IgAQEBBBIBJz8MBAIBCA4DBAEBCxQJByERFAkIAgQBDQUIGodcAwyaNZYqDYlOiiVjhjFgA5QCjGGDIIFngmM X-IronPort-AV: E=Sophos;i="4.80,321,1344211200"; d="scan'208";a="115624460" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2012 15:17:17 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7RFHHc9028188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 15:17:17 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 10:17:17 -0500 From: "Hemant Singh (shemant)" To: Cameron Byrne , Lorenzo Colitti Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWg Date: Mon, 27 Aug 2012 15:17:16 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006 x-tm-as-result: No--35.324100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:17:19 -0000 Cameron, -----Original Message----- From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Monday, August 27, 2012 10:05 AM To: Lorenzo Colitti Cc: Hemant Singh (shemant); v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >This is all fine, but this is not a draft about how to make tethering work= on a mobile network. Great. Also note, most details Lorenzo has provided are already covered in= RFC 6204 or RFC 6204bis. That is another reason not to cover them in the = xlat document. RFC6204 for the DSL Broadband Forum supports a unnumbered WA= N including any Loopback interface to source packets out the WAN of the CPE= router. =20 >Perhaps the draft should not just refer to ND Proxy but "ND Proxy and >other /64 sharing approaches" Right - we should re-work section 8.3.2 of the xlat document. This is a xl= at document that folks have expressed a need to get out fast for an RFC. T= hus we should not de-focus the document process with how the CLAT gets a /6= 4 prefix to source packets used by the XLATE protocol. During early revisi= ons of RFC 6404 when the I-D included the 3GPP single /64 use case and ND P= roxy, we were told by a v6ops Chair and other folks in the IESG that a v6op= s document cannot reference an Experimental RFC. You will, likely, face th= e same issue in the IESG with the xlat document if xlat continues to refere= nce the ND Proxy RFC.=20 Additionally, if the ND Proxy Experimental RFC is taken to re-work in 6man,= at least one year will transpire before a new RFC that fixes all cases cau= sing loops with RFC 4389. Protocol work tends to step gingerly. The other= issue with RFC 4389 is that the RFC also needs to support SEND (RFC 3971).= I don't think any complete fix to the ND Proxy RFC is less than two years= away. The other sharing approach covered in section 8.3.2 is a reserved IID which= is also taking longer to flush out text for and delaying the xlat document= . We could consider being silent on a reserved IID and also edit the IANA = Considerations section. One additional comment. Why does the document in several places including = section 8.3.2 include this text: [The CLAT MAY discover the Pref64::/n of the PLAT via some method such as T= R-069, DNS APL RR [RFC3123] or [I-D.ietf-behave-nat64-discovery-heuristic].= =20 First, please define what is "Pref64:/n" somewhere in the document. Is thi= s a global IPv6 subnet prefix and what does the PLAT use this prefix for? = Then why does the CLAT have a "MAY" need to discover this prefix? Thanks, Hemant From shemant@cisco.com Mon Aug 27 08:51:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88521F84CF for ; Mon, 27 Aug 2012 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onu5sCJ5D-09 for ; Mon, 27 Aug 2012 08:51:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CF40121F8528 for ; Mon, 27 Aug 2012 08:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2153; q=dns/txt; s=iport; t=1346082702; x=1347292302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XJogUcodfjAyfi+rEjE0FS6vxVWeX2GRYbCpn/H2Ou0=; b=Mz0hgET1ap/KXaLior//Z55E8VBE7vnoKGvnOT0V+o4zhCrrk55y070F Ytso84CEDcEmpqIKPkmdLvw5mJ3jZzcR3WkiVrYOxi5wY4EtGMUzBO1KS s0lavM1lh6DfSWaWfg5Hd7fkFJf6xERMfFr7UZYtXG2+3T88d4sF5mwji E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJaWO1CtJV2Z/2dsb2JhbABFuneBB4IgAQEBBBIBZhACAQgRBAEBCx0HMhQJCAIEDgUIGodrmjGgB4sIhjFgA4gam2mBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,321,1344211200"; d="scan'208";a="115683587" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 27 Aug 2012 15:51:41 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RFpfr5006594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 15:51:41 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 10:51:39 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtryqAgAAPgwCAAALRgP//0K+wgABplgD//7AxUIAAagOA//+xkYA= Date: Mon, 27 Aug 2012 15:51:38 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890784E6@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B890783C6@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006 x-tm-as-result: No--32.287500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:51:44 -0000 Lorenzo, From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Monday, August 27, 2012 11:03 AM To: Hemant Singh (shemant) Cc: Mark ZZZ Smith; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Nope. It doesn't need to preserve the parameters.=A0 Ok. The two basic operations of a ND Proxy are to (a) being able to sniff= all multicast packets (by default, an IPv6 node does not sniff all multica= st packets, and (b) write a new link-layer address in proxied messages. Bo= th operations are invoked on the RA received on the cell0 link before an RA= is issued on the wlan0 link. >In fact,=A0things really wouldn't work well if it did.=A0For example, the = CLAT will almost certainly want to change the interval between RAs (the def= ault in >the 3GPP spec is one RA every 4.5 hours). It will=A0probably want = to include a the link-layer address option. It might want to set the M bit = if it has a >DHCPv6 server. And so on. There is a third operation in the ND Proxy as specified in RFC 4389. The R= A is proxied as is to other interface(s) on creating a new link-layer for t= he packet. That is where you have a good catch in that the RA parameters c= hange from the SP RA to the RA issued on the wlan0 link. Thus if the xlat = document continues to reference RFC 4389, then the xlat document also has t= o address this caveat on the ND Proxy behavior. Also a v6ops document does= not specify any new protocol behavior. Now we have another reason to elid= e the RFC 4389 reference from the xlat document. =20 It also seems like the cellular requirements are being flushed out as we sp= eak. Thus the xlat document can get delayed further. Let's filter out any= new requirement that involve the ND Proxy or any prefix configuration on t= he UE. Such requirements do not affect the xlat directly.=20 The ND Proxy delayed my review of the xlat document. Outside of the ND Pro= xy, I may have minor comments which I will send out in a day or two. I am = on PTO for this whole week but replying to some emails.=20 Thanks all. Hemant From despres.remi@laposte.net Mon Aug 27 09:11:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE89121F847A for ; Mon, 27 Aug 2012 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGfzXH+pfrtw for ; Mon, 27 Aug 2012 09:11:28 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 23FEE21F8528 for ; Mon, 27 Aug 2012 09:11:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 4C116700039C; Mon, 27 Aug 2012 18:11:25 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 060E4700038C; Mon, 27 Aug 2012 18:11:24 +0200 (CEST) X-SFR-UUID: 20120827161125249.060E4700038C@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> Date: Mon, 27 Aug 2012 18:11:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:11:29 -0000 Le 2012-08-27 =E0 17:17, Hemant Singh (shemant) a =E9crit : > Cameron, >=20 > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 > Sent: Monday, August 27, 2012 10:05 AM > To: Lorenzo Colitti > Cc: Hemant Singh (shemant); v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 >> This is all fine, but this is not a draft about how to make tethering = work on a mobile network. >=20 > Great. Also note, most details Lorenzo has provided are already = covered in RFC 6204 or RFC 6204bis. That is another reason not to cover = them in the xlat document. RFC6204 for the DSL Broadband Forum supports = a unnumbered WAN including any Loopback interface to source packets out = the WAN of the CPE router. =20 >=20 >> Perhaps the draft should not just refer to ND Proxy but "ND Proxy and >> other /64 sharing approaches" >=20 > Right - we should re-work section 8.3.2 of the xlat document. This is = a xlat document that folks have expressed a need to get out fast for an = RFC. Thus we should not de-focus the document process with how the CLAT = gets a /64 prefix to source packets used by the XLATE protocol. During = early revisions of RFC 6404 when the I-D included the 3GPP single /64 = use case and ND Proxy, we were told by a v6ops Chair and other folks in = the IESG that a v6ops document cannot reference an Experimental RFC. = You will, likely, face the same issue in the IESG with the xlat document = if xlat continues to reference the ND Proxy RFC.=20 >=20 > Additionally, if the ND Proxy Experimental RFC is taken to re-work in = 6man, at least one year will transpire before a new RFC that fixes all = cases causing loops with RFC 4389. Protocol work tends to step = gingerly. The other issue with RFC 4389 is that the RFC also needs to = support SEND (RFC 3971). I don't think any complete fix to the ND Proxy = RFC is less than two years away. +1 to avoid ND-proxy reference in section 8.3.2. > The other sharing approach covered in section 8.3.2 is a reserved IID = which is also taking longer to flush out text for and delaying the xlat = document. Following the separate discussion on the reserved IID, there remains no = technical argument against it, especially with a MAY. OTOH, if an exclusive /64 routed to a CLAT node, it clearly avoids the = need for any specific provision against RFC4291-compliant hosts using = the /64 to collide with the CLAT IPv6 address. (Neither DAD complement = nor ND proxy is needed.) Deleting it would therefore be a step backward, justified only by = historical and undeserved FUD, against a feature already tested with = running code.=20 Regards, RD =20 > We could consider being silent on a reserved IID and also edit the = IANA Considerations section. >=20 > One additional comment. Why does the document in several places = including section 8.3.2 include this text: >=20 > [The CLAT MAY discover the Pref64::/n of the PLAT via some method such = as TR-069, DNS APL RR [RFC3123] or = [I-D.ietf-behave-nat64-discovery-heuristic]. =20 >=20 > First, please define what is "Pref64:/n" somewhere in the document. = Is this a global IPv6 subnet prefix and what does the PLAT use this = prefix for? Then why does the CLAT have a "MAY" need to discover this = prefix? >=20 > Thanks, >=20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Mon Aug 27 13:10:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4721F8532 for ; Mon, 27 Aug 2012 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zuJNo0rHtiK for ; Mon, 27 Aug 2012 13:10:48 -0700 (PDT) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with SMTP id EC1CC21F854E for ; Mon, 27 Aug 2012 13:10:47 -0700 (PDT) Received: from [98.139.212.150] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 20:10:47 -0000 Received: from [98.139.215.253] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 20:10:47 -0000 Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 20:10:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 996863.976.bm@omp1066.mail.bf1.yahoo.com Received: (qmail 28586 invoked by uid 60001); 27 Aug 2012 20:10:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1346098246; bh=CrTrju4iRfC4tVNiyPhlePAw89mU33ycwK2mTY4IHfY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qLmDxAlpw/K0qqew5rU+adUt6g5bpB6D8+VaEEzZNDNCH0+6voG+LiMxOV0KmPhGtfThptuWqpqyA726UEm6XdxzWAOurqAA30JOfyi+EJafXvd9myekCY6PzxPzNoB4q6E91IUNVnv8Dnz6mL2Z92Eh9aZsevQULt1Sr7wrLy4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RXCSI1OCx07XC50H0KTRrhPSyXJPdJQsFthrDnzLmAnquvF28svaPy1iX8w+0gACApMIUsCYHEeC0NI4uUOD9EYfL2KRQrqS/lTWJ5wWh2r+pH+0tuwFGf5sh99cUsQmrNWA8KOEmkXe5VXQ/rwrxIQa8PSPSMvN5QAvsjGzlkY=; X-YMail-OSG: Cj1XjaUVM1lPWVJb6kd7kKt9G_Q7mwEDqk9B3.bM_PyQaTd amTD7t8eLmd4byZyGnnxiw9pssimeEPjjmG.gDYyMh1Kd6jZJxFLgJrvH_nC nPyXtEL4dTA_94_pYDR5zHXmWmgj446UX3ghgMWmqAOLZ6BxJwtU623Jte9f YRzEDBtmIgmvCF3L9heSDub6Sab9Uzv9lqJLiPbI3dOQ_M4PK4lm4ikNJ8__ EkROKGvvDvWa8ZU2Bp_FnWsJ8Xk1ivmVKCDDTj4WImVtvLeVKtTEGjiCZ2SE GEecv2eIoQ_wV9A7daDah0WmXD4nfqEBhfJ7wVk.gFOoRHf5TU7urBtD3Ysc 0E_5bBdwKASwWwjMFgSsiudm45.MQNFTKpHPeK.f_qEzCgu7VtAGp4IRfk0r pfpgj6Wd1X3AHF.7oXNQ_nopBR2xboo_49BGj8juG4Hd1IIdMTGgcf6enPOw _DIKSLIgWSjhDRItFCeB_KcO.Gzh8BsGKGMAmwixeau1Ih16JgyVgw1Jc3pp gxRGJ Received: from [150.101.221.237] by web32506.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 13:10:46 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> Message-ID: <1346098246.60432.YahooMailNeo@web32506.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 13:10:46 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:10:48 -0000 Hi,=0A=0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Mark ZZZ Smith =0A>Cc: He= mant Singh (shemant) ; "v6ops@ietf.org" = =0A>Sent: Monday, 27 August 2012 8:00 PM=0A>Subject: Re: [v6ops] single /6= 4, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt=0A> =0A>=0A>On Mon, Aug 27= , 2012 at 6:50 PM, Mark ZZZ Smith wrote:=0A>=0A= >>6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, th= ey will fail DAD.=0A>>=0A>>=0A>>I think the above is a good idea. Perhaps r= ather than moving the address from the cell0 to wlan0 interface, the cell0 = interface could be permanently unnumbered, and loopback or similar virtual = interface is assigned an address from within the /64, and is a member of a = bridge. The wlan0 interface is added or removed from the bridge as tetherin= g is enabled and disabled.=0A>=0A>=0A>One of the reasons I suggest we don't= do bridging is that bridges forward broadcasts and ND packets, and that ca= n cause various nastiness. I think routing is much simpler, and if you don'= t want to move the IPv6 address from cell0 to wlan0 all you need to do is s= end proxy NAs for your own address (note - this *is different* from ND prox= y as defined in RFC 4389).=0A>=0A>=0A>=0A=0A=0AActually, I wasn't suggestin= g bridging over routing, just instead using a bridge virtual interface to a= void moving the address to and from the unnumbered link traffic source inte= rface to the wlan0 interface e.g.=0A=0Auntethered:=0A=0A[root@opy mark]# br= ctl show=0Abridge namebridge idSTP enabledinterfaces=0Abr08000.000000000000= no=0A[root@opy mark]#=0A=0A=0A[root@opy mark]# ip addr show dev br0=0A13: b= r0: mtu 1500 qdisc noqueue state UNKNOWN= =A0=0A=A0 =A0 link/ether 22:56:fd:56:39:87 brd ff:ff:ff:ff:ff:ff=0A=A0 =A0 = inet6 2001:db8::3496/64 scope global dynamic=A0=0A=A0 =A0 =A0 =A0valid_lft = 7192sec preferred_lft 3592sec=0A=A0 =A0 inet6 fe80::2056:fdff:fe56:3987/64 = scope link=A0=0A=A0 =A0 =A0 =A0valid_lft forever preferred_lft forever=0A[r= oot@opy mark]#=A0=0A=0A=0Atethered:=0A=0A[root@opy mark]# brctl show=0Abrid= ge namebridge idSTP enabledinterfaces=0Abr08000.000000000000nowlan0=0A[root= @opy mark]#=0A=0A=0AIt may even be better to permanently leave wlan0 in the= bridge instance, and use the interface's administrative state to enable or= disable tethering.=0A=0A(perhaps a bit down in the detail for this thread,= however I think it does show that what you're proposing could be done toda= y with existing deployed mechanisms)=0A From shemant@cisco.com Mon Aug 27 14:41:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEBF21E803D for ; Mon, 27 Aug 2012 14:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16DalmiHOhGq for ; Mon, 27 Aug 2012 14:41:25 -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 44CC321E803F for ; Mon, 27 Aug 2012 14:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7909; q=dns/txt; s=iport; t=1346103685; x=1347313285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RA8FQlHUtYytltm9Rlb9PnpSQC+GPfv3nfsDHr73+q8=; b=dTUPhfPz0RzZ+NMLjawrxED9W72/4NyzN3fbSpyFdflQzUpUL6JiCyNV 0WA8HBCYOsuxwgDlg2I5imu6mrmD2tIW9ipUV5xGWblAX/j2XEG1+YIoj QVrW15Fq/AYn6TyhiADNJhlNCwP/eLe9bj+5k6f0w93FPX+WMqRJXRcJ6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAfpO1CtJXG9/2dsb2JhbABFunyBB4IgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQsdByEGCxQJCAIEDgUIFgSHXAMGBguaSZZNDQaJRASKJWOFeWADiBqLaIxhgyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="115752206" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2012 21:41:22 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RLfMxu018275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 21:41:22 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 16:41:22 -0500 From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgA== Date: Mon, 27 Aug 2012 21:41:21 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> In-Reply-To: <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.9] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--45.879000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:41:26 -0000 Cameron (and other authors of the xlat doc), Some comments are included below. We do have to decide one last sticking po= int which is the use of the reserved IID or not. If any hosts in the LAN a= re active before the CLAT is, when the CLAT is operational, and any LAN hos= t needs tethering to the CLAT, just reset the host to perform new IPv6 addr= ess acquisition. DAD will deal with any IPv6 address clash. More details = on DAD are included below. COMMENT #1. Section 8.3.1. Please change=20 OLD ---- >From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to To NEW ---- >From the delegated DHCPv6 [RFC3633] prefix, a /64 prefix is dedicated to COMMENT #2. Here is a stab at a re-worked section 8.3.2. OLD ----- 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may not have a dedicated IPv6 prefix for translation. If the CLAT does not have a dedicated IPv6 prefix for translation, the CLAT can perform NAT44 and stateless translation [RFC6145]. IPv4 packets from the LAN are NAT44 to the private IPv4 host address of the CLAT that is not included in LAN segment of CLAT. Then, the CLAT will do a stateless translation [RFC6145] so that the IPv4 packets from the CLAT IPv4 host address are translated to the CLAT WAN IPv6 address as described in [RFC6145]. If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]. This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT. This document describes an example for this case in Example 2. of the Appendix A. NEW ---- 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may not have a dedicated IPv6 prefix for translation. If the CLAT does not have a dedicated IPv6 prefix for translation, the CLAT performs NAT44 and stateless translation [RFC6145]. IPv4 packets from the LAN are NAT44 translated to IPv4 address of the CL= AT. =20 Thereafter, CLAT performs a stateless translation [RFC6145] using the IP= v4=20 and the WAN IPv6 address of the CLAT as described in [RFC6145]. =20 The CLAT uses an ND Proxy to share the single /64 prefix between the LAN and WAN segments. Additionally, it is expected the hosts in the LAN segment of the CLAT are reset for new IPv6 address acquisition if the hosts were active before the CLAT was operational in the LAN segment= . =20 The idea is when the CLAT is booted and is operational, the CLAT user reset= s his/her IPv6 hosts if the hosts were already booted up and ready with an = IPv6 link-local address. Thus ND DAD operation will take over and detect a= ny duplicates in the LAN. If a duplicate is detected in the LAN and the du= plicate matches the IPv6 link-local of the CLAT LAN interface, and if the l= ink-local address is created using a globally unique IID using a mechanism = such as the EUI-64, the IP operations on both nodes stop. For other types = of IPv6 addresses, the tentative address is used and a receiver of the DAD = duplicate message logs a system management message. =20 My personal vote is to have the CLAT LAN win if a DAD duplicate is detected= in that the CLAT LAN continues with IPv6 operations and the LAN host is de= nied. However, this is new behavior above and beyond RFC 4862. A v6ops do= cument cannot specify new protocol behavior. However, I still do not like= the special-case of reserved IID because then the SP IPv6 nodes also chang= e to special-case the new reserved IID. So now what do we do? =20 Hemant -----Original Message----- From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 Sent: Monday, August 27, 2012 12:11 PM To: Hemant Singh (shemant) Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt Le 2012-08-27 =E0 17:17, Hemant Singh (shemant) a =E9crit : > Cameron, >=20 > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 > Sent: Monday, August 27, 2012 10:05 AM > To: Lorenzo Colitti > Cc: Hemant Singh (shemant); v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 >> This is all fine, but this is not a draft about how to make tethering wo= rk on a mobile network. >=20 > Great. Also note, most details Lorenzo has provided are already covered = in RFC 6204 or RFC 6204bis. That is another reason not to cover them in th= e xlat document. RFC6204 for the DSL Broadband Forum supports a unnumbered = WAN including any Loopback interface to source packets out the WAN of the C= PE router. =20 >=20 >> Perhaps the draft should not just refer to ND Proxy but "ND Proxy and >> other /64 sharing approaches" >=20 > Right - we should re-work section 8.3.2 of the xlat document. This is a = xlat document that folks have expressed a need to get out fast for an RFC. = Thus we should not de-focus the document process with how the CLAT gets a = /64 prefix to source packets used by the XLATE protocol. During early revi= sions of RFC 6404 when the I-D included the 3GPP single /64 use case and ND= Proxy, we were told by a v6ops Chair and other folks in the IESG that a v6= ops document cannot reference an Experimental RFC. You will, likely, face = the same issue in the IESG with the xlat document if xlat continues to refe= rence the ND Proxy RFC.=20 >=20 > Additionally, if the ND Proxy Experimental RFC is taken to re-work in 6ma= n, at least one year will transpire before a new RFC that fixes all cases c= ausing loops with RFC 4389. Protocol work tends to step gingerly. The oth= er issue with RFC 4389 is that the RFC also needs to support SEND (RFC 3971= ). I don't think any complete fix to the ND Proxy RFC is less than two yea= rs away. +1 to avoid ND-proxy reference in section 8.3.2. > The other sharing approach covered in section 8.3.2 is a reserved IID whi= ch is also taking longer to flush out text for and delaying the xlat docume= nt. Following the separate discussion on the reserved IID, there remains no tec= hnical argument against it, especially with a MAY. OTOH, if an exclusive /64 routed to a CLAT node, it clearly avoids the need= for any specific provision against RFC4291-compliant hosts using the /64 t= o collide with the CLAT IPv6 address. (Neither DAD complement nor ND proxy = is needed.) Deleting it would therefore be a step backward, justified only by historica= l and undeserved FUD, against a feature already tested with running code.=20 Regards, RD =20 > We could consider being silent on a reserved IID and also edit the IANA = Considerations section. >=20 > One additional comment. Why does the document in several places includin= g section 8.3.2 include this text: >=20 > [The CLAT MAY discover the Pref64::/n of the PLAT via some method such as= TR-069, DNS APL RR [RFC3123] or [I-D.ietf-behave-nat64-discovery-heuristic= ]. =20 >=20 > First, please define what is "Pref64:/n" somewhere in the document. Is t= his a global IPv6 subnet prefix and what does the PLAT use this prefix for?= Then why does the CLAT have a "MAY" need to discover this prefix? >=20 > Thanks, >=20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Mon Aug 27 15:34:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC721F846D for ; Mon, 27 Aug 2012 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viI-KTH8aOf0 for ; Mon, 27 Aug 2012 15:34:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCD21F846B for ; Mon, 27 Aug 2012 15:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=607; q=dns/txt; s=iport; t=1346106843; x=1347316443; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=98qQayRucD4uM5scGvufEfs5EjPTTdBNI4zY55wKttQ=; b=cXBNZmALgvWvzkpTHEHcdUj8tHjpQvocM9Gfxsn4VCq4LX3E7PsSckyi l1PfdYCg4r2yzzTC9qPZVQ7Ddv5vDu/qWzbZDa2zUSl9UJ5DIAMB/qHS2 jTeVECHr531JcVVTIdaEO3VU12Y2OD9V7zoqeSNpqonv2CGSYhHOdtI8n Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPz0O1CtJXG+/2dsb2JhbABFun2BB4IiAQQSASdRASoUQiYBBBsah2uZKIEooCiRAWADpAOBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="115572685" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 27 Aug 2012 22:34:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7RMY3pP031523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Aug 2012 22:34:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 17:34:02 -0500 From: "Hemant Singh (shemant)" To: "v6ops@ietf.org" Thread-Topic: more minor comments for draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2EpA5XtA1IeaoGRc+j/DiBFKxkeQ== Date: Mon, 27 Aug 2012 22:34:01 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890799BF@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.9] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--29.543200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] more minor comments for draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 22:34:04 -0000 # Section 9.2. Please change the following text from IPv4-only clients must be support through to IPv4-only clients must be supported through # Section 6.1. Change the following text from The v4p host behind the CLAT on this diagram with the private IPv4 addresse= s. To=20 The v4p host behind the CLAT on this diagram uses a private IPv4 address. I don't have any more comments. Please make all minor edits in a -08 versi= on ASAP so that when the reserved IID issue is resolved, you can publish a = -08 to reflect that consensus and shoot for a WGLC. Thanks, Hemant From despres.remi@laposte.net Mon Aug 27 15:48:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D176121E8034 for ; Mon, 27 Aug 2012 15:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLLUxxEuyPgZ for ; Mon, 27 Aug 2012 15:48:00 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9C11E8091 for ; Mon, 27 Aug 2012 15:47:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id 9FAF170000DE; Tue, 28 Aug 2012 00:47:58 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id 26853700008D; Tue, 28 Aug 2012 00:47:58 +0200 (CEST) X-SFR-UUID: 20120827224758157.26853700008D@msfrf2407.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> Date: Tue, 28 Aug 2012 00:47:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 22:48:00 -0000 Le 2012-08-27 =E0 23:41, Hemant Singh (shemant) a =E9crit : > Cameron (and other authors of the xlat doc), >=20 > Some comments are included below. We do have to decide one last = sticking point which is the use of the reserved IID or not. If any = hosts in the LAN are active before the CLAT is, when the CLAT is = operational, and any LAN host needs tethering to the CLAT, just reset = the host to perform new IPv6 address acquisition. DAD will deal with = any IPv6 address clash. More details on DAD are included below. >=20 > COMMENT #1. Section 8.3.1. Please change=20 >=20 > OLD > ---- >=20 > =46rom the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to >=20 > To >=20 > NEW > ---- >=20 > =46rom the delegated DHCPv6 [RFC3633] prefix, a /64 prefix is = dedicated to >=20 >=20 > COMMENT #2. Here is a stab at a re-worked section 8.3.2. >=20 > OLD > ----- >=20 > 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT >=20 > In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may > not have a dedicated IPv6 prefix for translation. If the CLAT does > not have a dedicated IPv6 prefix for translation, the CLAT can > perform NAT44 and stateless translation [RFC6145]. >=20 > IPv4 packets from the LAN are NAT44 to the private IPv4 host address > of the CLAT that is not included in LAN segment of CLAT. Then, the > CLAT will do a stateless translation [RFC6145] so that the IPv4 > packets from the CLAT IPv4 host address are translated to the CLAT > WAN IPv6 address as described in [RFC6145]. >=20 > If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction > of the implementation, the CLAT may use a dedicated IANA assigned > EUI-64 ID for creating a translated IPv6 address to be used in > stateless translation [RFC6145]. This will allow the CLAT to avoid > possible IPv6 address duplication issues between an IPv6 address for > stateless translation [RFC6145] in the CLAT and an IPv6 address > assigned to native IPv6 nodes behind the CLAT. This document > describes an example for this case in Example 2. of the Appendix A. >=20 >=20 >=20 > NEW > ---- >=20 > 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT >=20 > In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may > not have a dedicated IPv6 prefix for translation. If the CLAT does > not have a dedicated IPv6 prefix for translation, the CLAT > performs NAT44 and stateless translation [RFC6145]. >=20 > IPv4 packets from the LAN are NAT44 translated to IPv4 address of = the CLAT. =20 > Thereafter, CLAT performs a stateless translation [RFC6145] using = the IPv4=20 > and the WAN IPv6 address of the CLAT as described in [RFC6145]. >=20 > The CLAT uses an ND Proxy to share the single /64 prefix between the = LAN > and WAN segments. Additionally, it is expected the hosts in the LAN > segment of the CLAT are reset for new IPv6 address acquisition if > the hosts were active before the CLAT was operational in the LAN = segment. >=20 > The idea is when the CLAT is booted and is operational, the CLAT user = resets his/her IPv6 hosts if the hosts were already booted up and ready = with an IPv6 link-local address. Thus ND DAD operation will take over = and detect any duplicates in the LAN. If a duplicate is detected in the = LAN and the duplicate matches the IPv6 link-local of the CLAT LAN = interface, and if the link-local address is created using a globally = unique IID using a mechanism such as the EUI-64, the IP operations on = both nodes stop. For other types of IPv6 addresses, the tentative = address is used and a receiver of the DAD duplicate message logs a = system management message. =20 >=20 > My personal vote is to have the CLAT LAN win if a DAD duplicate is = detected in that the CLAT LAN continues with IPv6 operations and the LAN = host is denied. However, this is new behavior above and beyond RFC = 4862. A v6ops document cannot specify new protocol behavior. =20 Right. > However, I still do not like the special-case of reserved IID because = then the SP IPv6 nodes also change to special-case the new reserved IID. = So now what do we do? =20 Since this is apparently your only reason for objecting to the reserved = IID, which solves an otherwise unresolved issue, could you clarify what = you mean by "SP IPv6 nodes also change to special-case the new reserved = IID"?=20 (Only CLAT nodes are concerned with using the reserved IID, and they = have to be upgraded anyway.) =20 RD >=20 > Hemant >=20 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 > Sent: Monday, August 27, 2012 12:11 PM > To: Hemant Singh (shemant) > Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 >=20 > Le 2012-08-27 =E0 17:17, Hemant Singh (shemant) a =E9crit : >=20 >> Cameron, >>=20 >> -----Original Message----- >> From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 >> Sent: Monday, August 27, 2012 10:05 AM >> To: Lorenzo Colitti >> Cc: Hemant Singh (shemant); v6ops@ietf.org >> Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >>=20 >>> This is all fine, but this is not a draft about how to make = tethering work on a mobile network. >>=20 >> Great. Also note, most details Lorenzo has provided are already = covered in RFC 6204 or RFC 6204bis. That is another reason not to cover = them in the xlat document. RFC6204 for the DSL Broadband Forum supports = a unnumbered WAN including any Loopback interface to source packets out = the WAN of the CPE router. =20 >>=20 >>> Perhaps the draft should not just refer to ND Proxy but "ND Proxy = and >>> other /64 sharing approaches" >>=20 >> Right - we should re-work section 8.3.2 of the xlat document. This = is a xlat document that folks have expressed a need to get out fast for = an RFC. Thus we should not de-focus the document process with how the = CLAT gets a /64 prefix to source packets used by the XLATE protocol. = During early revisions of RFC 6404 when the I-D included the 3GPP single = /64 use case and ND Proxy, we were told by a v6ops Chair and other folks = in the IESG that a v6ops document cannot reference an Experimental RFC. = You will, likely, face the same issue in the IESG with the xlat document = if xlat continues to reference the ND Proxy RFC.=20 >>=20 >> Additionally, if the ND Proxy Experimental RFC is taken to re-work in = 6man, at least one year will transpire before a new RFC that fixes all = cases causing loops with RFC 4389. Protocol work tends to step = gingerly. The other issue with RFC 4389 is that the RFC also needs to = support SEND (RFC 3971). I don't think any complete fix to the ND Proxy = RFC is less than two years away. >=20 > +1 to avoid ND-proxy reference in section 8.3.2. >=20 >> The other sharing approach covered in section 8.3.2 is a reserved IID = which is also taking longer to flush out text for and delaying the xlat = document. >=20 > Following the separate discussion on the reserved IID, there remains = no technical argument against it, especially with a MAY. > OTOH, if an exclusive /64 routed to a CLAT node, it clearly avoids the = need for any specific provision against RFC4291-compliant hosts using = the /64 to collide with the CLAT IPv6 address. (Neither DAD complement = nor ND proxy is needed.) >=20 > Deleting it would therefore be a step backward, justified only by = historical and undeserved FUD, against a feature already tested with = running code.=20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> We could consider being silent on a reserved IID and also edit the = IANA Considerations section. >>=20 >> One additional comment. Why does the document in several places = including section 8.3.2 include this text: >>=20 >> [The CLAT MAY discover the Pref64::/n of the PLAT via some method = such as TR-069, DNS APL RR [RFC3123] or = [I-D.ietf-behave-nat64-discovery-heuristic]. =20 >>=20 >> First, please define what is "Pref64:/n" somewhere in the document. = Is this a global IPv6 subnet prefix and what does the PLAT use this = prefix for? Then why does the CLAT have a "MAY" need to discover this = prefix? >>=20 >> Thanks, >>=20 >> Hemant >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Mon Aug 27 17:00:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3E221E8039 for ; Mon, 27 Aug 2012 17:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Ada2+t1XQP for ; Mon, 27 Aug 2012 17:00:44 -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 EB47311E8097 for ; Mon, 27 Aug 2012 17:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2005; q=dns/txt; s=iport; t=1346112044; x=1347321644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pw/rdf5qzP5Z9vISmRg/ws17Fzbi3gQdyxM1bG+UEhg=; b=PohWMPCI+/TJs52OzCsju25zp74KiJd6azUpy9IMAdZ8kjAgXo5OPEG9 qqqQT+obQlmhKz6Vtx91iJ/gpuj/5qK3foFnNqz+ZNxBW1vRUIPEM76Im UDMnsICfqP1HuGGjkJ+5X2oND9qhiT7rlHeMrMcq3EfDF0AUV+M3Wn6KU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAoJPFCtJV2d/2dsb2JhbABFunyBB4IgAQEBBBIBZgwEAgEIEQQBAQsdBzIUCQgCBA4FCBMHh1wDDJphlkwTiUiLCBUShVJgA4gam2mBZ4JjgVkB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="115781476" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 28 Aug 2012 00:00:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7S00hRF026065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 00:00:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 19:00:42 -0500 From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgIAAeJ4A//+xJ+A= Date: Tue, 28 Aug 2012 00:00:42 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> In-Reply-To: <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--33.277100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 00:00:44 -0000 Remi, -----Original Message----- From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 Sent: Monday, August 27, 2012 6:48 PM To: Hemant Singh (shemant) Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Since this is apparently your only reason for objecting to the reserved II= D, which solves an otherwise unresolved issue, could you clarify what you m= ean >by "SP IPv6 nodes also change to special-case the new reserved IID"?=20 >(Only CLAT nodes are concerned with using the reserved IID, and they have = to be upgraded anyway.) =20 First, the IPv6 link-local address of the LAN of the CLAT is not covered by= the reserved CLAT IID and the CLAT LAN is expected to generate the link-lo= cal using the EUI-64 format. Only if there is bad hardware in the LAN segm= ent of the CLAT do we have a duplicate link-layer address and this is a pro= blem no one can solve with computer automata. Manual intervention is requi= red. =20 The reserved IID range is applicable to global IPv6 addresses. If an IID = range is reserved for CLAT use, doesn't the SP access network and its provi= sioning systems serving the CLATs have to make sure to not allocate IPv6 ad= dresses from IPv6 subnet pools that match the CLAT reserved IID range? Addi= tionally, even when a reserved IID range is used, a host in the LAN segment= can still generate CGA or privacy addresses that could clash with an IPv6 = address from the reserved IID range. So what good is the reserved IID? Pl= ease also see RFC 5453 that discourages reserved IID ranges for autonomous = autoconfiguration - see section 2 of RFC 5453. Lastly, "ND Proxy" is a workable solution. Why not then limit the xlat doc= ument to either use DHCPv6-PD or "ND Proxy"? After all the main focus of t= he xlat document is XLATE and not devise every possible solution for gettin= g a unique /64 prefix for use by XLATE. Hemant From randy@psg.com Mon Aug 27 19:28:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A602A11E8099; Mon, 27 Aug 2012 19:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDfq2S8Yrxgh; Mon, 27 Aug 2012 19:28:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA611E808E; Mon, 27 Aug 2012 19:28:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6BXt-0002BQ-AN; Tue, 28 Aug 2012 02:28:49 +0000 Date: Tue, 28 Aug 2012 09:29:34 +0700 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20120827132818.GA17806@puck.nether.net> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:28:50 -0000 > Sure, RFC2270 seems to be one reasonable solution for the use case of an > ISP providing ASNs to single homed customers that do not require route > connectivity to each other except via default, and yes, I'm aware of it > and seen it deployed at multiple places I've worked. Of course, the > unsaid thing in this draft is that using a seperate (private) ASN per > customer site was not viable due to limited private use ASN space 2270 is widely deployed. i have not run across the case where we wanted more than one private asn. any sane provider is doing templated or generated config, and using a single asn is simpler and just works. i am sure i can dream up convoluted uses for a mass of as numbers. but what i can not do is come up with convoluted case which is worth the end run on having good registration of the use/assignment of those asns. randy From farmer@umn.edu Mon Aug 27 19:46:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5967121E8040 for ; Mon, 27 Aug 2012 19:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RcTC5PvTq-g for ; Mon, 27 Aug 2012 19:46:20 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DF21E803F for ; Mon, 27 Aug 2012 19:46:20 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 27 Aug 2012 21:46:09 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by iabz25 with SMTP id z25so20834691iab.16 for ; Mon, 27 Aug 2012 19:46:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=oEdQi8oS31miwzhl95NLE1Zcrihkp3KT9Rqu/zhVhJg=; b=U0FtbafridEDgS1iHEIOgYsnMJz0onGYXBqRbR2o33eUVnZfRFGlNdE1u8dAhoUEfv KcR+7ph+CkwnOG+QOuruPLx7G/jeMeTIxiBPdpwxE3cehNih7Dxi2FMM5YMkYg2C7IVr okZ4zP7LdPMtXnQr2EhvOxJ9qIHNrpq1ioRMcYiKYNcrey1DWuwg3sgl1TmpJ1aVhnpV At/9vr2tqy+aOeaU6BiKsicf9ymNsF5XMM/R7mG52LTPO9bKsYPslxRSsjKunn5K5gdW 2VBhr12d9CusUJYPf/qmuKFQoGQVtapNLdzV8FDzfv/V5+l8a4K5FWIoT4eeCqM263tX A2tQ== Received: by 10.50.202.4 with SMTP id ke4mr12234907igc.72.1346121969011; Mon, 27 Aug 2012 19:46:09 -0700 (PDT) Received: from x-128-101-233-186.uofm-secure.wireless.umn.edu (x-128-101-233-186.uofm-secure.wireless.umn.edu. [128.101.233.186]) by mx.google.com with ESMTPS id ng5sm1736263igc.0.2012.08.27.19.46.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 19:46:08 -0700 (PDT) Message-ID: <503C30EE.4020102@umn.edu> Date: Mon, 27 Aug 2012 21:46:06 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Bush References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn6k7tZ0YrCNNvN8L1jaYnra63r8R9npEdbfcWx3Wfde7DPCy8WqdhDTNAocDD8Jvp2H9W0 Cc: idr wg , v6ops list , Jon Mitchell Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:46:20 -0000 On 8/27/12 21:29 CDT, Randy Bush wrote: >> Sure, RFC2270 seems to be one reasonable solution for the use case of an >> ISP providing ASNs to single homed customers that do not require route >> connectivity to each other except via default, and yes, I'm aware of it >> and seen it deployed at multiple places I've worked. Of course, the >> unsaid thing in this draft is that using a seperate (private) ASN per >> customer site was not viable due to limited private use ASN space > > 2270 is widely deployed. i have not run across the case where we wanted > more than one private asn. any sane provider is doing templated or > generated config, and using a single asn is simpler and just works. > > i am sure i can dream up convoluted uses for a mass of as numbers. but > what i can not do is come up with convoluted case which is worth the end > run on having good registration of the use/assignment of those asns. I'm sorry but it is not a convoluted use case, section 3.1 of RFC 2270 details the exact case, if the customer wants a full route table. And BGP customer wanting a full global route table in not convoluted, it is a perfectly reasonable request from a customer. If they don't have a globally unique ASN to use, then in that case the easiest thing to do is use a unique private ASN for that customer and no other customer. I recommend the customer gets an RIR assigned globally unique ASN, but some customers don't want to do that. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From randy@psg.com Mon Aug 27 19:59:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C8D11E80A5; Mon, 27 Aug 2012 19:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okErx7MqilmN; Mon, 27 Aug 2012 19:59:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4864B11E80A3; Mon, 27 Aug 2012 19:59:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6C1a-0002Fh-VD; Tue, 28 Aug 2012 02:59:31 +0000 Date: Tue, 28 Aug 2012 10:00:15 +0700 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <503C30EE.4020102@umn.edu> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> <503C30EE.4020102@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , IETF v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:59:33 -0000 > I'm sorry but it is not a convoluted use case, section 3.1 of RFC 2270 > details the exact case, if the customer wants a full route table. yes, that's a bit old. no problem giving a full table to 942 peers who all use the same asn. 2270 was written before the "ignore my as in path" hacks by all vendors. > I recommend the customer gets an RIR assigned globally unique ASN, but > some customers don't want to do that. no problem. use 2270+ignore-my-asn-hack this all works. this is all widely used. we do not need more cleverness. we do not need to end-run the rirs (we need to abolish them, but that's a whole other discussion in another venue) randy From lorenzo@google.com Mon Aug 27 20:56:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7821F8476 for ; Mon, 27 Aug 2012 20:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDIyNNiW2wvY for ; Mon, 27 Aug 2012 20:56:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09821F8473 for ; Mon, 27 Aug 2012 20:56:03 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10937948obb.31 for ; Mon, 27 Aug 2012 20:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=65bPrlpXn84ggVQFoJ2dc68Mv2YHtl2D2UD4DRC+uTk=; b=L/+tFziDXkA4y/DJVrXjWRXTXstUJC2bIx0UVx2j++sYNA7j3Q4N90Z7r9+hUDLi9Y 8YzA1+RbHhzjKnKmodweGk51O2Y84prftGp3sTI9vCv4seylto3PcwgYkWf47H2G4qG/ sH1mcCARzwn+z9N9OrWXGIf/zxYBaWuTl03Aa9H8ks4fCNFMzGrOHvo92jTNdV/qoLDT 99Uc/QaGIrjpiGweTkV/uR6IwXHYXse/G7m4NYL9J57IMBGoStyZxIzB9zoirLlIBsUv fzeugNqk2pcP4H6r5VybsxiZSNmD1Gphd1IJ9o/CNY5/9vbZSmozfZVsQX7LBJs7yMMw ECiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=65bPrlpXn84ggVQFoJ2dc68Mv2YHtl2D2UD4DRC+uTk=; b=l6rbVsI0hoeqTJl14TLeTqONBZtAH9NuZfxtmI6/K5dGejH0IQQO5+OPyaa+h5gaYU abF0DWXVXWct/Npg0NufdJtSLVV4MFHBZoTb3zZRVHyjh35HVDLmiH62nas6j2C+RRGL YQ8fQsGan6DCRH+KX9IWZWzhXgC/eeEf+nqYeUXZOTVM00wRZPxxS9DNUdLHsyNs0naG 45fB4EPHa9rBRxa2b70BdSAoNQuDsOAaSsv4fbiNp8+6CvPlSYTkfarZ/9pYz/v0dRh0 l9UUw9QGAHOyXf3ubowXFuTRkxtGTvzzBxUUpIxfft2LR9QceTqDCv/OPj1rNrI+Lkiy uSvA== Received: by 10.60.13.231 with SMTP id k7mr11437509oec.74.1346126160336; Mon, 27 Aug 2012 20:56:00 -0700 (PDT) Received: by 10.60.13.231 with SMTP id k7mr11437501oec.74.1346126160067; Mon, 27 Aug 2012 20:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Mon, 27 Aug 2012 20:55:38 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Tue, 28 Aug 2012 12:55:38 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=e89a8fb1ee0497fc0704c84b6b8d X-System-Of-Record: true X-Gm-Message-State: ALoCoQmxmW6F60R/5ti3DIdrjOYw1rLJjm8KkU66tMODuMju3Cv5KR5rWcPuCUKI7zUPYXOuLHe6sy5x8jp/b75EJsj/HYg+GbZButiANi3PAhSGlgZjWcTaxjII2SqHHIQ+6EIoGuOuPcsN6L/p7xAKQWRSACua8PH1PFdED/MmDoNHqArbwu2aE/AWCoqMBWQYkIKS/w0n Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 03:56:04 -0000 --e89a8fb1ee0497fc0704c84b6b8d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 28, 2012 at 6:41 AM, Hemant Singh (shemant) wrote: > The CLAT uses an ND Proxy to share the single /64 prefix between the LAN > and WAN segments. Additionally, it is expected the hosts in the LAN > segment of the CLAT are reset for new IPv6 address acquisition if > the hosts were active before the CLAT was operational in the LAN > segment. > Wait... so you're saying that when the user enables tethering, he needs to manually reset the hosts on the LAN? I think that's unreasonable, and a bad user experience. If that's the best we can do, we should give up and remove all text describing mention of how to share the CLAT's /64 with its clients. --e89a8fb1ee0497fc0704c84b6b8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 6:41 AM, Hemant Singh (shemant) &= lt;shemant@cisco.com= > wrote:
=A0 =A0The CLAT uses an ND Proxy to share the single /64 prefix between the= LAN
=A0 =A0and WAN segments. =A0Additionally, it is expected the hosts in the L= AN
=A0 =A0segment of the CLAT are reset for new IPv6 address acquisition if =A0 =A0the hosts were active before the CLAT was operational in the LAN seg= ment.

Wait... so you're saying that= when the user enables tethering, he needs to manually reset the hosts on t= he LAN? I think that's unreasonable, and a bad user experience. If that= 's the best we can do, we should give up and remove all text describing= mention of how to share the CLAT's /64 with its clients.
--e89a8fb1ee0497fc0704c84b6b8d-- From farmer@umn.edu Mon Aug 27 21:00:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534D421F8473 for ; Mon, 27 Aug 2012 21:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix9xcPEnoUGo for ; Mon, 27 Aug 2012 21:00:58 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id C098721F8474 for ; Mon, 27 Aug 2012 21:00:58 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 27 Aug 2012 23:00:49 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by iabz25 with SMTP id z25so21020433iab.16 for ; Mon, 27 Aug 2012 21:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=2ajiPoJWSTkao1UB1fgFrENt/nFNcGcSCNqYgV/gDD4=; b=X2Ermeeg7qQa8AIQil0g1N/uU1W9azsnpVMepoIiylubFcojFS62mwap4l/KJhmhuW htotfkdFKbfy3cmO4B1NFC7ckLMsjlQjrY7neOEs9C13RGO/CULAq2MjreDLdSwz6MQM N5zQOobawnH1HcIfgsE+Mz2oTOCpAzeuZyVoaSRez3yB+AKyLKmljHuVwhfV5xlqdfQG 7JKuSOXQtWOCxOGNw5OdOYlnYPpZvBjjs3DYqlXs1aXkkzDqREjhw7HXMUKQeH71ZlEf jd6q4d82G4rwkcszOa82WRoewlCKNY36fe0J7DDjXZ24qJD4tXDT41rW1KWYvgovgDeT QRXQ== Received: by 10.50.135.74 with SMTP id pq10mr12350564igb.29.1346126448782; Mon, 27 Aug 2012 21:00:48 -0700 (PDT) Received: from oit200959392.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id a3sm1918265igd.7.2012.08.27.21.00.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 21:00:47 -0700 (PDT) Message-ID: <503C426E.30502@umn.edu> Date: Mon, 27 Aug 2012 23:00:46 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Bush References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> <503C30EE.4020102@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlNHg5nGhmejnatsb14BMzA7Cw+NtKWDUujgBasePFQ0dRuQtdBVuHGwhcVpZOWxxr2Z+x0 Cc: IETF v6ops list , idr wg Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:00:59 -0000 On 8/27/12 22:00 CDT, Randy Bush wrote: >> I'm sorry but it is not a convoluted use case, section 3.1 of RFC 2270 >> details the exact case, if the customer wants a full route table. > > yes, that's a bit old. no problem giving a full table to 942 peers who > all use the same asn. 2270 was written before the "ignore my as in > path" hacks by all vendors. > >> I recommend the customer gets an RIR assigned globally unique ASN, but >> some customers don't want to do that. > > no problem. use 2270+ignore-my-asn-hack > > this all works. this is all widely used. we do not need more > cleverness. we do not need to end-run the rirs (we need to abolish > them, but that's a whole other discussion in another venue) That is just as much of a hack or convoluted way of doing things as you claim that using a unique private ASN per customer is a hack or convoluted. Yes, 2270+ignore-my-asn-hack is one way to do things, but using unique private ASNs per customer is another reasonable way to do things too. They are both more-or-less equal on the hack-o-meeter from my perspective. I've used both, I generally prefer unique private ASN per customer, but YMMV. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From randy@psg.com Mon Aug 27 21:11:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5821F849D; Mon, 27 Aug 2012 21:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWBNwuCAf8Ql; Mon, 27 Aug 2012 21:11:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0821F8494; Mon, 27 Aug 2012 21:11:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6D94-0002Mt-HT; Tue, 28 Aug 2012 04:11:19 +0000 Date: Tue, 28 Aug 2012 11:12:03 +0700 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <503C426E.30502@umn.edu> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> <503C30EE.4020102@umn.edu> <503C426E.30502@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , IETF v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:11:28 -0000 > Yes, 2270+ignore-my-asn-hack is one way to do things, but using unique > private ASNs per customer is another reasonable way to do things too. "It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful." -- Jon Postel From fred@cisco.com Mon Aug 27 23:35:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9B121F845D for ; Mon, 27 Aug 2012 23:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v6EFbhx+4xc for ; Mon, 27 Aug 2012 23:35:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 334D321F845E for ; Mon, 27 Aug 2012 23:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2530; q=dns/txt; s=iport; t=1346135702; x=1347345302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uwSsTy8kAXMHgs3rxn33SCgQeU0+GDzhbM3aprIgJDs=; b=Zv75icXslDjX+olGQrW9d8iuq6YQcufnVDTkfQS/mpdfnkORF/a5DMjC NOPUyl7uld2Ow1a5xibtRikFMgulNkFYCnyW5XgnBw87w5bq5vRhNYCNb t7KqBWHwnFVIR9XOLWEh0J5CgWafjeLHWesi17PV5+LszJKbCz2IymnFC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAFmPFCtJXG+/2dsb2JhbABFun6BB4IgAQEBAwESAWYFCwIBCEYyJQIEDieHZQYLmnOgKIsIhXlgA4gajTyBFI0agWeCYw X-IronPort-AV: E=Sophos;i="4.80,325,1344211200"; d="scan'208";a="115886885" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2012 06:35:01 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7S6Z1s8030692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 06:35:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 01:35:01 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat WGLC Thread-Index: AQHNhOc/PenwvQPEwUyFD0ZOMMto9A== Date: Tue, 28 Aug 2012 06:35:00 +0000 Message-ID: <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> References: <503B226D.3020205@redpill-linpro.com> In-Reply-To: <503B226D.3020205@redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.145.240] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--39.946100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8ACA45F668B32C4F970BE61354D992C9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:35:03 -0000 On Aug 27, 2012, at 12:31 AM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> This is to open a two week Working Group last Call on >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> "464XLAT: Combination of Stateful and Stateless Translation", >> Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>=20 >> Please read it now. We are interested in, among other things, >> technical commentary on the draft and the working group's perception >> on its usefulness to its target audience. >=20 > I've voluntarily used IPv6+NAT64/DNS64 as my primary mobile data > connection for well over a year, and while most things work just fine, > there is a small, but significant, percentage of apps and services which > fails to function correctly. Because of these, I can fully understand > that deploying IPv6 as a default connectivity method to =ABordinary=BB us= ers > in current 3G networks is simply not feasible. The statement confuses me. You have run translated IPv6 for a year, and as = a result believe that running native IPv6 is not feasible? Are you trying t= o say that you believe that running translation is not feasible for a certa= in set of applications? > That said, there is a pressing need to get IPv6 more widely deployed, > perhaps especially in mobile networks. In my opinion, 464XLAT appears to > allow those problematic apps and services to function correctly on > IPv6-only mobile networks, thus making IPv6-only service a commercially > viable strategy for the operators. That, I feel, is extremely valuable, > and not to mention urgent. >=20 > As to the current bickering going on about ND-Proxy and IANA-reserved > IID...we need a bike shed like 464XLAT *now*, regardless of hue. It > doesn't even have to be perfect and able fit all weird sorts of > velocipedes, trikes and future inventions - after all, its function is > only to support a small and diminishing number of legacy apps and > services that cannot make use of native IPv6 themselves. It's a stop-gap > measure, not the future of mobile networking. >=20 > I therefore support this document wholeheartedly, and hope I'll get an > implementation of it delivered to my phone =ABover the air=BB in the near > future. >=20 > Best regards, > --=20 > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From lorenzo@google.com Mon Aug 27 23:38:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4B11E80B8 for ; Mon, 27 Aug 2012 23:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIw-sc8-ASDh for ; Mon, 27 Aug 2012 23:38:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5111E80AE for ; Mon, 27 Aug 2012 23:38:06 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11132054obb.31 for ; Mon, 27 Aug 2012 23:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=3I0QMIz3zJAJinEHl5OjZDMGXZxz4cza7W1ol++SUJo=; b=VveVu1sSnmQ68nSc9ol+qJ18IOonb+Fab6F0fLcwgXqO2s/9tkQlBsqhA+u699gdMK GwfbK/91gVNpYgf2Sq/J+ZfYvZaaYcjDUBEKwLbfyt+8LWV3X7Sanl0zE9Dq9bsOu9bp ARDizbLmCVluyG6GEXlgL6mER3aDWqiljzS/XO4GBWHtMZRcQwGNcWUrmEI3qrCwZ9c7 ickiGL0OCnd4Lfbt98fCq2X2tEe3y1fEIvtZJKxZew566/YI89ZNh5Abthd6ekCLETl3 zSSvaKzG7FXm5DlpxTQMh36/ZomQk3MQkZa6mcxIHluOxZ1tkyq6DUpp7gx0+clzYjXi pkUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3I0QMIz3zJAJinEHl5OjZDMGXZxz4cza7W1ol++SUJo=; b=dxaxPNiEYkWmgEvU87Z0L6fNm/IMUmc7wvIfplKlew6zmLFk1wpTcglgGxpocXPXcz 7ZtVCGIB6ehbZKO8ESVlcqdGTCC8UIL0GEGTrCEbqeFpBJIhcg041SUfnxQ/O77yBG8c TG3wsRuiPOiqDdisWkCNPftYQTlP18EuZJX1ZXAxaMykqo/vA5MWwxRwce0S6K8etssF W8g/wJDfAsteLkX1/LKJfUyPKnr5yv6uBr//NbnZ/EqB4s+2oO3CyABD3TRoKWccAg85 Tk43rXmgQ8xW5UFWDMjPf4DqAVqU9/8XsnScezbSY1ja0nlxhwYiNer4CExacdPvBaeU 7k6w== Received: by 10.182.1.72 with SMTP id 8mr11586207obk.61.1346135885834; Mon, 27 Aug 2012 23:38:05 -0700 (PDT) Received: by 10.182.1.72 with SMTP id 8mr11586198obk.61.1346135885677; Mon, 27 Aug 2012 23:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Mon, 27 Aug 2012 23:37:45 -0700 (PDT) In-Reply-To: <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> References: <503B226D.3020205@redpill-linpro.com> <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> From: Lorenzo Colitti Date: Tue, 28 Aug 2012 15:37:45 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=f46d04462fe04903fb04c84daf6d X-System-Of-Record: true X-Gm-Message-State: ALoCoQn8Txrtl1bZOxnceR8xm+Chp7wkgg9Z9TRfTMTBWHlg1zJISQiyJ0vcf3Q0uRjKoa2DQBzDwc+APamGM/9eyDLwagFGtGGNBhXKk2+ttCEF8FMg8gokdG30OwtKnC6JeXz+ToW4Uu4a9ffQLLW0AMh8XkJzy63Qoq4GwQvuZkvNW0fAZ7o2QIKIGOSpW8l9//TlZCUq Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:38:07 -0000 --f46d04462fe04903fb04c84daf6d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 3:35 PM, Fred Baker (fred) wrote: > > I've voluntarily used IPv6+NAT64/DNS64 as my primary mobile data > > connection for well over a year, and while most things work just fine, > > there is a small, but significant, percentage of apps and services whic= h > > fails to function correctly. Because of these, I can fully understand > > that deploying IPv6 as a default connectivity method to =ABordinary=BB = users > > in current 3G networks is simply not feasible. > > The statement confuses me. You have run translated IPv6 for a year, and a= s > a result believe that running native IPv6 is not feasible? Are you trying > to say that you believe that running translation is not feasible for a > certain set of applications? I think he means that deploying IPv6+NAT64 as the *only* connectivity method to ordinary users is not feasible. Ordinarly users need to run IPv4-only apps as well. --f46d04462fe04903fb04c84daf6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 3:35 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> I've voluntarily used IPv6+NAT64/DNS64 as my pri= mary mobile data
> connection for well over a year, and while most things work just fine,=
> there is a small, but significant, percentage of apps and services whi= ch
> fails to function correctly. Because of these, I can fully understand<= br> > that deploying IPv6 as a default connectivity method to =ABordinary=BB= users
> in current 3G networks is simply not feasible.

The statement confuses me. You have run translated IPv6 for a year, a= nd as a result believe that running native IPv6 is not feasible? Are you tr= ying to say that you believe that running translation is not feasible for a= certain set of applications?

I think he means that deploying IPv6+NAT64 as the *only= * connectivity method to ordinary users is not feasible. Ordinarly users ne= ed to run IPv4-only apps as well.
--f46d04462fe04903fb04c84daf6d-- From tore.anderson@redpill-linpro.com Tue Aug 28 00:40:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46421F84D7 for ; Tue, 28 Aug 2012 00:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JB3xENBvsi4 for ; Tue, 28 Aug 2012 00:40:06 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 018B021F84B2 for ; Tue, 28 Aug 2012 00:40:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E5120182000E; Tue, 28 Aug 2012 09:40:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nehfkg+PWT4K; Tue, 28 Aug 2012 09:40:03 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 78D5A1820014; Tue, 28 Aug 2012 09:40:03 +0200 (CEST) Message-ID: <503C75D3.6030305@redpill-linpro.com> Date: Tue, 28 Aug 2012 09:40:03 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <503B226D.3020205@redpill-linpro.com> <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:40:07 -0000 * Lorenzo Colitti > On Tue, Aug 28, 2012 at 3:35 PM, Fred Baker (fred) > wrote: > >> The statement confuses me. You have run translated IPv6 for a year, >> and as a result believe that running native IPv6 is not feasible? No, I've been running *native* IPv6, with translated access to *IPv4* resources/services (using NAT64/DNS64). >> Are you trying to say that you believe that running translation is >> not feasible for a certain set of applications? > > I think he means that deploying IPv6+NAT64 as the *only* > connectivity method to ordinary users is not feasible. Ordinarly > users need to run IPv4-only apps as well. Yes. *I* am sufficiently interested in IPv6 deployment and technology to actually *want* to use it on my mobile phone, in spite of the fact that it causes troubles for certain apps and services. When that happens, I either simply opt not to use those apps or services, or I need to manually change the APN configuration to use IPv4 PDP type every time I want to use them. It's an acceptable situation for me, but I would certainly not give a phone that had to be operated in this way to, say, my mom. In fact, it would greatly surprise me if any mobile operator would - and because of this, IPv6 on current 3G networks is simply dead in the water, apart from friendly user pilots/opt-in programmes. 464XLAT appears to be the missing piece here, as it allows IPv6+NAT64 to function as well as IPv4 does from the end user perspective. We need that. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From despres.remi@laposte.net Tue Aug 28 00:52:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9653011E80D2 for ; Tue, 28 Aug 2012 00:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s7OoACBVH-p for ; Tue, 28 Aug 2012 00:52:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1211E808D for ; Tue, 28 Aug 2012 00:52:31 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6FAC3940147; Tue, 28 Aug 2012 09:52:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> Date: Tue, 28 Aug 2012 09:52:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:52:33 -0000 2012-08-28 02:00, Hemant Singh (shemant) : > Remi, >=20 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 > Sent: Monday, August 27, 2012 6:48 PM > To: Hemant Singh (shemant) > Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt (*) >> Since this is apparently your only reason for objecting to the = reserved IID, which solves an otherwise unresolved issue, could you = clarify what you mean >by "SP IPv6 nodes also change to special-case the = new reserved IID"?=20 >> (Only CLAT nodes are concerned with using the reserved IID, and they = have to be upgraded anyway.) =20 ... > The reserved IID range is applicable to global IPv6 addresses. If an = IID range is reserved for CLAT use, doesn't the SP access network and = its provisioning systems serving the CLATs have to make sure to not = allocate IPv6 addresses from IPv6 subnet pools that match the CLAT = reserved IID range? Additionally, even when a reserved IID range is = used, a host in the LAN segment can still generate CGA or privacy = addresses that could clash with an IPv6 address from the reserved IID = range. So what good is the reserved IID? Please also see RFC 5453 that = discourages reserved IID ranges for autonomous autoconfiguration - see = section 2 of RFC 5453. 1. Please note that it isn't an IID "range" that is reserved, only an = IID value 2. SP access networks do assign IIDs that comply with RFC 4291 (local = scope or MAC-address based EUI-64 IIDs). Thus, they cannot assign = addresses whose IIDs conflict with the CLAT-reserved IID. (This address = is EUI-64 not based on a MAC-address).=20 Consequently, NOTHING needs to be added in SP nodes to avoid collisions = between assigned IPv6 addresses and CLAT IPv6 addresses that use the = reserved IID. 3. CGA addresses and privacy addresses have u-bit =3D 0. Since the = CLAT-reserved IID has u-bit =3D 1. No collision is possible. 4. Section 2 of RFC 5453 says "reserved interface identifiers MUST NOT = be used for autonomous autoconfiguration or for managed address = configuration". That is exactly why, without manual and wrong = configuration, no host can collide with a CLAT IPv6 address that uses = the reserved IID. My sentence (*) above was an answer to your saying "I still do not like = the special-case of reserved IID because then the SP IPv6 nodes also = change to special-case the new reserved IID. So now what do we do?" Since the concern you expressed is shown to be unjustified, what can be = done (and should be done IMHO) is keeping in the draft that CLAT nodes = that have NAT44s MAY use the CLAT-reserved IID... and publish. I hope you can agree with this.=20 (If you find one more reason to doubt, thanks for asking for = clarification before making a FUD-instigating assertion.) Regards, RD=20 =20= From swmike@swm.pp.se Tue Aug 28 00:54:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B80211E80EF for ; Tue, 28 Aug 2012 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qoeWrFlpLHC for ; Tue, 28 Aug 2012 00:54:56 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9246411E80E6 for ; Tue, 28 Aug 2012 00:54:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 43BD29C; Tue, 28 Aug 2012 09:54:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3DE539A; Tue, 28 Aug 2012 09:54:54 +0200 (CEST) Date: Tue, 28 Aug 2012 09:54:54 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> Message-ID: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:54:57 -0000 On Mon, 27 Aug 2012, Hemant Singh (shemant) wrote: > Thanks for the details in your other email. The UE will still need to > proxy the RA from the service provider to the wlan0 segment of the UE. > Further an NS arrives at cell0 from the service provider. The UE will > also have to proxy this NS. Thus there is no getting around the ND > Proxy. The UE can/will get its address through other means than RA. In production right now are devices that get their /64 by means of 3GPP signalling "out of band", and then just point default at the rmnet0 device. During my testing, 2 out of 4 tested devices worked fine without seeing RA from the GGSN at all. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Aug 28 01:28:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A211E80A3 for ; Tue, 28 Aug 2012 01:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOlm2AxCR8bj for ; Tue, 28 Aug 2012 01:28:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 455EF11E808D for ; Tue, 28 Aug 2012 01:28:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 226DA9C; Tue, 28 Aug 2012 10:28:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1BB7E9A; Tue, 28 Aug 2012 10:28:27 +0200 (CEST) Date: Tue, 28 Aug 2012 10:28:27 +0200 (CEST) From: Mikael Abrahamsson To: Tore Anderson In-Reply-To: <503C75D3.6030305@redpill-linpro.com> Message-ID: References: <503B226D.3020205@redpill-linpro.com> <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> <503C75D3.6030305@redpill-linpro.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:28:28 -0000 On Tue, 28 Aug 2012, Tore Anderson wrote: > It's an acceptable situation for me, but I would certainly not give a > phone that had to be operated in this way to, say, my mom. In fact, it > would greatly surprise me if any mobile operator would - and because of > this, IPv6 on current 3G networks is simply dead in the water, apart > from friendly user pilots/opt-in programmes. 464XLAT appears to be the > missing piece here, as it allows IPv6+NAT64 to function as well as IPv4 > does from the end user perspective. We need that. I concur. As an operator, IPv6+NAT64+DNS64 is a no-go due to apps/programs not using dns and/or IPv6 APIs. There needs to be a way for a program to call a IPv4 literal and this would properly get sent over the IPv6 only access and translated in the NAT64 gateway for IPv4 connectivity. Not providing this means delaying IPv6 deployment until either all app menufacturers switch to DNS+IPv6API (will take time), or mobile phone networks (and handsets/dongles/routers) get v4v6 PDP context support (1-2 years out at least). 464XLAT is a software feature that can hopefully be implemented with an existing device software update. -- Mikael Abrahamsson email: swmike@swm.pp.se From ales.vizdal@t-mobile.cz Tue Aug 28 01:35:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD6711E80F0 for ; Tue, 28 Aug 2012 01:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1rm7FqOSS6v for ; Tue, 28 Aug 2012 01:35:20 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 398B511E808D for ; Tue, 28 Aug 2012 01:35:20 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 09CDC285813; Tue, 28 Aug 2012 10:35:13 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 28 Aug 2012 10:35:12 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mikael Abrahamsson , "Hemant Singh (shemant)" Date: Tue, 28 Aug 2012 10:35:11 +0200 Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2E8nc+AzZco6z8TBuHDd+qVzN/zAAAaEyA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D92E1A@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:35:21 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mikael > Abrahamsson > Sent: Tuesday, August 28, 2012 9:55 AM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 > On Mon, 27 Aug 2012, Hemant Singh (shemant) wrote: >=20 > > Thanks for the details in your other email. The UE will still need to > > proxy the RA from the service provider to the wlan0 segment of the UE. > > Further an NS arrives at cell0 from the service provider. The UE will > > also have to proxy this NS. Thus there is no getting around the ND > > Proxy. >=20 > The UE can/will get its address through other means than RA. In productio= n > right now are devices that get their /64 by means of 3GPP signalling "out > of band", and then just point default at the rmnet0 device. Hmm, the 3GPP specs are making SLAAC mandatory and the device shall use it, I cannot find a reference to what you're describing in the spec. It loo= ks that=20 the devices you have a behaving 'non-standard', but it is right the 3GPP ou= t-of-band signalling can provide the UE with all the necessary IP configuration.=20 (IPv6 prefix, DNS resolvers, link-local IID). > During my testing, 2 out of 4 tested devices worked fine without seeing R= A > from the GGSN at all. Interesting, thanks for sharing. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Tue Aug 28 01:36:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2411E80F3 for ; Tue, 28 Aug 2012 01:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScSDGNq-6gjn for ; Tue, 28 Aug 2012 01:36:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8790611E80F0 for ; Tue, 28 Aug 2012 01:36:38 -0700 (PDT) Received: by eaai11 with SMTP id i11so1446772eaa.31 for ; Tue, 28 Aug 2012 01:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0b2L0v7/pnlXwPQROdx4M43zJkKAtRxy938MqgQgD6A=; b=xYAE1u0ggpfPRwosNE/3nKoVJ+N3+owtFIioW4EVKZZ8jES5XOo3Ve1/3UI99U3Q7X yXU4HuHTmGxtOct48MPgJyk63o3JtSQk4mkIuGoZncOdHm123vVWipxrMx71nUPYlIDf EIQzFPH/n4PiNaW4YBJElpsqVaTWu+6vm4vXpi0XEc+gRG83OvYYSMQUmBq8vzhMOr9N XPoXkrctltR6OfJBjpNtOEsRkYmomAuXuQVIzU1zdr3Yo+xpzHo6dD5jBX/Qj3yVamxT zN0bN/jeu6iZCwJ7y0vmDQjA6BapkbyFRRVX5QKkpQsm1yGDYzejkd/ewJngCa/SUTVu kd4Q== Received: by 10.14.204.72 with SMTP id g48mr21073848eeo.45.1346142997706; Tue, 28 Aug 2012 01:36:37 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id y1sm59071257eel.0.2012.08.28.01.36.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 01:36:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 28 Aug 2012 11:36:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <223B08D9-2FA7-41D6-8678-775B770A3A5E@gmail.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:36:39 -0000 On Aug 28, 2012, at 10:54 AM, Mikael Abrahamsson wrote: > On Mon, 27 Aug 2012, Hemant Singh (shemant) wrote: >=20 >> Thanks for the details in your other email. The UE will still need = to proxy the RA from the service provider to the wlan0 segment of the = UE. Further an NS arrives at cell0 from the service provider. The UE = will also have to proxy this NS. Thus there is no getting around the ND = Proxy. >=20 > The UE can/will get its address through other means than RA. In = production right now are devices that get their /64 by means of 3GPP = signalling "out of band", and then just point default at the rmnet0 = device. >=20 > During my testing, 2 out of 4 tested devices worked fine without = seeing RA from the GGSN at all. Relying on NAS signaling to provide the prefix is non standard.. may = work for 3G but will fail in LTE. - Jouni >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Tue Aug 28 01:57:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC811E80F5 for ; Tue, 28 Aug 2012 01:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY-KMzcOBuJV for ; Tue, 28 Aug 2012 01:57:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FD11E808D for ; Tue, 28 Aug 2012 01:57:52 -0700 (PDT) Received: by eaai11 with SMTP id i11so1454158eaa.31 for ; Tue, 28 Aug 2012 01:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FczYdhz2PT6cXRZh1gslh8uWW1qgR4rOiIkmPRhjQkw=; b=m3IDBWJjIkqgMMO9U8ww9drViJMevYOMJBk17glbPBtlI/IIOEH51xcT7pngIe2IGX kncDF2QGEBece15zyT9Rx1P4W0u6nCg8W1MKHUVQ4fucH8Gp3wXUSw3HGKwsw02rouXs QScCIvpEDGFLbARXRgPSnTYiWofcGviQS28MJtpAwGUSzY92FCTj8dpiFh43Ovy+lcYC S8ytwvUjvv7QGeVuGQxDI2tLS2RolGptVjP2qwuTQFMTQ07ez2n/CW27Zj9JuP17DsAy JRWvisfq965eyNi0vWHTBe7ZfELBXos/R2AcayPdAVN5+MPHhXIgwcZlZa+v4z9p0zuS ykEw== Received: by 10.14.204.200 with SMTP id h48mr21335589eeo.7.1346144271299; Tue, 28 Aug 2012 01:57:51 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id i8sm3294829eeo.16.2012.08.28.01.57.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 01:57:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> Date: Tue, 28 Aug 2012 11:57:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:57:53 -0000 Hemant, On Aug 27, 2012, at 5:00 PM, Hemant Singh (shemant) wrote: > Jouni & Cameron, >=20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, August 27, 2012 2:36 AM > To: Hemant Singh (shemant) > Cc: Victor Kuarsingh; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 >=20 >> Your phone should then disable the proxy behavior according to = 4.1.3.3 of RFC4389 (the second last para). >=20 > In 60 minutes (as per RFC 4389) my phone disables ND Proxy when the = phone needs ND Proxy with a /64 assigned to the phone. My phone = tethering support is not available any more. Now I have an attack = vector to shutdown the ND Proxy of the phone and disable the tethering = support of the phone.=20 Life is tough ;=3D) >> Anyway, the topology described here is out of scope of RFC4389 as far = as I understand. Also, with the >> current mobiles, I don't think being a STA and AP at the same time is = possible, which seems to a >> prerequisite for the above topology. >=20 > Each of the two phones in my example, by itself, complies to the xlat = document and also the RFC 4389. It is perfectly reasonable to have both = phones enabled at the same time but powered on at different times. Then=20= Agree on your sentiment of the user behavior. I must be missing = something here. Is=20 your assumption that both mobiles and CPE's bridge would automatically = also join a mesh/wds type of setup? That would be a board assumption imho. - Jouni > any mis-configured tethered network can disrupt network services of = one of the phones or both. We should caution use of the ND Proxy. Here = is some proposed text to add to section 8.3.2 of the xlat document >=20 > "Note any loop in the tethered network may cause the ND Proxy on the = UE to be disabled."=20 >=20 > Thanks and regards, >=20 > Hemant >=20 >=20 >=20 From markzzzsmith@yahoo.com.au Tue Aug 28 02:44:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AF621F84FB for ; Tue, 28 Aug 2012 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cotLz2BKKK2V for ; Tue, 28 Aug 2012 02:44:47 -0700 (PDT) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id 8544E21F84FA for ; Tue, 28 Aug 2012 02:44:47 -0700 (PDT) Received: from [98.139.212.152] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:44:46 -0000 Received: from [98.139.212.202] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:44:46 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:44:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 944520.67974.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 95609 invoked by uid 60001); 28 Aug 2012 09:44:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1346147086; bh=J2UBjjDreoBDASk3CkPnO8yZuJiGgnQSEkuRikXXL5E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pquUNXZnEszyvBdw8Mp5iDGyfGoTod3ogF+R5NOhRUJ5qs940RPG1IuNqx2h5jLc8N/PEhKmFAJs1gVqahIXeBZsIuC7Hu7DoSI+WBCsFnxTkvbJOGn3I0zoKBvcANCbSeriTMlc7/NYK7ZYMEjSuJN3x13jfROdmto7pd5XIj0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cOyEG/3O33EXsNyAEfHYxjYQ+Hs9E6hMD3HKksCFmzlNODx/2WZ5z6igh9v0yOHTAabnMlKIUSIECvBptzMshO76irsPsoXi55mFNjMMxDsDxhP208Z+fZZa249ofiwuy2mePWWLcyMSaxvg9psTRI0XEYhQlRq8HJ1WbEmSCts=; X-YMail-OSG: 0OgPDeIVM1mWVxJzGOBwmQ4ynK8AlHa.FjgAZ6e26up9wz2 m8ZRpR9AX73Dg13COpRDATStSsjy7p0dWc9vKPFNemNh3T3rF1f2TntXtv1C RLROQnSNHBScRQ7dSmu.SXM0X1oC4MbK3iGsPnREcfzpqvfk.3cpGOeAG3a9 LevPtEAOrFOkyppj5OdbnKf6c3rOHpQpYzcrkH0UGKaisUvBmZfOLBFTcc2r UjXHeLR2Jhocaayfdcew_0Ii9B1VMhdSMYe6Cq4d5kC4Uwzly0hUBnBR56i5 FpCX.KJOoBE.4LMG_H6YKAAL8LhWpe2B6F_r2biVjZdBcr5vv46L_aDmyOH. aVdUTYgNwaLcU4erTXElCVdzpgR9M4fEWv9350qgGB7jiEel1h7xqV._Qizn 4WsKYzD39JyeI7IxaVzZy7c.F7fwYAGT8yx842xmrmUp9eSOwb9dc0Pmxx.f B24EIcteiTR2cF7015I6D3SL84z7wHw_tkZjOPtAp0E_vc3wGZja1kPNypUq 2AdM- Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 02:44:45 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC681D92E1A@SRVHKE02.rdm.cz> Message-ID: <1346147085.59089.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 02:44:45 -0700 (PDT) From: Mark ZZZ Smith To: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= , Mikael Abrahamsson , "Hemant Singh \(shemant\)" In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC681D92E1A@SRVHKE02.rdm.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:44:48 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: V=C3=ADzdal Ale=C5=A1 =0A> To: Mikael Abrahamsson ; Hema= nt Singh (shemant) =0A> Cc: "v6ops@ietf.org" =0A> Sent: Tuesday, 28 August 2012 6:35 PM=0A> Subject: Re: [v6ops] si= ngle /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt=0A> =0A>> -----Ori= ginal Message-----=0A>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces= @ietf.org] On Behalf Of =0A> Mikael=0A>> Abrahamsson=0A>> Sent: Tuesday, = August 28, 2012 9:55 AM=0A>> To: Hemant Singh (shemant)=0A>> Cc: v6ops@ie= tf.org=0A>> Subject: Re: [v6ops] single /64, ND Proxy, and =0A> draft-ietf= -v6ops-464xlat-07.txt=0A>> =0A>> On Mon, 27 Aug 2012, Hemant Singh (sheman= t) wrote:=0A>> =0A>> > Thanks for the details in your other email.=C2=A0 T= he UE will still need to=0A>> > proxy the RA from the service provider to = the wlan0 segment of the UE.=0A>> > Further an NS arrives at cell0 from th= e service provider.=C2=A0 The UE will=0A>> > also have to proxy this NS.= =C2=A0 Thus there is no getting around the ND=0A>> > Proxy.=0A>> =0A>> Th= e UE can/will get its address through other means than RA. In production=0A= >> right now are devices that get their /64 by means of 3GPP signalling = =0A> "out=0A>> of band", and then just point default at the rmnet0 device.= =0A> =0A> Hmm, the 3GPP specs are making SLAAC mandatory and the device sha= ll use=0A> it, I cannot find a reference to what you're describing in the s= pec. It =0A> looks that =0A> the devices you have a behaving 'non-standard'= , but it is right the 3GPP =0A> out-of-band=0A> signalling can provide the = UE with all the necessary IP configuration. =0A> (IPv6 prefix, DNS resolver= s, link-local IID).=0A>=C2=A0=0A=0AThe shame of that approach (and it's the= reason why IPv6CP in PPP doesn't do it=C2=A0any more), is that the option = set becomes constrained to what ever the link layer signalling protocol cur= rently supports. If they'd stuck with the IPv6 approach of using DHCPv6 ove= r the top of the once both the link and basic IPv6 had been established, th= en what ever current and future options the DHCPv6 server and DHCPv6 client= on the UE supported would automatically be "supported" by the link layer, = without the link layer signalling specs needing to be revised, and firmware= updates to the GGSN to provide the new option being deployed. The GGSN wou= ld act as a DHCPv6 relay, which makes it current and future DHCPv6 option t= ransparent.=0A=0A=0A=0A>> During my testing, 2 out of 4 tested devices wor= ked fine without seeing RA=0A>> from the GGSN at all.=0A> =0A> Interesting= , thanks for sharing.=0A> =0A>> --=0A>> Mikael Abrahamsson=C2=A0 =C2=A0 e= mail: swmike@swm.pp.se=0A>> ______________________________________________= _=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/= mailman/listinfo/v6ops=0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops=0A> From pkern@hub.kern.lc Tue Aug 28 02:43:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA421F84F1 for ; Tue, 28 Aug 2012 02:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.045 X-Spam-Level: X-Spam-Status: No, score=-5.045 tagged_above=-999 required=5 tests=[AWL=1.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTGjDr079Lgw for ; Tue, 28 Aug 2012 02:43:06 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [141.0.20.193]) by ietfa.amsl.com (Postfix) with ESMTP id 6865721F84E4 for ; Tue, 28 Aug 2012 02:43:06 -0700 (PDT) Received: from pkern by hub.kern.lc with local (Exim 4.80) (envelope-from ) id 1T6IJ9-0006sg-Fc for v6ops@ietf.org; Tue, 28 Aug 2012 11:42:03 +0200 Date: Tue, 28 Aug 2012 11:42:03 +0200 From: Philipp Kern To: v6ops WG Message-ID: <20120828094203.GA26433@hub.kern.lc> References: <503B226D.3020205@redpill-linpro.com> <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> <503C75D3.6030305@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Philipp Kern Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:48:33 -0000 On Tue, Aug 28, 2012 at 10:28:27AM +0200, Mikael Abrahamsson wrote: > As an operator, IPv6+NAT64+DNS64 is a no-go due to apps/programs not > using dns and/or IPv6 APIs. > > There needs to be a way for a program to call a IPv4 literal and > this would properly get sent over the IPv6 only access and > translated in the NAT64 gateway for IPv4 connectivity. That's not confined to the mobile space, too. I wish Linux, for instance, could be told the NAT64 prefix and transparently convert IPv4 access to IPv6 on the client side. That would also solve the IPv4 literal embedding problem. Kind regards Philipp Kern From swmike@swm.pp.se Tue Aug 28 03:16:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1334911E80FE for ; Tue, 28 Aug 2012 03:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKy-I5qXS42H for ; Tue, 28 Aug 2012 03:16:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7764411E80D9 for ; Tue, 28 Aug 2012 03:16:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3A5999C; Tue, 28 Aug 2012 12:16:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 370F09A; Tue, 28 Aug 2012 12:16:17 +0200 (CEST) Date: Tue, 28 Aug 2012 12:16:17 +0200 (CEST) From: Mikael Abrahamsson To: Philipp Kern In-Reply-To: <20120828094203.GA26433@hub.kern.lc> Message-ID: References: <503B226D.3020205@redpill-linpro.com> <39D105ED-9AFC-4F0B-BF13-FF21FA037CD7@cisco.com> <503C75D3.6030305@redpill-linpro.com> <20120828094203.GA26433@hub.kern.lc> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 10:16:19 -0000 On Tue, 28 Aug 2012, Philipp Kern wrote: > That's not confined to the mobile space, too. I wish Linux, for > instance, could be told the NAT64 prefix and transparently convert IPv4 > access to IPv6 on the client side. That would also solve the IPv4 > literal embedding problem. Yes, 464XLAT is definitely applicable to Windows as well. There are a *lot* of software that doesn't work in the v6+NAT64/DNS64 scenario. -- Mikael Abrahamsson email: swmike@swm.pp.se From jrmitche@puck.nether.net Tue Aug 28 06:02:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885EF21F8557; Tue, 28 Aug 2012 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAXhPhEBhWrb; Tue, 28 Aug 2012 06:02:30 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7621F8552; Tue, 28 Aug 2012 06:02:29 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q7SD2TCK002770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 09:02:29 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q7SD2SQF002769; Tue, 28 Aug 2012 09:02:28 -0400 Date: Tue, 28 Aug 2012 09:02:28 -0400 From: Jon Mitchell To: Randy Bush Message-ID: <20120828130228.GA839@puck.nether.net> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120820152248.GA20997@puck.nether.net> <20120827132818.GA17806@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 28 Aug 2012 09:02:29 -0400 (EDT) Cc: idr wg , v6ops list Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:02:30 -0000 On Tue, Aug 28, 2012 at 09:29:34AM +0700, Randy Bush wrote: > > Sure, RFC2270 seems to be one reasonable solution for the use case of an > > ISP providing ASNs to single homed customers that do not require route > > connectivity to each other except via default, and yes, I'm aware of it > > and seen it deployed at multiple places I've worked. Of course, the > > unsaid thing in this draft is that using a seperate (private) ASN per > > customer site was not viable due to limited private use ASN space > > 2270 is widely deployed. i have not run across the case where we wanted > more than one private asn. any sane provider is doing templated or > generated config, and using a single asn is simpler and just works. > > i am sure i can dream up convoluted uses for a mass of as numbers. but > what i can not do is come up with convoluted case which is worth the end > run on having good registration of the use/assignment of those asns. I agreed that this seems like a fine use case for a single ASN at the top of the thread, but I guess the convulted use cases you mention here include the rest of my email which specify why using a single private ASN in a large single organization (not an ISP) with many sites that may need to connect to each other (not always through one central AS) would not be optimal, hence you choose not to respond to that part. I think we've also determined you are not supportive of the use of private ASNs at this point and that you believe every use case is similar enough to RFC2270 or a network design you believe is convulted. I'm not sure continuing debate will do much to change either of our positions. I think the quote you replied to David with would have fit better if I was proposing a change in protocols or how to design networks, when this draft does neither. What it does propose is expanding the range of available asn numbers for private use, a commonly used numbering resource, in a extremely large available pool. I admit this may not pertain to a use case you are familiar with. Jon From shemant@cisco.com Tue Aug 28 07:24:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FC511E80F2 for ; Tue, 28 Aug 2012 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOCRoKzA4Jha for ; Tue, 28 Aug 2012 07:24:52 -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 77C7811E808D for ; Tue, 28 Aug 2012 07:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=780; q=dns/txt; s=iport; t=1346163892; x=1347373492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JIBB1cKbkXmQ9GPW0X80RrhH4UaUZA0Wul6hZ1b73L0=; b=G0TRI/BNiaCa6aGwFPDFzz/AJbhMoE8lyTP3d80yzhASKny5qgnC20PJ +nJMCD+9MForfRf22VpJDhveD/FV6tVjhSMGT5AF4fzLIf9TsoFpxmCKb lwsPMNBoOCnZTflSAuOTQQVQohRjmCvFojdT21PhQV52bBRfTlwNdeclM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHTUPFCtJXG9/2dsb2JhbABFhTy1LoEHgiABAQEEEgEnPwwEAgEIDgMEAQELFAkHMhQJCAIEDgUIGodrm0qgQYsIhXlgA6QEgWeCYw X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116003160" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 28 Aug 2012 14:24:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SEOjdB019685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 14:24:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 09:24:44 -0500 From: "Hemant Singh (shemant)" To: Mikael Abrahamsson Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtryqAgAAPgwCAAALRgP//0K+wgAGelQCAABiMsA== Date: Tue, 28 Aug 2012 14:24:43 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907AD3B@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--26.227000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:24:53 -0000 Mikael, -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, August 28, 2012 3:55 AM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Mark ZZZ Smith; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >The UE can/will get its address through other means than RA. In production= =20 >right now are devices that get their /64 by means of 3GPP signalling "out= =20 >of band", and then just point default at the rmnet0 device. >During my testing, 2 out of 4 tested devices worked fine without seeing RA= =20 >from the GGSN at all. The xlat document has referenced RFC 6459 which mandates the UE use SLACC a= nd the RA from the SP. See section 5.2 of RFC 6459. Hemant From shemant@cisco.com Tue Aug 28 07:31:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7921F8494 for ; Tue, 28 Aug 2012 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8vHc-Cu6J9y for ; Tue, 28 Aug 2012 07:31:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7370621F8469 for ; Tue, 28 Aug 2012 07:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=977; q=dns/txt; s=iport; t=1346164277; x=1347373877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W2mWlWqHbLi+nXqjzwJHM3+Te6GZE9TCN2ADBPXYqLg=; b=ik65aG443u8u8iGOYsJZzSjbFCwG1WcuE3jO4AmKH8tWgRR4tFQoL91u vYn2x1Y2IG0WbjwqNBurgt4VYxV/2usG47wjQ3ZfgMD94O9HS4+aJYodB Zr+MGkrzQxsDEzNMQ6YcZkicIDMcv5jBkoSDOKujuukyHEZZzro0ZfIQF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMnVPFCtJXG9/2dsb2JhbABFhTy1LoEHgiABAQEEEgEnPwwEAgEIEQQBAQsUCQchERQJCAIEDgUIEweHXAMMm0uWZw2JToolY4V5YAOUA4xhgyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116053325" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2012 14:31:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SEV9xI026436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 14:31:09 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 09:31:08 -0500 From: "Hemant Singh (shemant)" To: jouni korhonen Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtiH+AgAARL+CAAaiiAIAAB6Lg Date: Tue, 28 Aug 2012 14:31:07 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907AD6C@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--21.142200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:31:18 -0000 Jouni, -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Tuesday, August 28, 2012 4:58 AM To: Hemant Singh (shemant) Cc: Victor Kuarsingh; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Agree on your sentiment of the user behavior. I must be missing something = here. Is=20 >your assumption that both mobiles and CPE's bridge would automatically als= o join a >mesh/wds type of setup? That would be a board assumption imho. I just made the case for one mis-configured tethered network that includes = a bridge behind a wireless router that loops all traffic back to the CPE ro= uter who sends the traffic to the Wi-Fi link of the UE. Now that I know ho= w to shutdown ND Proxy on the CLAT, all I have to do is send an RA to the W= i-Fi link of the UE and the tethered service is disabled.=20 A better solution is to have the UE support DHCPv6-PD.=20 Hemant From shemant@cisco.com Tue Aug 28 07:47:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA4C21F84F9 for ; Tue, 28 Aug 2012 07:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O16H0uAgCB6W for ; Tue, 28 Aug 2012 07:47:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8513221F84BF for ; Tue, 28 Aug 2012 07:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6221; q=dns/txt; s=iport; t=1346165258; x=1347374858; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7UbmBNbchR8kYkBfTO+hTie41NmFqjdx8EsA00bebmo=; b=KPUnMNYQc1ptr44IkqhYHDmYt6VzCCtatuJRmBYYFlSHIVjDLcNhXoDz Uwg3i2+3a+j0eYXw5Q/hHI84rDpDdMusEuOl511/aA1FpK9TPv7PeD0XK qZ/o00o07bFfFP9AFiCcHaoM6D9TG2co/aXm6qwmpoDy/htAFxnF3zgfG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ/ZPFCtJV2b/2dsb2JhbABFgkq4IIEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIGodrm1CgRosIhXlgA4gam2qBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208,217";a="116016139" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 28 Aug 2012 14:47:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7SElUWo007272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 14:47:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 09:47:30 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgIAAzpgAgABe5VA= Date: Tue, 28 Aug 2012 14:47:29 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--31.021400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B8907ADA2xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:47:40 -0000 --_000_75B6FA9F576969419E42BECB86CB1B8907ADA2xmbrcdx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lorenzo, From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Monday, August 27, 2012 11:56 PM To: Hemant Singh (shemant) Cc: R=E9mi Despr=E9s; Cameron Byrne; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Wait... so you're saying that when the user enables tethering, he needs to= manually reset the hosts on the LAN? I think that's unreasonable, and a ba= d user experience. If that's the best we can do, >we should give up and rem= ove all text describing mention of how to share the CLAT's /64 with its cli= ents. It is an interesting situation. A Wi-Fi host in the LAN segment is active= with only the link-local address because the host hasn't seen any RA. La= ter, the CLAT UE powers up and gets operational and issues an RA in the LAN= segment of the CLAT. The host receives the RA and acquires a global IPv6 = address using SLAAC or DHCPv6 and issues a NS(DAD) for the global IPv6 addr= ess. No DAD operation is invoked for the link-local address which could b= e duplicate with the CLAT LAN interface link-local. That is why a reset o= f the tethered host makes sense so that the CLAT sees both the link-local a= nd the global IPv6 address of the host. Hemant --_000_75B6FA9F576969419E42BECB86CB1B8907ADA2xmbrcdx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lorenzo,

 <= /p>

From: Lorenzo = Colitti [mailto:lorenzo@google.com]
Sent: Monday, August 27, 2012 11:56 PM
To: Hemant Singh (shemant)
Cc: R=E9mi Despr=E9s; Cameron Byrne; v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464x= lat-07.txt

 

>Wait... so = you're saying that when the user enables tethering, he needs to manually re= set the hosts on the LAN? I think that's unreasonable, and a bad user exper= ience. If that's the best we can do, >we should give up and remove all t= ext describing mention of how to share the CLAT's /64 with its clients.

 <= /p>

It is an interesting situ= ation.  A Wi-Fi  host in the LAN segment is active with only the = link-local address because the host hasn’t seen any RA.   L= ater, the CLAT UE powers up and gets operational and issues an RA in the LAN segment= of the CLAT.  The host receives the RA and acquires a global IPv6 add= ress using SLAAC or DHCPv6 and issues a NS(DAD) for the global IPv6 address= .   No DAD operation is invoked for the link-local address which could be duplicate with the CLAT LAN interface li= nk-local.   That is why a reset of the tethered host makes sense = so that the CLAT sees both the link-local and the global IPv6 address of th= e host.

 <= /p>

Hemant

--_000_75B6FA9F576969419E42BECB86CB1B8907ADA2xmbrcdx06ciscocom_-- From ales.vizdal@t-mobile.cz Tue Aug 28 07:58:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E921F8554 for ; Tue, 28 Aug 2012 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFMj+piWeE7U for ; Tue, 28 Aug 2012 07:58:49 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 38C6521F854F for ; Tue, 28 Aug 2012 07:58:49 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 69FB3285831; Tue, 28 Aug 2012 16:58:48 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 28 Aug 2012 16:58:34 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Hemant Singh (shemant)" , jouni korhonen Date: Tue, 28 Aug 2012 16:58:31 +0200 Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtiH+AgAARL+CAAaiiAIAAB6LggAAIs0A= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D93045@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907AD6C@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907AD6C@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:58:50 -0000 Hemant, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Hemant > Singh (shemant) > Sent: Tuesday, August 28, 2012 4:31 PM > To: jouni korhonen > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 > Jouni, >=20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Tuesday, August 28, 2012 4:58 AM > To: Hemant Singh (shemant) > Cc: Victor Kuarsingh; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 > >Agree on your sentiment of the user behavior. I must be missing somethin= g here. Is > >your assumption that both mobiles and CPE's bridge would automatically a= lso join a > >mesh/wds type of setup? That would be a board assumption imho. >=20 > I just made the case for one mis-configured tethered network that include= s a bridge > behind a wireless router that loops all traffic back to the CPE router wh= o sends the > traffic to the Wi-Fi link of the UE. Now that I know how to shutdown ND = Proxy on the > CLAT, all I have to do is send an RA to the Wi-Fi link of the UE and the = tethered > service is disabled. >=20 > A better solution is to have the UE support DHCPv6-PD. the UE wouldn't be much of an issue, but the network support for IPv6 and s= ubsequently for PD ... I am sorry, but tethering using /64 will be required and will become a real= ity in mobile. > Hemant Ales From ales.vizdal@t-mobile.cz Tue Aug 28 08:00:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4EE21F8559 for ; Tue, 28 Aug 2012 08:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.716 X-Spam-Level: X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccfisWNBDgyw for ; Tue, 28 Aug 2012 08:00:37 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8B48B21F854B for ; Tue, 28 Aug 2012 08:00:37 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C9E94285828; Tue, 28 Aug 2012 17:00:36 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 28 Aug 2012 17:00:36 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: jouni korhonen , Mikael Abrahamsson Date: Tue, 28 Aug 2012 17:00:33 +0200 Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: Ac2E+FBkh9SiQ4xbRgWJTLyuH6C1JgANU7QQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D93046@SRVHKE02.rdm.cz> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1346061020.66528.YahooMailNeo@web32508.mail.mud.yahoo.com> <75B6FA9F576969419E42BECB86CB1B890782C0@xmb-rcd-x06.cisco.com> <223B08D9-2FA7-41D6-8678-775B770A3A5E@gmail.com> In-Reply-To: <223B08D9-2FA7-41D6-8678-775B770A3A5E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:00:38 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= jouni > korhonen > Sent: Tuesday, August 28, 2012 10:36 AM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-0= 7.txt >=20 >=20 > On Aug 28, 2012, at 10:54 AM, Mikael Abrahamsson wrote: >=20 > > On Mon, 27 Aug 2012, Hemant Singh (shemant) wrote: > > > >> Thanks for the details in your other email. The UE will still need to= proxy the RA > from the service provider to the wlan0 segment of the UE. Further an NS a= rrives at > cell0 from the service provider. The UE will also have to proxy this NS.= Thus there is > no getting around the ND Proxy. > > > > The UE can/will get its address through other means than RA. In product= ion right > now are devices that get their /64 by means of 3GPP signalling "out of ba= nd", and then > just point default at the rmnet0 device. > > > > During my testing, 2 out of 4 tested devices worked fine without seeing= RA from the > GGSN at all. >=20 > Relying on NAS signaling to provide the prefix is non standard.. may work= for 3G but will > fail in LTE. It may work in 3G, but it clearly violates the 3GPP TS29.061 v10.6.0, secti= on 11.2.1.3.2 where it says: 5x.The Attach Accept message will be sent along to the UE without the IPv6 = prefix. The UE shall ignore the IPv6 prefix if it receives one in the messa= ge. Ales =20 > - Jouni >=20 >=20 > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se From despres.remi@laposte.net Tue Aug 28 08:04:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EAC21F8545 for ; Tue, 28 Aug 2012 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4sLSMI-1EVt for ; Tue, 28 Aug 2012 08:04:10 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF321F854B for ; Tue, 28 Aug 2012 08:04:09 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 1A2C270000FD; Tue, 28 Aug 2012 17:04:07 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 816557000047; Tue, 28 Aug 2012 17:04:06 +0200 (CEST) X-SFR-UUID: 20120828150406530.816557000047@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-52-639342384 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> Date: Tue, 28 Aug 2012 17:04:06 +0200 Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:04:12 -0000 --Apple-Mail-52-639342384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-08-28 =E0 16:47, Hemant Singh (shemant) a =E9crit : > Lorenzo, > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Monday, August 27, 2012 11:56 PM > To: Hemant Singh (shemant) > Cc: R=E9mi Despr=E9s; Cameron Byrne; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt > =20 > >Wait... so you're saying that when the user enables tethering, he = needs to manually reset the hosts on the LAN? I think that's = unreasonable, and a bad user experience. If that's the best we can do, = >we should give up and remove all text describing mention of how to = share the CLAT's /64 with its clients. > =20 > It is an interesting situation. A Wi-Fi host in the LAN segment is = active with only the link-local address because the host hasn=92t seen = any RA. Later, the CLAT UE powers up and gets operational and issues = an RA in the LAN segment of the CLAT. The host receives the RA and = acquires a global IPv6 address using SLAAC or DHCPv6 and issues a = NS(DAD) for the global IPv6 address. =20 > No DAD operation is invoked for the link-local address which could be = duplicate with the CLAT LAN The CLAT-node downstream address is either EUI-64, which shouldn't = conflict with that of any host on the LAN, or is local scope, in which = case it should be subject to DAD before being confirmed. In any case, none of thee addresses can conflict with the CLAT upstream = address if this address has the CLAT-reserved IID. RD > interface link-local. That is why a reset of the tethered host makes = sense so that the CLAT sees both the link-local and the global IPv6 = address of the host. > =20 > Hemant --Apple-Mail-52-639342384 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Lorenzo Colitti = [mailto:lorenzo@google.com] 
Sent: Monday, August 27, 2012 = 11:56 PM
To: Hemant Singh = (shemant)
Cc: R=E9mi Despr=E9s; Cameron = Byrne; v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND = Proxy, and = draft-ietf-v6ops-464xlat-07.txt
 
 >we should give up and = remove all text describing mention of how to share the CLAT's /64 with = its clients.It is = an interesting situation.  A Wi-Fi  host in the LAN segment is = active with only the link-local address because the host hasn=92t seen = any RA.   Later, the CLAT UE powers up and gets operational = and issues an RA in the LAN segment of the CLAT.  The host receives = the RA and acquires a global IPv6 address using SLAAC or DHCPv6 and = issues a NS(DAD) for the global IPv6 address.  =  

No = DAD operation is invoked for the link-local address which could be = duplicate with the CLAT LAN =


The CLAT-node downstream address is either EUI-64, = which shouldn't conflict with that of any host on the LAN, or is local = scope, in which case it should be subject to DAD before being = confirmed.

In any case, none of thee addresses = can conflict with the CLAT upstream address if this address has the = CLAT-reserved = IID.

RD



To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , jouni korhonen Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtiH+AgAARL+CAAaiiAIAAB6LggAAIs0CAAAInoA== Date: Tue, 28 Aug 2012 15:11:38 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907ADF2@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907AD6C@xmb-rcd-x06.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC681D93045@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC681D93045@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--29.580600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:11:41 -0000 Vizdal, -----Original Message----- From: V=EDzdal Ale=B9 [mailto:ales.vizdal@t-mobile.cz]=20 Sent: Tuesday, August 28, 2012 10:59 AM To: Hemant Singh (shemant); jouni korhonen Cc: v6ops@ietf.org Subject: RE: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >the UE wouldn't be much of an issue, but the network support for IPv6 and = subsequently for PD ... >I am sorry, but tethering using /64 will be required and will become a rea= lity in mobile. No apologies needed. Go ahead and use ND Proxy as I and Cameron (remove an= y reference to RFC 4389) have proposed for text in a re-worked section 8.3.= 2 which was: "The CLAT uses an ND Proxy to share the single /64 prefix between the LAN a= nd WAN segments." In another email I had proposed one other sentence to note a pitfall with u= se of ND Proxy. Maybe we can add that text too and the new text looks as f= ollows: "The CLAT uses an ND Proxy to share the single /64 prefix between the LAN a= nd WAN segments. Note any loop in the CLAT tethered network may cause the = ND Proxy on the UE to be disabled." Regards, Hemant From shemant@cisco.com Tue Aug 28 08:38:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09A11E80F6 for ; Tue, 28 Aug 2012 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMq953U4Vu8r for ; Tue, 28 Aug 2012 08:38:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CFCD521F849C for ; Tue, 28 Aug 2012 08:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5551; q=dns/txt; s=iport; t=1346168294; x=1347377894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xkbsYY2HpY1htnExnBp6JdUW1R6nuz+sTiDWhoxqnwI=; b=ZeONv2qvjUzdn8+RfScQvSTnqspYDZaaYp2RMhHRsrzVO5Dz14ALhFmr 7YCCW6ZOGMU4TmWIqF8DJLtcR8Q0+f5TrVc+OllTUYKneI0/5vlIUsypC Id9bwkHbxMes8RhqJ5MvPzF7CHFoY71IcFIjfcbjwINW77UE/kRyMDVYn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMzkPFCtJXG9/2dsb2JhbABFgkq4IYEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIGodcAwybYZZvE4lIiwiFeWADiBqbaoFngmM X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208,217";a="113033007" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 28 Aug 2012 15:38:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SFcEED029576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 15:38:14 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 10:38:14 -0500 From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgIAAzpgAgABe5VCAAFvgAP//tOtA Date: Tue, 28 Aug 2012 15:38:12 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907AFC4@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--27.577800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B8907AFC4xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:38:15 -0000 --_000_75B6FA9F576969419E42BECB86CB1B8907AFC4xmbrcdx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Remi, From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] Sent: Tuesday, August 28, 2012 11:04 AM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Cameron Byrne; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >The CLAT-node downstream address is either EUI-64, which shouldn't conflic= t with that of any host on the LAN, or is local scope, in which case it sho= uld be subject to DAD before being >confirmed. This thread has already discussed that even with EUI-64, due to bad hardwar= e, even EUI-64 compliant link-local addresses can clash. Since the host is= up and running with a link-local before the CLAT UE is up, the host does n= ot perform DAD for the link-local. Hemant --_000_75B6FA9F576969419E42BECB86CB1B8907AFC4xmbrcdx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Remi,

 <= /p>

From: R=E9mi D= espr=E9s [mailto:despres.remi@laposte.net]
Sent: Tuesday, August 28, 2012 11:04 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Cameron Byrne; v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464x= lat-07.txt

 

 

>The CLAT-no= de downstream address is either EUI-64, which shouldn't conflict with that = of any host on the LAN, or is local scope, in which case it should be subje= ct to DAD before being >confirmed.

 

This thread has already d= iscussed that even with EUI-64, due to bad hardware, even EUI-64 compliant = link-local addresses can clash.  Since the host is up and running with a link-local before the CLAT UE is up, the host does not perf= orm DAD for the link-local.

 <= /p>

Hemant<= /p>

 <= /p>

--_000_75B6FA9F576969419E42BECB86CB1B8907AFC4xmbrcdx06ciscocom_-- From despres.remi@laposte.net Tue Aug 28 08:51:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4021F8566 for ; Tue, 28 Aug 2012 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFBcmfQMv5yW for ; Tue, 28 Aug 2012 08:51:27 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id B255321F855E for ; Tue, 28 Aug 2012 08:51:26 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 95CCC7001ABC; Tue, 28 Aug 2012 17:51:25 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 123907001AB6; Tue, 28 Aug 2012 17:51:24 +0200 (CEST) X-SFR-UUID: 20120828155125747.123907001AB6@msfrf2306.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-53-641913792 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907AFC4@xmb-rcd-x06.cisco.com> Date: Tue, 28 Aug 2012 17:46:57 +0200 Message-Id: <5EE0CE6B-1069-491A-9939-927703A88AE9@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907AFC4@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:51:28 -0000 --Apple-Mail-53-641913792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-28 =E0 17:38, Hemant Singh (shemant) a =E9crit : > Remi, > =20 > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 > Sent: Tuesday, August 28, 2012 11:04 AM > To: Hemant Singh (shemant) > Cc: Lorenzo Colitti; Cameron Byrne; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt > =20 > =20 > >The CLAT-node downstream address is either EUI-64, which shouldn't = conflict with that of any host on the LAN, or is local scope, in which = case it should be subject to DAD before being >confirmed. > =20 > This thread has already discussed that even with EUI-64, due to bad = hardware, even EUI-64 compliant link-local addresses can clash.=20 Sure, two EUI-64 with the same embedded MAC address can clash, but this = has nothing to do with 464XLAT. Not sure what you are trying to explain here. (The point of the = CLAT-reserved IID is to prevent any possible clash with LAN hosts having = good hardware and software.) RD > Since the host is up and running with a link-local before the CLAT UE = is up, the host does not perform DAD for the link-local. > =20 > Hemant > =20 --Apple-Mail-53-641913792 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
From: R=E9mi Despr=E9s = [mailto:despres.remi@laposte.net] 
Sent: Tuesday, August 28, 2012 = 11:04 AM
To: Hemant Singh = (shemant)
Cc: Lorenzo Colitti; Cameron = Byrne; v6ops@ietf.org
Subject: Re: [v6ops] single /64, ND = Proxy, and = draft-ietf-v6ops-464xlat-07.txt
 
 
 This = thread has already discussed that even with EUI-64, due to bad hardware, = even EUI-64 compliant link-local addresses can clash.  =

Sure, two EUI-64 with the same embedded MAC address can clash, but = this has nothing to do with 464XLAT.
Not sure what you are = trying to explain here. (The point of the CLAT-reserved IID is to = prevent any possible clash with LAN hosts having good hardware and = software.)

RD

Since the = host is up and running with a link-local before the CLAT UE is up, the = host does not perform DAD for the = link-local.
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:26:33 -0000 Hemant, > -----Original Message----- > From: V=C3=ADzdal Ale=C5=A1 [mailto:ales.vizdal@t-mobile.cz] > Sent: Tuesday, August 28, 2012 10:59 AM > To: Hemant Singh (shemant); jouni korhonen > Cc: v6ops@ietf.org > Subject: RE: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt > > >>the UE wouldn't be much of an issue, but the network support for IPv6 and >> subsequently for PD ... >>I am sorry, but tethering using /64 will be required and will become a >> reality in mobile. > > No apologies needed. Go ahead and use ND Proxy as I and Cameron (remove = any > reference to RFC 4389) have proposed for text in a re-worked section 8.3.= 2 > which was: > > "The CLAT uses an ND Proxy to share the single /64 prefix between the LAN > and WAN segments." > > In another email I had proposed one other sentence to note a pitfall with > use of ND Proxy. Maybe we can add that text too and the new text looks a= s > follows: > > "The CLAT uses an ND Proxy to share the single /64 prefix between the LAN > and WAN segments. Note any loop in the CLAT tethered network may cause t= he > ND Proxy on the UE to be disabled." Since the reference of RFC4389 is likely removed, I'm not sure why we should note the loop issue here. BRs Gang > Regards, > > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Tue Aug 28 09:43:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD0721F844E for ; Tue, 28 Aug 2012 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmCjGpJzRPQH for ; Tue, 28 Aug 2012 09:43:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8279A21F844D for ; Tue, 28 Aug 2012 09:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=658; q=dns/txt; s=iport; t=1346172185; x=1347381785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5dqlSBJZk6dAORxXHsGmYTw2EnHSWr4PmK4huCAkkfg=; b=MUOjn4BIfoJdowHD5mp+R5EgMNBzeFIFH5K26vrPug6TRLfSYYxuVeTS 8kVVzzbXkT1Njv7JAq8DJjFn2ZnZJHkyGoIduxi75VYrGAPtwalTtpwXM bGSHcZCr4UQ/P4UqrXleMnmlFE8rg5xx2CbLXcya/I78L1ilgUiHKVrhm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAI/0PFCtJXG8/2dsb2JhbABFhTxHs31ugQeCIAEBAQQSARARRQwEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQgah1wDDJtGjRiJVg2JToEhiQRjhUcyYAOUA4xhgyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116106128" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 28 Aug 2012 16:43:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7SGh5Ic025460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 16:43:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 11:43:04 -0500 From: "Hemant Singh (shemant)" To: GangChen Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNg/CpQ3F2alww0U20biBJJmepq5dtiH+AgAARL+CAAaiiAIAAB6LggAAIs0CAAAInoIAAauYA//+wcSA= Date: Tue, 28 Aug 2012 16:43:02 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907B0C6@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <1649C8F5-EA89-43B2-9AAB-FBE295A1EFD3@gmail.com> <75B6FA9F576969419E42BECB86CB1B890783DD@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907AD6C@xmb-rcd-x06.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC681D93045@SRVHKE02.rdm.cz> <75B6FA9F576969419E42BECB86CB1B8907ADF2@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.174] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--27.938900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:43:06 -0000 R2FuZywNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEdhbmdDaGVuIFttYWls dG86cGhkZ2FuZ0BnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgQXVndXN0IDI4LCAyMDEyIDEy OjI3IFBNDQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KQ2M6IFbDrXpkYWwgQWxlxaE7IGpv dW5pIGtvcmhvbmVuOyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gc2luZ2xl IC82NCwgTkQgUHJveHksIGFuZCBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtMDcudHh0DQoNCg0K PlNpbmNlIHRoZSByZWZlcmVuY2Ugb2YgUkZDNDM4OSBpcyBsaWtlbHkgcmVtb3ZlZCwgSSdtIG5v dCBzdXJlIHdoeSB3ZQ0KPnNob3VsZCBub3RlIHRoZSBsb29wIGlzc3VlIGhlcmUuDQoNCk9rLCBn cmVhdCBwb2ludCBmcm9tIHlvdS4gIFdlIGNhbiByZW1vdmUgdGhlIGxvb3AgaXNzdWUgdGhlbi4g IA0KDQpUaGFua3MsDQoNCkhlbWFudA0K From shemant@cisco.com Tue Aug 28 12:31:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E143821F861A for ; Tue, 28 Aug 2012 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4QUb0NAZddo for ; Tue, 28 Aug 2012 12:31:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0D21F85A0 for ; Tue, 28 Aug 2012 12:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1255; q=dns/txt; s=iport; t=1346182301; x=1347391901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5OJFUotMOwkD6RWn5AFcSAGA4fYM5YxofhG85Fw/6oI=; b=l94dl2BPLGtEuZjRe75rlm8xtocgwfwaomCmy9kyz+kEC0ktP132RBTU j8VN1Gz01VhgXm5SDoLIHWfqpJXjoiqKK7bafot6xGkONY07zRUDqhmqF 5EJrGEaQaybv8y77dkadmvRYiUqfj4nWlIoHJZ6PCVnn/VOdk3YOZ+HTU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANgbPVCtJXHB/2dsb2JhbABFunCBB4IgAQEBBBIBZgwEAgEIEQQBAQsdBzIUCQgCBA4FCBMHh1wDDJtxlnMTiUiLCIV5YAOIGptqgWeCYw X-IronPort-AV: E=Sophos;i="4.80,328,1344211200"; d="scan'208";a="113113555" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 28 Aug 2012 19:31:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7SJVesG005505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 19:31:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 14:31:40 -0500 From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgIAAeJ4A//+xJ+CAAOb2AIAAXGfg Date: Tue, 28 Aug 2012 19:31:39 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907B167@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.174] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19146.001 x-tm-as-result: No--29.300700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:31:42 -0000 Remi, -----Original Message----- From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 Sent: Tuesday, August 28, 2012 3:52 AM To: Hemant Singh (shemant) Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >1. Please note that it isn't an IID "range" that is reserved, only an IID = value The IANA section of the xlat document lists two IID values and that is what= I was referring to as "range" though not completely correctly.=20 >2. SP access networks do assign IIDs that comply with RFC 4291 (local scop= e or MAC-address based EUI-64 IIDs).=20 That is the missing link between us. I thought, why not global scope? If = global scope, then the SP has to check the reserved IID values before confi= guring the network to not use an IPv6 address with an IID that is a reserve= d IID. Thanks for the information on CGA and Privacy addresses that are n= ot global and thus I agree with you, no clash is possible with CGA/Privacy = address vs. a CLAT IID with "u" bit as 1. Another question. Why does the xlat document need another solution for get= ting a /64 to use by CLAT for XLATE when an ND Proxy solution exists? Hemant From lorenzo@google.com Tue Aug 28 17:53:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F0521F8512 for ; Tue, 28 Aug 2012 17:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykEtQR8WLGsW for ; Tue, 28 Aug 2012 17:53:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1754621F84FB for ; Tue, 28 Aug 2012 17:53:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4247obb.31 for ; Tue, 28 Aug 2012 17:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wJ5TOnDXwlY3MPrWKBdbPQo17qtyg6+fEa/TgogW5Po=; b=D9SxeBoOAj0R17RUsHps/vTHgmqKwkLSjOJLw1jVl+Lkgm8CZsPcDPKbsotr++n8YA 9dbrveyrAiXWdvlZtVRaz/y9IEw5JSPnrxaEzI4xSMfbpmjpnCPR+JMszqv0al3w8mWj IPAfuNUwjrurpzHOVe4seRyFpP5LoCfBtbhvY7a6uEIvHIHOnTRwv0BfSpzuH/+5DkXJ nQpsewzbrFvZWn7I2eD/bvM/oN2SWCj7EvNZTisnCVIAkSFV62nQnGS/PrKMsptd44+t VqxijKm2a3i0BZADDOmtX9yTqto/HXMM5sJWGsc+QcDoksBLTBdLTb5PYm33FNupkCbY t3Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wJ5TOnDXwlY3MPrWKBdbPQo17qtyg6+fEa/TgogW5Po=; b=ZPr4BK2FkbFHJAM9Bv0rPQeaWzC6PJ7QI1IQbne0hyPmbFk8eKeiAM2fFNhSBu0SdS kpBcmX0kyw0FDUu1l/fq8sj51oDazvBs6bZD025Q+7H4LCmbij/qOX8wqgnEHm1qJ7fn 7aUps/YUGt8YfSSnbe3JsoYM+A7dUT1dUC/fQNRCybwgMN3NW7g7dO0OO/gWbqKo7rIU DxpawPWjd6IXH2/D0H/gPDXAmpK5gcB62GsJ2Fcoz9DriyB5FWZ1S6j0bVNMfLUcLl7m IdDksBuz9Vwi+7ztbfQEkhA1Lhj51oPJ00pMnXuulu023E8dYssNEsYEAsSfv0HORyCu Pbzg== Received: by 10.182.110.40 with SMTP id hx8mr14017655obb.47.1346201629542; Tue, 28 Aug 2012 17:53:49 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr14017649obb.47.1346201629431; Tue, 28 Aug 2012 17:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 28 Aug 2012 17:53:29 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Wed, 29 Aug 2012 09:53:29 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=f46d044516ddeb16b704c85cfd9e X-System-Of-Record: true X-Gm-Message-State: ALoCoQnyn1xCtRT5gNsn9U/foQ2MqfbxXTBPDJJwysoW+ZkvI1k8oIOfSw/toG9SpCqtBqSLmRgBy2EMz2nJeuqu3+avj6Bv92J1sAhveZ6eE36yqs5wp+At1xeXZ8r3l0qQ1gOUtSmbV3cTaMqnJYD5tRbTevMyvZToirfpoyTmVYYNP2s0Cr6xlSRBQfwJT5dhX1AaFMME Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 00:53:50 -0000 --f46d044516ddeb16b704c85cfd9e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 11:47 PM, Hemant Singh (shemant) wrote: > It is an interesting situation. A Wi-Fi host in the LAN segment is > active with only the link-local address because the host hasn=92t seen an= y > RA. Later, the CLAT UE powers up and gets operational and issues an RA = in > the LAN segment of the CLAT. The host receives the RA and acquires a > global IPv6 address using SLAAC or DHCPv6 and issues a NS(DAD) for the > global IPv6 address. > Which fails if it picked the same IID as the CLAT. Which is working as intended. > No DAD operation is invoked for the link-local address which could be > duplicate with the CLAT LAN interface link-local. > Incorrect. Per RFC 4862 section 5.4, DAD MUST be performed on all unicast addresses, including link-local addresses. > That is why a reset of the tethered host makes sense so that the CLAT > sees both the link-local and the global IPv6 address of the host. > The reason you cite above is invalid. Do you have another reason to say that the host should be reset? --f46d044516ddeb16b704c85cfd9e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 11:47 PM, Hemant Singh (shemant) = <shemant@cisco.co= m> wrote:

It is an interesting situation.=A0 A Wi-Fi = =A0host in the LAN segment is active with only the link-local address becau= se the host hasn=92t seen any RA. =A0=A0Later, the CLAT UE powers up and gets operational and issues an RA in the LAN segment= of the CLAT.=A0 The host receives the RA and acquires a global IPv6 addres= s using SLAAC or DHCPv6 and issues a NS(DAD) for the global IPv6 address.


Which fails if it picked the s= ame IID as the CLAT. Which is working as intended.
=A0

No DAD operation is invoked for the link-local address which could be duplicate with the CLAT LAN interface li= nk-local.


Incorrect.= Per RFC 4862 section 5.4, DAD MUST be performed on all unicast addresses, = including link-local addresses.
=A0

=A0 =A0That is why= a reset of the tethered host makes sense so that the CLAT sees both the li= nk-local and the global IPv6 address of the host.


The reason you cite above is i= nvalid. Do you have another reason to say that the host should be reset?
--f46d044516ddeb16b704c85cfd9e-- From lorenzo@google.com Tue Aug 28 17:57:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B9021F8513 for ; Tue, 28 Aug 2012 17:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGBWWxxxX29K for ; Tue, 28 Aug 2012 17:57:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0441621F8422 for ; Tue, 28 Aug 2012 17:57:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9505obb.31 for ; Tue, 28 Aug 2012 17:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=LRaoKpwewRg+wXYWwSy+GQKCRNx1P/DWrec9w/X8Lc8=; b=Jh66gpAdT6xOlghubfGCdSMrqKdDCxq+mG8feHr/Bv5f8geCXSYh1Lxr1eYk8vCsLT WR815EfFmuCldUID0k3TaI877d7dd2OHzXELbu7DWEttK2IzujxQVK7YgI6v6yyWeIa9 H/NOtrWlFijYPhQSS7KVMXoVZQSOlJoJq23B1OTTAPShZzero6MPunXzxMoYwEL6Ur9a q20UrM6Br0ydFtMstBT9vVFGJCLxM8jXNOBX6m9iF0Lt54j4z4WJ80RTskhnAvHcD82r oZXbgIPcGujnpzvjTOKYKFWJvJPkc0ltqN8rw72d9wwper7Nak37V9OiM6pWFizrYuBz nU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=LRaoKpwewRg+wXYWwSy+GQKCRNx1P/DWrec9w/X8Lc8=; b=YU8MZ2uok36xa3zX/qxC6i2oxgE438eVDQfqwZpDv14Jibw1t7naneA/xgRDMRJScj ltOhwK2RtptJa7c9LNZZl6ETjtfLmW5bLFxCEMb0A9y985fjOTkCmAusKaJDJ/yWiv3a eHVwBQQe4V2Osy90H8QZ++Pvf6KjxM3o1spUdh4Mb7OJvaocwoi/ivzqifBpmD5QfffQ aKzWMkB7DLN8AH4IiZiOo07dNZCXBANvyDgbJdq0aq/PmMUSKErQzI0W/IKUWJ0xzr3w gk/H2CYj2n56rcmAmIX7H9JgUECDOjlLexLgbjlpnWDl6uJJLewoZ+L137dseJZshudC rlOQ== Received: by 10.182.48.8 with SMTP id h8mr13805731obn.75.1346201869590; Tue, 28 Aug 2012 17:57:49 -0700 (PDT) Received: by 10.182.48.8 with SMTP id h8mr13805725obn.75.1346201869471; Tue, 28 Aug 2012 17:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 28 Aug 2012 17:57:29 -0700 (PDT) In-Reply-To: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> From: Lorenzo Colitti Date: Wed, 29 Aug 2012 09:57:29 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=f46d04462fe439d18d04c85d0c3e X-System-Of-Record: true X-Gm-Message-State: ALoCoQk+45eM5/CYu8OnCfWV1fx2UPA0G93ec2oirg77XrbGbDC9Xowu/gqrjvKpmOKfIWz/WCO0RorvycUYAAj7s7KqG3dJYnxR3KGDz09h/JFsfGfdkWlRLGfosJR0PfT14ZBELjAvAAJlnD66F3cSqelyQdZV/9DtAdqkxv+dijBbR/hD83kZuc2cLZaX4siQnZK+W9+x Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 00:57:50 -0000 --f46d04462fe439d18d04c85d0c3e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 29, 2012 at 9:53 AM, Lorenzo Colitti wrote: > Incorrect. Per RFC 4862 section 5.4, DAD MUST be performed on all unicast > addresses, including link-local addresses. > Oh, wait - I see what you mean. You're saying that the host *does* perform DAD for its link-local address, but it does that when the CLAT is not on the link yet. This is still not an issue, for two reasons: 1. If the CLAT is the tethering router, then there is no link until the CLAT comes up, so what you describe cannot happen. 2. The CLAT does not use that IID for its link-local address anyway - it forms the link-local address from its wlan0 EUI-64 IID. So again, I see no need to reset the host. --f46d04462fe439d18d04c85d0c3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2012 at 9:53 AM, Lorenzo Colitti <lorenzo@google.com&= gt; wrote:
Incorrect. Per RFC 4862 section 5.4, DAD MUST be performe= d on all unicast addresses, including link-local addresses.

Oh, wait - I see what you mean. You're saying th= at the host *does* perform DAD for its link-local address, but it does that= when the CLAT is not on the link yet. This is still not an issue, for two = reasons:

1. If the CLAT is the tethering router, then there is n= o link until the CLAT comes up, so what you describe cannot happen.
2. The CLAT does not use that IID for its link-local address anyway - it= forms the link-local address from its wlan0 EUI-64 IID.

So again, I see no need to reset the host.
--f46d04462fe439d18d04c85d0c3e-- From despres.remi@laposte.net Tue Aug 28 23:48:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2811E809C for ; Tue, 28 Aug 2012 23:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZxo9CBswLLc for ; Tue, 28 Aug 2012 23:48:18 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8399711E809A for ; Tue, 28 Aug 2012 23:48:15 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 99F7C940128; Wed, 29 Aug 2012 08:48:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907B167@xmb-rcd-x06.cisco.com> Date: Wed, 29 Aug 2012 08:48:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C87F8A5-A53C-4B41-8A9A-DCAE9D6EAEBD@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907B167@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 06:48:18 -0000 2012-08-28 21:31, Hemant Singh (shemant) : > Remi, >=20 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 > Sent: Tuesday, August 28, 2012 3:52 AM > To: Hemant Singh (shemant) > Cc: Cameron Byrne; Lorenzo Colitti; v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and = draft-ietf-v6ops-464xlat-07.txt >=20 >=20 >> 1. Please note that it isn't an IID "range" that is reserved, only an = IID value >=20 > The IANA section of the xlat document lists two IID values and that is = what I was referring to as "range" though not completely correctly. Two values in -07, yes, but: - IANA being required to keep only one - as suggested in item (1) of = www.ietf.org/mail-archive/web/v6ops/current/msg13856.html, the choice = can be made by IETF in favor of 02-00-5E-10-00-00-00-00 (value used in = the Appendix) before its request to IANA. >> 2. SP access networks do assign IIDs that comply with RFC 4291 (local = scope or MAC-address based EUI-64 IIDs).=20 >=20 > That is the missing link between us. I thought, why not global scope? = If global scope, then the SP has to check the reserved IID values = before configuring the network to not use an IPv6 address with an IID = that is a reserved IID. Thanks for the information on CGA and Privacy = addresses that are not global and thus I agree with you, no clash is = possible with CGA/Privacy address vs. a CLAT IID with "u" bit as 1. There is no collision risk between a host global-scope IID and the = CLAT-reserved IID because: - host global-scope IID are EUI-64 based, containing the manufacturer = unique identifier (OUI) and manufacturer-assigned extension identifier - the CLAT-resreved IID contains the IANA OUI which differs from all = manufacturer OUIs (as already used in for ISATAP = (tools.ietf.org/html/rfc5214#section-6.1).=20 =20 > Another question. Why does the xlat document need another solution = for getting a /64 to use by CLAT for XLATE when an ND Proxy solution = exists? Use of the CLAT-resreved IID is independent from how the IPv6 prefix is = obtained.=20 BTW, note that it can usefully be used also with /x sorter than /64: it = eliminates the need to reserve for 464XLAT a /64 derived from this /x.=20= Again, I hope you finally acknowledge that your objections to the = CLAT-resreved IID have all been resolved. (If not, your additional = questions remain welcome.) Regards, RD =20 >=20 > Hemant >=20 >=20 From lorenzo@google.com Wed Aug 29 00:10:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E111E80EF for ; Wed, 29 Aug 2012 00:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUUqTcKFYKJ for ; Wed, 29 Aug 2012 00:10:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2659A11E809A for ; Wed, 29 Aug 2012 00:10:58 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so456435obb.31 for ; Wed, 29 Aug 2012 00:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=m8YOdDWMEoD2whp3MHcSt249ouh6cQMjSrBEFhpiEQ8=; b=pDZ4CaAfGb7kMvC897B2ZO2ITVxhANIgJshAZ4+Z5FOhnm6gJQwR79msr/y5mc0aAs RN2jsBKX00K7gxpKfLJ0Ajt475bLImzRuCqLptuw4gr6QTm6mnsiF9dPS2HFfrHBm9UB LtKf4+YYJwl+k+rXbgE9meo3MhOI3lZgEykY3mthX5goC/6Hh3iFkw617Z4Ji8WbG0wy onE4mo4TTQ5QaIKe0XB+s7w8khlErOPtc3J7ifpuWDX218BPFu+1JzarVjMk0M47aTaN mX3jDSWgDGXJKG+Es+otcjQTh5BqhWbwmqVlVKVT00eD0LfBzKN27t9hZ0DwkNtjPt7r QIgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=m8YOdDWMEoD2whp3MHcSt249ouh6cQMjSrBEFhpiEQ8=; b=f5054Q9FTtk11k2Hx+xyFTnEf0hON+ueRy8epI0fQsmb+JJoj2Qujy7HP8uDzfJvPW 4RvJbTFkna2EN3g+4OwdVpyvM6YZnDyVLFtOV3UQU+L519IS3il7Fr/k1sL3S9tHTAtS D2D284eqsSTEighFauNRLelB8V/BmZWYqX/Xsoytw58+xWccleehKQryGhWCM9ZvQp8w RQ61L1Z/siOgcfJmMa71tJuK05acT+XBxT4vBiBrOoWjDwDruPzPc4bXFpvSaCeE6Is/ Sw18CvNK5otVrCKVvEww65fM7N0iV6iAwBOso2LZW44o4ggNRTLaCUn0Pgwfdi9gZV+e J/PA== Received: by 10.182.202.1 with SMTP id ke1mr440089obc.51.1346224258569; Wed, 29 Aug 2012 00:10:58 -0700 (PDT) Received: by 10.182.202.1 with SMTP id ke1mr440081obc.51.1346224258474; Wed, 29 Aug 2012 00:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Wed, 29 Aug 2012 00:10:38 -0700 (PDT) In-Reply-To: <6C87F8A5-A53C-4B41-8A9A-DCAE9D6EAEBD@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907B167@xmb-rcd-x06.cisco.com> <6C87F8A5-A53C-4B41-8A9A-DCAE9D6EAEBD@laposte.net> From: Lorenzo Colitti Date: Wed, 29 Aug 2012 16:10:38 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f643690b6e14f04c8624224 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm8kOtaxuTg9tBK1URmRFYFnD4ns3dWCSU3TtOgDJJvFm7XykrHZHgX1rBPtobLJt1zOdpXWA8nv1F9yaQ5R9FDZDsr9Fl+LlgHDtMYxkSqt+1hbJBIVvioI2xxIW0HcNwjlhBCI6Rv0Ii097QZ4bgNgEO9T0BChQ56eWlz9d/Jb3wr+gzjKWGSFdT0eHCZSc1HEqaK Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:10:59 -0000 --e89a8f643690b6e14f04c8624224 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2012 at 3:48 PM, R=E9mi Despr=E9s wrote: > Again, I hope you finally acknowledge that your objections to the > CLAT-resreved IID have all been resolved. (If not, your additional > questions remain welcome. > Remi, can we please have the discussion on the IID on another thread and not on this one? This thread was started to discuss the model where the CLAT shares a single /64 with its clients, which is a separate problem. Thanks, Lorenzo --e89a8f643690b6e14f04c8624224 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2012 at 3:48 PM, R=E9mi Despr=E9s <despres.remi@lap= oste.net> wrote:
Again, I hope you finally acknowledge that your objections to the CLAT-resr= eved IID have all been resolved. (If not, your additional questions remain = welcome.

Remi,

can we please have the discussion on the IID on another thread and not= on this one? This thread was started to discuss the model where the CLAT s= hares a single /64 with its clients, which is a separate problem.

Thanks,
Lorenzo
--e89a8f643690b6e14f04c8624224-- From despres.remi@laposte.net Wed Aug 29 00:33:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67E421F84C2 for ; Wed, 29 Aug 2012 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CMaVLGExjYL for ; Wed, 29 Aug 2012 00:33:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0347721F84BF for ; Wed, 29 Aug 2012 00:33:14 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A24EF940078; Wed, 29 Aug 2012 09:33:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-54-698680990 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 29 Aug 2012 09:33:04 +0200 Message-Id: References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <0E5B68D0-2AB8-44F4-A7E6-0D2D15428B7C@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079A04@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907B167@xmb-rcd-x06.cisco.com> <6C87F8A5-A53C-4B41-8A9A-DCAE9D6EAEBD@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:33:16 -0000 --Apple-Mail-54-698680990 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-08-29 =E0 09:10, Lorenzo Colitti a =E9crit : > On Wed, Aug 29, 2012 at 3:48 PM, R=E9mi Despr=E9s = wrote: > Again, I hope you finally acknowledge that your objections to the = CLAT-resreved IID have all been resolved. (If not, your additional = questions remain welcome. >=20 > Remi, >=20 > can we please have the discussion on the IID on another thread and not = on this one? This thread was started to discuss the model where the CLAT = shares a single /64 with its clients, which is a separate problem. Why not? But I answer here to objections made on this list. If there is no objection, there is no answer. Cheers, RD >=20 > Thanks, > Lorenzo --Apple-Mail-54-698680990 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 29, 2012 at 3:48 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Again, I hope you finally acknowledge that your objections to the = CLAT-resreved IID have all been resolved. (If not, your additional = questions remain = welcome.

Remi,

can we please have the discussion on the IID on another thread and = not on this one? This thread was started to discuss the model where the = CLAT shares a single /64 with its clients, which is a separate = problem.

Why = not?
But I answer here to objections made on this = list.
If there is no objection, there is no = answer.

Cheers,
RD

=

Thanks,
Lorenzo

= --Apple-Mail-54-698680990-- From shemant@cisco.com Wed Aug 29 05:03:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBF21F8634 for ; Wed, 29 Aug 2012 05:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ojwmum7IwDM for ; Wed, 29 Aug 2012 05:03:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD721F84F3 for ; Wed, 29 Aug 2012 05:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2409; q=dns/txt; s=iport; t=1346241809; x=1347451409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Zx+0nuk0NEFMqih9YUTY+dESy17OQzgiOTymCheq9qo=; b=eMQCQrJUM3qSM9D7Xz8yZM+IGpN21oOLVbBW5cKK7tPSZgIYrOr3IOSD AlqbQSUESe1tRe6kLRd5X5KP0eXnyjjuV0/+nJPkRqamwcHCvJ+9fM8HA PlkpPA+mjMDB+aX49QkJwXbwo8I8odrF4rNtuhpltEphag+TqIviCHtB9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACkEPlCtJV2Z/2dsb2JhbABFum+BB4IgAQEBBBIBZhACAQgRBAEBCx0HMhQJCAIEDgUIARmHawubG6AqiwgahV9gA4gam2qBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,332,1344211200"; d="scan'208";a="116349751" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 29 Aug 2012 12:03:29 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7TC3T4W005839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 12:03:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 07:03:28 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti Thread-Topic: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNhFzgQ3F2alww0U20biBJJmepq5dttgWggAByQwD///YvgIAAzpgAgABe5VCAAQCMgIAAAR6AgABhPCA= Date: Wed, 29 Aug 2012 12:03:28 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907B8E8@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89078496@xmb-rcd-x06.cisco.com> <0047933E-40B6-4523-B5C0-5C7A5347ED24@laposte.net> <75B6FA9F576969419E42BECB86CB1B89079871@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B8907ADA2@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.58] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19146.006 x-tm-as-result: No--29.318000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:03:33 -0000 Lorenzo, From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Tuesday, August 28, 2012 8:57 PM To: Hemant Singh (shemant) Cc: R=E9mi Despr=E9s; Cameron Byrne; v6ops@ietf.org Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.= txt >Oh, wait - I see what you mean. You're saying that the host *does* perform= DAD for its link-local address, but it does that when the CLAT is not on t= he >link yet. This is still not an issue, for two reasons: >1. If the CLAT is the tethering router, then there is no link until the CL= AT comes up, so what you describe cannot happen. Agree. However, I am in my home and my wi-fi IPv6 node can pick up any wir= eless signal from the home or the neighborhood and get active on the wi-fi = link with a link-local address but does not see any RA. Now when the CLAT= wi-fi link is up, the IPv6 node has to be reset to move to the new wi-fi = link. Anyway, such a reset is obvious. Thus the following text goes away = from my proposal. "Additionally, it is expected the hosts in the LAN segment of the CLAT are = reset for new IPv6 address acquisition if the hosts were active before the = CLAT was operational in the LAN segment." New text for section 8.3.2 is now: 8.3.2. Case of enabling NAT44 and stateless XLATE on CLAT In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may not have a dedicated IPv6 prefix for translation. If the CLAT does not have a dedicated IPv6 prefix for translation, the CLAT performs NAT44 and stateless translation [RFC6145]. IPv4 packets from the LAN are NAT44 translated to IPv4 address of the CL= AT. =20 Thereafter, CLAT performs a stateless translation [RFC6145] using the IP= v4=20 and the WAN IPv6 address of the CLAT as described in [RFC6145]. =20 The CLAT uses an ND Proxy to share the single /64 prefix between the LAN and WAN segments. =20 >2. The CLAT does not use that IID for its link-local address anyway - it f= orms the link-local address from its wlan0 EUI-64 IID. Right. I too, said the same thing the other day. See below where I said b= ad hardware can cause a duplicate for the link-local and that is why DAD fo= r the link-local is needed. http://www.ietf.org/mail-archive/web/v6ops/current/msg14011.html >So again, I see no need to reset the host. Agree. Hemant From shemant@cisco.com Wed Aug 29 10:34:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52721F8667 for ; Wed, 29 Aug 2012 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lc72AhY+Pck for ; Wed, 29 Aug 2012 10:34:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2F21F8645 for ; Wed, 29 Aug 2012 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1476; q=dns/txt; s=iport; t=1346261642; x=1347471242; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ROrA86f6MC4UcxLca6Db2gJSMfz9GE4FND5zMcEhJyA=; b=HdWQvc1S7ViQlrxJYm2rxIQdZlmnAMbwcuU79FKEOpPs9unqOUgXfggf WvW8hikoh0dPlspSR5ShjqmvlIeJYvgmGbsojREVG0Hz0hNdsx303j2o4 pHdOyaPJvoWs4LjVkiuk9XrLHwhw3uZXuYo/88/8Y7E0EeAtGVvJ1eoRp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFpSPlCtJV2d/2dsb2JhbABFunOBB4IgAQEBBBIBJz8MBAIBCA4DBAEBCxQJByERFAkIAgQBDQUIGodcAwwLm1WWXg2JToolY4V5YAOUA4JniXqDIIFngmM X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="113464971" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 29 Aug 2012 17:33:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7THXokM014864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 17:33:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 12:33:50 -0500 From: "Hemant Singh (shemant)" To: Cameron Byrne , Ray Hunter Thread-Topic: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt Thread-Index: AQHNgwH2GNGIUsM86UyKbvfqcqjMhpdxDz4w Date: Wed, 29 Aug 2012 17:33:50 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8907BC2E@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.185] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19146.006 x-tm-as-result: No--25.463000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:34:03 -0000 Cameron, -----Original Message----- From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Saturday, August 25, 2012 4:41 PM To: Ray Hunter Cc: Hemant Singh (shemant); v6ops@ietf.org; Lorenzo Colitti Subject: Re: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat= -07.txt >I believe that is clearly documented here: >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 > >IF DHCP-PD available, then use DHCP-PD to grab as much address space as ne= eded > >Else if NDproxy available, do that > >Else if EUI-64 reserved address available, do that. Example 2 in Appendix A only gives an example using EUI-64 reserved IID. T= he more interesting example to show would be for how the ND Proxy works. I= don't mean to ask how an "ND Proxy" works, but the example for what the do= cument proposes the ND Proxy case should do with a single /64 and generate = a source IPv6 address from to send packets to the PLAT? I have two choices= below shown from RFC 6052 the ND Proxy example could use. The suffix is a= ll zeroes. +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Thanks, Hemant From despres.remi@laposte.net Wed Aug 29 23:35:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663611E80A3 for ; Wed, 29 Aug 2012 23:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsBpPa9ea824 for ; Wed, 29 Aug 2012 23:35:24 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 374A011E8097 for ; Wed, 29 Aug 2012 23:35:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id DF80770000CA; Thu, 30 Aug 2012 08:35:22 +0200 (CEST) Received: from [192.168.1.73] (188.204.170.89.rev.sfr.net [89.170.204.188]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 6126470000AD; Thu, 30 Aug 2012 08:35:22 +0200 (CEST) X-SFR-UUID: 20120830063522398.6126470000AD@msfrf2312.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8907BC2E@xmb-rcd-x06.cisco.com> Date: Thu, 30 Aug 2012 08:35:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52CE072B-CE46-4207-927D-10CAFA7EEEAF@laposte.net> References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <75B6FA9F576969419E42BECB86CB1B8907BC2E@xmb-rcd-x06.cisco.com> To: v6ops WG X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter Subject: [v6ops] No conflict between ND proxy and EUI-64 reserved IID X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:35:25 -0000 Hi, all, 2012-08-29 =E0 19:33, Hemant Singh (shemant) : ... > Example 2 in Appendix A only gives an example using EUI-64 reserved = IID. The more interesting example to show would be for how the ND Proxy = works. I don't mean to ask how an "ND Proxy" works, but the example for = what the document proposes the ND Proxy case should do with a single /64 = and generate a source IPv6 address from to send packets to the PLAT? I = have two choices below shown from RFC 6052 the ND Proxy example could = use. The suffix is all zeroes. >=20 > = +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |64| prefix | u | v4(32) | suffix = | > = +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |96| prefix | v4(32) = | > = +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Note that: - The external NAT44 address can be the unspecified IPv4 address = 0.0.0.0. (It does make sense since this external address is never used = in IPv4, and can take any value).=20 - the /96 can be the CLAT-node /64 followed by 200:5e10::/32 (the EUI-64 = IANA /32) Then, the CLAT IPv6 address DOES CONTAIN the CLAT-resreved EUI-64 IID = 02-00-5E-10-00-00-00-00. There is therefore NO CONFLICT between using ND proxy an using the = EUI-64 resreved IID. (As already documented, advantage of the reserved IID is that the CLAT = IPv6 address cannot conflict with that of any RFC4291-compliant host. = Consequently, if the CLAT is activated AFTER hosts have been assigned = their IPv6 addresses, neither the CLAT nor any host needs to change its = IPv6 address.) Regards, RD >=20 > Thanks, >=20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Thu Aug 30 23:59:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4921F8535; Thu, 30 Aug 2012 23:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdWQ3gjchODs; Thu, 30 Aug 2012 23:59:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61321F8505; Thu, 30 Aug 2012 23:59:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120831065925.16050.1989.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 23:59:25 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:59:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Servi= ce Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-03.txt Pages : 24 Date : 2012-08-30 Abstract: This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-icp-guidance-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Fri Aug 31 00:14:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5921F8570 for ; Fri, 31 Aug 2012 00:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.224 X-Spam-Level: X-Spam-Status: No, score=-101.224 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8VbPTp8Cw6D for ; Fri, 31 Aug 2012 00:14:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6121F84FA for ; Fri, 31 Aug 2012 00:14:49 -0700 (PDT) Received: by eekb45 with SMTP id b45so1037331eek.31 for ; Fri, 31 Aug 2012 00:14:48 -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=nTmMkLqzM4EhyfY58UFmqMnwQVk49sJHaDfcTfXO90Y=; b=hYiTCHI6Q5up3TWO74DJB45ichDspOQwxcUJpAIYJI4ajAo7CPq4XR1hJcg9At8Eep P7dDODMqMB8tEZ2E06yafg7mQ9HW8XI2wDV+X0sW+dT4jZwbmr1TJ2qG8v2tsLsOR1kR oHk/cyeLWIpUk55RkEc1A8C7xTL75fqIiHNY5pI349PYZBXub2wsTNtr995GsXYXigMb L71Ya5woWMpxbPsXggCVMD0FNdeww8UUtaxnO/kH6ij5Tel3wpME5VSlR6Vbt9GEJ3Ka TBXHecW7GQjqPbSSlqGeJ8exzm4iDe3j0UNqejt45y4IC9mS/y1uYhE6zFsP/xWaRM70 q8TA== Received: by 10.14.182.69 with SMTP id n45mr9683322eem.28.1346397288565; Fri, 31 Aug 2012 00:14:48 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-147.as13285.net. [2.102.216.147]) by mx.google.com with ESMTPS id z3sm10829865eel.15.2012.08.31.00.14.45 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 00:14:46 -0700 (PDT) Message-ID: <5040646F.6000103@gmail.com> Date: Fri, 31 Aug 2012 08:14:55 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 07:14:50 -0000 Hi, This version is updated in response to WG Last Call. There are a lot of changes. You can see the diffs at http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-03.txt The most important change is that the text on PA prefixes, especially on multiple PA prefixes, has been changed in response to comments that it was unrealistic. Other changes were relatively minor, but there are several new points from Erik Nygren's extensive review (thanks, Erik!). Here are some detailed responses to Erik's suggestions: Most of Erik's changes have been implemented, but quite often reworded for stylistic reasons. Some changes have been moved elsehwere in the document. Some cosmetic changes have not been included due to stylistic preference. Various changes related to multiple PA prefixes have not been applied, because that text has been changed anyway and needs complete review. > + Additionally, many deployments of IPv6-only clients (such as those > + using NAT64 for their IPv4 connectivity) will have the clients > + communicating with their DNS resolvers over IPv6, and those DNS resolvers > + may in-turn be dual-stacked or IPv4-only. We don't see that - a DNS64 by definition needs to communicate with the IPv4 world. Anyway, this point seems distracting for an ICP. They just need to dual stack their own DNS; that is sufficient advice. > +Because dual-stacked clients may switch between IPv4 and IPv6, as well as switching > +between multiple IPv6 addresses when privacy addressing is in-use, special care will > +need to be taken with any load balancers using IP addresses for session affinity as > +the same client might otherwise go to different servers for subsequent requests. Point moved to the new "complexity" section, and that section has been moved later in the document to improve logical flow. > +A surrogate (such as an HTTP reverse proxy) ... We prefer to refer to RFC2616 where proxy behaviour is actually specified. RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: I've also never understood the phrase "reverse proxy"; it's just a proxy that happens to be near the server instead of near the client, but what it actually does is the same. Also, "proxy" and "surrogate" mean the same thing in English.) > +For multi-tier applications, it may be initially sufficient to dual-stack > +the Web Tier (often operating as an HTTP surrogate) and to provide IPv6 > +connectivity to back-end application layers in a later phase. This point is already made in the Introduction. > +
> One important recommendation here is that all applications should use domain names, which are IP-version-independent, That isn't restricted to clients - it should apply everywhere. In any case we can't really tell ICPs to change their clients' software. > Note that > + the behavior of dual-stack clients will vary between operating systems and browsers. For example, some client > + implementation of "happy eyeballs" may result in a dual-stack client making > + connections to the same domain name over both IPv4 and IPv6 over time. Moved to the new "complexity" section. >
We didn't understand the reason for the changes suggested here, and we don't think the CDN topic should be embedded in the "complexity" section. It's basic for most ICPs, these days. > -As far as possible, however, mutual dependency between IPv4 and IPv6 operations should be avoided. > +As far as possible, however, mutual dependency between IPv4 and IPv6 availability should be avoided. Disagree, the point is more general than just availability. Brian + Sheng -------- Original Message -------- Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-03.txt Date: Thu, 30 Aug 2012 23:59:25 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: v6ops@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Service Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-03.txt Pages : 24 Date : 2012-08-30 Abstract: This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From tore.anderson@redpill-linpro.com Fri Aug 31 01:58:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF2921F8546 for ; Fri, 31 Aug 2012 01:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RC5eVzn2AIN for ; Fri, 31 Aug 2012 01:58:23 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9021F850D for ; Fri, 31 Aug 2012 01:58:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 952811820030; Fri, 31 Aug 2012 10:58:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s2I+qFwtvgB; Fri, 31 Aug 2012 10:58:20 +0200 (CEST) Received: from envy.fud.no (cm-84.209.194.19.getinternet.no [84.209.194.19]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 29F34182002A; Fri, 31 Aug 2012 10:58:20 +0200 (CEST) Message-ID: <50407CAB.4060903@redpill-linpro.com> Date: Fri, 31 Aug 2012 10:58:19 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5040646F.6000103@gmail.com> In-Reply-To: <5040646F.6000103@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 08:58:24 -0000 Regarding PI addresses, the new version says: «This option is available to an ICP willing to deal directly with the relevant Regional Internet Registry and pay the associated fees» This is misleading, at least in the RIPE NCC service area. An ICP could opt to obtain PI addresses through his LIR of choice. This LIR is then called a «sponsoring LIR». The RIPE NCC very obviously tries to steer PI users in that direction - a single PI resource registered through a sponsoring LIR costs €50/year (which will on the LIR's invoice), while a direct assignment from the NCC costs €1300/year + a one-time fee of €2000. See . Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From brian.e.carpenter@gmail.com Fri Aug 31 03:41:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAC521F855F for ; Fri, 31 Aug 2012 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.526 X-Spam-Level: X-Spam-Status: No, score=-101.526 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AB+PABi2t9j for ; Fri, 31 Aug 2012 03:41:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E25421F852B for ; Fri, 31 Aug 2012 03:41:27 -0700 (PDT) Received: by eaai11 with SMTP id i11so854577eaa.31 for ; Fri, 31 Aug 2012 03:41:26 -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=PsPLItL9UV65XiaFqy+gPNhHxzgy0tNoNuPsKsqYfcE=; b=l5tB3SJbx2ECfEN0r4vs3inNsC4BlOMnUCAYOVuHMWT1sDRcoCy7aXMAp5mOlSPPsv FbapDwtrsCBf94InpfTVKsqr08B1t5jKNSePn/JspWvsHmMFje3tezte5rLxdALTU9V/ IpOv9zXZ93ywca5YJ4+llEccoE/3S4AlZcHSbIKSFvDP12Yoe5Kn14h2iSKomQZestEz zYTtNMyqgfSHyUQg5wv6d5ImszAJR9CeotVnFlRZpJq7sO1hUZaS/LKEcYjcqc4c5l17 my6veu27gBX7qeqVi28cOP9yDFVt+9KpDmeguBEXKjoE4kHyK/txDY4fvXmrob5f4vFn a5Zg== Received: by 10.14.202.66 with SMTP id c42mr10498616eeo.35.1346409686664; Fri, 31 Aug 2012 03:41:26 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-147.as13285.net. [2.102.216.147]) by mx.google.com with ESMTPS id u8sm12315229eel.11.2012.08.31.03.41.23 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 03:41:24 -0700 (PDT) Message-ID: <504094DD.9060708@gmail.com> Date: Fri, 31 Aug 2012 11:41:33 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> In-Reply-To: <50407CAB.4060903@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:41:28 -0000 On 31/08/2012 09:58, Tore Anderson wrote: > Regarding PI addresses, the new version says: >=20 > =C2=ABThis option is available to an ICP willing to deal directly with = the > relevant Regional Internet Registry and pay the associated fees=C2=BB >=20 > This is misleading, at least in the RIPE NCC service area.=20 Ah, OK, would it be accurate to simply delete the word "Regional"? Brian > An ICP could > opt to obtain PI addresses through his LIR of choice. This LIR is then > called a =C2=ABsponsoring LIR=C2=BB. The RIPE NCC very obviously tries = to steer PI > users in that direction - a single PI resource registered through a > sponsoring LIR costs =E2=82=AC50/year (which will on the LIR's invoice)= , while a > direct assignment from the NCC costs =E2=82=AC1300/year + a one-time fe= e of > =E2=82=AC2000. See > . >=20 > Best regards, From tore.anderson@redpill-linpro.com Fri Aug 31 04:12:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291B521F8497 for ; Fri, 31 Aug 2012 04:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyqoGKrGW0qb for ; Fri, 31 Aug 2012 04:12:48 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1E74021F8450 for ; Fri, 31 Aug 2012 04:12:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id EB13C1820031; Fri, 31 Aug 2012 13:12:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaDGsUeMEXpb; Fri, 31 Aug 2012 13:12:43 +0200 (CEST) Received: from envy.fud.no (cm-84.209.194.19.getinternet.no [84.209.194.19]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 7D6051820030; Fri, 31 Aug 2012 13:12:43 +0200 (CEST) Message-ID: <50409C2A.2060805@redpill-linpro.com> Date: Fri, 31 Aug 2012 13:12:42 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> In-Reply-To: <504094DD.9060708@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 11:12:49 -0000 * Brian E Carpenter >> «This option is available to an ICP willing to deal directly with the >> relevant Regional Internet Registry and pay the associated fees» >> >> This is misleading, at least in the RIPE NCC service area. > > Ah, OK, would it be accurate to simply delete the word "Regional"? Strictly speaking, I suppose so. But the message is still a bit confusing. The «willing to deal directly with» formulation is in all likelihood a red herring, because the ICP will be already dealing directly with an LIR - his ISP. And which ICP would care about €50/year? The document continues in the same vein: «only large content providers can justify the bother and expense of obtaining a PI prefix». Can't say I agree. The bother and expense is for all practical purposes negligible, especially when compared to the potential bother and expense associated with renumbering out of a PA assignment down the road. It is probably a bigger hurdle for the ICP (compared to getting a PA assignment from an ISP) to acquire and set up BGP-speaking routers. However, it is also possible to have the upstream ISP(s) advertise the PI prefix on the ICP's behalf, so even that might not be a problem after all. Truth to be told I don't see any real reason why an ICP shouldn't go for PI from day one. Except for altruism, that is. (I'm not well informed when it comes to the other four RIRs' PI policies, so the above might be limited only to the RIPE service area.) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From brian.e.carpenter@gmail.com Fri Aug 31 05:21:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A921F85AA for ; Fri, 31 Aug 2012 05:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.527 X-Spam-Level: X-Spam-Status: No, score=-101.527 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHCjuidIZIY5 for ; Fri, 31 Aug 2012 05:21:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9321F858E for ; Fri, 31 Aug 2012 05:21:04 -0700 (PDT) Received: by eaai11 with SMTP id i11so887720eaa.31 for ; Fri, 31 Aug 2012 05:21:04 -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=xzMGbh7warY+Toxc0OdDDM3S9JWQQuZW/oGnUX9n6WM=; b=Df0Te6/lkezsbWdxZtIrPZB+DxRqFRYx9Cda+nJ26Ksr0IFZvAMG9irEY2LC/8Scpm oO+g+J+8LlWgm9V2qeXTlhMhDjCSDejkZo1utdo5oNdpOuFjnvA8MPmII9Fl2e2tIIz+ M7bVjq7U6j7+wu9lz14teHbhhTmUhETEAiR3Vxu2GJ+75ZsywiTkokpk4t8sq4UVSlFy hCZgac5wYy22aP6xm1YbzBEfHsnx+0vnDl6CPG/jufvmHl+R9c037njG7RfRK+etCV1e rKP0KFRGbgtZQnb2r1ZOr15oKSH4sHb8M8hJE0x9v4IN+j23zr+mgT3tIG8g5muaBeAt HIhA== Received: by 10.14.202.71 with SMTP id c47mr10890463eeo.42.1346415663977; Fri, 31 Aug 2012 05:21:03 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-147.as13285.net. [2.102.216.147]) by mx.google.com with ESMTPS id e7sm13071604eep.2.2012.08.31.05.21.02 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 05:21:02 -0700 (PDT) Message-ID: <5040AC38.5080505@gmail.com> Date: Fri, 31 Aug 2012 13:21:12 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> In-Reply-To: <50409C2A.2060805@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:21:06 -0000 > Except for altruism, that is. Exactly. I don't believe the IETF should be making it seem that blowing up BGP4 is the recommended approach. We should actually be advocating altruism IMHO. Regards Brian On 31/08/2012 12:12, Tore Anderson wrote: > * Brian E Carpenter >=20 >>> =C2=ABThis option is available to an ICP willing to deal directly wit= h the >>> relevant Regional Internet Registry and pay the associated fees=C2=BB= >>> >>> This is misleading, at least in the RIPE NCC service area.=20 >> Ah, OK, would it be accurate to simply delete the word "Regional"? >=20 > Strictly speaking, I suppose so. But the message is still a bit > confusing. The =C2=ABwilling to deal directly with=C2=BB formulation is= in all > likelihood a red herring, because the ICP will be already dealing > directly with an LIR - his ISP. And which ICP would care about =E2=82=AC= 50/year? >=20 > The document continues in the same vein: =C2=ABonly large content provi= ders > can justify the bother and expense of obtaining a PI prefix=C2=BB. Can'= t say > I agree. The bother and expense is for all practical purposes > negligible, especially when compared to the potential bother and expens= e > associated with renumbering out of a PA assignment down the road. >=20 > It is probably a bigger hurdle for the ICP (compared to getting a PA > assignment from an ISP) to acquire and set up BGP-speaking routers. > However, it is also possible to have the upstream ISP(s) advertise the > PI prefix on the ICP's behalf, so even that might not be a problem afte= r > all. >=20 > Truth to be told I don't see any real reason why an ICP shouldn't go fo= r > PI from day one. Except for altruism, that is. >=20 > (I'm not well informed when it comes to the other four RIRs' PI > policies, so the above might be limited only to the RIPE service area.)= >=20 > Best regards, From nick@inex.ie Fri Aug 31 05:54:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9285921F85F4 for ; Fri, 31 Aug 2012 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeNZSO5WpLjH for ; Fri, 31 Aug 2012 05:54:25 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id CDC6321F8577 for ; Fri, 31 Aug 2012 05:54:23 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q7VCqf2d038900 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 13:52:41 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <5040B3FB.7060502@inex.ie> Date: Fri, 31 Aug 2012 13:54:19 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Tore Anderson References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> In-Reply-To: <50409C2A.2060805@redpill-linpro.com> X-Enigmail-Version: 1.4.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:54:25 -0000 On 31/08/2012 12:12, Tore Anderson wrote: > The document continues in the same vein: «only large content providers > can justify the bother and expense of obtaining a PI prefix». Can't say > I agree. +1. PI is easy to get and there are plenty of smaller organisations who depend on it for their business requirements (at least for ipv4). There are no substantial issues with routing PIv6 address space, because the minimum assignment size is /48, which corresponds with the RIRs' recommendations on minimum prefix filter length. Nick From despres.remi@laposte.net Fri Aug 31 07:45:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FD921F861B for ; Fri, 31 Aug 2012 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2PlvIeC-lcP for ; Fri, 31 Aug 2012 07:45:38 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0921F861A for ; Fri, 31 Aug 2012 07:45:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 24F6470000BA; Fri, 31 Aug 2012 16:45:37 +0200 (CEST) Received: from [192.168.1.73] (188.204.170.89.rev.sfr.net [89.170.204.188]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id DDA7370000B1; Fri, 31 Aug 2012 16:45:36 +0200 (CEST) X-SFR-UUID: 20120831144536907.DDA7370000B1@msfrf2219.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <52CE072B-CE46-4207-927D-10CAFA7EEEAF@laposte.net> Date: Fri, 31 Aug 2012 16:45:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75B6FA9F576969419E42BECB86CB1B890779FB@xmb-rcd-x06.cisco.com> <50392728.6020002@globis.net> <75B6FA9F576969419E42BECB86CB1B8907BC2E@xmb-rcd-x06.cisco.com> <52CE072B-CE46-4207-927D-10CAFA7EEEAF@laposte.net> To: v6ops WG X-Mailer: Apple Mail (2.1084) Subject: [v6ops] 464XLAT - Applicability of reserved IID prefix to CLATs having no NAT44 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:45:39 -0000 Hi, all, A interesting fact is that benefit of using an IANA-resreved EUI-64 IID = for the NAT44 case can be extended to the non-NAT44 case. Thus: - ND proxy is no longer needed to prevent native IPv6 addresses of = client hosts to conflict with IPv4-embedded CLAT addresses. - This prevention applies even if hosts obtain their addresses before = CLAT activation, and aren't reset.=20 For this, it is sufficient that, instead of just reserving IID = 200:5e10::/64 for one address, reservation is also made for an exclusive = /40 IID prefix.=20 More precisely, having CLATs to use 10../8 private addresses on their = LAN side, and reserving IID prefix 200:5e10:a000::/40, the end result = is:=20 - IPv4-embedded IPv6 addresses of CLATs are = :200:5e10:, where CLAT_64 is any IPv6 prefix = in the space assigned to the CLAT node. - No ND proxy is needed to prevent hosts to conflict with this address. - Conflicts are avoided even for host that get their IPv6 addresses = before CLAT activation. - No need to assign a 464XLAT specific prefix, and /64 assignments are = supported.=20 Sorry for not having seen this before (probably because focusing = exclusively on the NAT44 case) but, following the discussion on ND = proxy, this seems to me a significant simplification of CLAT design and = operation. If this isn't clear enough, please don't hesitate to ask for = clarification. Regards, RD From joelja@bogus.com Fri Aug 31 07:45:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EB921F865C for ; Fri, 31 Aug 2012 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o23mkmXuxPvs for ; Fri, 31 Aug 2012 07:45:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D87F821F8650 for ; Fri, 31 Aug 2012 07:45:41 -0700 (PDT) Received: from Joels-MacBook-Pro.local (71-93-165-75.dhcp.hspr.ca.charter.com [71.93.165.75]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7VEjboD087005 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 31 Aug 2012 14:45:39 GMT (envelope-from joelja@bogus.com) Message-ID: <5040CA3B.4090602@bogus.com> Date: Fri, 31 Aug 2012 07:29:15 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com> In-Reply-To: <5040AC38.5080505@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 31 Aug 2012 14:45:40 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:45:42 -0000 On 8/31/12 05:21 , Brian E Carpenter wrote: >> Except for altruism, that is. > > Exactly. I don't believe the IETF should be making it seem that > blowing up BGP4 is the recommended approach. We should actually be > advocating altruism IMHO. The IETF should make recommendations that responsible network operators can follow without interfering with their business. With respect to PA address space, it should be understood that some of the internet content providers this document addresses will be deploying from the networks of their colo providers, ASPs, cloud providers and so on. these will be necessarily numbered out of provider assigned address space for convenience, because the provider itself is multihomed and so forth. joel > Regards > Brian > > On 31/08/2012 12:12, Tore Anderson wrote: >> * Brian E Carpenter >> >>>> «This option is available to an ICP willing to deal directly with the >>>> relevant Regional Internet Registry and pay the associated fees» >>>> >>>> This is misleading, at least in the RIPE NCC service area. >>> Ah, OK, would it be accurate to simply delete the word "Regional"? >> >> Strictly speaking, I suppose so. But the message is still a bit >> confusing. The «willing to deal directly with» formulation is in all >> likelihood a red herring, because the ICP will be already dealing >> directly with an LIR - his ISP. And which ICP would care about €50/year? >> >> The document continues in the same vein: «only large content providers >> can justify the bother and expense of obtaining a PI prefix». Can't say >> I agree. The bother and expense is for all practical purposes >> negligible, especially when compared to the potential bother and expense >> associated with renumbering out of a PA assignment down the road. >> >> It is probably a bigger hurdle for the ICP (compared to getting a PA >> assignment from an ISP) to acquire and set up BGP-speaking routers. >> However, it is also possible to have the upstream ISP(s) advertise the >> PI prefix on the ICP's behalf, so even that might not be a problem after >> all. >> >> Truth to be told I don't see any real reason why an ICP shouldn't go for >> PI from day one. Except for altruism, that is. >> >> (I'm not well informed when it comes to the other four RIRs' PI >> policies, so the above might be limited only to the RIPE service area.) >> >> Best regards, > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Fri Aug 31 07:53:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18A21F8628 for ; Fri, 31 Aug 2012 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.528 X-Spam-Level: X-Spam-Status: No, score=-101.528 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AerxxD61TpIe for ; Fri, 31 Aug 2012 07:53:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B721F8621 for ; Fri, 31 Aug 2012 07:53:24 -0700 (PDT) Received: by eaai11 with SMTP id i11so940018eaa.31 for ; Fri, 31 Aug 2012 07:53:23 -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=aBlLBs17LoaOy/3l4jL6uLzLYShYAEjYkyF22L23ats=; b=Ye5GztnZMyR4lw0sCqTp+7fl2yW62JTZVjpFMhQG7dYFXUYMM2QMEPGLv1s7YJjhnW HRutQuE6LwB6L1S+UVlbzhQo/MYUwNd6V5SK8l8N/tI/WLg0KpsT3/4zwQWrHsUkXV9K tNvT/XmazjfdbU89PQgnZaFh6XufRUqJCJg/ueSSWNTXGWlNV5J/HywttG0XCfZ95wcB rQ9/yIA2BH07EQKixxS/TgSIfXRpoFHwSIq6Qmm/WbwTzZ0Ljt0oP5Fs9/zWuwhG0WJ4 2cqVx+eL3MNNr+ya9gPmanHGmVvZwYzw+Z2akavYRY4912yjBYkl37GlQuiEKeUzQ7ov lHeg== Received: by 10.14.203.69 with SMTP id e45mr11525391eeo.23.1346424803836; Fri, 31 Aug 2012 07:53:23 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-147.as13285.net. [2.102.216.147]) by mx.google.com with ESMTPS id v3sm14104871eep.10.2012.08.31.07.53.22 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 07:53:22 -0700 (PDT) Message-ID: <5040CFEC.9010307@gmail.com> Date: Fri, 31 Aug 2012 15:53:32 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040B3FB.7060502@inex.ie> In-Reply-To: <5040B3FB.7060502@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:53:26 -0000 Nick, On 31/08/2012 13:54, Nick Hilliard wrote: > On 31/08/2012 12:12, Tore Anderson wrote: >> The document continues in the same vein: =C2=ABonly large content prov= iders >> can justify the bother and expense of obtaining a PI prefix=C2=BB. Can= 't say >> I agree. >=20 > +1. >=20 > PI is easy to get and there are plenty of smaller organisations who dep= end > on it for their business requirements (at least for ipv4). =20 It's a solution, not a requirement. It may well be the *only* solution in= IPv4, but this is about IPv6 which needs to be much more scaleable than IPv4 to make any sense. > There are no > substantial issues with routing PIv6 address space, because the minimum= > assignment size is /48, which corresponds with the RIRs' recommendation= s on > minimum prefix filter length. That is, however, just a pragmatic choice and with the *current* size of = the IPv6 RIB, simply not an issue. The point is that we (the IETF) need to se= t things rolling in a way that will scale to an IPv6 RIB many times bigger than the current IPv4 RIB. Recommending PI unconditionally is, in my opinion, highly irresponsible in that context. As document editors we will of course do what the WG chairs determine is the WG consensus. As an individual contributor, I will continue to pre= ss for recognition of the PA approach. Brian >=20 > Nick >=20 >=20 From brian.e.carpenter@gmail.com Fri Aug 31 08:29:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55D21F8623 for ; Fri, 31 Aug 2012 08:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.229 X-Spam-Level: X-Spam-Status: No, score=-101.229 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ1NC4cesaO2 for ; Fri, 31 Aug 2012 08:29:09 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE0E821F861A for ; Fri, 31 Aug 2012 08:29:08 -0700 (PDT) Received: by eaai11 with SMTP id i11so951951eaa.31 for ; Fri, 31 Aug 2012 08:29:06 -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=RI8/KAw/S47UsQQiDqj9pQeljSI69XX5Nj1j6qs/yc8=; b=ge8K+KrDYTHrAVzXujq2tohkI4a639xBLfFEzL9xVZZnmeEjZ/JOVRjTG0QckxHqZp /w8ghpbljUwCJ/sQ2U9+IYJ+W85zYiKx2kpHOa4tlK49F/iUYklbYlWce/uIRKDybyOO MhWzGwnlaYqY1CU6/OFxzqxXeJqDC0A9+LYX/kKbaKGQJRtZ5BSddk7EPUyve2ybm6PR lgP55rMoQrYreH6vJVK//2r4ZDH3tdxDv7H0Fha5D+qrm1m7jCUOuEcTeOATOdimtTTZ nd7/0S9jRegcJ0l7S/65bqwF4yNUTSjcsLqMnKPidBX84HA40/Fh4D41cAZSaK+1rspe 2iXA== Received: by 10.14.211.133 with SMTP id w5mr11602216eeo.46.1346426946664; Fri, 31 Aug 2012 08:29:06 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-147.as13285.net. [2.102.216.147]) by mx.google.com with ESMTPS id i8sm14311584eeo.16.2012.08.31.08.29.04 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 08:29:05 -0700 (PDT) Message-ID: <5040D84B.2060201@gmail.com> Date: Fri, 31 Aug 2012 16:29:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com> <5040CA3B.4090602@bogus.com> In-Reply-To: <5040CA3B.4090602@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:29:09 -0000 On 31/08/2012 15:29, Joel jaeggli wrote: > On 8/31/12 05:21 , Brian E Carpenter wrote: >>> Except for altruism, that is. >> Exactly. I don't believe the IETF should be making it seem that >> blowing up BGP4 is the recommended approach. We should actually be >> advocating altruism IMHO. >=20 > The IETF should make recommendations that responsible network operators= > can follow without interfering with their business. Yes. But we are also supposed to worry about the long-term health of the network; the difficulty is finding the right balance. > With respect to PA address space, it should be understood that some of > the internet content providers this document addresses will be deployin= g > from the networks of their colo providers, ASPs, cloud providers and so= > on. these will be necessarily numbered out of provider assigned address= > space for convenience, because the provider itself is multihomed and so= > forth. Absolutely, and the draft should recognise that as well as the PI option.= Specific suggestions for rewriting the text would be welcome. That's the first two paragraphs at http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-03#section-5.1 Brian >=20 > joel >=20 >> Regards >> Brian >> >> On 31/08/2012 12:12, Tore Anderson wrote: >>> * Brian E Carpenter >>> >>>>> =C2=ABThis option is available to an ICP willing to deal directly w= ith the >>>>> relevant Regional Internet Registry and pay the associated fees=C2=BB= >>>>> >>>>> This is misleading, at least in the RIPE NCC service area.=20 >>>> Ah, OK, would it be accurate to simply delete the word "Regional"? >>> Strictly speaking, I suppose so. But the message is still a bit >>> confusing. The =C2=ABwilling to deal directly with=C2=BB formulation = is in all >>> likelihood a red herring, because the ICP will be already dealing >>> directly with an LIR - his ISP. And which ICP would care about =E2=82= =AC50/year? >>> >>> The document continues in the same vein: =C2=ABonly large content pro= viders >>> can justify the bother and expense of obtaining a PI prefix=C2=BB. Ca= n't say >>> I agree. The bother and expense is for all practical purposes >>> negligible, especially when compared to the potential bother and expe= nse >>> associated with renumbering out of a PA assignment down the road. >>> >>> It is probably a bigger hurdle for the ICP (compared to getting a PA >>> assignment from an ISP) to acquire and set up BGP-speaking routers. >>> However, it is also possible to have the upstream ISP(s) advertise th= e >>> PI prefix on the ICP's behalf, so even that might not be a problem af= ter >>> all. >>> >>> Truth to be told I don't see any real reason why an ICP shouldn't go = for >>> PI from day one. Except for altruism, that is. >>> >>> (I'm not well informed when it comes to the other four RIRs' PI >>> policies, so the above might be limited only to the RIPE service area= =2E) >>> >>> Best regards, >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 From iesg-secretary@ietf.org Fri Aug 31 09:05:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2849421F85A1; Fri, 31 Aug 2012 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMOCEApNJXCW; Fri, 31 Aug 2012 09:05:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86821F8546; Fri, 31 Aug 2012 09:04:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120831160458.25436.40986.idtracker@ietfa.amsl.com> Date: Fri, 31 Aug 2012 09:04:58 -0700 Cc: v6ops@ietf.org Subject: [v6ops] V6OPS WG Interim Meeting, September 29, 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:05:06 -0000 Greetings folks, The V6OPS Working Group will hold an interim meeting on September = 29, 2012 in Amsterdam, the Netherlands. Venue location will be = announced later, and is expected to be arranged as part of the IETF = Large Interim Meeting (LIM). The commentary on our proposal was appreciated. The slot that IAD has allocated to us is: 1330 - 1630 CEST on the 29th of Sept 2012 I am aware so far, that opsec is planning to meet in the same location from 0900-1200 and the SIDR has an interim scheduled for the entire day that Saturday. While there are some details still to be worked out it's time to get the framework in place for the interim to coincide with the end of RIPE 65, Amsterdam, 24 - 28 September 2012. I think we should plan to maintain an interim document submission deadline two weeks out from the meeting itself. To be considered for inclusion in the interim agenda new or revised documented should be submitted to the IETF document system by 23:59 UTC on Sept 14th. Documents currently being hashed out on the list are certainly fair game for inclusion in the interim. Thanks Joel