From xuxh@huawei.com Tue Dec 1 01:09:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE49228C0E7 for ; Tue, 1 Dec 2009 01:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=1.853, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBOfGoPB+GI3 for ; Tue, 1 Dec 2009 01:09:29 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 07CC328C0CE for ; Tue, 1 Dec 2009 01:09:29 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY00D10UOK54@szxga03-in.huawei.com> for behave@ietf.org; Tue, 01 Dec 2009 17:07:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY003D0UOK8B@szxga03-in.huawei.com> for behave@ietf.org; Tue, 01 Dec 2009 17:07:32 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTY00NMRUOJ2A@szxml06-in.huawei.com> for behave@ietf.org; Tue, 01 Dec 2009 17:07:32 +0800 (CST) Date: Tue, 01 Dec 2009 17:07:31 +0800 From: Xu Xiaohu In-reply-to: To: 'Cameron Byrne' Message-id: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AcpyWIu0sFUFn6wNSvyOT+CH1uW4WAACIJ8w Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:09:30 -0000 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Cameron Byrne [mailto:cb.list6@gmail.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=881=E6=97=A5 15:32 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu > =E6=8A=84=E9=80=81: mohamed.boucadair@orange-ftgroup.com; = behave@ietf.org > =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s = standardisedprotocols//re: > draft-xu-behave-nat-state-sync-00 >=20 > On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu wrote: > > > > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > >> Cameron Byrne > >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=881=E6=97=A5 1:19 > >> =E6=94=B6=E4=BB=B6=E4=BA=BA: mohamed.boucadair@orange-ftgroup.com > >> =E6=8A=84=E9=80=81: behave@ietf.org; Xu Xiaohu > >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s = standardised > protocols//re: > >> draft-xu-behave-nat-state-sync-00 > >> > >> On Mon, Nov 30, 2009 at 4:54 AM, = > >> wrote: > >> > > >> > Dear Cameron, > >> > > >> > The issue you are describing is more about load distribution = rather than > NAT > >> state sync. > >> > >> Correct, i believe we can best provide service availability in the > >> macro network with DNS64 controlled load distribution. NAT sync in > >> the macro network faces too many challenges to be useful > > > > Do you want to use DNS64 to achieve NAT redundancy while realizing > load-balancing? Do you mean offering the IPv6 host another prefix64 by = DNS64 > if the NAT box for the previous prefix crashes? > > > > Xiaohu >=20 > Yes, I want DNS64 to facilitate NAT64 redundancy from a macro-network > perspective while also providing load-sharing. Load sharing and > redundancy are frequently coupled (web server farms, sip proxies, > anycast DNS servers ...). This solutions is only focused on AAAA > query responses to an IPv6-only host from a DNS64, which in my > use-case is the most common scenario. Other use-cases do not interest > me as much and may better fit a well know anycast prefix64. In order to use the correct prefix64 in synthesizing AAAA records, the = DNS64 should be able to determine which prefix64 is available by some = means, e.g., exchanging messages with NAT64, or sending probe packets to = a given IPv4 host within the IPv4 Internet by using different prefix64s. BTW, once the NAT box for a given prefix fails, would the communications = using that prefix be interrupted till the corresponding AAAA records in = the DNS caches of IPv6 hosts expire? Xiaohu > >> > I agree with the requirement you have (BTW, similar solutions = exist for > the > >> selection of the outbound proxy SIP) but this may be easy to = implement with > >> stateless NATxy rather than stateful one since the path MUST be = symmetric > (the > >> same NAT device must be crossed) and appropriate routing actions = should be > >> undertaken to redirect the traffic to the appropriate NATxy device. = If you > have > >> a fully distributed NATxy and all advertise the same IPv4 net, then = the > symmetry > >> requirement is difficult to meet. Not to mention that the load = should be > >> controlled in both sides of the NAT. > >> > > >> > >> Unfortunately, i have yet to find an useful application for = stateless > >> NATxy in my network. The NAT44 i have deployed today require > >> multiplexing many users behind a small pool public IP address. > >> Changing the source from IPv4 to IPv6 will face the same limitation > >> that requires multiplexing many users behind a few IPv4 addresses = and > >> consequently requires a stateful multiplexed solution. > >> > >> Regarding symmetrical flows, I don't really understand your = comment. > >> I don't support the idea of macro network state sync, and i do see > >> that people who try to deploy that will have a symmetry issue. > >> > >> My expectation is that each stateful NAT64 (local 1+1) with a = unique > >> PREF64 will advertise a unique IPv4 prefix, so the flows are always > >> symmetric. The entire network has many stateful NAT64 (local 1+1) = and > >> the translation load and resiliency is solved by distributing these > >> autonomous building blocks of capacity and availability throughout = the > >> network. > >> > >> > Cheers, > >> > Med > >> > > >> > > >> > -----Message d'origine----- > >> > De : Cameron Byrne [mailto:cb.list6@gmail.com] > >> > Envoy=C3=A9 : jeudi 26 novembre 2009 18:43 > >> > =C3=80 : BOUCADAIR Mohamed NCPI/NAD/TIP > >> > Cc : Xu Xiaohu; Brian E Carpenter; behave@ietf.org > >> > Objet : Re: [BEHAVE] proprietary implementation v.s standardised = protocols > >> //re: draft-xu-behave-nat-state-sync-00 > >> > > >> > On Thu, Nov 26, 2009 at 12:04 AM, = > >> wrote: > >> >> > >> >> Dear Cameron, > >> >> > >> >> This may be true for 1+1 redundancy schemes, but what about N+1 = ones? > >> > > >> > In other threads i have proposed using multiple NAT64 / PREF64 = pairs > >> > handed out by the DNS64, and having feedback from the NAT64 to = the > >> > DNS64 to communicate health of NAT64 box such that the PREF64 can = be > >> > taken out of rotation if needed by the DNS64. This is how global = site > >> > load balancing works today for web sites and CDNs. I do expect = this > >> > type of implementation to have NAT64 in 1+1 for local instant = fault > >> > tolerance and the DNS64 to be a more macro level recovery and = load > >> > sharing technique > >> > > >> > If can't get it into the standard, i can get a vendor to do it. = And, > >> > if i can't get a vendor to do it i can probably rig it myself = with a > >> > perl script to SNMP poll the NAT64 for health and load and reset = the > >> > DNS64 config automatically to redirect traffic from bad PREF64 / > >> > NAT64s to good PREF64 NAT64s > >> > > >> > I know the tricks that global site load balancing does are not = pure, > >> > but my perpective is that this is the reality of the internet, it = is > >> > the only way google, facebook, yahoo can scale. It is the only = way > >> > NAT64 can scale linearly as a system of hardware building blocks = and > >> > survive at a macro level. > >> > > >> > Cameron > >> > > >> >> > >> >> Cheers > >> >> Med > >> >> > >> >> > >> >> -----Message d'origine----- > >> >> De : Cameron Byrne [mailto:cb.list6@gmail.com] > >> >> Envoy=C3=A9 : mercredi 25 novembre 2009 18:50 > >> >> =C3=80 : Xu Xiaohu > >> >> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E Carpenter; = behave@ietf.org > >> >> Objet : Re: [BEHAVE] proprietary implementation v.s standardised > protocols > >> //re: draft-xu-behave-nat-state-sync-00 > >> >> > >> >> On Wed, Nov 25, 2009 at 2:05 AM, Xu Xiaohu = wrote: > >> >>> > >> >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > >> >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3 > =E8=A1=A8 > >> >>>> mohamed.boucadair@orange-ftgroup.com > >> >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B411=E6=9C=8813=E6=97=A5 14:41 > >> >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Brian E Carpenter; = behave@ietf.org > >> >>>> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] = draft-xu-behave-nat-state-sync-00 > >> >>>> > >> >>>> > >> >>>> Dear all, > >> >>>> > >> >>>> I guess that the question should be asked priori to yours: > >> >>>> > >> >>>> Do we let vendors define their proprietary solutions or does = the IETF > >> define > >> >>>> a solution based on standardised protocols to achieve reliable = state > >> >>>> synchronisation? > >> >>> > >> >>> For a small enterprise network, maybe it's acceptable to deploy = two or > more > >> NAT boxes purchased from the same vendor for redundancy. However, = for a large > >> ISP network or large enterprise network, it is not reliable enough. = For > example, > >> an abnormal packet will cause the router OS to crash, it is not = absolutely > >> acceptable. Hence I believe the standardization of NAT redundancy = is > necessary. > >> >>> > >> >> > >> >> In the large scale NAT44 we run today, all vendors have 1+1 > >> >> proprietary state sync. They also sync configuration and other = OAM > >> >> elements over this sync channel. I do not think it is at all = required > >> >> for vendors to have a standard state sync. If I deploy multiple > >> >> vendors for NAT, i will keep the 1+1 pairs of the same vendor = and use > >> >> different vendor 1+1 pairs for higher level network topology = driven > >> >> redundancy, not local state synchronization. > >> >> > >> >> Cameron Byrne > >> >> Principal Engineer > >> >> T-Mobile USA > >> >> > >> >>> Xiaohu > >> >>> > >> >>> > >> >>>> From a service provider perspective, I'd like to see a = solution with > IETF > >> stamp > >> >>>> so as to be included in our RFPs/analysis. Vendors are then = free to > propose > >> >>>> more reliable solutions, if any, compared to the one = standardised by > IETF. > >> >>>> > >> >>>> Cheers, > >> >>>> Med > >> >>>> > >> >>>> > >> >>>> -----Message d'origine----- > >> >>>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] = De la > part > >> de > >> >>>> Brian E Carpenter > >> >>>> Envoy=C3=A9 : vendredi 13 novembre 2009 02:55 > >> >>>> =C3=80 : behave@ietf.org > >> >>>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00 > >> >>>> > >> >>>> My question about this draft is whether there is available = code and > >> >>>> implementation experience with SCSP, which was defined in = 1998. > >> >>>> > >> >>>> If there isn't code and experience, since it is a quite = complex design, > >> I would > >> >>>> be a bit worried. > >> >>>> > >> >>>> On the other hand, I believe that something of the complexity = of SCSP > is > >> >>>> absolutely required to provide reliable synchronisation. > >> >>>> There is no simple, lightweight way to do this reliably. > >> >>>> > >> >>>> Brian > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Behave mailing list > >> >>>> Behave@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/behave > >> >>>> > >> >>>> ********************************* > >> >>>> This message and any attachments (the "message") are = confidential and > >> intended > >> >>>> solely for the addressees. > >> >>>> Any unauthorised use or dissemination is prohibited. > >> >>>> Messages are susceptible to alteration. > >> >>>> France Telecom Group shall not be liable for the message if = altered, > >> changed > >> >>>> or falsified. > >> >>>> If you are not the intended addressee of this message, please = cancel > it > >> >>>> immediately and inform the sender. > >> >>>> ******************************** > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Behave mailing list > >> >>>> Behave@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/behave > >> >>> > >> >>> _______________________________________________ > >> >>> Behave mailing list > >> >>> Behave@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/behave > >> >>> > >> >> > >> >> ********************************* > >> >> This message and any attachments (the "message") are = confidential and > >> intended solely for the addressees. > >> >> Any unauthorised use or dissemination is prohibited. > >> >> Messages are susceptible to alteration. > >> >> France Telecom Group shall not be liable for the message if = altered, > changed > >> or falsified. > >> >> If you are not the intended addressee of this message, please = cancel it > >> immediately and inform the sender. > >> >> ******************************** > >> >> > >> >> > >> > > >> > ********************************* > >> > This message and any attachments (the "message") are confidential = and > >> intended solely for the addressees. > >> > Any unauthorised use or dissemination is prohibited. > >> > Messages are susceptible to alteration. > >> > France Telecom Group shall not be liable for the message if = altered, changed > >> or falsified. > >> > If you are not the intended addressee of this message, please = cancel it > >> immediately and inform the sender. > >> > ******************************** > >> > > >> > > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Tue Dec 1 01:41:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034663A6A20 for ; Tue, 1 Dec 2009 01:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQWz5J1KvWBA for ; Tue, 1 Dec 2009 01:41:45 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 02B073A67F4 for ; Tue, 1 Dec 2009 01:41:44 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 147DF65524E for ; Tue, 1 Dec 2009 10:41:36 +0100 (CET) Message-ID: <4B14E4D0.7070007@it.uc3m.es> Date: Tue, 01 Dec 2009 10:41:36 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17042.006 Subject: [BEHAVE] Handling fragments in the stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:41:46 -0000 Hi, after the discussion in hiroshima, I have updated the draft. The current 03 version reads: If the incoming IP packet contains a fragment, then more processing may be needed. This specification leaves open the exact details of how a NAT64 handles incoming IP packets containing fragments, and simply requires that a NAT64 handle fragments arriving out-of-order. A NAT64 MAY elect to queue the fragments as they arrive and translate all fragments at the same time. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the latter case, the NAT64 will still need to handle the situation where subsequent fragments arrive before the first. Implementors of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Assuming it otherwise has sufficient resources, a NAT64 MUST allow the fragments to arrive over a time interval of at least 10 seconds. A NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the first fragment. Let me know if you have issues witht eh current text. I hope it reflects the received feedback. Regards, marcelo From marcelo@it.uc3m.es Tue Dec 1 01:46:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1CB3A6A2A for ; Tue, 1 Dec 2009 01:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCG1Ts-jnRhP for ; Tue, 1 Dec 2009 01:46:50 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 34D473A680C for ; Tue, 1 Dec 2009 01:46:49 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 1201CBA69E1; Tue, 1 Dec 2009 10:46:41 +0100 (CET) Message-ID: <4B14E601.7020500@it.uc3m.es> Date: Tue, 01 Dec 2009 10:46:41 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Wing References: <4AFF20DC.2050308@viagenie.ca> <4B02FC62.9010309@viagenie.ca><4B0E9061.40107@ericsson.com> <4B0E9744.4080606@viagenie.ca> <04e301ca71ec$5b6dbf20$c3f0200a@cisco.com> In-Reply-To: <04e301ca71ec$5b6dbf20$c3f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:46:51 -0000 Dan Wing escribió: > > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Thursday, November 26, 2009 6:57 AM >> To: Magnus Westerlund >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling >> >> Magnus Westerlund wrote, on 2009-11-26 09:27: >> >>> I think for that address dependent mapping may work if one >>> >> restrict it >> >>> to cases where it is known that there is a strict client >>> >> server protocol >> >>> on the port. I think the most gain for the least hassle would be to >>> allow address dependent mappings for flows that has destination that >>> matches TCP.port=80 or TCP.port=443. I don't know how that >>> >> would affect >> >>> the more esoteric usages of HTTP. >>> >> Something similar to this was proposed by Rémi Després on >> 2008-05-22 with the >> name "Address-port sparing NATs". >> >> I would agree that this is a useful optimization. >> >> >>> But, in general it is difficult to know what application >>> >> that runs on >> >>> top of the transport protocol and what its need is. Thus >>> >> this should be >> >>> done with significant care. I would recommend a minimal set of >>> identified applications where an operator may chose this option to >>> achieve a bit better address re-use. >>> >> Agreed. >> >> Rémi Després suggested HTTP, HTTPS, DNS, POP3, IMAP, SNMP. >> >> I suggest that this list be interpreted as guidance for >> operators, as in e.g. >> "these protocols fine with adddress and port-dependent >> mappnig." Ultimately this >> is an operational issue and we can only provide guidance. >> >> However, address and port-dependent mapping is implemented completely >> differently than what is described in the current draft. For >> instance, there is >> no longer a need for separate binding and session tables. So >> I would like to >> hear from authors what they think of this suggestion, and if >> they'd like me to >> provide text. >> > > This sort of optimization feels like an informational/experimental-track > document and can be separate from draft-ietf-behave-v6v4-xlate-stateful. > Yes, this seems to be common to any CGN, nat64 and nat44. I understand that this is related to having bigger nat boxes and i understand there is ongoing work to identify what of the behave requirements can be lifted in the case of CGNs. So, this has been discussed several tiems already and the proposed way forward was: - define nat64 as complying with the behave requirements - define another doc where the behave requirements are contrasted witht eh reality of CGNs and identify which requirements can be lifted. makes sense? Regards, marcelo > -d > > > >> Simon >> -- >> DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> vCard 4.0 --> http://www.vcarddav.org >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From simon.perreault@viagenie.ca Tue Dec 1 02:38:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B96A3A67FC for ; Tue, 1 Dec 2009 02:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwTW2YUW2Kmq for ; Tue, 1 Dec 2009 02:38:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8E2043A67DF for ; Tue, 1 Dec 2009 02:38:09 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E8FB720806; Tue, 1 Dec 2009 05:38:01 -0500 (EST) Message-ID: <4B14F209.7050100@viagenie.ca> Date: Tue, 01 Dec 2009 05:38:01 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: marcelo bagnulo braun References: <4AFF20DC.2050308@viagenie.ca> <4B02FC62.9010309@viagenie.ca><4B0E9061.40107@ericsson.com> <4B0E9744.4080606@viagenie.ca> <04e301ca71ec$5b6dbf20$c3f0200a@cisco.com> <4B14E601.7020500@it.uc3m.es> In-Reply-To: <4B14E601.7020500@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 10:38:10 -0000 On 12/01/2009 04:46 AM, marcelo bagnulo braun wrote: > So, this has been discussed several tiems already and the proposed way > forward was: > - define nat64 as complying with the behave requirements > - define another doc where the behave requirements are contrasted witht > eh reality of CGNs and identify which requirements can be lifted. Oh, good. I certainly remember the discussions, but I don't remember that a decision had been made. > makes sense? Certainly! (But let's not talk about CGNs as if they were something completely different. They're not. It's just about scaling, which is a continuum.) Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Tue Dec 1 02:42:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0EC3A684F for ; Tue, 1 Dec 2009 02:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQcue0Z1+wNy for ; Tue, 1 Dec 2009 02:42:54 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 215253A6824 for ; Tue, 1 Dec 2009 02:42:54 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AE8B720DF9 for ; Tue, 1 Dec 2009 05:42:46 -0500 (EST) Message-ID: <4B14F326.40009@viagenie.ca> Date: Tue, 01 Dec 2009 05:42:46 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> In-Reply-To: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 10:42:55 -0000 On 12/01/2009 04:07 AM, Xu Xiaohu wrote: > In order to use the correct prefix64 in synthesizing AAAA records, the DNS64 should be able to determine which prefix64 is available by some means, e.g., exchanging messages with NAT64, or sending probe packets to a given IPv4 host within the IPv4 Internet by using different prefix64s. > > BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted till the corresponding AAAA records in the DNS caches of IPv6 hosts expire? This is exactly why each "box" is in fact many boxes whose state is synchronized. Handling the complete failure of a set of such boxes is really up to the operator and doesn't need to be standardized, in my opinion. Many custom actions would need to be taken in such a case. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Tue Dec 1 08:21:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5477128C0EE for ; Tue, 1 Dec 2009 08:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foaq2UaaE302 for ; Tue, 1 Dec 2009 08:21:50 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1FE4128C0E0 for ; Tue, 1 Dec 2009 08:21:50 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAHfRFEurRN+K/2dsb2JhbACKNrZSmAqCLoIDBIFq X-IronPort-AV: E=Sophos;i="4.47,321,1257120000"; d="scan'208";a="204122328" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2009 16:21:42 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1GLgaj002225; Tue, 1 Dec 2009 16:21:42 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <4AFF20DC.2050308@viagenie.ca> <4B02FC62.9010309@viagenie.ca><4B0E9061.40107@ericsson.com> <4B0E9744.4080606@viagenie.ca> <04e301ca71ec$5b6dbf20$c3f0200a@cisco.com> <4B14E601.7020500@it.uc3m.es> Date: Tue, 1 Dec 2009 08:21:42 -0800 Message-ID: <08f501ca72a2$5e5e0990$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B14E601.7020500@it.uc3m.es> Thread-index: AcpyazDX+JcuYPWyS/uBVq0D0aA91AANxbZQ Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:21:51 -0000 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Tuesday, December 01, 2009 1:47 AM > To: Dan Wing > Cc: 'Simon Perreault'; 'Magnus Westerlund'; behave@ietf.org > Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling >=20 > Dan Wing escribi=F3: > > =20 > > > > =20 > >> -----Original Message----- > >> From: behave-bounces@ietf.org=20 > >> [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault > >> Sent: Thursday, November 26, 2009 6:57 AM > >> To: Magnus Westerlund > >> Cc: behave@ietf.org > >> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling > >> > >> Magnus Westerlund wrote, on 2009-11-26 09:27: > >> =20 > >>> I think for that address dependent mapping may work if one=20 > >>> =20 > >> restrict it > >> =20 > >>> to cases where it is known that there is a strict client=20 > >>> =20 > >> server protocol > >> =20 > >>> on the port. I think the most gain for the least hassle=20 > would be to > >>> allow address dependent mappings for flows that has=20 > destination that > >>> matches TCP.port=3D80 or TCP.port=3D443. I don't know how that=20 > >>> =20 > >> would affect > >> =20 > >>> the more esoteric usages of HTTP. > >>> =20 > >> Something similar to this was proposed by R=E9mi Despr=E9s on=20 > >> 2008-05-22 with the > >> name "Address-port sparing NATs". > >> > >> I would agree that this is a useful optimization. > >> > >> =20 > >>> But, in general it is difficult to know what application=20 > >>> =20 > >> that runs on > >> =20 > >>> top of the transport protocol and what its need is. Thus=20 > >>> =20 > >> this should be > >> =20 > >>> done with significant care. I would recommend a minimal set of > >>> identified applications where an operator may chose this option to > >>> achieve a bit better address re-use. > >>> =20 > >> Agreed. > >> > >> R=E9mi Despr=E9s suggested HTTP, HTTPS, DNS, POP3, IMAP, SNMP. > >> > >> I suggest that this list be interpreted as guidance for=20 > >> operators, as in e.g. > >> "these protocols fine with adddress and port-dependent=20 > >> mappnig." Ultimately this > >> is an operational issue and we can only provide guidance. > >> > >> However, address and port-dependent mapping is implemented=20 > completely > >> differently than what is described in the current draft. For=20 > >> instance, there is > >> no longer a need for separate binding and session tables. So=20 > >> I would like to > >> hear from authors what they think of this suggestion, and if=20 > >> they'd like me to > >> provide text. > >> =20 > > > > This sort of optimization feels like an=20 > informational/experimental-track > > document and can be separate from=20 > draft-ietf-behave-v6v4-xlate-stateful. > > =20 >=20 > Yes, this seems to be common to any CGN, nat64 and nat44. > I understand that this is related to having bigger nat boxes and i=20 > understand there is ongoing work to identify what of the behave=20 > requirements can be lifted in the case of CGNs. >=20 > So, this has been discussed several tiems already and the=20 > proposed way=20 > forward was: > - define nat64 as complying with the behave requirements > - define another doc where the behave requirements are=20 > contrasted witht=20 > eh reality of CGNs and identify which requirements can be lifted. >=20 > makes sense? Yes, makes sense. It also allows us to keep stateful NAT64 on its current schedule to be sent to IESG this month. -d > Regards, marcelo >=20 >=20 > > -d > > > > > > =20 > >> Simon > >> --=20 > >> DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca > >> vCard 4.0 --> http://www.vcarddav.org > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> =20 > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > =20 >=20 From dwing@cisco.com Tue Dec 1 08:22:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8913A63EB for ; Tue, 1 Dec 2009 08:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3GVExnQXMvv for ; Tue, 1 Dec 2009 08:22:48 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DA0583A672E for ; Tue, 1 Dec 2009 08:22:48 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPzRFEurRN+K/2dsb2JhbACKNrZdmAqCLoIDBIFq X-IronPort-AV: E=Sophos;i="4.47,321,1257120000"; d="scan'208";a="226561907" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2009 16:22:41 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1GMfqo002980; Tue, 1 Dec 2009 16:22:41 GMT From: "Dan Wing" To: "'Simon Perreault'" , "'marcelo bagnulo braun'" References: <4AFF20DC.2050308@viagenie.ca> <4B02FC62.9010309@viagenie.ca><4B0E9061.40107@ericsson.com> <4B0E9744.4080606@viagenie.ca> <04e301ca71ec$5b6dbf20$c3f0200a@cisco.com> <4B14E601.7020500@it.uc3m.es> <4B14F209.7050100@viagenie.ca> Date: Tue, 1 Dec 2009 08:22:41 -0800 Message-ID: <08f601ca72a2$8187a7a0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B14F209.7050100@viagenie.ca> Thread-index: AcpyclyqO5pTqAZmQMOivJDuE/RyUgAMAcEQ Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:22:49 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, December 01, 2009 2:38 AM > To: marcelo bagnulo braun > Cc: Dan Wing; 'Magnus Westerlund'; behave@ietf.org > Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling > > On 12/01/2009 04:46 AM, marcelo bagnulo braun wrote: > > So, this has been discussed several tiems already and the > proposed way > > forward was: > > - define nat64 as complying with the behave requirements > > - define another doc where the behave requirements are > contrasted witht > > eh reality of CGNs and identify which requirements can be lifted. > > Oh, good. I certainly remember the discussions, but I don't remember > that a decision had been made. > > > makes sense? > > Certainly! > > (But let's not talk about CGNs as if they were something completely > different. They're not. It's just about scaling, which is a > continuum.) "LSN" (large scale NAT) is perhaps the better term; afterall, you don't necessarily need to be a "carrier" to want/need a large NAT. You might be a University, a large company, etc. -d > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org From cb.list6@gmail.com Tue Dec 1 09:10:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AAB3A6A22 for ; Tue, 1 Dec 2009 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCotLUoRMGUt for ; Tue, 1 Dec 2009 09:10:36 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 5FB8B3A68E4 for ; Tue, 1 Dec 2009 09:10:35 -0800 (PST) Received: by ywh15 with SMTP id 15so4405812ywh.5 for ; Tue, 01 Dec 2009 09:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PhFpjnct/L40FPhEQarSholfHHSNa5zLIh8vJ01xKwg=; b=UbgFZA2cvKjzbqteix1PYPZgdMSZnUhCAApni2jBQiCJqQLD1Zgo5N8hMOcRb1F+// dlNcQh6HVvoBN+qL9BxpxZ3Vfj1ORyNEgFPV/PPlBqYE+HBeAUxNIVQEe8Y6deLT4Ahj lJEOrFl+qnsrCB4v1CuyokFiDhl2sCCzdHU08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=woGOAuOnxizcj5bv1TSsj7ZH2jRS/+2ncB5XzEBo38Z1oBxU6Y2hdvkdLX1pk24fAC 0LaMEylt815pUHI15c79alcRDA/8w2febBZGmrZKlUfueMyOnx8bCc/Fo4/IzCaCtV0y BkyJUGbvvWV7bOM5P6d18DRpqRtlR1dozczg4= MIME-Version: 1.0 Received: by 10.150.129.27 with SMTP id b27mr10201399ybd.208.1259687420417; Tue, 01 Dec 2009 09:10:20 -0800 (PST) In-Reply-To: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> Date: Tue, 1 Dec 2009 09:10:20 -0800 Message-ID: From: Cameron Byrne To: Xu Xiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:10:39 -0000 On Tue, Dec 1, 2009 at 1:07 AM, Xu Xiaohu wrote: > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Cameron Byrne [mailto:cb.list6@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=881=E6=97=A5= 15:32 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu >> =E6=8A=84=E9=80=81: mohamed.boucadair@orange-ftgroup.com; behave@ietf.or= g >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s standard= isedprotocols//re: >> draft-xu-behave-nat-state-sync-00 >> >> On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu wrote: >> > >> > >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org [mailto:behave-b= ounces@ietf.org] =E4=BB=A3=E8=A1=A8 >> >> Cameron Byrne >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=881=E6=97= =A5 1:19 >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: mohamed.boucadair@orange-ftgroup.com >> >> =E6=8A=84=E9=80=81: behave@ietf.org; Xu Xiaohu >> >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s stand= ardised >> protocols//re: >> >> draft-xu-behave-nat-state-sync-00 >> >> >> >> On Mon, Nov 30, 2009 at 4:54 AM, =C2=A0 >> >> wrote: >> >> > >> >> > Dear Cameron, >> >> > >> >> > The issue you are describing is more about load distribution rather= than >> NAT >> >> state sync. >> >> >> >> Correct, i believe we can best provide service availability in the >> >> macro network with DNS64 controlled load distribution. =C2=A0NAT sync= in >> >> the macro network faces too many challenges to be useful >> > >> > Do you want to use DNS64 to achieve NAT redundancy while realizing >> load-balancing? Do you mean offering the IPv6 host another prefix64 by D= NS64 >> if the NAT box for the previous prefix crashes? >> > >> > Xiaohu >> >> Yes, I want DNS64 to facilitate NAT64 redundancy from a macro-network >> perspective while also providing load-sharing. Load sharing and >> redundancy are frequently coupled (web server farms, sip proxies, >> anycast DNS servers ...). =C2=A0This solutions is only focused on AAAA >> query responses to an IPv6-only host from a DNS64, which in my >> use-case is the most common scenario. =C2=A0Other use-cases do not inter= est >> me as much and may better fit a well know anycast prefix64. > > In order to use the correct prefix64 in synthesizing AAAA records, the DN= S64 should be able to determine which prefix64 is available by some means, = e.g., exchanging messages with NAT64, or sending probe packets to a given I= Pv4 host within the IPv4 Internet by using different prefix64s. > Yes, i have suggested that the DNS64 SNMP poll the NAT64 to understand its health and load (CPU, memory, active connections, ...). > BTW, once the NAT box for a given prefix fails, would the communications = using that prefix be interrupted till the corresponding AAAA records in the= DNS caches of IPv6 hosts expire? > Yes, the host would have to re-query to the DNS64 unless we wanted to provide the host with multiple AAAA responses with different addresses synthesized from different pref64 > Xiaohu > >> >> > I agree with the requirement you have (BTW, similar solutions exist= for >> the >> >> selection of the outbound proxy SIP) but this may be easy to implemen= t with >> >> stateless NATxy rather than stateful one since the path MUST be symme= tric >> (the >> >> same NAT device must be crossed) and appropriate routing actions shou= ld be >> >> undertaken to redirect the traffic to the appropriate NATxy device. I= f you >> have >> >> a fully distributed NATxy and all advertise the same IPv4 net, then t= he >> symmetry >> >> requirement is difficult to meet. Not to mention that the load should= be >> >> controlled in both sides of the NAT. >> >> > >> >> >> >> Unfortunately, i have yet to find an useful application for stateless >> >> NATxy in my network. =C2=A0The NAT44 i have deployed today require >> >> multiplexing many users behind a small pool public IP address. >> >> Changing the source from IPv4 to IPv6 will face the same limitation >> >> that requires multiplexing many users behind a few IPv4 addresses and >> >> consequently requires a stateful multiplexed solution. >> >> >> >> Regarding symmetrical flows, I don't really understand your comment. >> >> I don't support the idea of macro network state sync, and i do see >> >> that people who try to deploy that will have a symmetry issue. >> >> >> >> My expectation is that each stateful NAT64 (local 1+1) with a unique >> >> PREF64 will advertise a unique IPv4 prefix, so the flows are always >> >> symmetric. =C2=A0The entire network has many stateful NAT64 (local 1+= 1) and >> >> the translation load and resiliency is solved by distributing these >> >> autonomous building blocks of capacity and availability throughout th= e >> >> network. >> >> >> >> > Cheers, >> >> > Med >> >> > >> >> > >> >> > -----Message d'origine----- >> >> > De : Cameron Byrne [mailto:cb.list6@gmail.com] >> >> > Envoy=C3=A9 : jeudi 26 novembre 2009 18:43 >> >> > =C3=80 : BOUCADAIR Mohamed NCPI/NAD/TIP >> >> > Cc : Xu Xiaohu; Brian E Carpenter; behave@ietf.org >> >> > Objet : Re: [BEHAVE] proprietary implementation v.s standardised pr= otocols >> >> //re: draft-xu-behave-nat-state-sync-00 >> >> > >> >> > On Thu, Nov 26, 2009 at 12:04 AM, =C2=A0 >> >> wrote: >> >> >> >> >> >> Dear Cameron, >> >> >> >> >> >> This may be true for 1+1 redundancy schemes, but what about N+1 on= es? >> >> > >> >> > In other threads i have proposed using multiple =C2=A0NAT64 / PREF6= 4 pairs >> >> > handed out by the DNS64, and having feedback from the NAT64 to the >> >> > DNS64 to communicate health of NAT64 box such that the PREF64 can b= e >> >> > taken out of rotation if needed by the DNS64. =C2=A0This is how glo= bal site >> >> > load balancing works today for web sites and CDNs. =C2=A0I do expec= t this >> >> > type of implementation to have NAT64 in 1+1 for local instant fault >> >> > tolerance and the DNS64 to be a more macro level recovery and load >> >> > sharing technique >> >> > >> >> > If can't get it into the standard, i can get a vendor to do it. =C2= =A0And, >> >> > if i can't get a vendor to do it i can probably rig it myself with = a >> >> > perl script to SNMP poll the NAT64 for health and load and reset th= e >> >> > DNS64 config automatically to redirect traffic from bad PREF64 / >> >> > NAT64s to good PREF64 NAT64s >> >> > >> >> > I know the tricks that global site load balancing does are not pure= , >> >> > but my perpective is that this is the reality of the internet, it i= s >> >> > the only way google, facebook, yahoo can scale. =C2=A0It is the onl= y way >> >> > NAT64 can scale linearly as a system of hardware building blocks an= d >> >> > survive at a macro level. >> >> > >> >> > Cameron >> >> > >> >> >> >> >> >> Cheers >> >> >> Med >> >> >> >> >> >> >> >> >> -----Message d'origine----- >> >> >> De : Cameron Byrne [mailto:cb.list6@gmail.com] >> >> >> Envoy=C3=A9 : mercredi 25 novembre 2009 18:50 >> >> >> =C3=80 : Xu Xiaohu >> >> >> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E Carpenter; behave@iet= f.org >> >> >> Objet : Re: [BEHAVE] proprietary implementation v.s standardised >> protocols >> >> //re: draft-xu-behave-nat-state-sync-00 >> >> >> >> >> >> On Wed, Nov 25, 2009 at 2:05 AM, Xu Xiaohu wrote= : >> >> >>> >> >> >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org [mailto:beh= ave-bounces@ietf.org] =E4=BB=A3 >> =E8=A1=A8 >> >> >>>> mohamed.boucadair@orange-ftgroup.com >> >> >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B411=E6=9C=8813= =E6=97=A5 14:41 >> >> >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Brian E Carpenter; behave@ietf.org >> >> >>>> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] draft-xu-behave-nat-state-sync-= 00 >> >> >>>> >> >> >>>> >> >> >>>> Dear all, >> >> >>>> >> >> >>>> I guess that the question should be asked priori to yours: >> >> >>>> >> >> >>>> Do we let vendors define their proprietary solutions or does the= IETF >> >> define >> >> >>>> a solution based on standardised protocols to achieve reliable s= tate >> >> >>>> synchronisation? >> >> >>> >> >> >>> For a small enterprise network, maybe it's acceptable to deploy t= wo or >> more >> >> NAT boxes purchased from the same vendor for redundancy. However, for= a large >> >> ISP network or large enterprise network, it is not reliable enough. F= or >> example, >> >> an abnormal packet will cause the router OS to crash, it is not absol= utely >> >> acceptable. Hence I believe the standardization of NAT redundancy is >> necessary. >> >> >>> >> >> >> >> >> >> In the large scale NAT44 we run today, all vendors have 1+1 >> >> >> proprietary state sync. =C2=A0They also sync configuration and oth= er OAM >> >> >> elements over this sync channel. =C2=A0I do not think it is at all= required >> >> >> for vendors to have a standard state sync. =C2=A0If I deploy multi= ple >> >> >> vendors for NAT, i will keep the 1+1 pairs of the same vendor and = use >> >> >> different vendor 1+1 pairs for higher level network topology drive= n >> >> >> redundancy, not local state synchronization. >> >> >> >> >> >> Cameron Byrne >> >> >> Principal Engineer >> >> >> T-Mobile USA >> >> >> >> >> >>> Xiaohu >> >> >>> >> >> >>> >> >> >>>> From a service provider perspective, I'd like to see a solution = with >> IETF >> >> stamp >> >> >>>> so as to be included in our RFPs/analysis. Vendors are then free= to >> propose >> >> >>>> more reliable solutions, if any, compared to the one standardise= d by >> IETF. >> >> >>>> >> >> >>>> Cheers, >> >> >>>> Med >> >> >>>> >> >> >>>> >> >> >>>> -----Message d'origine----- >> >> >>>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De= la >> part >> >> de >> >> >>>> Brian E Carpenter >> >> >>>> Envoy=C3=A9 : vendredi 13 novembre 2009 02:55 >> >> >>>> =C3=80 : behave@ietf.org >> >> >>>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00 >> >> >>>> >> >> >>>> My question about this draft is whether there is available code = and >> >> >>>> implementation experience with SCSP, which was defined in 1998. >> >> >>>> >> >> >>>> If there isn't code and experience, since it is a quite complex = design, >> >> I would >> >> >>>> be a bit worried. >> >> >>>> >> >> >>>> On the other hand, I believe that something of the complexity of= SCSP >> is >> >> >>>> absolutely required to provide reliable synchronisation. >> >> >>>> There is no simple, lightweight way to do this reliably. >> >> >>>> >> >> >>>> =C2=A0 =C2=A0 Brian >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Behave mailing list >> >> >>>> Behave@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/behave >> >> >>>> >> >> >>>> ********************************* >> >> >>>> This message and any attachments (the "message") are confidentia= l and >> >> intended >> >> >>>> solely for the addressees. >> >> >>>> Any unauthorised use or dissemination is prohibited. >> >> >>>> Messages are susceptible to alteration. >> >> >>>> France Telecom Group shall not be liable for the message if alte= red, >> >> changed >> >> >>>> or falsified. >> >> >>>> If you are not the intended addressee of this message, please ca= ncel >> it >> >> >>>> immediately and inform the sender. >> >> >>>> ******************************** >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Behave mailing list >> >> >>>> Behave@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/behave >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Behave mailing list >> >> >>> Behave@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/behave >> >> >>> >> >> >> >> >> >> ********************************* >> >> >> This message and any attachments (the "message") are confidential = and >> >> intended solely for the addressees. >> >> >> Any unauthorised use or dissemination is prohibited. >> >> >> Messages are susceptible to alteration. >> >> >> France Telecom Group shall not be liable for the message if altere= d, >> changed >> >> or falsified. >> >> >> If you are not the intended addressee of this message, please canc= el it >> >> immediately and inform the sender. >> >> >> ******************************** >> >> >> >> >> >> >> >> > >> >> > ********************************* >> >> > This message and any attachments (the "message") are confidential a= nd >> >> intended solely for the addressees. >> >> > Any unauthorised use or dissemination is prohibited. >> >> > Messages are susceptible to alteration. >> >> > France Telecom Group shall not be liable for the message if altered= , changed >> >> or falsified. >> >> > If you are not the intended addressee of this message, please cance= l it >> >> immediately and inform the sender. >> >> > ******************************** >> >> > >> >> > >> >> _______________________________________________ >> >> Behave mailing list >> >> Behave@ietf.org >> >> https://www.ietf.org/mailman/listinfo/behave >> > >> > _______________________________________________ >> > Behave mailing list >> > Behave@ietf.org >> > https://www.ietf.org/mailman/listinfo/behave >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From cb.list6@gmail.com Tue Dec 1 09:11:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555643A6A24 for ; Tue, 1 Dec 2009 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6Z+DLXeQLU for ; Tue, 1 Dec 2009 09:11:47 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id E023D28C101 for ; Tue, 1 Dec 2009 09:11:43 -0800 (PST) Received: by yxe30 with SMTP id 30so10285197yxe.29 for ; Tue, 01 Dec 2009 09:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bXfUcT7r4Kzvdw8xL1+VRLtMO/LrCOZUXBRbY2aXULU=; b=cFbXw7yJmPrG7ToDaZbjwxc4a46TxuTHFVo/lvEC8GDC9RidKk/cEIMtEK5r0Z38mB 3XX54wCUhuPWWbZFxrKhT2CD7FY+Z6s/gvwXB2Fm8zvkVNfD5xi4PxTcA+RWgZSnqSjq eGYuMEJqA+kydt7v1grDUPkVkc56eN9wu559Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jNVuqmPtiOddyn+DfvUkc76jEXcYmgkM+tHegPeKesI6MwR4fx+Nw9W/GLdXjEJHyj 25pKbilqL1mvwqN2XPBDvVVlgXflmK/n3D84xGCTGkul0dVwJpCsqFRg7tbcVwAE5HvU d9XVfvb9B/xeru0QT4Nt+Gjq3no1vcUqYVIUk= MIME-Version: 1.0 Received: by 10.150.28.27 with SMTP id b27mr10306207ybb.59.1259687492873; Tue, 01 Dec 2009 09:11:32 -0800 (PST) In-Reply-To: <4B14F326.40009@viagenie.ca> References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <4B14F326.40009@viagenie.ca> Date: Tue, 1 Dec 2009 09:11:32 -0800 Message-ID: From: Cameron Byrne To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:11:49 -0000 On Tue, Dec 1, 2009 at 2:42 AM, Simon Perreault wrote: > On 12/01/2009 04:07 AM, Xu Xiaohu wrote: >> >> In order to use the correct prefix64 in synthesizing AAAA records, the >> DNS64 should be able to determine which prefix64 is available by some me= ans, >> e.g., exchanging messages with NAT64, or sending probe packets to a give= n >> IPv4 host within the IPv4 Internet by using different prefix64s. >> >> BTW, once the NAT box for a given prefix fails, would the communications >> using that prefix be interrupted till the corresponding AAAA records in = the >> DNS caches of IPv6 hosts expire? > > This is exactly why each "box" is in fact many boxes whose state is > synchronized. > > Handling the complete failure of a set of such boxes is really up to the > operator and doesn't need to be standardized, in my opinion. Many custom > actions would need to be taken in such a case. agreed. > > Simon > -- > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Tue Dec 1 09:16:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9223A68E4 for ; Tue, 1 Dec 2009 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUtaEMgN03s8 for ; Tue, 1 Dec 2009 09:16:41 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 125DB3A6A0C for ; Tue, 1 Dec 2009 09:16:41 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJzeFEurRN+J/2dsb2JhbACESIVutmmHD5EDgS+CL1MEgWo X-IronPort-AV: E=Sophos;i="4.47,321,1257120000"; d="scan'208";a="112202419" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2009 17:16:33 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB1HGXO7014837; Tue, 1 Dec 2009 17:16:33 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'Cameron Byrne'" References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> Date: Tue, 1 Dec 2009 09:16:33 -0800 Message-ID: <097401ca72aa$0828aa50$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> Thread-index: AcpyWIu0sFUFn6wNSvyOT+CH1uW4WAACIJ8wABIT/XA= Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:16:43 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > Sent: Tuesday, December 01, 2009 1:08 AM > To: 'Cameron Byrne' > Cc: behave@ietf.org; mohamed.boucadair@orange-ftgroup.com > Subject: Re: [BEHAVE] proprietary implementation v.s=20 > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 >=20 >=20 >=20 > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Cameron Byrne = [mailto:cb.list6@gmail.com] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=881=E6=97=A5 15:32 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu > > =E6=8A=84=E9=80=81: mohamed.boucadair@orange-ftgroup.com; = behave@ietf.org > > =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s=20 > standardisedprotocols//re: > > draft-xu-behave-nat-state-sync-00 > >=20 > > On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu wrote: > > > > > > > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > > >> Cameron Byrne > > >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=881=E6=97=A5 1:19 > > >> =E6=94=B6=E4=BB=B6=E4=BA=BA: mohamed.boucadair@orange-ftgroup.com > > >> =E6=8A=84=E9=80=81: behave@ietf.org; Xu Xiaohu > > >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s = standardised > > protocols//re: > > >> draft-xu-behave-nat-state-sync-00 > > >> > > >> On Mon, Nov 30, 2009 at 4:54 AM, =20 > > > >> wrote: > > >> > > > >> > Dear Cameron, > > >> > > > >> > The issue you are describing is more about load=20 > distribution rather than > > NAT > > >> state sync. > > >> > > >> Correct, i believe we can best provide service=20 > availability in the > > >> macro network with DNS64 controlled load distribution. =20 > NAT sync in > > >> the macro network faces too many challenges to be useful > > > > > > Do you want to use DNS64 to achieve NAT redundancy while realizing > > load-balancing? Do you mean offering the IPv6 host another=20 > prefix64 by DNS64 > > if the NAT box for the previous prefix crashes? > > > > > > Xiaohu > >=20 > > Yes, I want DNS64 to facilitate NAT64 redundancy from a=20 > macro-network > > perspective while also providing load-sharing. Load sharing and > > redundancy are frequently coupled (web server farms, sip proxies, > > anycast DNS servers ...). This solutions is only focused on AAAA > > query responses to an IPv6-only host from a DNS64, which in my > > use-case is the most common scenario. Other use-cases do=20 > not interest > > me as much and may better fit a well know anycast prefix64. >=20 > In order to use the correct prefix64 in synthesizing AAAA=20 > records, the DNS64 should be able to determine which prefix64=20 > is available by some means, e.g., exchanging messages with=20 > NAT64, or sending probe packets to a given IPv4 host within=20 > the IPv4 Internet by using different prefix64s. >=20 > BTW, once the NAT box for a given prefix fails, would the=20 > communications using that prefix be interrupted till the=20 > corresponding AAAA records in the DNS caches of IPv6 hosts expire? It's not just the AAAA records getting cached. It's also the=20 applications that have done their getaddrinfo() and now have the IPv6 address in their internal datastructures. There is no lifetime for that, and very very few applications pay any attention to the TTL of the AAAA record. Applications expect the IPv6 address to=20 be fixed and to be valid as long as they need it. This means that to provide reasonable service, 'backup' NAT64=20 has to serve the same Pref64 as the now-failed NAT64, and=20 routing needs to send those IPv6 packets towards the 'backup'=20 NAT64 (typically accomplished on a LAN with HSRP or VRRP). -d > Xiaohu >=20 > > >> > I agree with the requirement you have (BTW, similar=20 > solutions exist for > > the > > >> selection of the outbound proxy SIP) but this may be=20 > easy to implement with > > >> stateless NATxy rather than stateful one since the path=20 > MUST be symmetric > > (the > > >> same NAT device must be crossed) and appropriate routing=20 > actions should be > > >> undertaken to redirect the traffic to the appropriate=20 > NATxy device. If you > > have > > >> a fully distributed NATxy and all advertise the same=20 > IPv4 net, then the > > symmetry > > >> requirement is difficult to meet. Not to mention that=20 > the load should be > > >> controlled in both sides of the NAT. > > >> > > > >> > > >> Unfortunately, i have yet to find an useful application=20 > for stateless > > >> NATxy in my network. The NAT44 i have deployed today require > > >> multiplexing many users behind a small pool public IP address. > > >> Changing the source from IPv4 to IPv6 will face the same=20 > limitation > > >> that requires multiplexing many users behind a few IPv4=20 > addresses and > > >> consequently requires a stateful multiplexed solution. > > >> > > >> Regarding symmetrical flows, I don't really understand=20 > your comment. > > >> I don't support the idea of macro network state sync,=20 > and i do see > > >> that people who try to deploy that will have a symmetry issue. > > >> > > >> My expectation is that each stateful NAT64 (local 1+1)=20 > with a unique > > >> PREF64 will advertise a unique IPv4 prefix, so the flows=20 > are always > > >> symmetric. The entire network has many stateful NAT64=20 > (local 1+1) and > > >> the translation load and resiliency is solved by=20 > distributing these > > >> autonomous building blocks of capacity and availability=20 > throughout the > > >> network. > > >> > > >> > Cheers, > > >> > Med > > >> > > > >> > > > >> > -----Message d'origine----- > > >> > De : Cameron Byrne [mailto:cb.list6@gmail.com] > > >> > Envoy=C3=A9 : jeudi 26 novembre 2009 18:43 > > >> > =C3=80 : BOUCADAIR Mohamed NCPI/NAD/TIP > > >> > Cc : Xu Xiaohu; Brian E Carpenter; behave@ietf.org > > >> > Objet : Re: [BEHAVE] proprietary implementation v.s=20 > standardised protocols > > >> //re: draft-xu-behave-nat-state-sync-00 > > >> > > > >> > On Thu, Nov 26, 2009 at 12:04 AM, =20 > > > >> wrote: > > >> >> > > >> >> Dear Cameron, > > >> >> > > >> >> This may be true for 1+1 redundancy schemes, but what=20 > about N+1 ones? > > >> > > > >> > In other threads i have proposed using multiple NAT64=20 > / PREF64 pairs > > >> > handed out by the DNS64, and having feedback from the=20 > NAT64 to the > > >> > DNS64 to communicate health of NAT64 box such that the=20 > PREF64 can be > > >> > taken out of rotation if needed by the DNS64. This is=20 > how global site > > >> > load balancing works today for web sites and CDNs. I=20 > do expect this > > >> > type of implementation to have NAT64 in 1+1 for local=20 > instant fault > > >> > tolerance and the DNS64 to be a more macro level=20 > recovery and load > > >> > sharing technique > > >> > > > >> > If can't get it into the standard, i can get a vendor=20 > to do it. And, > > >> > if i can't get a vendor to do it i can probably rig it=20 > myself with a > > >> > perl script to SNMP poll the NAT64 for health and load=20 > and reset the > > >> > DNS64 config automatically to redirect traffic from=20 > bad PREF64 / > > >> > NAT64s to good PREF64 NAT64s > > >> > > > >> > I know the tricks that global site load balancing does=20 > are not pure, > > >> > but my perpective is that this is the reality of the=20 > internet, it is > > >> > the only way google, facebook, yahoo can scale. It is=20 > the only way > > >> > NAT64 can scale linearly as a system of hardware=20 > building blocks and > > >> > survive at a macro level. > > >> > > > >> > Cameron > > >> > > > >> >> > > >> >> Cheers > > >> >> Med > > >> >> > > >> >> > > >> >> -----Message d'origine----- > > >> >> De : Cameron Byrne [mailto:cb.list6@gmail.com] > > >> >> Envoy=C3=A9 : mercredi 25 novembre 2009 18:50 > > >> >> =C3=80 : Xu Xiaohu > > >> >> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E=20 > Carpenter; behave@ietf.org > > >> >> Objet : Re: [BEHAVE] proprietary implementation v.s=20 > standardised > > protocols > > >> //re: draft-xu-behave-nat-state-sync-00 > > >> >> > > >> >> On Wed, Nov 25, 2009 at 2:05 AM, Xu Xiaohu=20 > wrote: > > >> >>> > > >> >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > >> >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] =E4=BB=A3 > > =E8=A1=A8 > > >> >>>> mohamed.boucadair@orange-ftgroup.com > > >> >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B411=E6=9C=8813=E6=97=A5 14:41 > > >> >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Brian E Carpenter; = behave@ietf.org > > >> >>>> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] = draft-xu-behave-nat-state-sync-00 > > >> >>>> > > >> >>>> > > >> >>>> Dear all, > > >> >>>> > > >> >>>> I guess that the question should be asked priori to yours: > > >> >>>> > > >> >>>> Do we let vendors define their proprietary=20 > solutions or does the IETF > > >> define > > >> >>>> a solution based on standardised protocols to=20 > achieve reliable state > > >> >>>> synchronisation? > > >> >>> > > >> >>> For a small enterprise network, maybe it's=20 > acceptable to deploy two or > > more > > >> NAT boxes purchased from the same vendor for redundancy.=20 > However, for a large > > >> ISP network or large enterprise network, it is not=20 > reliable enough. For > > example, > > >> an abnormal packet will cause the router OS to crash, it=20 > is not absolutely > > >> acceptable. Hence I believe the standardization of NAT=20 > redundancy is > > necessary. > > >> >>> > > >> >> > > >> >> In the large scale NAT44 we run today, all vendors have 1+1 > > >> >> proprietary state sync. They also sync configuration=20 > and other OAM > > >> >> elements over this sync channel. I do not think it=20 > is at all required > > >> >> for vendors to have a standard state sync. If I=20 > deploy multiple > > >> >> vendors for NAT, i will keep the 1+1 pairs of the=20 > same vendor and use > > >> >> different vendor 1+1 pairs for higher level network=20 > topology driven > > >> >> redundancy, not local state synchronization. > > >> >> > > >> >> Cameron Byrne > > >> >> Principal Engineer > > >> >> T-Mobile USA > > >> >> > > >> >>> Xiaohu > > >> >>> > > >> >>> > > >> >>>> From a service provider perspective, I'd like to=20 > see a solution with > > IETF > > >> stamp > > >> >>>> so as to be included in our RFPs/analysis. Vendors=20 > are then free to > > propose > > >> >>>> more reliable solutions, if any, compared to the=20 > one standardised by > > IETF. > > >> >>>> > > >> >>>> Cheers, > > >> >>>> Med > > >> >>>> > > >> >>>> > > >> >>>> -----Message d'origine----- > > >> >>>> De : behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] De la > > part > > >> de > > >> >>>> Brian E Carpenter > > >> >>>> Envoy=C3=A9 : vendredi 13 novembre 2009 02:55 > > >> >>>> =C3=80 : behave@ietf.org > > >> >>>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00 > > >> >>>> > > >> >>>> My question about this draft is whether there is=20 > available code and > > >> >>>> implementation experience with SCSP, which was=20 > defined in 1998. > > >> >>>> > > >> >>>> If there isn't code and experience, since it is a=20 > quite complex design, > > >> I would > > >> >>>> be a bit worried. > > >> >>>> > > >> >>>> On the other hand, I believe that something of the=20 > complexity of SCSP > > is > > >> >>>> absolutely required to provide reliable synchronisation. > > >> >>>> There is no simple, lightweight way to do this reliably. > > >> >>>> > > >> >>>> Brian > > >> >>>> > > >> >>>> _______________________________________________ > > >> >>>> Behave mailing list > > >> >>>> Behave@ietf.org > > >> >>>> https://www.ietf.org/mailman/listinfo/behave > > >> >>>> > > >> >>>> ********************************* > > >> >>>> This message and any attachments (the "message")=20 > are confidential and > > >> intended > > >> >>>> solely for the addressees. > > >> >>>> Any unauthorised use or dissemination is prohibited. > > >> >>>> Messages are susceptible to alteration. > > >> >>>> France Telecom Group shall not be liable for the=20 > message if altered, > > >> changed > > >> >>>> or falsified. > > >> >>>> If you are not the intended addressee of this=20 > message, please cancel > > it > > >> >>>> immediately and inform the sender. > > >> >>>> ******************************** > > >> >>>> > > >> >>>> _______________________________________________ > > >> >>>> Behave mailing list > > >> >>>> Behave@ietf.org > > >> >>>> https://www.ietf.org/mailman/listinfo/behave > > >> >>> > > >> >>> _______________________________________________ > > >> >>> Behave mailing list > > >> >>> Behave@ietf.org > > >> >>> https://www.ietf.org/mailman/listinfo/behave > > >> >>> > > >> >> > > >> >> ********************************* > > >> >> This message and any attachments (the "message") are=20 > confidential and > > >> intended solely for the addressees. > > >> >> Any unauthorised use or dissemination is prohibited. > > >> >> Messages are susceptible to alteration. > > >> >> France Telecom Group shall not be liable for the=20 > message if altered, > > changed > > >> or falsified. > > >> >> If you are not the intended addressee of this=20 > message, please cancel it > > >> immediately and inform the sender. > > >> >> ******************************** > > >> >> > > >> >> > > >> > > > >> > ********************************* > > >> > This message and any attachments (the "message") are=20 > confidential and > > >> intended solely for the addressees. > > >> > Any unauthorised use or dissemination is prohibited. > > >> > Messages are susceptible to alteration. > > >> > France Telecom Group shall not be liable for the=20 > message if altered, changed > > >> or falsified. > > >> > If you are not the intended addressee of this message,=20 > please cancel it > > >> immediately and inform the sender. > > >> > ******************************** > > >> > > > >> > > > >> _______________________________________________ > > >> Behave mailing list > > >> Behave@ietf.org > > >> https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From dwing@cisco.com Tue Dec 1 09:24:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DBD3A68B8 for ; Tue, 1 Dec 2009 09:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzLrirZ05EAd for ; Tue, 1 Dec 2009 09:24:30 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D52A33A689B for ; Tue, 1 Dec 2009 09:24:30 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMPfFEurRN+K/2dsb2JhbACKNrZgmBKEMQSBag X-IronPort-AV: E=Sophos;i="4.47,321,1257120000"; d="scan'208";a="112208840" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2009 17:23:58 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1HNvcS028466; Tue, 1 Dec 2009 17:23:57 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , "'Behave WG'" References: <4B14E4D0.7070007@it.uc3m.es> Date: Tue, 1 Dec 2009 09:23:58 -0800 Message-ID: <097b01ca72ab$11232350$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B14E4D0.7070007@it.uc3m.es> Thread-index: Acpyanw9YHpb2JO5TQWdEipdXgyqPgAQDUmA Subject: Re: [BEHAVE] Handling fragments in the stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:24:31 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Tuesday, December 01, 2009 1:42 AM > To: Behave WG > Subject: [BEHAVE] Handling fragments in the stateful NAT64 > > Hi, > > after the discussion in hiroshima, I have updated the draft. > The current 03 version reads: > > If the incoming IP packet contains a fragment, then more processing > may be needed. This specification leaves open the exact details of > how a NAT64 handles incoming IP packets containing fragments, and > simply requires that a NAT64 handle fragments arriving > out-of-order. That sentence above says "requires that a NAT64 handle fragments arriving out-of-order", yet ... (see "A", below) > A NAT64 MAY elect to queue the fragments as they arrive > and translate > all fragments at the same time. Alternatively, a NAT64 > MAY translate > the fragments as they arrive, by storing information that allows it > to compute the 5-tuple for fragments other than the first. In the > latter case, the NAT64 will still need to handle the > situation where > subsequent fragments arrive before the first. > > Implementors of NAT64 should be aware that there are a number of > well-known attacks against IP fragmentation; see [RFC1858] and > [RFC3128]. RFC4963 might be useful to cite, as well. > Assuming it otherwise has sufficient resources, a NAT64 MUST allow > the fragments to arrive over a time interval of at least > 10 seconds. "A": The sentence below does *not* require the NAT64 to handle out-of- order fragments. The sentence below contains a RFC2119 keyword, so I guess it is normative and overrides the non-RFC2119 sentence above, but it would be better if the descriptive text above matched the RFC2119 keyworded sentence below. Or remove one or the other. > A NAT64 MAY require that the UDP, TCP, or ICMP header be completely > contained within the first fragment. -d > > Let me know if you have issues witht eh current text. I hope > it reflects > the received feedback. > > Regards, marcelo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Tue Dec 1 09:46:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DF83A68E4 for ; Tue, 1 Dec 2009 09:46:38 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wh62DXRNFcD for ; Tue, 1 Dec 2009 09:46:37 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 67A373A6881 for ; Tue, 1 Dec 2009 09:46:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVWbPHoVtV6NC4lWrWvw/5WefrOwufk@postini.com; Tue, 01 Dec 2009 09:46:30 PST 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.1.393.1; Tue, 1 Dec 2009 09:43:54 -0800 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, 1 Dec 2009 12:43:54 -0500 From: Reinaldo Penno To: Dan Wing , 'marcelo bagnulo braun' , 'Behave WG' Date: Tue, 1 Dec 2009 12:43:51 -0500 Thread-Topic: [BEHAVE] Handling fragments in the stateful NAT64 Thread-Index: Acpyanw9YHpb2JO5TQWdEipdXgyqPgAQDUmAAADJn9M= Message-ID: In-Reply-To: <097b01ca72ab$11232350$c3f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Handling fragments in the stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:46:38 -0000 Comments inline... On 12/1/09 9:23 AM, "Dan Wing" wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Tuesday, December 01, 2009 1:42 AM >> To: Behave WG >> Subject: [BEHAVE] Handling fragments in the stateful NAT64 >>=20 >> Hi, >>=20 >> after the discussion in hiroshima, I have updated the draft. >> The current 03 version reads: >>=20 >> If the incoming IP packet contains a fragment, then more processing >> may be needed. This specification leaves open the exact details of >> how a NAT64 handles incoming IP packets containing fragments, and >> simply requires that a NAT64 handle fragments arriving >> out-of-order. >=20 > That sentence above says "requires that a NAT64 handle fragments arriving > out-of-order", yet ... (see "A", below) I agree with what was stated by Dan (If I understand it properly). After the first paragraph above (which pretty much leaves the mechanism open), using normative text in other paragraphs is confusing and might lead to interpretation issues. On the other hand, if you NAT64 needs to handle out of order fragments through whatever mechanism (as stated in the first paragraph), then that's where you need to use normative text such as the one in RFC487. Something like from 4787 " REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior. a) A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets. " Thanks, Reinaldo >=20 >> A NAT64 MAY elect to queue the fragments as they arrive >> and translate >> all fragments at the same time. Alternatively, a NAT64 >> MAY translate >> the fragments as they arrive, by storing information that allows it >> to compute the 5-tuple for fragments other than the first. In the >> latter case, the NAT64 will still need to handle the >> situation where >> subsequent fragments arrive before the first. >>=20 >> Implementors of NAT64 should be aware that there are a number of >> well-known attacks against IP fragmentation; see [RFC1858] and >> [RFC3128]. >=20 > RFC4963 might be useful to cite, as well. >=20 >> Assuming it otherwise has sufficient resources, a NAT64 MUST allow >> the fragments to arrive over a time interval of at least >> 10 seconds. >=20 > "A": The sentence below does *not* require the NAT64 to handle out-of- > order fragments. The sentence below contains a RFC2119 keyword, so > I guess it is normative and overrides the non-RFC2119 sentence above, > but it would be better if the descriptive text above matched the > RFC2119 keyworded sentence below. Or remove one or the other. >=20 >> A NAT64 MAY require that the UDP, TCP, or ICMP header be completely >> contained within the first fragment. >=20 > -d >=20 >=20 >>=20 >> Let me know if you have issues witht eh current text. I hope >> it reflects=20 >> the received feedback. >>=20 >> Regards, marcelo >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Tue Dec 1 09:51:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CE93A68E4 for ; Tue, 1 Dec 2009 09:51:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzODTaaxOBu1 for ; Tue, 1 Dec 2009 09:51:19 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 047F73A6956 for ; Tue, 1 Dec 2009 09:51:14 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nB1HoZ1I074889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2009 18:50:37 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B14E4D0.7070007@it.uc3m.es> Date: Tue, 1 Dec 2009 18:50:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B14E4D0.7070007@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Handling fragments in the stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:51:19 -0000 On 1 dec 2009, at 10:41, marcelo bagnulo braun wrote: > Assuming it otherwise has sufficient resources, a NAT64 MUST allow > the fragments to arrive over a time interval of at least 10 seconds. The first clause makes the requirement meaningless. Someone could always = claim lack of resources. Also, is this 10 seconds between all fragments (so 30 seconds in the = case of 4 fragments) or 10 seconds from the first fragment to arrive = until the last? I'm not very happy about the 10 seconds, in practice all fragments will = arrive within a few hundred milliseconds. But I guess if we assume a = worst case network speed of 8 kbps (really slow GPRS link) and packet = size (64k) then it can take more than a minute for all fragments to = arrive...= From simon.perreault@viagenie.ca Tue Dec 1 10:01:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBE928C12A for ; Tue, 1 Dec 2009 10:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHJLIvsPZP58 for ; Tue, 1 Dec 2009 10:01:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9A3ED28C127 for ; Tue, 1 Dec 2009 10:01:18 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id F09F521BC1 for ; Tue, 1 Dec 2009 13:01:10 -0500 (EST) Message-ID: <4B1559E6.4060003@viagenie.ca> Date: Tue, 01 Dec 2009 13:01:10 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> In-Reply-To: <097401ca72aa$0828aa50$c3f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:01:19 -0000 Dan Wing wrote, on 2009-12-01 12:16: > It's not just the AAAA records getting cached. It's also the > applications that have done their getaddrinfo() and now have the > IPv6 address in their internal datastructures. There is no lifetime > for that, and very very few applications pay any attention to the > TTL of the AAAA record. Applications expect the IPv6 address to > be fixed and to be valid as long as they need it. How hard should NAT64 try to accommodate broken applications? These applications would fail in many other cases that don't involve NAT64. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From rpenno@juniper.net Tue Dec 1 10:21:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4333A6910 for ; Tue, 1 Dec 2009 10:21:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NER5eToCZwFI for ; Tue, 1 Dec 2009 10:21:27 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id E29953A67FD for ; Tue, 1 Dec 2009 10:21:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSxVemgXFErvkkfgmvxrXhLTDgVmVXOlo@postini.com; Tue, 01 Dec 2009 10:21:19 PST 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.1.393.1; Tue, 1 Dec 2009 10:20:21 -0800 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, 1 Dec 2009 13:20:21 -0500 From: Reinaldo Penno To: Iljitsch van Beijnum , marcelo bagnulo braun Date: Tue, 1 Dec 2009 13:20:18 -0500 Thread-Topic: [BEHAVE] Handling fragments in the stateful NAT64 Thread-Index: AcpyruFkB1+JTL9YQgCPYZoQ3cc/wQABA4F1 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Handling fragments in the stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:21:28 -0000 I agree that 10 seconds in Internet today is a long time for fragments to arrive. Should we optimize for the common case or the worst case? Although there will always be exceptions as mention by Iljitschv, providers should be allowed to optimize for the their common case. So, I would sugges= t to include text to say that the the interval MAY be configurable. Thanks, Reinaldo On 12/1/09 9:50 AM, "Iljitsch van Beijnum" wrote: > On 1 dec 2009, at 10:41, marcelo bagnulo braun wrote: >=20 >> Assuming it otherwise has sufficient resources, a NAT64 MUST allow >> the fragments to arrive over a time interval of at least 10 seconds. >=20 > The first clause makes the requirement meaningless. Someone could always = claim > lack of resources. >=20 > Also, is this 10 seconds between all fragments (so 30 seconds in the case= of 4 > fragments) or 10 seconds from the first fragment to arrive until the last= ? >=20 > I'm not very happy about the 10 seconds, in practice all fragments will a= rrive > within a few hundred milliseconds. But I guess if we assume a worst case > network speed of 8 kbps (really slow GPRS link) and packet size (64k) the= n it > can take more than a minute for all fragments to arrive... > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Dec 1 10:40:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CAE3A6A47 for ; Tue, 1 Dec 2009 10:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RrqBME2aqjG for ; Tue, 1 Dec 2009 10:40:07 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B22BA3A6A39 for ; Tue, 1 Dec 2009 10:40:07 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFjxFEurRN+K/2dsb2JhbACKNrYQmBiEMQSBag X-IronPort-AV: E=Sophos;i="4.47,322,1257120000"; d="scan'208";a="112243429" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2009 18:39:59 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1Idw7Y026459; Tue, 1 Dec 2009 18:39:58 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com><097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> Date: Tue, 1 Dec 2009 10:39:57 -0800 Message-ID: <0a0701ca72b5$afb51e10$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B1559E6.4060003@viagenie.ca> Thread-index: AcpysEdU1CrJXOIyRTqLYRwIEm/mBgABPgmA Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:40:08 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Tuesday, December 01, 2009 10:01 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > Dan Wing wrote, on 2009-12-01 12:16: > > It's not just the AAAA records getting cached. It's also the > > applications that have done their getaddrinfo() and now have the > > IPv6 address in their internal datastructures. There is no lifetime > > for that, and very very few applications pay any attention to the > > TTL of the AAAA record. Applications expect the IPv6 address to > > be fixed and to be valid as long as they need it. > > How hard should NAT64 try to accommodate broken applications? My point is that it shouldn't make things worse. If the functioning NAT64's prefix changes and the old prefix no longer works, that makes things worse -- it effectively causes IPv6 addresses to change. That breaks not just applications that are sensitive to IP address changes, but also existing TCP sessions. SCTP handles IP address changes better, but there is scant deployment of SCTP yet (due to many reasons). > These applications would fail in many other cases that don't > involve NAT64. But IPv4 addresses on today's Internet don't change much, especially while connections are up. When they do, yes, applications break. That's part of the whole Location/Identifier split problem. -d From simon.perreault@viagenie.ca Tue Dec 1 11:15:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901933A6829 for ; Tue, 1 Dec 2009 11:15:57 -0800 (PST) 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.114, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XCpBcayVhQP for ; Tue, 1 Dec 2009 11:15:52 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A62263A696C for ; Tue, 1 Dec 2009 11:15:49 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id D620321521; Tue, 1 Dec 2009 14:15:40 -0500 (EST) Message-ID: <4B156B5C.7060800@viagenie.ca> Date: Tue, 01 Dec 2009 14:15:40 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Dan Wing References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com><097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <0a0701ca72b5$afb51e10$c3f0200a@cisco.com> In-Reply-To: <0a0701ca72b5$afb51e10$c3f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:15:57 -0000 Dan Wing wrote, on 2009-12-01 13:39: > My point is that it shouldn't make things worse. If the functioning > NAT64's prefix changes and the old prefix no longer works, that makes > things worse -- it effectively causes IPv6 addresses to change. That > breaks not just applications that are sensitive to IP address changes, > but also existing TCP sessions. SCTP handles IP address changes > better, but there is scant deployment of SCTP yet (due to many > reasons). I don't understand where you're going. There are two kinds of breakage: 1. One NAT64 box in a cluster* dies. No impact beyond the fact that you now have a dead box that needs replacing. 2. A whole cluster dies. This is not pain-free, and it's not designed to be. Suddenly, you need to redirect all clients to the new Pref64::/n. There are known issues with that, but this event will happen rarely enough that it's worth the risk. If you're really afraid of breakage #2, you have to use bigger clusters. But that has disadvantages too. It ends up being an operational issue. Tradeoffs, etc. Another idea: have another cluster "take over" the prefix of the dead one. Use routing to redirect clients to the new cluster. Tradeoffs, etc., again. My point is that #2 doesn't need standardization. The solutions are diverse and everyone will be dealing with it differently. On the other hand, #1 is a well understood problem, with a well understood solution, with various proprietary incarnations in use right now (hint! hint!). * Cluster = A set of synchronized NAT64 boxes sharing a single Pref64::/n. Cheers, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dthaler@microsoft.com Tue Dec 1 11:26:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B093A692B for ; Tue, 1 Dec 2009 11:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.27 X-Spam-Level: X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp1wtY6zQuiO for ; Tue, 1 Dec 2009 11:26:39 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B3B843A690A for ; Tue, 1 Dec 2009 11:26:39 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 11:26:58 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 1 Dec 2009 11:26:31 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 1 Dec 2009 11:26:31 -0800 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: AQHKcqpG2eUdkzWZQUCTf9KecyFv9ZFRAU4A//+QcDA= Date: Tue, 1 Dec 2009 19:26:29 +0000 Message-ID: References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> In-Reply-To: <4B1559E6.4060003@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:26:40 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Tuesday, December 01, 2009 10:01 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 >=20 > Dan Wing wrote, on 2009-12-01 12:16: > > It's not just the AAAA records getting cached. It's also the > > applications that have done their getaddrinfo() and now have the > > IPv6 address in their internal datastructures. There is no lifetime > > for that, and very very few applications pay any attention to the > > TTL of the AAAA record. Applications expect the IPv6 address to > > be fixed and to be valid as long as they need it. >=20 > How hard should NAT64 try to accommodate broken applications? >=20 > These applications would fail in many other cases that don't involve > NAT64. >=20 > Simon Yes but it's not the apps that are broken, it's the sockets API that's broken (getaddrinfo and its predecessor gethostbyname don't return it). Applications just call APIs and are agnostic as to whether the name gets resolved using DNS, hosts file, mDNS, LLMNR, NetBIOS over TCP, or whatever else. The only applications that pay attention to TTL are ones that only support DNS and not other protocols, and generally either implement DNS themselves=20 or call DNS-specific APIs that expose a TTL. So yes NAT64 should try (to the extent that is practical)=20 to accommodate apps that don't pay attention to TTL, since that's 99.99% of all applications. -Dave From ajs@shinkuro.com Tue Dec 1 11:40:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CEAF3A6A48 for ; Tue, 1 Dec 2009 11:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQSPnEGVlfHM for ; Tue, 1 Dec 2009 11:40:27 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C3A873A6A47 for ; Tue, 1 Dec 2009 11:40:27 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 984892FE8CDD for ; Tue, 1 Dec 2009 19:40:19 +0000 (UTC) Date: Tue, 1 Dec 2009 14:40:18 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091201194017.GU71984@shinkuro.com> References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:40:28 -0000 On Tue, Dec 01, 2009 at 07:26:29PM +0000, Dave Thaler wrote: > So yes NAT64 should try (to the extent that is practical) > to accommodate apps that don't pay attention to TTL, since that's > 99.99% of all applications. Either that, or we should get to work on changing the APIs. Since I predict heat death of the universe first, I agree with Dave. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Dec 1 12:02:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEEF3A6991 for ; Tue, 1 Dec 2009 12:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN-1LgAZO-fC for ; Tue, 1 Dec 2009 12:02:34 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A841B3A6A59 for ; Tue, 1 Dec 2009 12:02:17 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAI8EFUurRN+K/2dsb2JhbACKNrYcmBiEMQSBag X-IronPort-AV: E=Sophos;i="4.47,322,1257120000"; d="scan'208";a="56160711" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2009 20:02:10 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1K290S009198; Tue, 1 Dec 2009 20:02:10 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com><097401ca72aa$0828aa50$c3f0200a@cisco.com><4B1559E6.4060003@viagenie.ca><0a0701ca72b5$afb51e10$c3f0200a@cisco.com> <4B156B5C.7060800@viagenie.ca> Date: Tue, 1 Dec 2009 12:02:09 -0800 Message-ID: <0a9201ca72c1$2a725130$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B156B5C.7060800@viagenie.ca> Thread-index: AcpyurY2mC0kTf2rSt2AtvarEBIEXQABfXrw Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:02:35 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Tuesday, December 01, 2009 11:16 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > Dan Wing wrote, on 2009-12-01 13:39: > > My point is that it shouldn't make things worse. If the functioning > > NAT64's prefix changes and the old prefix no longer works, > that makes > > things worse -- it effectively causes IPv6 addresses to > change. That > > breaks not just applications that are sensitive to IP > address changes, > > but also existing TCP sessions. SCTP handles IP address changes > > better, but there is scant deployment of SCTP yet (due to many > > reasons). > > I don't understand where you're going. > > There are two kinds of breakage: > > 1. One NAT64 box in a cluster* dies. No impact beyond the > fact that you now have > a dead box that needs replacing. > > 2. A whole cluster dies. This is not pain-free, and it's not > designed to be. > Suddenly, you need to redirect all clients to the new > Pref64::/n. There are > known issues with that, but this event will happen rarely > enough that it's worth > the risk. > > If you're really afraid of breakage #2, you have to use > bigger clusters. But > that has disadvantages too. It ends up being an operational > issue. Tradeoffs, etc. > > Another idea: have another cluster "take over" the prefix of > the dead one. Use > routing to redirect clients to the new cluster. Tradeoffs, > etc., again. > > My point is that #2 doesn't need standardization. The > solutions are diverse and > everyone will be dealing with it differently. On the other > hand, #1 is a well > understood problem, with a well understood solution, with > various proprietary > incarnations in use right now (hint! hint!). > > > * Cluster = A set of synchronized NAT64 boxes sharing a > single Pref64::/n. Agreed. I think we were just mis-communicating between the two types of breakage. I had thought you were describing breakage (1) as needing (or wanting) a new Pref64. -d > Cheers, > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Dec 1 12:07:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219E828C13E for ; Tue, 1 Dec 2009 12:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9I27FZD7LxB for ; Tue, 1 Dec 2009 12:07:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0EE3B28C17A for ; Tue, 1 Dec 2009 12:07:24 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 26A1021B9D for ; Tue, 1 Dec 2009 15:07:12 -0500 (EST) Message-ID: <4B15776F.4080901@viagenie.ca> Date: Tue, 01 Dec 2009 15:07:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <20091201194017.GU71984@shinkuro.com> In-Reply-To: <20091201194017.GU71984@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:07:40 -0000 Andrew Sullivan wrote, on 2009-12-01 14:40: > On Tue, Dec 01, 2009 at 07:26:29PM +0000, Dave Thaler wrote: >> So yes NAT64 should try (to the extent that is practical) >> to accommodate apps that don't pay attention to TTL, since that's >> 99.99% of all applications. > > Either that, or we should get to work on changing the APIs. Since I > predict heat death of the universe first, I agree with Dave. No, let's change the APIs to make NAT64 work! Just kidding... we all agree on that. But what was the point again? The point was that you cannot fail over clients from one Pref64::/n to another because applications will remember addresses. This is true, to some extent. If it was 100% true then you wouldn't be able to change anything once you publish a DNS record. In reality, hosts are rebooted, applications are restarted, and web pages are reloaded. So you have some wiggle room. Failing over to another Pref64::/n is an unlikely event. It means that something *really bad* happened. (See my other email about the two types of breakage.) Any partial fix is better than just shutting of the Internet to your customers. If it means they have to close Outlook and restart it, so be it. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Tue Dec 1 12:43:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEAD3A69AE for ; Tue, 1 Dec 2009 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKwLujX0C1in for ; Tue, 1 Dec 2009 12:43:44 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 50E593A6849 for ; Tue, 1 Dec 2009 12:43:44 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 294812FE8CDD for ; Tue, 1 Dec 2009 20:43:36 +0000 (UTC) Date: Tue, 1 Dec 2009 15:43:34 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091201204334.GZ71984@shinkuro.com> References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <20091201194017.GU71984@shinkuro.com> <4B15776F.4080901@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B15776F.4080901@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:43:45 -0000 On Tue, Dec 01, 2009 at 03:07:11PM -0500, Simon Perreault wrote: > The point was that you cannot fail over clients from one Pref64::/n to another > because applications will remember addresses. This is true, to some extent. If > it was 100% true then you wouldn't be able to change anything once you publish a > DNS record. In reality, hosts are rebooted, applications are restarted, and web > pages are reloaded. So you have some wiggle room. "Reloading a web page" often doesn't help. I have experience of at least one popular browser that reaches down and remembers the A record for the target host. Then the magic DNS load balancer decides to pull that IP out of the mix, and stuff starts breaking randomly. (One of the many ways in which DNS load balancers don't work the way their deployers seem to think they do.) That said, > partial fix is better than just shutting of the Internet to your > customers. If it means they have to close Outlook and restart it, so > be it. I completely agree here. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon.perreault@viagenie.ca Tue Dec 1 14:04:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E453A685E for ; Tue, 1 Dec 2009 14:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGXV1pKFgHly for ; Tue, 1 Dec 2009 14:04:31 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4C4403A679C for ; Tue, 1 Dec 2009 14:04:31 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 8863C20E63; Tue, 1 Dec 2009 17:04:23 -0500 (EST) Message-ID: <4B1592E7.2030104@viagenie.ca> Date: Tue, 01 Dec 2009 17:04:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: draft-ietf-behave-v6v4-xlate@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:04:32 -0000 Hello again, In section 3.2 we have the following: Parameter Problem (Type 4) If the Code is 1, translate this to an ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set the Type to 12 and the Code to zero. The Pointer needs to be updated to point to the corresponding field in the translated inner IP header. Question: How is that pointer updating performed? Do I have to establish correspondences between IPv6 and IPv4 fields? If so, shouldn't this be in the text? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From cb.list6@gmail.com Tue Dec 1 14:05:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974AB3A679C for ; Tue, 1 Dec 2009 14:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JoP5+hrD+4m for ; Tue, 1 Dec 2009 14:05:37 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9A24F3A692E for ; Tue, 1 Dec 2009 14:05:37 -0800 (PST) Received: by yxe30 with SMTP id 30so10584647yxe.29 for ; Tue, 01 Dec 2009 14:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c38K3l0OPNEu/6WXzvHGvOoXeo+RT2nFtBTcPR4vjfY=; b=ZjlTtXUs0F5r/0aS4jrEIgCyR9R2PQvV0aHwMHRtZ+FVTgIhHvM93wTIp5zdsTANhq 3jBAMsPs7BmBsczdJ+GnsQUhCgHck6D3U4DSaMavWYny7LG4cXMS4zOBAs9Y/Dmz8w0u ez9yI9OjShfgrGy/jUfM/c+AZz/VjxkqO9g68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SttxOgybxe19aKha2L18envtjRyOdtD3EAw1Kp72GxE5rA9ujIC9Of/7o33ZzW71Ql jurY2aaR2f5vlhzlwd1jGCqDkFf2pcOFz+8wLfiCiO+/96VexHoR+sAw8ZvGjtTopInb Gz1qLIqjb0NA1UQcIVLf/vxau0A2K0ptOWWwg= MIME-Version: 1.0 Received: by 10.150.250.21 with SMTP id x21mr9788482ybh.181.1259705123564; Tue, 01 Dec 2009 14:05:23 -0800 (PST) In-Reply-To: <4B15776F.4080901@viagenie.ca> References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <20091201194017.GU71984@shinkuro.com> <4B15776F.4080901@viagenie.ca> Date: Tue, 1 Dec 2009 14:05:23 -0800 Message-ID: From: Cameron Byrne To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:05:38 -0000 On Tue, Dec 1, 2009 at 12:07 PM, Simon Perreault wrote: > Andrew Sullivan wrote, on 2009-12-01 14:40: >> On Tue, Dec 01, 2009 at 07:26:29PM +0000, Dave Thaler wrote: >>> So yes NAT64 should try (to the extent that is practical) >>> to accommodate apps that don't pay attention to TTL, since that's >>> 99.99% of all applications. >> >> Either that, or we should get to work on changing the APIs. =A0Since I >> predict heat death of the universe first, I agree with Dave. > > No, let's change the APIs to make NAT64 work! > > Just kidding... we all agree on that. But what was the point again? > > The point was that you cannot fail over clients from one Pref64::/n to an= other > because applications will remember addresses. This is true, to some exten= t. If > it was 100% true then you wouldn't be able to change anything once you pu= blish a > DNS record. In reality, hosts are rebooted, applications are restarted, a= nd web > pages are reloaded. So you have some wiggle room. > > Failing over to another Pref64::/n is an unlikely event. It means that so= mething > *really bad* happened. (See my other email about the two types of breakag= e.) Any > partial fix is better than just shutting of the Internet to your customer= s. If > it means they have to close Outlook and restart it, so be it. 100% agree. Members in a cluster failing can locally be resolved without bouncing the Pref64. If entire cluster fails, this is very unlikely but catastrophic, i just want a fail safe that can work *mostly*, and if the networks really broke, asking a user to reboot their phone and be fixed in 1 minute is better than waiting for a 4 hour RMA or guy with backhoe to fix fiber or electrician to arrve ,... > > Simon > -- > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marka@isc.org Tue Dec 1 15:32:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD4C3A682C for ; Tue, 1 Dec 2009 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdweOuq3cXo3 for ; Tue, 1 Dec 2009 15:32:28 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 69BEF3A6783 for ; Tue, 1 Dec 2009 15:32:15 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0EC37E6068; Tue, 1 Dec 2009 23:32:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB1NW3a8054432; Wed, 2 Dec 2009 10:32:03 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912012332.nB1NW3a8054432@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews References: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <20091201194017.GU71984@shinkuro.com> <4B15776F.4080901@viagenie.ca> <20091201204334.GZ71984@shinkuro.com> In-reply-to: Your message of "Tue, 01 Dec 2009 15:43:34 CDT." <20091201204334.GZ71984@shinkuro.com> Date: Wed, 02 Dec 2009 10:32:03 +1100 Sender: marka@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 23:32:28 -0000 In message <20091201204334.GZ71984@shinkuro.com>, Andrew Sullivan writes: > On Tue, Dec 01, 2009 at 03:07:11PM -0500, Simon Perreault wrote: > > > The point was that you cannot fail over clients from one Pref64::/n to anot > her > > because applications will remember addresses. This is true, to some extent. > If > > it was 100% true then you wouldn't be able to change anything once you publ > ish a > > DNS record. In reality, hosts are rebooted, applications are restarted, and > web > > pages are reloaded. So you have some wiggle room. > > "Reloading a web page" often doesn't help. I have experience of at > least one popular browser that reaches down and remembers the A record > for the target host. Then the magic DNS load balancer decides to pull > that IP out of the mix, and stuff starts breaking randomly. (One of > the many ways in which DNS load balancers don't work the way their > deployers seem to think they do.) That said, > > > partial fix is better than just shutting of the Internet to your > > customers. If it means they have to close Outlook and restart it, so > > be it. > > I completely agree here. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave getaddrinfo() is designed to be extensible. Lets exercise that extensiblity. Resolution methods w/o a TTL get some default value set (0 or 10 mins) or a flag which says it is not set. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Tue Dec 1 17:48:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E593A686E for ; Tue, 1 Dec 2009 17:48:38 -0800 (PST) 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.762, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwad3Tyg2sQX for ; Tue, 1 Dec 2009 17:48:37 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9577A3A6898 for ; Tue, 1 Dec 2009 17:48:32 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000EPV5042P@szxga04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:48:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000H935042G@szxga04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:48:04 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU0001FW5044K@szxml04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:48:04 +0800 (CST) Date: Wed, 02 Dec 2009 09:48:03 +0800 From: Xu Xiaohu In-reply-to: <4B156B5C.7060800@viagenie.ca> To: 'Simon Perreault' , 'Dan Wing' Message-id: <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYog Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:48:38 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Simon > Perreault > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C22=C8=D5 3:16 > =CA=D5=BC=FE=C8=CB: Dan Wing > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: > draft-xu-behave-nat-state-sync-00 >=20 > Dan Wing wrote, on 2009-12-01 13:39: > > My point is that it shouldn't make things worse. If the functioning > > NAT64's prefix changes and the old prefix no longer works, that = makes > > things worse -- it effectively causes IPv6 addresses to change. = That > > breaks not just applications that are sensitive to IP address = changes, > > but also existing TCP sessions. SCTP handles IP address changes > > better, but there is scant deployment of SCTP yet (due to many > > reasons). >=20 > I don't understand where you're going. >=20 > There are two kinds of breakage: >=20 > 1. One NAT64 box in a cluster* dies. No impact beyond the fact that = you now > have > a dead box that needs replacing. >=20 > 2. A whole cluster dies. This is not pain-free, and it's not designed = to be. > Suddenly, you need to redirect all clients to the new Pref64::/n. = There are > known issues with that, but this event will happen rarely enough that = it's worth > the risk. >=20 > If you're really afraid of breakage #2, you have to use bigger = clusters. But > that has disadvantages too. It ends up being an operational issue. Tradeoffs, > etc. >=20 > Another idea: have another cluster "take over" the prefix of the dead = one. Use > routing to redirect clients to the new cluster. Tradeoffs, etc., = again. >=20 > My point is that #2 doesn't need standardization. The solutions are diverse > and > everyone will be dealing with it differently. On the other hand, #1 is = a well > understood problem, with a well understood solution, with various proprietary > incarnations in use right now (hint! hint!). >=20 >=20 > * Cluster =3D A set of synchronized NAT64 boxes sharing a single = Pref64::/n. Does that mean a set of NAT64 boxes within a cluster should be from a = single vendor? If so, how to deal with the case that some abnormal packets = cause NAT boxes (using the same OS) within a cluster to crash simultaneously = due to a bug with that OS? Xiaohu From simon.perreault@viagenie.ca Tue Dec 1 17:52:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A203A6972 for ; Tue, 1 Dec 2009 17:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQrDp5orWAJ7 for ; Tue, 1 Dec 2009 17:52:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 740EA3A6926 for ; Tue, 1 Dec 2009 17:52:10 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A857320E63; Tue, 1 Dec 2009 20:52:02 -0500 (EST) Message-ID: <4B15C842.902@viagenie.ca> Date: Tue, 01 Dec 2009 20:52:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Xu Xiaohu References: <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> In-Reply-To: <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:52:11 -0000 On 12/01/2009 08:48 PM, Xu Xiaohu wrote: >> On the other hand, #1 is a well >> understood problem, with a well understood solution, with various proprietary >> incarnations in use right now (hint! hint!). > > Does that mean a set of NAT64 boxes within a cluster should be from a single > vendor? No! I was hinting exactly to the contrary. We should standardize NAT64 state synchronization. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xuxh@huawei.com Tue Dec 1 17:58:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9943A68F2 for ; Tue, 1 Dec 2009 17:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9QqaOXwfpLC for ; Tue, 1 Dec 2009 17:58:28 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 75F0D3A679F for ; Tue, 1 Dec 2009 17:58:28 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000EDV5GYFU@szxga01-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:58:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000HL05GY4X@szxga01-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:58:10 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU0001CY5GXK0@szxml04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 09:58:10 +0800 (CST) Date: Wed, 02 Dec 2009 09:58:09 +0800 From: Xu Xiaohu In-reply-to: To: 'Cameron Byrne' , 'Simon Perreault' Message-id: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: Acpy0mn3S8LOZsW/SWW5oxGfCX6NjAAH5KCw Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:58:29 -0000 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > Cameron Byrne > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=882=E6=97=A5 6:05 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Simon Perreault > =E6=8A=84=E9=80=81: behave@ietf.org > =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s = standardisedprotocols//re: > draft-xu-behave-nat-state-sync-00 >=20 > On Tue, Dec 1, 2009 at 12:07 PM, Simon Perreault > wrote: > > Andrew Sullivan wrote, on 2009-12-01 14:40: > >> On Tue, Dec 01, 2009 at 07:26:29PM +0000, Dave Thaler wrote: > >>> So yes NAT64 should try (to the extent that is practical) > >>> to accommodate apps that don't pay attention to TTL, since that's > >>> 99.99% of all applications. > >> > >> Either that, or we should get to work on changing the APIs. Since = I > >> predict heat death of the universe first, I agree with Dave. > > > > No, let's change the APIs to make NAT64 work! > > > > Just kidding... we all agree on that. But what was the point again? > > > > The point was that you cannot fail over clients from one Pref64::/n = to another > > because applications will remember addresses. This is true, to some = extent. > If > > it was 100% true then you wouldn't be able to change anything once = you publish > a > > DNS record. In reality, hosts are rebooted, applications are = restarted, and > web > > pages are reloaded. So you have some wiggle room. > > > > Failing over to another Pref64::/n is an unlikely event. It means = that > something > > *really bad* happened. (See my other email about the two types of = breakage.) > Any > > partial fix is better than just shutting of the Internet to your = customers. > If > > it means they have to close Outlook and restart it, so be it. >=20 > 100% agree. Members in a cluster failing can locally be resolved > without bouncing the Pref64. If entire cluster fails, this is very > unlikely but catastrophic, i just want a fail safe that can work > *mostly*, and if the networks really broke, asking a user to reboot Ask a user or ask a huge amount of users? By the way, if one uses one of those mechanisms defined in = draft-wing-behave-learn-prefix, other than DNS64, to synthesize IPv6 = addresses, does that mean the DNS server or the DHCP server should also = dynamically detect the availability of each prefix64? Xiaohu > their phone and be fixed in 1 minute is better than waiting for a 4 > hour RMA or guy with backhoe to fix fiber or electrician to arrve > ,... >=20 >=20 > > > > Simon > > -- > > DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > vCard 4.0 --> http://www.vcarddav.org > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Dec 1 18:07:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7818828C10F for ; Tue, 1 Dec 2009 18:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpzY6QAXNQdL for ; Tue, 1 Dec 2009 18:07:25 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 397483A69CE for ; Tue, 1 Dec 2009 18:07:01 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAM9aFUurRN+J/2dsb2JhbACKN7UlmCWEMQSBag X-IronPort-AV: E=Sophos;i="4.47,325,1257120000"; d="scan'208";a="112460414" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2009 02:06:53 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB226rHd006882; Wed, 2 Dec 2009 02:06:53 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'Simon Perreault'" References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> Date: Tue, 1 Dec 2009 18:06:53 -0800 Message-ID: <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYogAACgIiA= Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:07:27 -0000 ... > > * Cluster = A set of synchronized NAT64 boxes sharing a > > single Pref64::/n. > > Does that mean a set of NAT64 boxes within a cluster should > be from a single > vendor? If so, how to deal with the case that some abnormal > packets cause > NAT boxes (using the same OS) within a cluster to crash > simultaneously due to a bug with that OS? The vendor fixes the bug. The operational complexity of running two NATs, from two different vendors, is very high: different CLIs, different alarming/alerting (e.g., SYSLOG, SNMP, per-session NAT logging), different features (e.g., IPsec Passthru, SCTP), different implementation of features (e.g., TCP MSS adjustment, fragmentation [timeouts? how much memory dedicated to reassembly? out-of-order packets supported?]), bandwidth and throughput (Mbps, pps), make it too hard to operate both NATs. To my knowledge, sites do not run two different implementations of DNS servers (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back up each other. Like NAT, DNS needs to be rock-solid reliable, and a single packet could take out a DNS server. -d From marka@isc.org Tue Dec 1 18:38:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2353A6813 for ; Tue, 1 Dec 2009 18:38:19 -0800 (PST) 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.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg6uAuS3i6Pg for ; Tue, 1 Dec 2009 18:38:19 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 17F203A679F for ; Tue, 1 Dec 2009 18:38:19 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 69848E6063; Wed, 2 Dec 2009 02:38:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB22c6v8005164; Wed, 2 Dec 2009 13:38:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020238.nB22c6v8005164@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> In-reply-to: Your message of "Tue, 01 Dec 2009 18:06:53 -0800." <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> Date: Wed, 02 Dec 2009 13:38:06 +1100 Sender: marka@isc.org Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:38:20 -0000 In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan Wing" writes: > To my knowledge, sites do not run two different implementations of DNS server > s > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back > up each other. Like NAT, DNS needs to be rock-solid reliable, and a single > packet could take out a DNS server. Actually lots of sites use multiple vendors for DNS. That being said there is not of lot of state to share between DNS servers. DHCP servers on the other had need to share lots of state. I don't believe the failover draft (draft-ietf-dhc-failover-12) reached a conclusion even though we implement most (all?) of it in our DHCP servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Tue Dec 1 18:40:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80C53A6813 for ; Tue, 1 Dec 2009 18:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTj7DuvNCTc1 for ; Tue, 1 Dec 2009 18:40:17 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 479C03A679F for ; Tue, 1 Dec 2009 18:40:17 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANdhFUurRN+J/2dsb2JhbACKN7UQmCKEMQSBag X-IronPort-AV: E=Sophos;i="4.47,325,1257120000"; d="scan'208";a="112473945" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2009 02:40:09 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB22e9Oq022904; Wed, 2 Dec 2009 02:40:09 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'Cameron Byrne'" , "'Simon Perreault'" References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> Date: Tue, 1 Dec 2009 18:40:09 -0800 Message-ID: <000801ca72f8$c3fa5820$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acpy0mn3S8LOZsW/SWW5oxGfCX6NjAAH5KCwAAGDm/A= Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:40:18 -0000 ... > > 100% agree. Members in a cluster failing can locally be resolved > > without bouncing the Pref64. If entire cluster fails, this is very > > unlikely but catastrophic, i just want a fail safe that can work > > *mostly*, and if the networks really broke, asking a user to reboot > > Ask a user or ask a huge amount of users? All the affected users. > By the way, if one uses one of those mechanisms defined in > draft-wing-behave-learn-prefix, other than DNS64, to > synthesize IPv6 addresses, does that mean the DNS server or > the DHCP server should also dynamically detect the > availability of each prefix64? Whatever hands out the prefix (DNS, IPv6 router advertisements, DHCPv6) should hand out a functioning prefix. Providing a non-functioning prefix is harmful. The same is true of a DHCP server providing the IP address of DNS servers, NTP servers, and suchlike. If a DHCP server hands out IP addresses for broken (or dead) servers, it is harmful. Does that need to be stated, though? -d From marka@isc.org Tue Dec 1 18:54:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893A63A69E2 for ; Tue, 1 Dec 2009 18:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU9mDurJOl+0 for ; Tue, 1 Dec 2009 18:54:30 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id ABFE23A6813 for ; Tue, 1 Dec 2009 18:54:30 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 13E30E6065; Wed, 2 Dec 2009 02:54:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB22sIvO028323; Wed, 2 Dec 2009 13:54:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020254.nB22sIvO028323@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> In-reply-to: Your message of "Tue, 01 Dec 2009 18:40:09 -0800." <000801ca72f8$c3fa5820$c3f0200a@cisco.com> Date: Wed, 02 Dec 2009 13:54:18 +1100 Sender: marka@isc.org Cc: 'Cameron Byrne' , behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:54:31 -0000 In message <000801ca72f8$c3fa5820$c3f0200a@cisco.com>, "Dan Wing" writes: > ... > > > 100% agree. Members in a cluster failing can locally be resolved > > > without bouncing the Pref64. If entire cluster fails, this is very > > > unlikely but catastrophic, i just want a fail safe that can work > > > *mostly*, and if the networks really broke, asking a user to reboot > > > > Ask a user or ask a huge amount of users? > > All the affected users. > > > By the way, if one uses one of those mechanisms defined in > > draft-wing-behave-learn-prefix, other than DNS64, to > > synthesize IPv6 addresses, does that mean the DNS server or > > the DHCP server should also dynamically detect the > > availability of each prefix64? > > Whatever hands out the prefix (DNS, IPv6 router advertisements, > DHCPv6) should hand out a functioning prefix. Providing a > non-functioning prefix is harmful. Actually it shouldn't be. If a prefix doesn't work it it like a router being down. The machines are just not reachable. > The same is true of a DHCP server providing the IP address of > DNS servers, NTP servers, and suchlike. If a DHCP server hands > out IP addresses for broken (or dead) servers, it is harmful. Which is why DHCP is designed to hand out multiple ones so that individual failures are not a issue. > Does that need to be stated, though? > > -d -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Tue Dec 1 19:41:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF12D3A6812 for ; Tue, 1 Dec 2009 19:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxkzTYw4Ewzb for ; Tue, 1 Dec 2009 19:41:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 23AAD3A67AE for ; Tue, 1 Dec 2009 19:41:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJpwFUurRN+K/2dsb2JhbACKN7UCmCMChC8E X-IronPort-AV: E=Sophos;i="4.47,326,1257120000"; d="scan'208";a="56341053" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2009 03:41:43 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB23fhU6025057; Wed, 2 Dec 2009 03:41:43 GMT From: "Dan Wing" To: References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <200912020238.nB22c6v8005164@drugs.dv.isc.org> Date: Tue, 1 Dec 2009 19:41:43 -0800 Message-ID: <002201ca7301$5db9a710$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200912020238.nB22c6v8005164@drugs.dv.isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acpy+H0dioQPAqajR6qve9xwJpJdPQACM/ZA Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:41:51 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Tuesday, December 01, 2009 6:38 PM > To: Dan Wing > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan > Wing" writes: > > To my knowledge, sites do not run two different > implementations of DNS server > > s > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > where both DNSs back > > up each other. Like NAT, DNS needs to be rock-solid > reliable, and a single > > packet could take out a DNS server. > > Actually lots of sites use multiple vendors for DNS. That being > said there is not of lot of state to share between DNS servers. So they would update each other when one receives, say, a DNS UPDATE? -d > DHCP servers on the other had need to share lots of state. I don't > believe the failover draft (draft-ietf-dhc-failover-12) reached a > conclusion even though we implement most (all?) of it in our DHCP > servers. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Tue Dec 1 19:43:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C52E3A6812 for ; Tue, 1 Dec 2009 19:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amEdRg7zveH4 for ; Tue, 1 Dec 2009 19:43:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8EC493A682D for ; Tue, 1 Dec 2009 19:43:40 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAB9xFUurRN+K/2dsb2JhbACKN7R+mCIChC8EgWo X-IronPort-AV: E=Sophos;i="4.47,326,1257120000"; d="scan'208";a="112491551" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2009 03:43:33 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB23hW8O025625; Wed, 2 Dec 2009 03:43:33 GMT From: "Dan Wing" To: References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> <200912020254.nB22sIvO028323@drugs.dv.isc.org> Date: Tue, 1 Dec 2009 19:43:32 -0800 Message-ID: <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200912020254.nB22sIvO028323@drugs.dv.isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acpy+r/gc/iadQeGRg2r6hFSq12USAABqTbQ Cc: 'Cameron Byrne' , behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:43:41 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Tuesday, December 01, 2009 6:54 PM > To: Dan Wing > Cc: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'; behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > In message <000801ca72f8$c3fa5820$c3f0200a@cisco.com>, "Dan > Wing" writes: > > ... > > > > 100% agree. Members in a cluster failing can locally > be resolved > > > > without bouncing the Pref64. If entire cluster fails, > this is very > > > > unlikely but catastrophic, i just want a fail safe that can work > > > > *mostly*, and if the networks really broke, asking a > user to reboot > > > > > > Ask a user or ask a huge amount of users? > > > > All the affected users. > > > > > By the way, if one uses one of those mechanisms defined in > > > draft-wing-behave-learn-prefix, other than DNS64, to > > > synthesize IPv6 addresses, does that mean the DNS server or > > > the DHCP server should also dynamically detect the > > > availability of each prefix64? > > > > Whatever hands out the prefix (DNS, IPv6 router advertisements, > > DHCPv6) should hand out a functioning prefix. Providing a > > non-functioning prefix is harmful. > > Actually it shouldn't be. If a prefix doesn't work it it like a > router being down. The machines are just not reachable. Not being reachable is what I would define as 'harmful'. > > The same is true of a DHCP server providing the IP address of > > DNS servers, NTP servers, and suchlike. If a DHCP server hands > > out IP addresses for broken (or dead) servers, it is harmful. > > Which is why DHCP is designed to hand out multiple ones so that > individual failures are not a issue. draft-wing-behave-learn-prefix-05, not yet published, allows multiple prefixes as well. It also removes the unicast/ASM/SSM specifics and relies on the IPv6 prefix itself to declare if its unicast/ASM/SSM. -d > > > Does that need to be stated, though? > > > > -d > > -- > 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 Tue Dec 1 20:37:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7665A3A67C2 for ; Tue, 1 Dec 2009 20:37:27 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-XV90GDEg9e for ; Tue, 1 Dec 2009 20:37:26 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 3341A3A67AE for ; Tue, 1 Dec 2009 20:37:15 -0800 (PST) Received: by gxk28 with SMTP id 28so3038277gxk.9 for ; Tue, 01 Dec 2009 20:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=evF2yLYaAMy2p+b3mMrreD1wUGkjXq1eEVXN5twf/go=; b=bOI3i5iTzCI0MPBK63SJT8cveFcUOBqdIDUNnhEc6Mk8iRrw9nhpgVYZs5PsSvYemD lE/D0wawD1qpzaQ969ayU6Ad3QGTKY/P0sz2/ED5jWs/SliWuWq08VgqeR9cxh4ou2MR nJ+j+oqljaFfcrFJK8/M1k54RRsTbqXQJ4k/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lp3Pd7Ih1I5Mg5upspqATKMOkKLDJWRQQT9GaxAKJxncvVNLMF5q9rYATBum9iFr55 Q5D6qaKBdnRekQtq2nl11ylpArMa6xWzEdWbDKgk7FwjefYTeinyi6ZNHxjS1E73coao MBNqq3iTwvPpDpceJU78iNI2Dk/vEqB98GzM8= MIME-Version: 1.0 Received: by 10.150.162.18 with SMTP id k18mr11421938ybe.155.1259728624858; Tue, 01 Dec 2009 20:37:04 -0800 (PST) In-Reply-To: <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> Date: Tue, 1 Dec 2009 20:37:04 -0800 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Xu Xiaohu Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 04:37:27 -0000 On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing wrote: > ... >> > * Cluster =3D A set of synchronized NAT64 boxes sharing a >> > single Pref64::/n. >> >> Does that mean a set of NAT64 boxes within a cluster should >> be from a single >> vendor? If so, how to deal with the case that some abnormal >> packets cause >> NAT boxes (using the same OS) within a cluster to crash >> simultaneously due to a bug with that OS? > > The vendor fixes the bug. > 100% agree. The counter to Xu Xiaohu's point is what happens when vendor X sends a buggy sync update to vendor Y, and now vendor Y crashes.... ok. We traded one unlikely (but real) bad situation for another unlikely but bad situation. > The operational complexity of running two NATs, from two different vendor= s, is > very high: =A0different CLIs, different alarming/alerting (e.g., SYSLOG, = SNMP, > per-session NAT logging), different features (e.g., IPsec Passthru, SCTP)= , > different implementation of features (e.g., TCP MSS adjustment, fragmenta= tion > [timeouts? =A0how much memory dedicated to reassembly? =A0out-of-order pa= ckets > supported?]), bandwidth and throughput (Mbps, pps), =A0make it too hard t= o > operate both NATs. 100% agree. > > To my knowledge, sites do not run two different implementations of DNS se= rvers > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs b= ack > up each other. =A0Like NAT, DNS needs to be rock-solid reliable, and a si= ngle > packet could take out a DNS server. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xuxh@huawei.com Tue Dec 1 20:39:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42023A67C2 for ; Tue, 1 Dec 2009 20:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6qGkepZVnji for ; Tue, 1 Dec 2009 20:39:24 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1EEA63A67AE for ; Tue, 1 Dec 2009 20:39:24 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU0001KFCXEFN@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000AZMCXEA2@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:14 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU000BW4CXERJ@szxml04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:14 +0800 (CST) Date: Wed, 02 Dec 2009 12:39:14 +0800 From: Xu Xiaohu In-reply-to: <000801ca72f8$c3fa5820$c3f0200a@cisco.com> To: 'Dan Wing' , 'Cameron Byrne' , 'Simon Perreault' Message-id: <004101ca7309$668d5a00$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acpy0mn3S8LOZsW/SWW5oxGfCX6NjAAH5KCwAAGDm/AABCGFcA== Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 04:39:25 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C22=C8=D5 10:40 > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: > draft-xu-behave-nat-state-sync-00 >=20 > ... > > > 100% agree. Members in a cluster failing can locally be resolved > > > without bouncing the Pref64. If entire cluster fails, this is = very > > > unlikely but catastrophic, i just want a fail safe that can work > > > *mostly*, and if the networks really broke, asking a user to = reboot > > > > Ask a user or ask a huge amount of users? >=20 > All the affected users. >=20 > > By the way, if one uses one of those mechanisms defined in > > draft-wing-behave-learn-prefix, other than DNS64, to > > synthesize IPv6 addresses, does that mean the DNS server or > > the DHCP server should also dynamically detect the > > availability of each prefix64? >=20 > Whatever hands out the prefix (DNS, IPv6 router advertisements, > DHCPv6) should hand out a functioning prefix. Providing a > non-functioning prefix is harmful. Agree. In fact, with the IPv6 RA approach, the gateway router could dynamically learn the available prefix64 through IGP extension (e.g., = Router Information LSA in OSPF). Xiaohu > The same is true of a DHCP server providing the IP address of > DNS servers, NTP servers, and suchlike. If a DHCP server hands > out IP addresses for broken (or dead) servers, it is harmful. >=20 > Does that need to be stated, though? >=20 > -d From jmh@joelhalpern.com Tue Dec 1 20:45:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A893A69EE for ; Tue, 1 Dec 2009 20:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hFofjxC3Jd2 for ; Tue, 1 Dec 2009 20:45:56 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6445C3A69E2 for ; Tue, 1 Dec 2009 20:45:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2739843B315; Tue, 1 Dec 2009 20:45:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-79.clppva.btas.verizon.net [71.161.50.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0CA6743B314; Tue, 1 Dec 2009 20:45:47 -0800 (PST) Message-ID: <4B15F0FC.5000509@joelhalpern.com> Date: Tue, 01 Dec 2009 23:45:48 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cameron Byrne References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Xu Xiaohu , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 04:45:57 -0000 I believe we have agreed that we want to support the configuration of multiple stateful NAT64s in a cluster sharing state (using the same prefix, backing each other up / sharing load / ... ). While it is true that one can deploy that with solutions from a single vendor, it seems natural and consistent with the rest of what we do here that we want to allow folks to build such a cluster using devices from different vendors. Arguing about why an operator might or might not do that is a waste of time. Some will want multiple vendors. Some will want a single vendor. Some will want the ability to migrate to a new vendor. For the IETF therefore, the protocol for the state sharing seems a sensible thing to standardize. Yours, Joel Cameron Byrne wrote: > On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing wrote: >> ... >>>> * Cluster = A set of synchronized NAT64 boxes sharing a >>>> single Pref64::/n. >>> Does that mean a set of NAT64 boxes within a cluster should >>> be from a single >>> vendor? If so, how to deal with the case that some abnormal >>> packets cause >>> NAT boxes (using the same OS) within a cluster to crash >>> simultaneously due to a bug with that OS? >> The vendor fixes the bug. >> > > 100% agree. The counter to Xu Xiaohu's point is what happens when > vendor X sends a buggy sync update to vendor Y, and now vendor Y > crashes.... ok. We traded one unlikely (but real) bad situation for > another unlikely but bad situation. > > >> The operational complexity of running two NATs, from two different vendors, is >> very high: different CLIs, different alarming/alerting (e.g., SYSLOG, SNMP, >> per-session NAT logging), different features (e.g., IPsec Passthru, SCTP), >> different implementation of features (e.g., TCP MSS adjustment, fragmentation >> [timeouts? how much memory dedicated to reassembly? out-of-order packets >> supported?]), bandwidth and throughput (Mbps, pps), make it too hard to >> operate both NATs. > > 100% agree. > >> To my knowledge, sites do not run two different implementations of DNS servers >> (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back >> up each other. Like NAT, DNS needs to be rock-solid reliable, and a single >> packet could take out a DNS server. >> >> -d >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marka@isc.org Tue Dec 1 20:51:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9733A69FA for ; Tue, 1 Dec 2009 20:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwYxHnG9k+bR for ; Tue, 1 Dec 2009 20:51:26 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id EF70E3A69F4 for ; Tue, 1 Dec 2009 20:51:25 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5AC76E6069; Wed, 2 Dec 2009 04:51:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB24pD45014602; Wed, 2 Dec 2009 15:51:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020451.nB24pD45014602@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <200912020238.nB22c6v8005164@drugs.dv.isc.org> <002201ca7301$5db9a710$c3f0200a@cisco.com> In-reply-to: Your message of "Tue, 01 Dec 2009 19:41:43 -0800." <002201ca7301$5db9a710$c3f0200a@cisco.com> Date: Wed, 02 Dec 2009 15:51:12 +1100 Sender: marka@isc.org Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 04:51:27 -0000 In message <002201ca7301$5db9a710$c3f0200a@cisco.com>, "Dan Wing" writes: > > > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Sent: Tuesday, December 01, 2009 6:38 PM > > To: Dan Wing > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > Subject: Re: [BEHAVE] proprietary implementation v.s > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan > > Wing" writes: > > > To my knowledge, sites do not run two different > > implementations of DNS server > > > s > > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > > where both DNSs back > > > up each other. Like NAT, DNS needs to be rock-solid > > reliable, and a single > > > packet could take out a DNS server. > > > > Actually lots of sites use multiple vendors for DNS. That being > > said there is not of lot of state to share between DNS servers. > > So they would update each other when one receives, say, a DNS UPDATE? UPDATEs are forwarded to the master server that then applies the update and sends out NOTIFY messages to say the zone contents have changed. The slaves then do a IXFR request triggered by the NOFIFY. serial 1 serial 1 client -> UPDATE -> slave -> FORWARED UPDATE -> master serial 2 client <- UPDATE RESPONSE <- slave <- UPDATE RESPONSE <- master slaves <- NOTIFY (serial 2) <- master slaves -> NOTIFY RESPONSE -> master slaves -> IXFR (serial 1) -> master slaves <- IXFR RESPONSE <- master serial 2 > -d > > > DHCP servers on the other had need to share lots of state. I don't > > believe the failover draft (draft-ietf-dhc-failover-12) reached a > > conclusion even though we implement most (all?) of it in our DHCP > > servers. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Tue Dec 1 21:12:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4554228C148 for ; Tue, 1 Dec 2009 21:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5cv9+6uYeyh for ; Tue, 1 Dec 2009 21:12:34 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9E77D28C13D for ; Tue, 1 Dec 2009 21:12:33 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU0006GWEGOCH@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 13:12:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000GNIEGO41@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 13:12:24 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU000JC3EGN4S@szxml06-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 13:12:24 +0800 (CST) Date: Wed, 02 Dec 2009 13:12:23 +0800 From: Xu Xiaohu In-reply-to: To: 'Cameron Byrne' , 'Dan Wing' Message-id: <004201ca730e$086f9ff0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: AcpzCSjOvthYO94IRQ2tnhlJlOvVrQABBCXw Cc: behave@ietf.org Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:12:36 -0000 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > Cameron Byrne > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=882=E6=97=A5 12:37 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Dan Wing > =E6=8A=84=E9=80=81: behave@ietf.org; Xu Xiaohu > =E4=B8=BB=E9=A2=98: Re: [BEHAVE] proprietary implementation v.s = standardisedprotocols//re: > draft-xu-behave-nat-state-sync-00 >=20 > On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing wrote: > > ... > >> > * Cluster =3D A set of synchronized NAT64 boxes sharing a > >> > single Pref64::/n. > >> > >> Does that mean a set of NAT64 boxes within a cluster should > >> be from a single > >> vendor? If so, how to deal with the case that some abnormal > >> packets cause > >> NAT boxes (using the same OS) within a cluster to crash > >> simultaneously due to a bug with that OS? > > > > The vendor fixes the bug. > > >=20 > 100% agree. The counter to Xu Xiaohu's point is what happens when > vendor X sends a buggy sync update to vendor Y, and now vendor Y > crashes.... ok. We traded one unlikely (but real) bad situation for > another unlikely but bad situation. Aha, as long as the router from vendor X is still available, that would = be OK. Maybe you would say later how about if router X kills itself = after making router Y crash. Just a joke! ^_^ Xiaohu > > The operational complexity of running two NATs, from two different = vendors, > is > > very high: different CLIs, different alarming/alerting (e.g., = SYSLOG, > SNMP, > > per-session NAT logging), different features (e.g., IPsec Passthru, = SCTP), > > different implementation of features (e.g., TCP MSS adjustment, > fragmentation > > [timeouts? how much memory dedicated to reassembly? out-of-order = packets > > supported?]), bandwidth and throughput (Mbps, pps), make it too = hard to > > operate both NATs. >=20 > 100% agree. >=20 > > > > To my knowledge, sites do not run two different implementations of = DNS servers > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both = DNSs back > > up each other. Like NAT, DNS needs to be rock-solid reliable, and a = single > > packet could take out a DNS server. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Dec 1 21:14:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13CD28C0ED for ; Tue, 1 Dec 2009 21:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCH0Hys0yivA for ; Tue, 1 Dec 2009 21:14:57 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B5C083A69F4 for ; Tue, 1 Dec 2009 21:14:57 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAC6GFUurRN+K/2dsb2JhbACKN7RgmCwChC8E X-IronPort-AV: E=Sophos;i="4.47,327,1257120000"; d="scan'208";a="112521168" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2009 05:14:48 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB25ElIH011831; Wed, 2 Dec 2009 05:14:47 GMT From: "Dan Wing" To: References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <200912020238.nB22c6v8005164@drugs.dv.isc.org> <002201ca7301$5db9a710$c3f0200a@cisco.com> <200912020451.nB24pD45014602@drugs.dv.isc.org> Date: Tue, 1 Dec 2009 21:14:47 -0800 Message-ID: <005301ca730e$5e44bd20$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200912020451.nB24pD45014602@drugs.dv.isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpzCxgfECyaalRGTfWGdMjbmvEYdQAAzHpQ Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:14:58 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Tuesday, December 01, 2009 8:51 PM > To: Dan Wing > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > In message <002201ca7301$5db9a710$c3f0200a@cisco.com>, "Dan > Wing" writes: > > > > > > > -----Original Message----- > > > From: marka@isc.org [mailto:marka@isc.org] > > > Sent: Tuesday, December 01, 2009 6:38 PM > > > To: Dan Wing > > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > > Subject: Re: [BEHAVE] proprietary implementation v.s > > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > > > > In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan > > > Wing" writes: > > > > To my knowledge, sites do not run two different > > > implementations of DNS server > > > > s > > > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > > > where both DNSs back > > > > up each other. Like NAT, DNS needs to be rock-solid > > > reliable, and a single > > > > packet could take out a DNS server. > > > > > > Actually lots of sites use multiple vendors for DNS. That being > > > said there is not of lot of state to share between DNS servers. > > > > So they would update each other when one receives, say, a > DNS UPDATE? > > UPDATEs are forwarded to the master server They're both master servers; you can't invoke DNS's master/secondary concept here. :-) -d > that then applies the > update and sends out NOTIFY messages to say the zone contents have > changed. The slaves then do a IXFR request triggered by the NOFIFY. > > serial 1 serial 1 > client -> UPDATE -> slave -> FORWARED UPDATE -> master > serial 2 > client <- UPDATE RESPONSE <- slave <- UPDATE RESPONSE <- master > slaves <- NOTIFY (serial 2) <- master > slaves -> NOTIFY RESPONSE -> master > slaves -> IXFR (serial 1) -> master > slaves <- IXFR RESPONSE <- master > serial 2 > > > -d > > > > > DHCP servers on the other had need to share lots of > state. I don't > > > believe the failover draft (draft-ietf-dhc-failover-12) reached a > > > conclusion even though we implement most (all?) of it in our DHCP > > > servers. > > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Tue Dec 1 21:20:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BB93A68AA for ; Tue, 1 Dec 2009 21:20:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y5ZhGg5nVW9 for ; Tue, 1 Dec 2009 21:20:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 491123A67E1 for ; Tue, 1 Dec 2009 21:20:44 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAqIFUurRN+J/2dsb2JhbACKN7RbmCyEMQSBag X-IronPort-AV: E=Sophos;i="4.47,327,1257120000"; d="scan'208";a="56369184" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2009 05:20:36 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB25KaOC010052; Wed, 2 Dec 2009 05:20:36 GMT From: "Dan Wing" To: "'Joel M. Halpern'" , "'Cameron Byrne'" References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <4B15F0FC.5000509@joelhalpern.com> Date: Tue, 1 Dec 2009 21:20:36 -0800 Message-ID: <005a01ca730f$2e1ce630$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4B15F0FC.5000509@joelhalpern.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpzClI7Evjyrbb1SB2APNGIB81nDQABC+mw Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:20:45 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, December 01, 2009 8:46 PM > To: Cameron Byrne > Cc: Dan Wing; behave@ietf.org; Xu Xiaohu > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > I believe we have agreed that we want to support the configuration of > multiple stateful NAT64s in a cluster sharing state (using the same > prefix, backing each other up / sharing load / ... ). > > While it is true that one can deploy that with solutions from > a single > vendor, it seems natural and consistent with the rest of what > we do here > that we want to allow folks to build such a cluster using > devices from > different vendors. Arguing about why an operator might or > might not do > that is a waste of time. Some will want multiple vendors. Some will > want a single vendor. Some will want the ability to migrate to a new > vendor. > > For the IETF therefore, the protocol for the state sharing seems a > sensible thing to standardize. FWIW, I will be asking my co-chair to decide WG consensus to move forward with NAT synchronization. -d > Yours, > Joel > > Cameron Byrne wrote: > > On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing wrote: > >> ... > >>>> * Cluster = A set of synchronized NAT64 boxes sharing a > >>>> single Pref64::/n. > >>> Does that mean a set of NAT64 boxes within a cluster should > >>> be from a single > >>> vendor? If so, how to deal with the case that some abnormal > >>> packets cause > >>> NAT boxes (using the same OS) within a cluster to crash > >>> simultaneously due to a bug with that OS? > >> The vendor fixes the bug. > >> > > > > 100% agree. The counter to Xu Xiaohu's point is what happens when > > vendor X sends a buggy sync update to vendor Y, and now vendor Y > > crashes.... ok. We traded one unlikely (but real) bad situation for > > another unlikely but bad situation. > > > > > >> The operational complexity of running two NATs, from two > different vendors, is > >> very high: different CLIs, different alarming/alerting > (e.g., SYSLOG, SNMP, > >> per-session NAT logging), different features (e.g., IPsec > Passthru, SCTP), > >> different implementation of features (e.g., TCP MSS > adjustment, fragmentation > >> [timeouts? how much memory dedicated to reassembly? > out-of-order packets > >> supported?]), bandwidth and throughput (Mbps, pps), make > it too hard to > >> operate both NATs. > > > > 100% agree. > > > >> To my knowledge, sites do not run two different > implementations of DNS servers > >> (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > where both DNSs back > >> up each other. Like NAT, DNS needs to be rock-solid > reliable, and a single > >> packet could take out a DNS server. > >> > >> -d > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From marka@isc.org Tue Dec 1 21:49:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B310D3A69EE for ; Tue, 1 Dec 2009 21:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvQHUGPwmMeQ for ; Tue, 1 Dec 2009 21:49:21 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id AD9003A696F for ; Tue, 1 Dec 2009 21:49:21 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 104B1E6069; Wed, 2 Dec 2009 05:49:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB25n8Yu058184; Wed, 2 Dec 2009 16:49:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020549.nB25n8Yu058184@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> <200912020254.nB22sIvO028323@drugs.dv.isc.org> <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> In-reply-to: Your message of "Tue, 01 Dec 2009 19:43:32 -0800." <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> Date: Wed, 02 Dec 2009 16:49:08 +1100 Sender: marka@isc.org Cc: 'Cameron Byrne' , behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:49:22 -0000 In message <002301ca7301$9ef3f4b0$c3f0200a@cisco.com>, "Dan Wing" writes: > > > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Sent: Tuesday, December 01, 2009 6:54 PM > > To: Dan Wing > > Cc: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'; behave@ietf.org > > Subject: Re: [BEHAVE] proprietary implementation v.s > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > In message <000801ca72f8$c3fa5820$c3f0200a@cisco.com>, "Dan > > Wing" writes: > > > ... > > > > > 100% agree. Members in a cluster failing can locally > > be resolved > > > > > without bouncing the Pref64. If entire cluster fails, > > this is very > > > > > unlikely but catastrophic, i just want a fail safe that can work > > > > > *mostly*, and if the networks really broke, asking a > > user to reboot > > > > > > > > Ask a user or ask a huge amount of users? > > > > > > All the affected users. > > > > > > > By the way, if one uses one of those mechanisms defined in > > > > draft-wing-behave-learn-prefix, other than DNS64, to > > > > synthesize IPv6 addresses, does that mean the DNS server or > > > > the DHCP server should also dynamically detect the > > > > availability of each prefix64? > > > > > > Whatever hands out the prefix (DNS, IPv6 router advertisements, > > > DHCPv6) should hand out a functioning prefix. Providing a > > > non-functioning prefix is harmful. > > > > Actually it shouldn't be. If a prefix doesn't work it it like a > > router being down. The machines are just not reachable. > > Not being reachable is what I would define as 'harmful'. You don't, in general, pull hosts from the DNS because a router is down. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Dec 1 21:55:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0B73A6805 for ; Tue, 1 Dec 2009 21:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pSSYgu1wCu1 for ; Tue, 1 Dec 2009 21:55:26 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 2F0153A67EE for ; Tue, 1 Dec 2009 21:55:26 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id B344AE6068; Wed, 2 Dec 2009 05:55:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB25tEu5058590; Wed, 2 Dec 2009 16:55:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020555.nB25tEu5058590@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <200912020238.nB22c6v8005164@drugs.dv.isc.org> <002201ca7301$5db9a710$c3f0200a@cisco.com> <200912020451.nB24pD45014602@drugs.dv.isc.org> <005301ca730e$5e44bd20$c3f0200a@cisco.com> In-reply-to: Your message of "Tue, 01 Dec 2009 21:14:47 -0800." <005301ca730e$5e44bd20$c3f0200a@cisco.com> Date: Wed, 02 Dec 2009 16:55:14 +1100 Sender: marka@isc.org Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:55:27 -0000 In message <005301ca730e$5e44bd20$c3f0200a@cisco.com>, "Dan Wing" writes: > > > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Sent: Tuesday, December 01, 2009 8:51 PM > > To: Dan Wing > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > Subject: Re: [BEHAVE] proprietary implementation v.s > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > In message <002201ca7301$5db9a710$c3f0200a@cisco.com>, "Dan > > Wing" writes: > > > > > > > > > > -----Original Message----- > > > > From: marka@isc.org [mailto:marka@isc.org] > > > > Sent: Tuesday, December 01, 2009 6:38 PM > > > > To: Dan Wing > > > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > > > Subject: Re: [BEHAVE] proprietary implementation v.s > > > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > > > > > > > In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan > > > > Wing" writes: > > > > > To my knowledge, sites do not run two different > > > > implementations of DNS server > > > > > s > > > > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > > > > where both DNSs back > > > > > up each other. Like NAT, DNS needs to be rock-solid > > > > reliable, and a single > > > > > packet could take out a DNS server. > > > > > > > > Actually lots of sites use multiple vendors for DNS. That being > > > > said there is not of lot of state to share between DNS servers. > > > > > > So they would update each other when one receives, say, a > > DNS UPDATE? > > > > UPDATEs are forwarded to the master server > > They're both master servers; you can't invoke DNS's master/secondary > concept here. :-) UPDATE doesn't support multi-master, it hasn't been specified. > > that then applies the > > update and sends out NOTIFY messages to say the zone contents have > > changed. The slaves then do a IXFR request triggered by the NOFIFY. > > > > serial 1 serial 1 > > client -> UPDATE -> slave -> FORWARED UPDATE -> master > > serial 2 > > client <- UPDATE RESPONSE <- slave <- UPDATE RESPONSE <- master > > slaves <- NOTIFY (serial 2) <- master > > slaves -> NOTIFY RESPONSE -> master > > slaves -> IXFR (serial 1) -> master > > slaves <- IXFR RESPONSE <- master > > serial 2 > > > > > -d > > > > > > > DHCP servers on the other had need to share lots of > > state. I don't > > > > believe the failover draft (draft-ietf-dhc-failover-12) reached a > > > > conclusion even though we implement most (all?) of it in our DHCP > > > > servers. > > > > > > > > Mark > > > > -- > > > > Mark Andrews, ISC > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- 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 Tue Dec 1 22:03:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7593A6805 for ; Tue, 1 Dec 2009 22:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmsSJ8hyU7qK for ; Tue, 1 Dec 2009 22:03:05 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 80E4D3A67F5 for ; Tue, 1 Dec 2009 22:03:05 -0800 (PST) Received: by gxk28 with SMTP id 28so3076134gxk.9 for ; Tue, 01 Dec 2009 22:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I4HzhGDH9r92y+hUkqFFWKF0miOxtxAAR3U936sXJ6g=; b=AIkGV+LrzRrWU8AvCbLXuH0jvCM1pFv8iuhOns6Cb74FAD9KwApdn8WKGDvfGw3MxK hAJsbBl3NaGXVys14YO+h/At9Iq1P9bN1j1Y+4x7SJuE77Kx0QgvYrw90/qNti1YSaFF ufJGkZaHJ4cMoAxfz1BXH0a/OUW0dIgxKMm2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UEmuOSWvQgtYq+7t//dxKbiI3jRmbDn/HytEwd3NtQBvJkr/BaJhKklx+rKPHUFNMt X3MaijWhR68RV+74arYf+jBfGUSyTKoqKQ/4m4iEmX8dMnFoLCpANzdlkljn6NHk5aoZ p69Xc75EOQsoxIKVO8DHsmkGSJDri56jc1E1o= MIME-Version: 1.0 Received: by 10.150.28.27 with SMTP id b27mr11647336ybb.59.1259733773038; Tue, 01 Dec 2009 22:02:53 -0800 (PST) In-Reply-To: <200912020549.nB25n8Yu058184@drugs.dv.isc.org> References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> <200912020254.nB22sIvO028323@drugs.dv.isc.org> <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> <200912020549.nB25n8Yu058184@drugs.dv.isc.org> Date: Tue, 1 Dec 2009 22:02:52 -0800 Message-ID: From: Cameron Byrne To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Xu Xiaohu , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:03:06 -0000 On Tue, Dec 1, 2009 at 9:49 PM, Mark Andrews wrote: > > In message <002301ca7301$9ef3f4b0$c3f0200a@cisco.com>, "Dan Wing" writes: >> >> >> > -----Original Message----- >> > From: marka@isc.org [mailto:marka@isc.org] >> > Sent: Tuesday, December 01, 2009 6:54 PM >> > To: Dan Wing >> > Cc: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'; behave@ietf.org >> > Subject: Re: [BEHAVE] proprietary implementation v.s >> > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 >> > >> > >> > In message <000801ca72f8$c3fa5820$c3f0200a@cisco.com>, "Dan >> > Wing" writes: >> > > ... >> > > > > 100% agree. =A0Members in a cluster failing can locally >> > be resolved >> > > > > without bouncing the Pref64. =A0If entire cluster fails, >> > this is very >> > > > > unlikely but catastrophic, i just want a fail safe that can work >> > > > > *mostly*, and if the networks really broke, asking a >> > user to reboot >> > > > >> > > > Ask a user or ask a huge amount of users? >> > > >> > > All the affected users. >> > > >> > > > By the way, if one uses one of those mechanisms defined in >> > > > draft-wing-behave-learn-prefix, other than DNS64, to >> > > > synthesize IPv6 addresses, does that mean the DNS server or >> > > > the DHCP server should also dynamically detect the >> > > > availability of each prefix64? >> > > >> > > Whatever hands out the prefix (DNS, IPv6 router advertisements, >> > > DHCPv6) should hand out a functioning prefix. =A0Providing a >> > > non-functioning prefix is harmful. >> > >> > Actually it shouldn't be. =A0If a prefix doesn't work it it like a >> > router being down. =A0The machines are just not reachable. >> >> Not being reachable is what I would define as 'harmful'. > > You don't, in general, pull hosts from the DNS because a router is > down. If i understand your statement right, you do pull host from the a given DNS server upon failure if it is anycast DNS > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > From dwing@cisco.com Tue Dec 1 22:05:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4033A67F5 for ; Tue, 1 Dec 2009 22:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP5jjnkKDAAV for ; Tue, 1 Dec 2009 22:05:24 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 122513A67B5 for ; Tue, 1 Dec 2009 22:05:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJeSFUurRN+J/2dsb2JhbACKN7RZmCYChC8EgWo X-IronPort-AV: E=Sophos;i="4.47,327,1257120000"; d="scan'208";a="56381502" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2009 06:05:13 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB265Dwj001800; Wed, 2 Dec 2009 06:05:13 GMT From: "Dan Wing" To: References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <200912020238.nB22c6v8005164@drugs.dv.isc.org> <002201ca7301$5db9a710$c3f0200a@cisco.com> <200912020451.nB24pD45014602@drugs.dv.isc.org> <005301ca730e$5e44bd20$c3f0200a@cisco.com> <200912020555.nB25tEu5058590@drugs.dv.isc.org> Date: Tue, 1 Dec 2009 22:05:13 -0800 Message-ID: <006401ca7315$69a57900$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200912020555.nB25tEu5058590@drugs.dv.isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpzFAaOyJyDYFU+TB+cbry+F2ozhgAAQQoA Cc: behave@ietf.org, 'Xu Xiaohu' Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:05:25 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Tuesday, December 01, 2009 9:55 PM > To: Dan Wing > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > Subject: Re: [BEHAVE] proprietary implementation v.s > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > In message <005301ca730e$5e44bd20$c3f0200a@cisco.com>, "Dan > Wing" writes: > > > > > > > -----Original Message----- > > > From: marka@isc.org [mailto:marka@isc.org] > > > Sent: Tuesday, December 01, 2009 8:51 PM > > > To: Dan Wing > > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > > Subject: Re: [BEHAVE] proprietary implementation v.s > > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > > > > In message <002201ca7301$5db9a710$c3f0200a@cisco.com>, "Dan > > > Wing" writes: > > > > > > > > > > > > > -----Original Message----- > > > > > From: marka@isc.org [mailto:marka@isc.org] > > > > > Sent: Tuesday, December 01, 2009 6:38 PM > > > > > To: Dan Wing > > > > > Cc: 'Xu Xiaohu'; 'Simon Perreault'; behave@ietf.org > > > > > Subject: Re: [BEHAVE] proprietary implementation v.s > > > > > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > > > > > > > > > > > > > > > In message <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>, "Dan > > > > > Wing" writes: > > > > > > To my knowledge, sites do not run two different > > > > > implementations of DNS server > > > > > > s > > > > > > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) > > > > > where both DNSs back > > > > > > up each other. Like NAT, DNS needs to be rock-solid > > > > > reliable, and a single > > > > > > packet could take out a DNS server. > > > > > > > > > > Actually lots of sites use multiple vendors for DNS. > That being > > > > > said there is not of lot of state to share between > DNS servers. > > > > > > > > So they would update each other when one receives, say, a > > > DNS UPDATE? > > > > > > UPDATEs are forwarded to the master server > > > > They're both master servers; you can't invoke DNS's master/secondary > > concept here. :-) > > UPDATE doesn't support multi-master, it hasn't been specified. I know. Then the multi-vendor mixed DNS environment you had described earlier isn't happening: one DNS is master, the others are secondary. That's different from the active/standby of NAT64 being proposed, where the standby NAT64 takes over completely and fully for the now-deceased (e.g., crashed) NAT64, and is now a fully-functioning node. With a secondary taking over for a master, it is not a fully funtional node (it can't accept UPDATEs, for example, and changing its serial number on a zone file will be forgotten when the master comes back alive). Only the master is fully functional. Seems different to me. -d > > > that then applies the > > > update and sends out NOTIFY messages to say the zone contents have > > > changed. The slaves then do a IXFR request triggered by > the NOFIFY. > > > > > > serial 1 serial 1 > > > client -> UPDATE -> slave -> FORWARED UPDATE > -> master > > > serial 2 > > > client <- UPDATE RESPONSE <- slave <- UPDATE RESPONSE <- master > > > slaves <- NOTIFY (serial 2) <- master > > > slaves -> NOTIFY RESPONSE -> master > > > slaves -> IXFR (serial 1) -> master > > > slaves <- IXFR RESPONSE <- master > > > serial 2 > > > > > > > -d > > > > > > > > > DHCP servers on the other had need to share lots of > > > state. I don't > > > > > believe the failover draft > (draft-ietf-dhc-failover-12) reached a > > > > > conclusion even though we implement most (all?) of it > in our DHCP > > > > > servers. > > > > > > > > > > Mark > > > > > -- > > > > > Mark Andrews, ISC > > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohamed.boucadair@orange-ftgroup.com Tue Dec 1 22:53:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9F33A67B0 for ; Tue, 1 Dec 2009 22:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWQvaL9QcgO4 for ; Tue, 1 Dec 2009 22:53:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id B015A3A6844 for ; Tue, 1 Dec 2009 22:53:51 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 30AC7C0273; Wed, 2 Dec 2009 07:53:43 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1977438406B; Wed, 2 Dec 2009 07:53:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 2 Dec 2009 07:53:42 +0100 From: To: Dan Wing , 'Xu Xiaohu' , 'Simon Perreault' Date: Wed, 2 Dec 2009 07:53:41 +0100 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYogAACgIiAACjWLwA== Message-ID: <29025_1259736823_4B160EF7_29025_3067_1_94C682931C08B048B7A8645303FDC9F30EF27742B6@PUEXCB1B.nanterre.francetelecom.fr> References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> In-Reply-To: <000001ca72f4$1e1a30a0$c3f0200a@cisco.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.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.2.10325 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:53:53 -0000 Dear Dan, Please see inline. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Dan Wing Envoy=E9 : mercredi 2 d=E9cembre 2009 03:07 =C0 : 'Xu Xiaohu'; 'Simon Perreault' Cc : behave@ietf.org Objet : Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//= re: draft-xu-behave-nat-state-sync-00 ...=20 > > * Cluster =3D A set of synchronized NAT64 boxes sharing a=20 > > single Pref64::/n. >=20 > Does that mean a set of NAT64 boxes within a cluster should=20 > be from a single > vendor? If so, how to deal with the case that some abnormal=20 > packets cause > NAT boxes (using the same OS) within a cluster to crash=20 > simultaneously due to a bug with that OS? The vendor fixes the bug. The operational complexity of running two NATs, from two different vendors,= is very high: different CLIs, different alarming/alerting (e.g., SYSLOG, SNMP, per-session NAT logging), different features (e.g., IPsec Passthru, SCTP), different implementation of features (e.g., TCP MSS adjustment, fragmentati= on [timeouts? how much memory dedicated to reassembly? out-of-order packets supported?]), bandwidth and throughput (Mbps, pps), make it too hard to operate both NATs. Med: Except for the configuration operations, the remaining features should= be the same, since both implementations should met the SP's requirement. Furthermore, having both the primary and that backup nodes from the same ve= ndor induces other unpredictable problems (and therefore long unavailabilit= y period). We experienced that kind of problems/behaviour with L2 nodes, it= may be the case for NATxy boxes too. To my knowledge, sites do not run two different implementations of DNS serv= ers (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back up each other. Like NAT, DNS needs to be rock-solid reliable, and a single packet could take out a DNS server. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From marka@isc.org Tue Dec 1 23:14:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EC43A6A1B for ; Tue, 1 Dec 2009 23:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuhTRAU9KubW for ; Tue, 1 Dec 2009 23:14:08 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 1AD323A67F7 for ; Tue, 1 Dec 2009 23:14:08 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3A521E6065; Wed, 2 Dec 2009 07:13:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nB27DtVH060582; Wed, 2 Dec 2009 18:13:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912020713.nB27DtVH060582@drugs.dv.isc.org> To: Cameron Byrne From: Mark Andrews References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> <200912020254.nB22sIvO028323@drugs.dv.isc.org> <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> <200912020549.nB25n8Yu058184@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 01 Dec 2009 22:02:52 -0800." Date: Wed, 02 Dec 2009 18:13:55 +1100 Sender: marka@isc.org Cc: behave@ietf.org, Xu Xiaohu , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 07:14:09 -0000 In message , Camer on Byrne writes: > On Tue, Dec 1, 2009 at 9:49 PM, Mark Andrews wrote: > > > > In message <002301ca7301$9ef3f4b0$c3f0200a@cisco.com>, "Dan Wing" writes: > >> > >> > >> > -----Original Message----- > >> > From: marka@isc.org [mailto:marka@isc.org] > >> > Sent: Tuesday, December 01, 2009 6:54 PM > >> > To: Dan Wing > >> > Cc: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'; behave@ietf.org > >> > Subject: Re: [BEHAVE] proprietary implementation v.s > >> > standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 > >> > > >> > > >> > In message <000801ca72f8$c3fa5820$c3f0200a@cisco.com>, "Dan > >> > Wing" writes: > >> > > ... > >> > > > > 100% agree. =A0Members in a cluster failing can locally > >> > be resolved > >> > > > > without bouncing the Pref64. =A0If entire cluster fails, > >> > this is very > >> > > > > unlikely but catastrophic, i just want a fail safe that can work > >> > > > > *mostly*, and if the networks really broke, asking a > >> > user to reboot > >> > > > > >> > > > Ask a user or ask a huge amount of users? > >> > > > >> > > All the affected users. > >> > > > >> > > > By the way, if one uses one of those mechanisms defined in > >> > > > draft-wing-behave-learn-prefix, other than DNS64, to > >> > > > synthesize IPv6 addresses, does that mean the DNS server or > >> > > > the DHCP server should also dynamically detect the > >> > > > availability of each prefix64? > >> > > > >> > > Whatever hands out the prefix (DNS, IPv6 router advertisements, > >> > > DHCPv6) should hand out a functioning prefix. =A0Providing a > >> > > non-functioning prefix is harmful. > >> > > >> > Actually it shouldn't be. =A0If a prefix doesn't work it it like a > >> > router being down. =A0The machines are just not reachable. > >> > >> Not being reachable is what I would define as 'harmful'. > > > > You don't, in general, pull hosts from the DNS because a router is > > down. > > If i understand your statement right, you do pull host from the a > given DNS server upon failure if it is anycast DNS No. Normally you leave the address records in and let the client determine if the host is reachable or not. You never want to remove all addresses as that makes the host disappear and that changes recovery strategies. > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohamed.boucadair@orange-ftgroup.com Tue Dec 1 23:16:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC89528C0FD for ; Tue, 1 Dec 2009 23:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8Knd6RpSvfx for ; Tue, 1 Dec 2009 23:16:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 652A53A6914 for ; Tue, 1 Dec 2009 23:16:20 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 1F881190493; Wed, 2 Dec 2009 08:16:12 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 07FF438403A; Wed, 2 Dec 2009 08:16:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 2 Dec 2009 08:16:11 +0100 From: To: "Joel M. Halpern" Date: Wed, 2 Dec 2009 08:16:10 +0100 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: AcpzClV2gjsmSUZkRzyCUUaGZXvxjgAFN8Lg Message-ID: <29028_1259738172_4B16143C_29028_27025_1_94C682931C08B048B7A8645303FDC9F30EF27742C2@PUEXCB1B.nanterre.francetelecom.fr> References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> <4B15F0FC.5000509@joelhalpern.com> In-Reply-To: <4B15F0FC.5000509@joelhalpern.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.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.2.65416 Cc: "behave@ietf.org" , Dan Wing , Xu Xiaohu Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 07:16:21 -0000 =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Joel M. Halpern Envoy=E9 : mercredi 2 d=E9cembre 2009 05:46 =C0 : Cameron Byrne Cc : behave@ietf.org; Xu Xiaohu; Dan Wing Objet : Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//= re: draft-xu-behave-nat-state-sync-00 I believe we have agreed that we want to support the configuration of=20 multiple stateful NAT64s in a cluster sharing state (using the same=20 prefix, backing each other up / sharing load / ... ). While it is true that one can deploy that with solutions from a single=20 vendor, it seems natural and consistent with the rest of what we do here=20 that we want to allow folks to build such a cluster using devices from=20 different vendors. Arguing about why an operator might or might not do=20 that is a waste of time. Some will want multiple vendors. Some will=20 want a single vendor. Some will want the ability to migrate to a new=20 vendor. For the IETF therefore, the protocol for the state sharing seems a=20 sensible thing to standardize. Med: I fully agree. Yours, Joel Cameron Byrne wrote: > On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing wrote: >> ... >>>> * Cluster =3D A set of synchronized NAT64 boxes sharing a >>>> single Pref64::/n. >>> Does that mean a set of NAT64 boxes within a cluster should >>> be from a single >>> vendor? If so, how to deal with the case that some abnormal >>> packets cause >>> NAT boxes (using the same OS) within a cluster to crash >>> simultaneously due to a bug with that OS? >> The vendor fixes the bug. >> >=20 > 100% agree. The counter to Xu Xiaohu's point is what happens when > vendor X sends a buggy sync update to vendor Y, and now vendor Y > crashes.... ok. We traded one unlikely (but real) bad situation for > another unlikely but bad situation. >=20 >=20 >> The operational complexity of running two NATs, from two different vendo= rs, is >> very high: different CLIs, different alarming/alerting (e.g., SYSLOG, S= NMP, >> per-session NAT logging), different features (e.g., IPsec Passthru, SCTP= ), >> different implementation of features (e.g., TCP MSS adjustment, fragment= ation >> [timeouts? how much memory dedicated to reassembly? out-of-order packe= ts >> supported?]), bandwidth and throughput (Mbps, pps), make it too hard to >> operate both NATs. >=20 > 100% agree. >=20 >> To my knowledge, sites do not run two different implementations of DNS s= ervers >> (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs = back >> up each other. Like NAT, DNS needs to be rock-solid reliable, and a sin= gle >> packet could take out a DNS server. >> >> -d >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From marcelo@it.uc3m.es Wed Dec 2 01:45:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4B028C185 for ; Wed, 2 Dec 2009 01:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xofx2s4o83f9 for ; Wed, 2 Dec 2009 01:45:01 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C097528C17B for ; Wed, 2 Dec 2009 01:45:01 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 395DB7F3F3D for ; Wed, 2 Dec 2009 10:44:51 +0100 (CET) Message-ID: <4B163713.8070001@it.uc3m.es> Date: Wed, 02 Dec 2009 10:44:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Subject: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:45:02 -0000 So, based on the comments from Dan, Iljitshc and Reinaldo, I have rewritten the text as follows: If the incoming IP packet contains a fragment, then more processing may be needed. This specification leaves open the exact details of how a NAT64 handles incoming IP packets containing fragments, and simply requires that the external behavior of the NAT64 is compliant with the following conditions: The NAT64 MUST handle fragments arriving out-of-order conditioned to the following: The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to prevent from DoS attack. The NAT64 MUST allow the fragments to arrive over a time interval. The time interval MUST be configurable and the default value MUST be of at least 10 seconds. The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the first fragment. A NAT64 MAY elect to queue the fragments as they arrive and translate all fragments at the same time. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the latter case, the NAT64 will still need to handle the situation where subsequent fragments arrive before the first. Implementers of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, described in [RFC4963] The basic idea is that the NAT64 must handle fragments as long as the conditions hold. does that makes sense? Or should i change if for a SHOULD and qualify it with the conditions? About the timer, i have required it to be configurable, still not convinced we shoudl propose a lower defualt value with the existent qualifications of the must. From ajs@shinkuro.com Wed Dec 2 06:37:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8273A6864 for ; Wed, 2 Dec 2009 06:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAgp6IDDkISX for ; Wed, 2 Dec 2009 06:37:32 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 62A163A67FC for ; Wed, 2 Dec 2009 06:37:32 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 30C722FE8CDD for ; Wed, 2 Dec 2009 14:37:24 +0000 (UTC) Date: Wed, 2 Dec 2009 09:37:22 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091202143722.GF75004@shinkuro.com> References: <003501ca72f2$e6021a30$d40c6f0a@china.huawei.com> <000801ca72f8$c3fa5820$c3f0200a@cisco.com> <200912020254.nB22sIvO028323@drugs.dv.isc.org> <002301ca7301$9ef3f4b0$c3f0200a@cisco.com> <200912020549.nB25n8Yu058184@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:37:33 -0000 On Tue, Dec 01, 2009 at 10:02:52PM -0800, Cameron Byrne wrote: > > If i understand your statement right, you do pull host from the a > given DNS server upon failure if it is anycast DNS Not in the anycast deployments I've been involved with, but maybe I don't understand your remark properly. Normally, when you anycast DNS, you have one host address in the DNS, but you announce different routes to that host in the routing system. You should be able to observe this with different looking glasses for (for example) the host a0.org.afilias-nst.info. Note that I'm no longer involved with the operation of that network, so I am not entirely sure it still works that way, but I'd be surprised if it changed that much. Maybe this isn't what you were talking about? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From rpenno@juniper.net Wed Dec 2 11:46:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214943A690D for ; Wed, 2 Dec 2009 11:46:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aANjCHsXhgRX for ; Wed, 2 Dec 2009 11:46:03 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 8E7F73A6403 for ; Wed, 2 Dec 2009 11:45:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSxbD7DBurZMDUvZX4nZJODDwD5YjiM2b@postini.com; Wed, 02 Dec 2009 11:45:55 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 11:45:38 -0800 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, 2 Dec 2009 14:45:37 -0500 From: Reinaldo Penno To: Dan Wing , 'Xu Xiaohu' , 'Simon Perreault' Date: Wed, 2 Dec 2009 14:45:33 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYogAACgIiAAJV1tuw== Message-ID: In-Reply-To: <000001ca72f4$1e1a30a0$c3f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:46:04 -0000 I agree with Dan in the operational complexity and said so in a different post pointing issues such as different memory footprints, timers, configuration, etc. I think before we jump in and work on standardizing a protocol we should exercise caution, take a step back and understand the challenges and scope of the work.=20 I suggest the IETF works on a document discussing what kind of information is synched between two NAT boxes/cards of the same vendor today and assumptions around platform (Memory, CPU, throughput), configuration, timer= s (TCP, UDP, fragmentation, etc), keep-alives, and others that go with that. Thanks, Reinaldo On 12/1/09 6:06 PM, "Dan Wing" wrote: > ...=20 >>> * Cluster =3D A set of synchronized NAT64 boxes sharing a >>> single Pref64::/n. >>=20 >> Does that mean a set of NAT64 boxes within a cluster should >> be from a single >> vendor? If so, how to deal with the case that some abnormal >> packets cause >> NAT boxes (using the same OS) within a cluster to crash >> simultaneously due to a bug with that OS? >=20 > The vendor fixes the bug. >=20 > The operational complexity of running two NATs, from two different vendor= s, is > very high: different CLIs, different alarming/alerting (e.g., SYSLOG, SN= MP, > per-session NAT logging), different features (e.g., IPsec Passthru, SCTP)= , > different implementation of features (e.g., TCP MSS adjustment, fragmenta= tion > [timeouts? how much memory dedicated to reassembly? out-of-order packet= s > supported?]), bandwidth and throughput (Mbps, pps), make it too hard to > operate both NATs. >=20 > To my knowledge, sites do not run two different implementations of DNS se= rvers > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs b= ack > up each other. Like NAT, DNS needs to be rock-solid reliable, and a sing= le > packet could take out a DNS server. >=20 > -d >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Wed Dec 2 15:19:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A4B3A692E for ; Wed, 2 Dec 2009 15:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUoiOjtVUciq for ; Wed, 2 Dec 2009 15:19:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B9A823A692B for ; Wed, 2 Dec 2009 15:19:33 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9822E20E63; Wed, 2 Dec 2009 18:19:24 -0500 (EST) Message-ID: <4B16F5FB.8000607@viagenie.ca> Date: Wed, 02 Dec 2009 18:19:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 23:19:34 -0000 On 12/02/2009 02:45 PM, Reinaldo Penno wrote: > I suggest the IETF works on a document discussing what kind of information > is synched between two NAT boxes/cards of the same vendor today and > assumptions around platform (Memory, CPU, throughput), configuration, timers > (TCP, UDP, fragmentation, etc), keep-alives, and others that go with that. How is this relevant to NAT64? What we need to consider is NAT64 state and not care about NAT44. Otherwise it will be a tar pit. And I don't think we need any other separate document. This is a well understood problem. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Wed Dec 2 17:36:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CD63A6872 for ; Wed, 2 Dec 2009 17:36:20 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1s9Sxsisd9H for ; Wed, 2 Dec 2009 17:36:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6A18F3A6358 for ; Wed, 2 Dec 2009 17:36:19 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEalFktAZnwN/2dsb2JhbACKKLVyl2mEMQSBag X-IronPort-AV: E=Sophos;i="4.47,331,1257120000"; d="scan'208";a="71716125" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2009 01:36:10 +0000 Received: from dwingwxp01 ([10.32.240.195]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB31a8nq016595; Thu, 3 Dec 2009 01:36:09 GMT From: "Dan Wing" To: Date: Wed, 2 Dec 2009 17:36:07 -0800 Message-ID: <03d801ca73b8$fdfeee80$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acpzt/rQ69a8xjf4TxOGhT82PwXl9w== Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-ipv6-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 01:36:20 -0000 We are starting a two-week working group last call for "Traversal Using Relays around NAT (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6-07, http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6-07 Please send comments to the list or the authors. WGLC for this document will end on Wednesday, December 16. -d From rpenno@juniper.net Wed Dec 2 19:15:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C08A3A69B0 for ; Wed, 2 Dec 2009 19:15:21 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdXO2lYoSrnx for ; Wed, 2 Dec 2009 19:15:20 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 8A0BB3A6885 for ; Wed, 2 Dec 2009 19:15:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSxctNyWc88vlo1/tYIRXaKLP30ICVelk@postini.com; Wed, 02 Dec 2009 19:15:12 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 19:14:55 -0800 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, 2 Dec 2009 22:14:54 -0500 From: Reinaldo Penno To: Simon Perreault Date: Wed, 2 Dec 2009 22:14:51 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: AcpzpeTEDReKJVoRTGaNq5SDHKAgFAAIOIRe Message-ID: In-Reply-To: <4B16F5FB.8000607@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 03:15:21 -0000 On 12/2/09 3:19 PM, "Simon Perreault" wrote: > On 12/02/2009 02:45 PM, Reinaldo Penno wrote: >> I suggest the IETF works on a document discussing what kind of informati= on >> is synched between two NAT boxes/cards of the same vendor today and >> assumptions around platform (Memory, CPU, throughput), configuration, ti= mers >> (TCP, UDP, fragmentation, etc), keep-alives, and others that go with tha= t. >=20 > How is this relevant to NAT64? Maybe we are not talking about the same thing so let's work through an throughput example and if we decide we are talking about the same thing we can discuss the other issues I pointed out in the light of NAT64. Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is processing packets for 3 NAT sessions and as master have synched these 3 NA= T sessions to NAT-B. If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B will be able to handle these sessions in terms of packets per second? Thanks, Reinaldo >=20 > What we need to consider is NAT64 state and not care about NAT44. > Otherwise it will be a tar pit. >=20 > And I don't think we need any other separate document. This is a well > understood problem. >=20 > Simon From simon.perreault@viagenie.ca Thu Dec 3 04:15:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B103A6826 for ; Thu, 3 Dec 2009 04:15:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vqhb9XROf34 for ; Thu, 3 Dec 2009 04:15:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9F8C43A67F0 for ; Thu, 3 Dec 2009 04:15:44 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 333D321BCA; Thu, 3 Dec 2009 07:15:36 -0500 (EST) Message-ID: <4B17ABE7.9020108@viagenie.ca> Date: Thu, 03 Dec 2009 07:15:35 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 12:15:46 -0000 On 12/02/2009 10:14 PM, Reinaldo Penno wrote: > Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is > processing packets for 3 NAT sessions and as master have synched these 3 NAT > sessions to NAT-B. > > If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B will > be able to handle these sessions in terms of packets per second? Assuming s/NAT/NAT64/g... This is an operational issue. You just ensure that this will work when you buy and deploy A and B. Check spec sheets, chat with vendors, perform tests, etc. What's your point? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From caozhenpku@gmail.com Thu Dec 3 05:58:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9709C3A68F2 for ; Thu, 3 Dec 2009 05:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXdQ7q1yaAxb for ; Thu, 3 Dec 2009 05:58:55 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 71F703A6862 for ; Thu, 3 Dec 2009 05:58:55 -0800 (PST) Received: by pwi5 with SMTP id 5so369761pwi.29 for ; Thu, 03 Dec 2009 05:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yXMmIe9r5aVIufS0t5Q44lB/IxMEPgRG5l/Vkutl1C0=; b=s9eWJ+3tpHsLxpI1KMHbtzTBZnpOR7R87iAeFhZQJCFr+TUu5z7BWXuuhr13yAKZZw DQyi5PfmEJGULOPH03tbO0QRKg0UpxhY48fMtpftLTwaSRmOoxcC6Ykd8MTNH0Qvxym8 pDtAoxs0KEpQXDAjVPEGTWG7FHiSvlUK2XY5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mw4Rvvc/8SzKS478bfPGpmbCy4Knma/CVr+8xbWLZnoOzrlA28i1ONfKivnwmpLU7N Oi60gQesxwrVLjS0OAa0N7PP6+DBFpUDxrf6Py8zkYCQm901sTjsk7GdWdEmGhgcyxer GM83On/UFNTIqQzT7i2o0nYCoifMlymojILeg= MIME-Version: 1.0 Received: by 10.143.137.2 with SMTP id p2mr191678wfn.136.1259848724797; Thu, 03 Dec 2009 05:58:44 -0800 (PST) In-Reply-To: <4B163713.8070001@it.uc3m.es> References: <4B163713.8070001@it.uc3m.es> Date: Thu, 3 Dec 2009 21:58:44 +0800 Message-ID: From: Zhen Cao To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 13:58:56 -0000 On Wed, Dec 2, 2009 at 5:44 PM, marcelo bagnulo braun wrote: > So, based on the comments from Dan, Iljitshc and Reinaldo, I have rewritt= en > the text as follows: > > =A0If the incoming IP packet contains a fragment, then more processing > =A0may be needed. =A0This specification leaves open the exact details of > =A0how a NAT64 handles incoming IP packets containing fragments, and > =A0simply requires that the external behavior of the NAT64 is compliant > =A0with the following conditions: > > =A0 =A0 The NAT64 MUST handle fragments arriving out-of-order conditioned > =A0 =A0 to the following: > > =A0 =A0 =A0 =A0The NAT64 MUST limit the amount of resources devoted to th= e > =A0 =A0 =A0 =A0storage of fragmented packets in order to prevent from DoS > =A0 =A0 =A0 =A0attack. > > =A0 =A0 =A0 =A0The NAT64 MUST allow the fragments to arrive over a time > =A0 =A0 =A0 =A0interval. =A0The time interval MUST be configurable and th= e > =A0 =A0 =A0 =A0default value MUST be of at least 10 seconds. I would like to know why you defined 10 seconds as the lower bound. I do not think this value is needed in the document. For a flow that has few fragments (e.g. just two fragments), the low bound may delay the processing efficiency. > > =A0 =A0 =A0 =A0The NAT64 MAY require that the UDP, TCP, or ICMP header be > =A0 =A0 =A0 =A0completely contained within the first fragment. > > =A0 =A0 A NAT64 MAY elect to queue the fragments as they arrive and > =A0 =A0 translate all fragments at the same time. =A0Alternatively, a NAT= 64 > =A0 =A0 MAY translate the fragments as they arrive, by storing informatio= n > =A0 =A0 that allows it to compute the 5-tuple for fragments other than th= e > =A0 =A0 first. =A0In the latter case, the NAT64 will still need to handle > =A0 =A0 the situation where subsequent fragments arrive before the first. > > =A0 =A0 Implementers of NAT64 should be aware that there are a number of > =A0 =A0 well-known attacks against IP fragmentation; see [RFC1858] and > =A0 =A0 [RFC3128]. =A0Implementers should also be aware of additional iss= ues > =A0 =A0 with reassembling packets at high rates, described in [RFC4963] > > > > > The basic idea is that the NAT64 must handle fragments as long as the > conditions hold. does that makes sense? Or should i change if for a SHOUL= D > and qualify it with the conditions? > > About the timer, i have required it to be configurable, still not convinc= ed > we shoudl propose a lower defualt value with the existent qualifications = of > the must. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Thu Dec 3 10:31:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5353A681F for ; Thu, 3 Dec 2009 10:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.114 X-Spam-Level: X-Spam-Status: No, score=-7.114 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, FRT_FOLLOW2=0.422, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6ey0mAeUNyz for ; Thu, 3 Dec 2009 10:30:56 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 580783A6807 for ; Thu, 3 Dec 2009 10:30:55 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id D482EB48609; Thu, 3 Dec 2009 19:30:45 +0100 (CET) Message-ID: <4B1803D5.7030003@it.uc3m.es> Date: Thu, 03 Dec 2009 19:30:45 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-stateful-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:31:01 -0000 Hi George, thanks for the thorough review. find my replies below. George Tsirtsis escribió: > Hi all, > > I have been reviewing this draft in considerable detail. I think the > document is on the right track but I also I think it needs a fair > amount of work to make it comprehensible and clear enough to be > implementable. > > Specifically I propose: > - to more clearly identify the type of mapping and filtering > (Endpoint-Independent., Address-Dependent, Address and Port-Dependent) > supported in general and/or described in particular in certain parts > of the document. This will help put context and reason in some of the > processing described. > right, will try to do that > - to utilise the notation (X',x) <--> (T,t) and (X',x),(Y',y) <--> > (T,t),(Z,z) when describing the searching or setting of the BIB and > session table entries. This will help make descriptions much easier to > understand, because some of them at the moment are little > mind-twisters. > > ok > I also provide a number of other comments/clarifications/corrections. > > Due to the extend of the comments and description style changes I > propose for Section 3 and below, I stopped the review at section > 3.2.2. for now, to get some feedback from the WG and the authors. If > the authors and WG think the comments are reasonable and useful, I > will continue the review to the rest of the document, and will work > with the authors as needed. > > Regards > George > ----------- > > > draft-ietf-behave-v6v4-xlate-stateful-03 > > 1. Introduction > > ... > > 1.1. Features of NAT64 > > GT> I think it would be beneficial to state clearly the type of NAT > mapping and filtering that is supported in this document. The document > seems to specifically support ONLY Endpoint-Independent Mappings, > while WRT to filtering types it says it adheres to RFC4787 and > RFC5382. right, it supports both endpoint independent filtering and address dependent filtering for both TCP and UDP. I will state that up front in the feature description > In practice, however, it is not clear to what extend it does > that. see below. > > I am not sure what do you meanby this maybe will become clearer when i continue reading... > The features of NAT64 and DNS64 are: > > o It enables IPv6-only nodes to initiate a client-server connection > with an IPv4-only server, without needing any changes on either > IPv4 or IPv6 nodes. This works for roughly the same class of > applications that work through IPv4-to-IPv4 NATs. > > o It supports peer-to-peer communication between IPv4 and IPv6 > nodes, including the ability for IPv4 nodes to initiate > communication with IPv6 nodes using peer-to-peer techniques (i.e., > using a rendezvous server and ICE). To this end, NAT64 is > compliant with the recommendations for how NATs should handle UDP > [RFC4787], TCP [RFC4787], and ICMP [RFC5508]. > > GT> //TCP [RFC4787]/TCP [RFC5382] > > o NAT64 supports IPv4 initiated communications to a subset of the > IPv6 hosts through statically configured bindings in the NAT64 > device. > > o Compatible with ICE. > > > GT> It would be better to spell things out a bit more clearly: > a) in the *absence* of any state in NAT64 regarding a given IPv6 > node, only said IPv6 node can initiate sessions to IPv4 nodes > b) depending on the filtering used (Endpoint-Independent, > Address-Dependent, Address and Port-Dependent), IPv4-nodes MAY be able > to initiate sessions to a given IPv6 node, if the NAT64 somehow has an > appropriate mapping (i.e.,state) for said IPv6 node, via one of the > following mechanism. > i) the IPv6 node has recently initiated a session to the > same or other external-IPv4 node > ii) The IPv6 node has used ICE which essentially results in (i) > iii) if static configuration (i.e., mapping) exists > regarding said IPv6 node > > o Supports additional features with some changes on nodes. These > features include: > > * Support for DNSSEC > > GT> in some cases only though, no? > > * Some forms of IPsec support > So, i have rephrased the section, used you text and now looks like 1.1. Features of NAT64 The features of NAT64 are: o NAT64 as specified in this document is compliant with the recommendations for how NATs should handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, NAT64 only supports Endpoint-Independent mappings and supports both Endpoint- Independent and Address dependent filtering. Because of the compliance with the aforementioned requirements, NAT64 is compatible with ICE. o In the absence of any state in NAT64 regarding a given IPv6 node, only said IPv6 node can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs. o Depending on the filtering policy used (Endpoint-Independent, or Address-Dependent), IPv4-nodes MAY be able to initiate sessions to a given IPv6 node, if the NAT64 somehow has an appropriate mapping (i.e.,state) for said IPv6 node, via one of the following mechanism. * The IPv6 node has recently initiated a session to the same or other external-IPv4 node. * The IPv6 node has used a NAT-traversal technique (such as ICE) which essentially results in the previous bullet point. * If static configuration (i.e., mapping) exists regarding said IPv6 node > 1.2. Overview > > This section provides a non-normative introduction to the mechanisms > of NAT64. > > NAT64 mechanism is implemented in an NAT64 box which has two > interfaces, an IPv4 interface connected to the the IPv4 network, and > an IPv6 interface connected to the IPv6 network. > > GT> I think this is an overly simplistic view of the world. Right, the goal of this section is to provide an introduction of the behaviour of the nat64, so that people can have an initial approach to the mechanism I have added a clarification in this respect as follows: This section provides a non-normative introduction to the mechanisms of NAT64. This is achieved by describing the NAT64 behavior involving a simple setup, that involves a single NAT64 box, a single DNS64 box and a simple network topology. The goal of this description is to provide the reader with a general view of NAT64. It is not the goal of this section to describe all possible configurations nor to provide a normative specification of the NAT64 behavior. The normative specification of NAT64 is provided in . > If for the > purpose of specification this makes descriptions easier then so be it > but there should at least be a section towards the end of the document > dealing with more complex scenarios where more than two interfaces > exist, IPv4-only, IPv6-only, and dual stack nodes are mixed in a given > site; identification and handling of packets not needing translation > etc, if there is interest in clarifying any of this we can discuss > separately. > Right, several people in the list have previously commented that it would be useful to have some operational guidelines of how to handle more complex scenarios, including multiple nat64 boxes multiple dns64 and so on. My understanding is that we decided that it would be good to do that, but do it in a separated document. > Packets generated > in the IPv6 network for a receiver located in the IPv4 network will > be routed within the IPv6 network towards the NAT64 box. The NAT64 > box will translate them and forward them as IPv4 packets through the > IPv4 network to the IPv4 receiver. > > GT> We should not refer to NAT64 as a "box". Instead it is a function > that may operate on any interface of any router device. As a function, > NAT64 may only consider two IFs but a "box" may have many more IFs > etc. > throughout the document, we use different ways to refer to the NAT64, including NAT64, NAT64 mechanism, NAT64 function, NAT64 box and NAT64 device. It is clearly stated in several places that the NAT64 is a mechanism that is executed in a device. When we use the expression NAT64 device or NAT64 box is basically because we are describing an aspect of the behaviour that is related to a box, for instance, it is clearer (to me at least) to send packet to a box than to send packets to a function. So, while i agree wihth you that is a bit of an abuse of language, i think it is useful to refer to the NAT64 box (as a short for the box that is executing the NAT64 function) If there is any particular case where the usage of the expression is really bothering you, we can discuss the specific case, but i would rather use it in some cases. > The reverse takes place for > packets generated in the IPv4 network for an IPv6 receiver. NAT64, > however, is not symmetric. In order to be able to perform IPv6 - > IPv4 translation NAT64 requires state, binding an IPv6 address and > port (hereafter called an IPv6 transport address) to an IPv4 address > and port (hereafter called an IPv4 transport address). > > Such binding state is created when the first packet flowing from the > > > > Bagnulo, et al. Expires May 25, 2010 [Page 5] > > Internet-Draft NAT64 November 2009 > > > IPv6 network to the IPv4 network is translated. After the binding > state has been created, packets flowing in either direction on that > particular flow are translated. The result is that NAT64 only > supports communications initiated by the IPv6-only node towards an > IPv4-only node. Some additional mechanisms, like ICE, can be used in > combination with NAT64 to provide support for communications > initiated by the IPv4-only node to the IPv6-only node. The > specification of such mechanisms, however, is out of the scope of > this document. > > GT> I think the above is inaccurate in multiple levels. > - static configuration is not mentioned > - assuming filtering allows it, endpoint independent mappings mean > that even w/o ICE, an IPv4 node may be able to contact an IPv6 node > itf the latter has initiated a session to the same or other IPv4 node. > > Right, i have rephrased the paragrpah as follows, to capture that: Such binding state is either statically configured in the NAT64 or it is created when the first packet flowing from the IPv6 network to the IPv4 network is translated. After the binding state has been created, and if the filtering policy permits, packets flowing in either direction on that particular flow are translated. The result is that, in the general case, NAT64 only supports communications initiated by the IPv6-only node towards an IPv4-only node. Some additional mechanisms (like ICE) or static binding configuration, can be used to provide support for communications initiated by the IPv4-only node to the IPv6-only node. > 1.2.1. NAT64 solution elements > > In this section we describe the different elements involved in the > NAT64 approach. > > The main component of the proposed solution is the translator itself. > The translator has essentially two main parts, the address > translation mechanism and the protocol translation mechanism. > > Protocol translation from IPv4 packet header to IPv6 packet header > and vice-versa is performed according to IP/ICMP Translation > Algorithm [I-D.ietf-behave-v6v4-xlate]. > > Address translation maps IPv6 transport addresses to IPv4 transport > addresses and vice-versa. In order to create these mappings the > NAT64 box has two pools of addresses i.e. an IPv6 address pool (to > represent IPv4 addresses in the IPv6 network) and an IPv4 address > pool (to represent IPv6 addresses in the IPv4 network). Since there > is enough IPv6 address space, it is possible to map every IPv4 > address into a different IPv6 address. > > NAT64 creates the required mappings by using as the IPv6 address pool > an IPv6 IPv6 prefix (hereafter called Pref64::/n). This allows each > IPv4 address to be mapped into a different IPv6 address by simply > concatenating the Pref64::/n prefix assigned as the IPv6 address pool > of the NAT64, with the IPv4 address being mapped and a suffix (i.e. > an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX). > The NAT64 prefix Pref64::/n is assigned by the administrator of the > NAT64 box from the global unicast IPv6 address block assigned to the > site. > > The IPv4 address pool is a set of IPv4 addresses, normally a small > prefix assigned by the local administrator. Since IPv4 address space > is a scarce resource, the IPv4 address pool is small and typically > not sufficient to establish permanent one-to-one mappings with IPv6 > addresses. So, mappings using the IPv4 address pool will be created > and released dynamically. Moreover, because of the IPv4 address > scarcity, the usual practice for NAT64 is likely to be the mapping of > > > > Bagnulo, et al. Expires May 25, 2010 [Page 6] > > Internet-Draft NAT64 November 2009 > > > IPv6 transport addresses into IPv4 transport addresses, instead of > IPv6 addresses into IPv4 addresses directly, which enable a higher > utilization of the limited IPv4 address pool. > > Because of the dynamic nature of the IPv6 to IPv4 address mapping and > the static nature of the IPv4 to IPv6 address mapping, it is easy to > understand that it is far simpler to allow communication initiated > from the IPv6 side toward an IPv4 node, which address is permanently > > GT> instead of "permanently" maybe use the term "deterministically" or > maybe "algorithmically"? > ok > mapped into an IPv6 address, than communications initiated from IPv4- > only nodes to an IPv6 node in which case IPv4 address needs to be > associated with it dynamically. For this reason NAT64 supports only > communications initiated from the IPv6 side. > > GT> Delete the last statement, which is NOT true given possible static > configuration as well as some other rather peculiar tricks the > document supports below for p2p apps etc. > done > An IPv6 initiator can know or derive in advance the IPv6 address > representing the IPv4 target and send packets to that address. The > packets are intercepted by the NAT64 device, which associates an IPv4 > transport address of its IPv4 pool to the IPv6 transport address of > the initiator, creating binding state, so that reply packets can be > translated and forwarded back to the initiator. The binding state is > kept while packets are flowing. Once the flow stops, and based on a > timer, the IPv4 transport address is returned to the IPv4 address > pool so that it can be reused for other communications. > > To allow an IPv6 initiator to do the standard DNS lookup to learn the > address of the responder, DNS64 [I-D.ietf-behave-dns64] is used to > synthesize an AAAA RR from the A RR (containing the real IPv4 address > of the responder). DNS64 receives the DNS queries generated by the > IPv6 initiator. If there is no AAAA record available for the target > node (which is the normal case when the target node is an IPv4-only > node), DNS64 performs a query for the A record. If an A record is > discovered, DNS64 creates a synthetic AAAA RR that includes the IPv6 > representations of the IPv4 address created by concatenating the > Pref64::/n of a NAT64 to the responder's IPv4 address and a suffix > (i.e. if the IPv4 node has IPv4 address X, then the synthetic AAAA RR > will contain the IPv6 address formed as Pref64:X:SUFFIX). The > synthetic AAAA RR is passed back to the IPv6 initiator, which will > initiate an IPv6 communication with the IPv6 address associated to > the IPv4 receiver. The packet will be routed to the NAT64 device, > which will create the IPv6 to IPv4 address mapping as described > before. > > 1.2.2. Walkthrough > > In this example, we consider an IPv6 node located in a IPv6-only site > that initiates a communication to a IPv4 node located in the IPv4 > network. > > The notation used is the following: upper case letters are IPv4 > > > > Bagnulo, et al. Expires May 25, 2010 [Page 7] > > Internet-Draft NAT64 November 2009 > > > addresses; upper case letters with a prime(') are IPv6 addresses; > lower case letters are ports; prefixes are indicated by "P::X", which > is a IPv6 address built from an IPv4 address X by adding the prefix > P, mappings are indicated as "(X,x) <--> (Y',y)". > > The scenario for this case is depicted in the following figure: > > > +---------------------------------------+ +---------------+ > |IPv6 network +-------------+ | | | > | +----+ | Name server | +-------+ | IPv4 | > | | H1 | | with DNS64 | | NAT64 |----| Network | > | +----+ +-------------+ +-------+ | | > | |IP addr: Y' | | | | IP addr: X | > | --------------------------------- | | +----+ | > +---------------------------------------+ | | H2 | | > | +----+ | > +---------------+ > > The figure shows a IPv6 node H1 which has an IPv6 address Y' and an > IPv4 node H2 with IPv4 address X. > > A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 > has a /n prefix (called Pref64::/n) that it uses to represent IPv4 > addresses in the IPv6 address space and an IPv4 address T assigned to > its IPv4 interface. the routing is configured in such a way, that the > IPv6 packets addressed to a destination address containing Pref64::/n > are routed to the IPv6 interface of the NAT64 box. > > GT> I think it might be good to indicate that for this site, > Pref64::/n is uniquely used for mapping the IPv4 address space to > IPv6 i.e., no address from Pref64::/n is to be assigned to a native > IPv6 interface. It should also be said that Pref64::/ should only be > given to a single NAT64 in a given site. Anything other than that > requires a lot more explanation. > the reccomendations about how to assign the prefix and what to do with it are contained in http://www.ietf.org/id/draft-ietf-behave-address-format-01.txt I think they are better there, since they address both stateful and stateless considerations > > Also shown is a local name server with DNS64 functionality. The > local name server needs to know the /n prefix assigned to the local > NAT64 (Pref64::/n). For the purpose of this example, we assume it > learns this through manual configuration. > > For this example, assume the typical DNS situation where IPv6 hosts > have only stub resolvers and the local name server does the recursive > lookups. > > The steps by which H1 establishes communication with H2 are: > > 1. H1 performs a DNS query for FQDN(H2) and receives the synthetic > AAAA RR from the local name server that implements the DNS64 > functionality. The AAAA record contains an IPv6 address formed > by the Pref64::/n associated to the NAT64 box and the IPv4 > address of H2 and a suffix. > > 2. H1 sends a packet to H2. The packet is sent from a source > transport address of (Y',y) to a destination transport address of > > > > Bagnulo, et al. Expires May 25, 2010 [Page 8] > > Internet-Draft NAT64 November 2009 > > > (Pref64:X:SUFFIX,x), where y and x are ports set by H1. > > 3. The packet is routed to the IPv6 interface of the NAT64 (since > the IPv6 routing is configured that way). > > 4. The NAT64 receives the packet and performs the following actions: > > * The NAT64 selects an unused port t on its IPv4 address T and > creates the mapping entry (Y',y) <--> (T,t) > > * The NAT64 translates the IPv6 header into an IPv4 header using > IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]. > > * The NAT64 includes (T,t) as source transport address in the > packet and (X,x) as destination transport address in the > packet. Note that X is extracted directly from the > destination IPv6 address of the received IPv6 packet that is > being translated. > > 5. The NAT64 sends the translated packet out its IPv4 interface and > the packet arrives at H2. > > 6. H2 node responds by sending a packet with destination transport > address (T,t) and source transport address (X,x). > > 7. The packet is routed to the NAT64 box, which will look for an > existing mapping containing (T,t). Since the mapping (Y',y) <--> > (T,t) exists, the NAT64 performs the following operations: > > * The NAT64 translates the IPv4 header into an IPv6 header using > IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]. > > * The NAT64 includes (Y',y) as destination transport address in > the packet and (Pref64:X:SUFFIX,x) as source transport address > in the packet. Note that X is extracted directly from the > source IPv4 address of the received IPv4 packet that is being > translated. > > 8. The translated packet is sent out the IPv6 interface to H1. > > The packet exchange between H1 and H2 continues and packets are > translated in the different directions as previously described. > > It is important to note that the translation still works if the IPv6 > initiator H1 learns the IPv6 representation of H2's IPv4 address > (i.e. Pref64:X:SUFFIX) through some scheme other than a DNS look-up. > This is because the DNS64 processing does NOT result in any state > installed in the NAT64 box and because the mapping of the IPv4 > > > > Bagnulo, et al. Expires May 25, 2010 [Page 9] > > Internet-Draft NAT64 November 2009 > > > address into an IPv6 address is the result of concatenating the > prefix defined within the site for this purpose (called Pref64::/n in > this document) to the original IPv4 address and a suffix. > > 1.2.3. Filtering > > A NAT64 box may do filtering, which means that it only allows a > packet in through an interface if the appropriate permission exists. > A NAT64 may do no filtering, or it may filter on its IPv4 interface. > Filtering on the IPv6 interface is not supported, as mappings are > only created by packets traveling in the IPv6 --> IPv4 direction. > > GT> Again this NOT strictly true given the rest of the document. What > is it that you mean here by "filtering on the IPv6 interface"? > I have changed the references to IPv6 interface to incoming IPv6 packets. In addition, i have rewritten the section to account for the comments you make below the reuslt is: A NAT64 box may do filtering, which means that it only allows a packet in through an interface if the appropriate permission exists. A NAT64 may do no filtering, or it may filter incoming IPv4 packets. Filtering of incoming IPv6 packets is not described in this specification. NAT64 filtering is consistent with the recommendations of RFC 4787 , and the ones of RFC 5382 . Because of that, the NAT64 as specified in this document, supports both Endpoint-Independent filtering and Address-Dependent filtering, both for TCP and UDP. If a NAT64 performs Endpoint-Independent filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state for the destination transport address of the incoming IPv4 packet. If a NAT64 performs Address-Dependent filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state involving the destination transport address of the IPv4 incoming packet and the particular source IP address of the incoming IPv4 packet. > If a NAT64 performs address-dependent filtering according to RFC4787 > [RFC4787] on its IPv4 interface, then an incoming packet is dropped > unless a packet has been recently sent out the interface with a > source transport address equal to the destination transport address > of the incoming packet and destination IP address equal to the source > IP address of the incoming packet. > > NAT64 filtering is consistent with the recommendations of RFC 4787 > [RFC4787], and the ones of RFC 5382 [RFC5382] > > > GT> I think this section should be re-written. RFCs4787/5382 provide > very detailed requirements and reasoning for each type of filtering, > most of which is lost in this section. The brief description of only > some cases is misleading and over-simplified. Since it is rather > pointless to repeat the contents of these RFCs, It would be beneficial > to simply list the known filtering behaviours ("Endpoint-Independent > Filtering", "Address-Dependent Filtering", "Address and Port-Dependent > Filtering") and then summarize what the quoted RFCs recommend i.e. use > Endpoint-Independent Filtering whenever possible, use > Address-Dependent Filtering when you have to, and avoid using Address > and Port-Dependent Filtering if at all possible. Then the reader > should be encourage to really read these quoted RFCs to get all the > details, w/o which it is actually very difficult to understand the > rest of this document. > > right, see above > 2. Terminology > > This section provides a definitive reference for all the terms used > in document. > > 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 RFC 2119 [RFC2119]. > > The following terms are used in this document: > > 3-Tuple: The tuple (source IP address, destination IP address, Query > Identifier). A 3-tuple uniquely identifies an ICMP Query session. > When an ICMP Query session flows through a NAT64, each session has > two different 3-tuples: one with IPv4 addresses and one with IPv6 > addresses. > > 5-Tuple: The tuple (source IP address, source port, destination IP > address, destination port, transport protocol). A 5-tuple > uniquely identifies a UDP/TCP session. When a UDP/TCP session > flows through a NAT64, each session has two different 5-tuples: > one with IPv4 addresses and one with IPv6 addresses. > > > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 10] > > Internet-Draft NAT64 November 2009 > > > BIB: Binding Information Base. A table of mappings kept by a NAT64. > Each NAT64 has three BIBs, one for TCP, one for UDP and one for > ICMP Queries. > > DNS64: A logical function that synthesizes AAAA Resource Records > (containing IPv6 addresses) from A Resource Records (containing > IPv4 addresses). > > Endpoint-Independent Mapping: In NAT64, using the same mapping for > all the sessions involving a given IPv6 transport address of an > IPv6 host (irrespectively of the transport address of the IPv4 > host involved in the communication). Endpoint-independent mapping > is important for peer-to-peer communication. See [RFC4787] for > the definition of the different types of mappings in IPv4-to-IPv4 > NATs. > > GT> It would probably be useful to also include the terms "Address- > Dependent" and "Address and Port-Dependent" > mmm, in this spec we don't use other forms of mappings (i.e. address dependent mappings or address and port dependent mappings) It would make sense to add a definition of endpoint independent filtering and address dependent filtering i guess. I don't think it is worth adding the definition of address and and port dependent filtering, as it is not supported. I have added: The NAT64 filters out only incoming IPv4 packets not destined to a transport address for which there is not state in the NAT64, regardless of the source IPv4 transport address. The NAT forwards any packets destined to any transport address for which it has state. In other words, having state for a given transport address is sufficient to allow any packets back to the internal endpoint. The NAT64 filters out incoming IPv4 packets not destined to a transport address for which there is no state (similar to the Endpoint-Independent filtering). Additionally, the NAT64 will filter out incoming IPv4 packets coming from IPv4 address X and destined for a transport address that it has state for if the NAT64 has not sent packets to X previously (independently of the port used by X). In other words, for receiving packets from a specific IPv4 endpoint, it is necessary for the IPv6 endpoint to send packets first to that specific IPv4 endpoint's IP address. > Hairpinning: Having a packet do a "U-turn" inside a NAT and come > back out the same interface as it arrived on. Hairpinning support > is important for peer-to-peer applications, as there are cases > when two different hosts on the same side of a NAT can only > communicate using sessions that hairpin through the NAT. > > Mapping: A mapping between an IPv6 transport address and a IPv4 > transport address. Used to translate the addresses and ports of > packets flowing between the IPv6 host and the IPv4 host. In > NAT64, the IPv4 transport address is always a transport address > assigned to the NAT64 itself, while the IPv6 transport address > belongs to some IPv6 host. > > GT> What about the term "Filtering"? > Filtering as the general concept is defined in the previous section I have added the definition the both flavours of filtering that we use > NAT64: A device that translates IPv6 packets to IPv4 packets and > vice-versa, with the provision that the communication must be > initiated from the IPv6 side. The translation involves not only > the IP header, but also the transport header (TCP or UDP). > > Session: A TCP, UDP or ICMP Query session. In other words, the bi- > directional flow of packets between two ports on two different > hosts. In NAT64, typically one host is an IPv4 host, and the > other one is an IPv6 host. > > Session table: A table of sessions kept by a NAT64. Each NAT64 has > three session tables, one for TCP, one for UDP and one for ICMP > Queries. > > Synthetic RR: A DNS Resource Record (RR) that is not contained in > any zone data file, but has been synthesized from other RRs. An > example is a synthetic AAAA record created from an A record. > > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 11] > > Internet-Draft NAT64 November 2009 > > > Transport Address: The combination of an IPv6 or IPv4 address and a > port. Typically written as (IP address, port); e.g. (192.0.2.15, > 8001). > > Tuple: Refers to either a 3-Tuple or a 5-tuple as defined above. > > For a detailed understanding of this document, the reader should also > be familiar with DNS terminology [RFC1035] and current NAT > terminology [RFC4787]. > > > 3. NAT64 Normative Specification > > A NAT64 is a device with at least one IPv6 interface and at least one > IPv4 interface. Each NAT64 device MUST have one unicast /n IPv6 > prefix assigned to it, denoted Pref64::/n. Additional consideration > about the Pref64::/n are presented in Section 3.2.5. Each NAT64 box > MUST have one or more unicast IPv4 addresses assigned to it. > > A NAT64 uses the following dynamic data structures: > > o UDP Binding Information Base > > o UDP Session Table > > o TCP Binding Information Base > > o TCP Session Table > > o ICMP Query Binding Information Base > > o ICMP Query Session Table > > A NAT64 has three Binding Information Bases (BIBs): one for TCP, one > for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, > each BIB entry specifies a mapping between an IPv6 transport address > and an IPv4 transport address: > > (X',x) <--> (T,t) > > GT> This notation is very useful, I wish you used it much more in the > descriptions below...see more on that later. > any specific suggestions of were the usage of this notation could be useful? > where X' is some IPv6 address, T is an IPv4 address, and x and t are > ports. T will always be one of the IPv4 addresses assigned to the > NAT64. A given IPv6 or IPv4 transport address can appear in at most > one entry in a BIB: for example, (2001:db8::17, 4) can appear in at > most one TCP and at most one UDP BIB entry. > > GT> Maybe it should be noted that this is what implements/ensure > "Endpoint-Independent mappings"?. > Right, i have added This implementation of the BIBs ensures Endpoint-Independent mappings in the NAT64. > TCP and UDP have > separate BIBs because the port number space for TCP and UDP are > distinct. > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 12] > > Internet-Draft NAT64 November 2009 > > > In the case of the ICMP Query BIB, each ICMP Query BIB entry specify > a mapping between an (IPv6 address, Query Identifier) pair and an > (IPv4 address, Query Identifier pair). > > (X',I1) <--> (T,I2) > > where X' is some IPv6 address, T is an IPv4 address, and I1 and I2 > are Query Identifiers. T will always be one of the IPv4 addresses > assigned to the NAT64. A given (IPv6 or IPv4 address, Query Id) pair > can appear in at most one entry in the ICMP Query BIB. > > Entries in any of the three BIBs can be created dynamically as the > result of the flow of packets as described in the section Section 3.2 > but the can also can be created manually by the system administrator. > > GT> //can also can/can also > > ok > NAT64 implementations SHOULD support manually configured BIB entries > for any of the three BIBs. Dynamically-created entries are deleted > from the corresponding BIB when the last session associated to the > BIB entry is removed from the session table. > > GT> MUST/SHOULD/MAY??? sounds like a SHOULD to me. or is a MUST if > associated with a max-wait time. > > mmm, i think this is how the mechanism work, didn't wanted to abuse on the usage of the normative language, i think it should be either a SHOULD or a MUST, but i am not convinced we need to use normative language for this > Manually-configured BIB > entries are not deleted when there is no corresponding session table > entry and can only be deleted by the administrator. > > > GT> All of the text above regarding BIBs, says what BIBs are but it > does not say what BIBs are for. e.g., well, BIBs contain the mapping information, and that is mentioned earlier. In any case, i have added text stating that endpoint indpeepndet filtering is implemented using the bibs. The resulting text is: A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB entry specifies a mapping between an IPv6 transport address and an IPv4 transport address: (X',x) <--> (T,t) where X' is some IPv6 address, T is an IPv4 address, and x and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. A given IPv6 or IPv4 transport address can appear in at most one entry in a BIB: for example, (2001:db8::17, 4) can appear in at most one TCP and at most one UDP BIB entry. TCP and UDP have separate BIBs because the port number space for TCP and UDP are distinct. This implementation of the BIBs ensures Endpoint-Independent mappings in the NAT64. The information in the BIBs is also used to implement Endpoint-Independent filtering. (Address-Dependent filtering is implemented using the Session tables described below.) > BIBs implement > "Endpoint-Independent filtering"....other types of filtering can be > implemented with session entries. All session table entries MUST have > corresponding BIB entries. right? > > A NAT64 also has three session tables: one for TCP sessions, one for > UDP sessions and one for ICMP Query sessions. Each entry keeps > information on the state of the corresponding session. In the TCP > and UDP session tables, each entry specifies a mapping between a pair > of IPv6 transport address and a pair of IPv4 transport address: > > (X',x),(Y',y) <--> (T,t),(Z,z) > > where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and > x, y, z and t are ports. T will always be one of the IPv4 addresses > assigned to the NAT64. Y' is always the IPv6 representation of the > IPv4 address Z, so Y' is obtained from Z using the algorithm applied > by the NAT64 to create IPv6 representations of IPv4 addresses. y is > always equal to z. In addition, each session table entry has a > lifetime. > > GT> Instead of "is" this and "will always be" that, consider using > normative MUSTs. > ok > > In the ICMP query session table, each entry specifies a mapping > between a 3-tuple of IPv6 source address, IPv6 destination address > and ICMPv6 Query Id and a 3-tuple of IPv4 source address, IPv4 > destination address and ICMPv4 Query Id: > > (X',Y',I1) <--> (T,Z,I2) > > where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and > I1 and I2 are ICMP query Ids. T will always be one of the IPv4 > addresses assigned to the NAT64. Y' is always the IPv6 > representation of the IPv4 address Z, so Y' is obtained from Z using > > > > Bagnulo, et al. Expires May 25, 2010 [Page 13] > > Internet-Draft NAT64 November 2009 > > > the algorithm applied by the NAT64 to create IPv6 representations of > IPv4 addresses. In addition, each session table entry has a > lifetime. > > The NAT64 uses the session state information to determine when the > session is completed, and also uses session information for ingress > filtering. > > GT> what kind? Address-Dependent? Address and Port-Dependent > Filtering? both? other? > Address dependent filtering, i ahve removed the ingress filtering cause is indeed misleading and stated that this is for address dependent filtering. > A session can be uniquely identified by either an > incoming tuple or an outgoing tuple. > > GT> what is "ingress" in this context? > > I have removed the ingress from above > For each session, there is a corresponding BIB entry, uniquely > specified by either the source IPv6 transport address or the source > IPv6 address and ICMPv6 Query Id (in the IPv6 --> IPv4 direction) or > the destination IPv4 transport address or the destination IPv4 > address and the ICMPv4 Query Id (in the IPv4 --> IPv6 direction). > > GT> It is not clear why the above is ICMP specific and why the BIB > entry can be identified in so many different ways. I am a bit > confused. > right, the thing is that UDP and TCP sessions are identified in one way, while ICMP queries sessions are identified in another way. I have rewritten the paragraph as follows: For each TCP or UDP session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 transport address (in the IPv6 --> IPv4 direction) or the destination IPv4 transport address (in the IPv4 --> IPv6 direction). For each ICMP Query session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 address and ICMPv6 Query Id (in the IPv6 --> IPv4 direction) or the destination IPv4 address and the ICMPv4 Query Id (in the IPv4 --> IPv6 direction). However, for all the BIBs, a single BIB entry can have multiple corresponding sessions. When the last corresponding session is deleted, if the BIB entry was dynamically created, the BIB entry is deleted. > However, a single BIB entry can have multiple corresponding sessions. > When the last corresponding session is deleted, if the BIB entry was > dynamically created, the BIB entry is deleted. > > GT> this was said also earlier...see if one instance can be removed. > > mmm, i would preffer keep this both in the bib description and the session table description If someone else complains, i will remove it > The processing of an incoming IP packet takes the following steps: > > 1. Determining the incoming tuple > > 2. Filtering and updating binding and session information > > 3. Computing the outgoing tuple > > 4. Translating the packet > > 5. Handling hairpinning > > The details of these steps are specified in the following > subsections. > > This breakdown of the NAT64 behavior into processing steps is done > for ease of presentation. A NAT64 MAY perform the steps in a > different order, or MAY perform different steps, as long as the > externally visible outcome is the same. > > 3.1. Determining the Incoming tuple > > GT> It would be helpful to make clear what "incoming IP packet" the > text refers to. Since no IP version is indicated, I assume that this > section is common to all IPv4, IPv6, and ICMP packets received by the > NAT64 function. > > I have added this text: The NAT64 will receive packet through its interfaces. These packets can be either IPv6 packets or IPv4 packets and they may carry TCP traffic, UDP traffic or ICMP. The processing of the packets will be described next. In the case that the processing is common to all the aforementioned types of packets, we will refer to the packet as the incoming packet in general. In case that the processing is specific to IPv6 packets, we will refer to the incoming IPv6 packet and similarly to the IPv4 packets. > This step associates a incoming tuple with every incoming IP packet > for use in subsequent steps. In the case of TCP, UDP and ICMP error > packets, the tuple is a 5-tuple consisting of source IP address, > source port, destination IP address, destination port, transport > protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting > of the source IP address, destination IP address and Query > Identifier. > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 14] > > Internet-Draft NAT64 November 2009 > > > If the incoming IP packet contains a complete (un-fragmented) UDP or > TCP protocol packet, then the 5-tuple is computed by extracting the > appropriate fields from the packet. > > If the incoming packet is an ICMP query message (i.e. an ICMPv4 Query > message or an ICMPv6 Informational message), the 3-tuple is the > source IP address. the destination IP address and the ICMP Query > Identifier. > > If the incoming IP packet contains a complete (un-fragmented) ICMP > error message, then the 5-tuple is computed by extracting the > appropriate fields from the IP packet embedded inside the ICMP error > message. However, the role of source and destination is swapped when > doing this: the embedded source IP address becomes the destination IP > address in the 5-tuple, the embedded source port becomes the > destination port in the 5-tuple, etc. If it is not possible to > determine the 5-tuple (perhaps because not enough of the embedded > packet is reproduced inside the ICMP message), then the incoming IP > packet is silently discarded. > > NOTE: The transport protocol is always one of TCP or UDP, even if > the IP packet contains an ICMP Error message. > > GT> I do not understand this note. > > I have removed it > If the incoming IP packet contains a fragment, then more processing > may be needed. This specification leaves open the exact details of > how a NAT64 handles incoming IP packets containing fragments, and > simply requires that a NAT64 handle fragments arriving out-of-order. > A NAT64 MAY elect to queue the fragments as they arrive and translate > all fragments at the same time. Alternatively, a NAT64 MAY translate > the fragments as they arrive, by storing information that allows it > to compute the 5-tuple for fragments other than the first. In the > latter case, the NAT64 will still need to handle the situation where > subsequent fragments arrive before the first. > > GT> Has the option of NAT64 reassembling packets before translating > been discussed at all? > not sure what the question is here, but i have rewritten this section already as result from the discussions in the ml and the new text is: If the incoming IP packet contains a fragment, then more processing may be needed. This specification leaves open the exact details of how a NAT64 handles incoming IP packets containing fragments, and simply requires that the external behavior of the NAT64 is compliant with the following conditions: The NAT64 MUST handle fragments arriving out-of-order conditioned to the following: The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to prevent from DoS attack. The NAT64 MUST allow the fragments to arrive over a time interval. The time interval MUST be configurable and the default value MUST be of at least 10 seconds. The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the first fragment. A NAT64 MAY elect to queue the fragments as they arrive and translate all fragments at the same time. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the latter case, subsequent fragments may arrive before the first. Implementers of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, described in [RFC4963]. > GT> On a different note, this section is supposed to be about > "determining the incoming tuple". I think handling fragments should > only be discussed in as far as it is needed to determine the > tuple....other fragmentation concerns (i.e., most of the rest of the > text) should not be here IMO. > > but the only difficulty in handling fragments is that fragments other than the first one do not contain the port information so we need to do extra work to determine the incoming tuple, so i still think it is a reasonable match to describe it here, since it is most of the work. > Implementors of NAT64 should be aware that there are a number of > well-known attacks against IP fragmentation; see [RFC1858] and > [RFC3128]. > > Assuming it otherwise has sufficient resources, a NAT64 MUST allow > the fragments to arrive over a time interval of at least 10 seconds. > A NAT64 MAY require that the UDP, TCP, or ICMP header be completely > contained within the first fragment. > > Except from the retrieval of 5-tuple information from the incoming > packets as discussed above, all other fragmentation and PMTUD related > processing performed by the NAT64 device is performed as defined in > [I-D.ietf-behave-v6v4-xlate], including the translation of all > related fragmentation fields in the IP header, the determination of > > > > Bagnulo, et al. Expires May 25, 2010 [Page 15] > > Internet-Draft NAT64 November 2009 > > > the outgoing packet size, the fragmentation of outgoing packets and > the generation and processing of ICMP Packet Too Big errors. > > In particular, the NAT64 must generate ICMP Packet Too Big error > messages in the case the outgoing packet does not fit in the outgoing > MTU and needs to be discarded. > > GT> Is this correct? Section 2.1 of [I-D.ietf-behave-v6v4-xlate] > indicates that IPv4 packets can be fragmented further to fit in IPv6 > packets... why don't we just stay silent on the issue and just point > to [I-D.ietf-behave-v6v4-xlate]? > will do that i.e. i will simply remove the last paragraph and leave the previous one with a pointer to the xlate > 3.2. Filtering and Updating Binding and Session Information > > This step updates binding and session information stored in the > appropriate tables. This step may also filter incoming packets, if > desired. > > Irrespectively of the transport protocol used, the NAT64 must > silently discard all incoming IPv6 packets containing a source > address that contains the Pref64::/n. This is required in order to > prevent hairpinning loops as described in the Security Considerations > section. > > The details of this step depend on the protocol (UDP TCP or ICMP > Query). > > 3.2.1. UDP Session Handling > > The state information stored for a UDP session in the UDP session > table includes a timer that tracks the remaining lifetime of the UDP > session. The NAT64 decrements this timer at regular intervals. When > the timer expires, the UDP session is deleted. If all the UDP > sessions corresponding to a UDP BIB entry are deleted, then the UDP > BIB entry is also deleted (only applies to the case of dynamically > created entries). > > GT> I commented on this earlier so align any changes you make earlier with this. > mmm, i think this text is coherent with the previous text including the changes, not sure if you think something needs to be changed here... > An IPv6 incoming packet is processed as follows: > > GT> Presumably such a packet is only processed if the destination > address is from Pref64::/n? It would help to state this. > > right, i have added earlier in the general part common to TCP, UDP and ICMP NAT64 function will only process incoming IPv6 packet that contain a destination address that contains Pref64::/n. > The NAT64 searches for a UDP BIB entry that matches the IPv6 > source transport address. If such entry does not exists, a new > entry is created. As IPv6 address, the source IPv6 transport > address of the packet is included and an IPv4 transport address > allocated using the rules defined in Section 3.2.3 is included as > IPv4 address. > > GT> The last sentence does not read well. It would help to be more > exact in this and subsequent descriptions. For example: the new BIB > entry has the form of (Y*,y)<->(T,t), where Y* is set to the source > IPv6 address of the packet, y is set to the source port number of the > packet, T is one of the NAT64's IPv4 addresses used for translation > and t is set to an unused port number on the selected IPv4 address T. > I have rewritten this. I include all the text below. I have prefered to explicitly define the fields of the BIB and make refgerecne to that. I have used thisnotation for the session table > The NAT64 searches for the session table entry corresponding to > the incoming 5-tuple. > > GT> This search, I assume is only meaningful if there was already a > BIB entry? If the BIB entry was just created based on the last > paragraph, there is no point in searching the session table, right? > right, not sure it worth adding another conditional if here for this, though (i mean, the condition is trivially met) > If no such entry is found, a new entry is > created. The information included in the session table is as > follows: the IPv6 transport source and destination addresses > contained in the received IPv6 packet, the IPv4 transport source > address is extracted from the corresponding UDP BIB entry and the > IPv4 transport destination address contains the same port as the > > > > Bagnulo, et al. Expires May 25, 2010 [Page 16] > > Internet-Draft NAT64 November 2009 > > > IPv6 destination transport address and the IPv4 address that is > algorithmically generated from the IPv6 destination address using > the reverse algorithm as specified in Section 3.2.5. > > GT> Again, reading this makes my head hurt. I think this could be much > clearer if you use the (X',x),(Y',y) <--> (T,t),(Z,z) and say how > these values are set based on the incoming packet. > > done that, or at least i have tried see below > The NAT64 sets or resets the timer in the session table entry to > maximum session lifetime. By default, the maximum session > lifetime is 5 minutes, but for specific destination ports in the > Well-Known port range (0..1023), the NAT64 MAY use a smaller > maximum lifetime. > > GT> It would be nice to indicate why a smaller mac lifetime is suggested here. > > right, i have added, Note: The reason why the lifetime for the sessions involving Well-Known ports can be shorter than the recommended default value is to allow greater reutilization of the pool of transport addresses of the NAT64 for bindings involving the Well-Known ports, since it is less likely that the application using these ports will use the NAT traversal techniques that rely on having a binding alive to enable incoming communications. > The packet is translated and forwarded as > described in the following sections. > > An IPv4 incoming packet is processed as follows: > > The NAT64 searches for a UDP BIB entry that matches the IPv4 > destination transport address. > > GT> More accurately: Given the BIB entries are of the form > (Y*,y)<->(T,t), NAT64 attempts to match the destination IPv4 transport > address to the (T,t) part of the BIB entires. > i ahve rewritten the whole thing, hopefully is clearer noe > If such entry does not exists, the > packet is dropped. An ICMP message MAY be sent to the original > sender of the packet, unless the discarded packet is itself an > ICMP message. The ICMP message, if sent, has a type of 3 > (Destination Unreachable). > > If the NAT64 filters on its IPv4 interface, > > GT> You have to define what this means. if I understand correctly > below you describes "Address and Port-Dependent Filtering" or is it > "Address-Dependent Filtering"? it is hard to tell given that you try > to match "addresses" with "transport addresses" which makes no sense. > > rephrased as: If the NAT64 applies Address-Dependent filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the address-dependent filtering rule. > then the NAT64 checks > to see if the incoming packet is allowed according to the address- > dependent filtering rule. To do this, it searches for a session > table entry with a source IPv4 transport address equal to the > destination IPv4 transport address in the incoming 5-tuple and > destination IPv4 address (in the session table entry) equal to the > source IPv4 address in the incoming 5-tuple. > > GT> This is really hard to parse. If you use the (X',x),(Y',y) <--> > (T,t),(Z,z) notation it all becomes much clearer. For example, here > the NAT64 could implement "Address and Port-Dependent Filtering" by > trying to match the destination IPv4 transport address in the packet > with the (T,t) part, and the source IPv4 transport address of the > packet with the (Z,z) part, of the entries in the session table. Is > this what you mean? If instead you do "Address-Dependent Filtering" > you simply drop the t and z from the above. > I have rewritttne this using this notation > If such an entry is > found (there may be more than one), packet processing continues. > > GT> I do not get how there can be more than one of these. > > Otherwise, the packet is discarded. If the packet is discarded, > then an ICMP message MAY be sent to the original sender of the > packet, unless the discarded packet is itself an ICMP message. > The ICMP message, if sent, has a type of 3 (Destination > Unreachable) and a code of 13 (Communication Administratively > Prohibited). > > GT> Now it gets really confusing. What follows is clearly not a > continuation from the above. It looks like its a case where a session > is allowed to be initiated from the IPv4 side; if that is the case > then it should be clearly stated! Also does the following describe > processing when NAT64 does NOT filter at all on IPv4? or when it does > "Endpoint-Independent Filtering"? or " Address-Dependent Filtering"? > It seems that the description below only assumes a matching BIB entry > so my guess is that the following is based on "Endpoint-Independent > Filtering" > In order to link it with the previous paragraph, i have added In case the packet is not discarded in the previous processing, then the NAT64 searches for the session table entry > The NAT64 searches for the session table entry corresponding to > the incoming 5-tuple. > > GT> Again you should use the (X',x),(Y',y) <--> (T,t),(Z,z) notation > to make clear what "searching" means above, as well as to define how > the new entry is "created" below. > > right, see below > If no such entry is found, a new entry is > created. The UDP session table entry contains the transport > source and destination address contained in the IPv4 packet and > the source IPv6 transport address (in the IPv6 --> IPv4 direction) > contained in the existing UDP BIB entry. The destination IPv6 > transport address contains the same port than the destination IPv4 > transport address and the IPv6 representation of the IPv4 address > of the destination IPv4 transport address, generated using the > algorithm described in Section 3.2.5. > > The NAT64 sets or resets the timer in the session table entry to > maximum session lifetime. By default, the maximum session > > > > Bagnulo, et al. Expires May 25, 2010 [Page 17] > > Internet-Draft NAT64 November 2009 > > > lifetime is 5 minutes, but for specific destination ports in the > Well-Known port range (0..1023), the NAT64 MAY use a smaller > maximum lifetime. > > > GT> OK...I am stopping here...lets see if any of the above makes sense > to people and then I will continue. > I have rewritten the UDP processing section as follwows: In the BIB description i have written: A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB entry specifies a mapping between an IPv6 transport address and an IPv4 transport address: (X',x) <--> (T,t) where X' is some IPv6 address, T is an IPv4 address, and x and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. The BIB has then two columns, the BIB IPv6 transport address and the BIB IPv4 transport address. In the Session table description is have written: For each Session Table Entry (STE), there are then five columns: The STE source IPv6 transport address, (X',x) in the example above, The STE destination IPv6 transport address, (Y',y) in the example above, The STE source IPv4 transport address, (T,t) in the example above, and, The STE destination IPv4 transport address, (Z,z) in the example above. The STE lifetime. And then, the UDP processing is: (i need to review the text to make sure that i didn't confuse any source with destination...) 3.2.1. UDP Session Handling The state information stored for a UDP session in the UDP session table includes a timer that tracks the remaining lifetime of the UDP session. The NAT64 decrements this timer at regular intervals. When the timer expires, the UDP session is deleted. If all the UDP sessions corresponding to a UDP BIB entry are deleted, then the UDP BIB entry is also deleted (only applies to the case of dynamically created entries). An IPv6 incoming packet with source transport address (X',x) and destination transport address (Y',y) is processed as follows: The NAT64 searches for a UDP BIB entry that contains an BIB IPv6 transport address that matches the IPv6 source transport address (X',x). If such entry does not exists, a new entry is created. As BIB IPv6 transport address, the source IPv6 transport address of the packet (X',x) is included and the BIB IPv4 transport address is set to (T,t) which is allocated using the rules defined in Section 3.2.3. The result is a BIB entry as follows: (X',x) <--> (T,t). The NAT64 searches for the session table entry corresponding to the incoming 5-tuple. If no such entry is found, a new entry is created. The information included in the session table is as follows: The STE source IPv6 transport address is set to (X',x) the source IPv6 transport addresses contained in the received IPv6 packet, The STE destination IPv6 transport address is set to (Y',y) the destination IPv6 transport addresses contained in the received IPv6 packet, The STE source IPv4 transport address is extracted from the corresponding UDP BIB entry i.e. is set to (T,t), The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e. Y') using the reverse algorithm as specified in Section 3.2.5 . The result is a Session table entry as follows: (X',x),(Y',y) <--> (T,t),(Z(Y'),y) The NAT64 sets or resets the timer in the session table entry to maximum session lifetime. By default, the maximum session lifetime is 5 minutes, but for specific destination ports in the Well-Known port range (0..1023), the NAT64 MAY use a smaller maximum lifetime. Note: The reason why the lifetime for the sessions involving Well-Known ports can be shorter than the recommended default value is to allow greater reutilization of the pool of transport addresses of the NAT64 for bindings involving the Well-Known ports, since it is less likely that the application using these ports will use the NAT traversal techniques that rely on having a binding alive to enable incoming communications. The packet is translated and forwarded as described in the following sections. An IPv4 incoming packet, with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x) is processed as follows: The NAT64 searches for a UDP BIB entry that contains an BIB IPv4 transport address matches (Y,y) i.e. the IPv4 destination transport address in the incoming IPv4 packet. If such entry does not exists, the packet is dropped. An ICMP message MAY be sent to the original sender of the packet, unless the discarded packet is itself an ICMP message. The ICMP message, if sent, has a type of 3 (Destination Unreachable). If the NAT64 applies Address-Dependent filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the address-dependent filtering rule. To do this, it searches for a session table entry with a STE source IPv4 transport address equal to (X,x) (i.e. the destination IPv4 transport address in the incoming packet) and STE destination IPv4 address equal to Y (i.e. the source IPv4 address in the incoming packet). If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP message MAY be sent to the original sender of the packet, unless the discarded packet is itself an ICMP message. The ICMP message, if sent, has a type of 3 (Destination Unreachable) and a code of 13 (Communication Administratively Prohibited). In case the packet is not discarded in the previous processing, then the NAT64 searches for the session table entry corresponding containing the STE source IPv4 transport address equal to (X,x) and the STE destination IPv4 transport address equal to (Y,y). If no such entry is found, a new entry is created. In case a new UDP session table entry is created, it contains the following information: The STE source IPv6 transport address is extracted from the corresponding UDP BIB entry The STE destination IPv6 transport address is set to (Z'(Y),y), y being the same port y than the destination IPv4 transport address and Z'(Y) being the IPv6 representation of Y, generated using the algorithm described in Section 3.2.5 The STE source IPv4 transport address is set to (X,x) the destination IPv4 transport addresses contained in the received IPv4 packet,, The STE destination IPv4 transport is set to (Y,y), the source IPv4 transport addresses contained in the received IPv4 packet. The NAT64 sets or resets the timer in the session table entry to maximum session lifetime. By default, the maximum session lifetime is 5 minutes, but for specific destination ports in the Well-Known port range (0..1023), the NAT64 MAY use a smaller maximum lifetime. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From rpenno@juniper.net Thu Dec 3 13:45:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2203A6A72 for ; Thu, 3 Dec 2009 13:45:37 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVqaYFLJptw7 for ; Thu, 3 Dec 2009 13:45:37 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 345CA3A696C for ; Thu, 3 Dec 2009 13:45:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSxgxdPGuYswJBcdHOwqAPORBvZ9gctQE@postini.com; Thu, 03 Dec 2009 13:45:28 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 3 Dec 2009 13:43:32 -0800 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; Thu, 3 Dec 2009 16:43:32 -0500 From: Reinaldo Penno To: Simon Perreault , Cameron Byrne Date: Thu, 3 Dec 2009 16:43:29 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: Acp0ElNWVlOr+wz4QOmh1Xee0QLqFgAT1NOw Message-ID: In-Reply-To: <4B17ABE7.9020108@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:45:37 -0000 First of all you state that all NAT64 implementations will be the same because the standard is new. Therefore I did the following exercise: I re-read a _single_ section of NAT64 (3.2.4. ICMP Query Session Handling)= . I found that developers have the following choices (and this does not go into implementation details): * Local Security Policy can drop ICMPv6 packets (yes/no) * Local Security Policy can drop ICMPv6 packets configurable per interface/rule/etc (yes/no for each one) * ICMPv6 lifetime can be configurable (yes/no) * ICMPv6 lifetime can be configurable within a certain range (yes/no) * ICMPv6 lifetime can be configurable with a granularity of ms/seconds/etc (yes/no) * ICMPv4 message will be sent back to sender (yes/no/configurable) * ICMPv4 message will be sent back to sender per configuration interface/nat rule/etc (yes/no each one) * ICMPv4 message will be sent back to sender in case of filtering (yes/no/configurable) * ICMPv4 message will be sent back to sender per configuration (interface/rule/etc) * ICMPv4 lifetime can be configurable (yes/no) * ICMPv4 lifetime can be configurable within a certain range (yes/no) * ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc (yes/no) =20 And do not even get me started in generic address-filtering behavior which is much more complex and have more implementation choices. And this the way things are because different providers have different networks and provider service to customer with different needs. Second, you indicate that operational complexity is something on the side. Providers are interested in Service Continuity as a solution. Operational complexity cannot be dismissed off hand with 'This is an operational issue'= . Several people made this point clear in the list. But, let's take this further: Can you elaborate on which tests need to be done in order to guarantee that this scenario will work between two different vendors? Of course after the provider go through all the tests for this single and only scenario, if NAT64-A or NAT64-B needs to be upgraded, it is not guarantee that things will work again. Software from different vendors evolve differently, are EOLed differently, change behavior differently. Finally, If you pin down all specific behavior you need within all possible permutations of different vendors, weigh the operational cost of a multi-dimensional testing to find two boxes that can provide the High Availability with the NAT behavior you need, I think you will find out that NAT64-A and NAT64-B are made by the same vendor. Thanks, On 12/3/09 4:15 AM, "Simon Perreault" wrote: > On 12/02/2009 10:14 PM, Reinaldo Penno wrote: >> Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is >> processing packets for 3 NAT sessions and as master have synched these 3= NAT >> sessions to NAT-B. >>=20 >> If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B wi= ll >> be able to handle these sessions in terms of packets per second? >=20 > Assuming s/NAT/NAT64/g... >=20 > This is an operational issue. You just ensure that this will work when > you buy and deploy A and B. Check spec sheets, chat with vendors, > perform tests, etc. >=20 > What's your point? >=20 > Simon From simon.perreault@viagenie.ca Thu Dec 3 14:00:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACC13A657C for ; Thu, 3 Dec 2009 14:00:35 -0800 (PST) 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.209, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkd9Th9i2myT for ; Thu, 3 Dec 2009 14:00:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6F0203A6947 for ; Thu, 3 Dec 2009 14:00:34 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id F17D421BAF; Thu, 3 Dec 2009 17:00:24 -0500 (EST) Message-ID: <4B1834F8.3020903@viagenie.ca> Date: Thu, 03 Dec 2009 17:00:24 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:00:35 -0000 Reinaldo Penno wrote, on 2009-12-03 16:43: > First of all you state that all NAT64 implementations will be the same > because the standard is new. This is exaggerated. I think that because NAT64 is *well specified* (compared with NAT44), chances are higher that a standard state sync protocol will work. > I re-read a _single_ section of NAT64 (3.2.4. ICMP Query Session Handling). > I found that developers have the following choices (and this does not go > into implementation details): > > * Local Security Policy can drop ICMPv6 packets (yes/no) > * Local Security Policy can drop ICMPv6 packets configurable per > interface/rule/etc (yes/no for each one)> * ICMPv4 message will be sent back to sender (yes/no/configurable) > * ICMPv4 message will be sent back to sender per configuration > interface/nat rule/etc (yes/no each one) > * ICMPv4 message will be sent back to sender in case of filtering > (yes/no/configurable) > * ICMPv4 message will be sent back to sender per configuration > (interface/rule/etc) These do not affect state. > * ICMPv6 lifetime can be configurable (yes/no) > * ICMPv6 lifetime can be configurable within a certain range (yes/no) > * ICMPv6 lifetime can be configurable with a granularity of ms/seconds/etc > (yes/no) > * ICMPv4 lifetime can be configurable (yes/no) > * ICMPv4 lifetime can be configurable within a certain range (yes/no) > * ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc > (yes/no) These will need to be taken into account by an eventual state sync protocol. For example, we could have a phase at connection establishment where these parameters are explicitly stated and we make sure that the two are configured with the same values. Or we could do dynamic configuration in master/slave fashion. I don't see this as anything more than a requirement for a state sync protocol. > And do not even get me started in generic address-filtering behavior which > is much more complex and have more implementation choices. Please do! This is helpful design work! ;) > And this the way things are because different providers have different > networks and provider service to customer with different needs. I don't see how this is relevant. > Second, you indicate that operational complexity is something on the side. Again, this is exaggerated. Of course you need NAT devices that are spec'ed correctly. I don't see how this affects a state sync protocol. > Can you elaborate on which tests need to be done in order to guarantee that > this scenario will work between two different vendors? So you mean that because vendor A and vendor B will not swear that each other's stuff works fine, we should only use stuff from a single vendor? This statement has nothing to do with NATs and applies in many other cases you know... > Finally, If you pin down all specific behavior you need within all possible > permutations of different vendors, weigh the operational cost of a > multi-dimensional testing to find two boxes that can provide the High > Availability with the NAT behavior you need, I think you will find out that > NAT64-A and NAT64-B are made by the same vendor. That could very well be true. It is also often the case for e.g. BGP speakers. But some people like to run stuff from multiple vendors. And it works, and it has advantages and disadvantages. Tradeoffs, etc. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dthaler@microsoft.com Thu Dec 3 14:03:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92ED3A696C for ; Thu, 3 Dec 2009 14:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5w-y9Xam1PR for ; Thu, 3 Dec 2009 14:03:57 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id BA4BC3A681B for ; Thu, 3 Dec 2009 14:03:57 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Dec 2009 14:03:49 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 3 Dec 2009 14:03:49 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 3 Dec 2009 14:03:34 -0800 From: Dave Thaler To: marcelo bagnulo braun , Behave WG Thread-Topic: [BEHAVE] handling packet with fragments, second try Thread-Index: AQHKczQx0kk98B7SHUOhMFGdHK/yv5FT4Tag Date: Thu, 3 Dec 2009 22:03:34 +0000 Message-ID: References: <4B163713.8070001@it.uc3m.es> In-Reply-To: <4B163713.8070001@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:03:58 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Wednesday, December 02, 2009 1:45 AM > To: Behave WG > Subject: [BEHAVE] handling packet with fragments, second try >=20 > So, based on the comments from Dan, Iljitshc and Reinaldo, I have > rewritten the text as follows: >=20 > If the incoming IP packet contains a fragment, then more processing > may be needed. This specification leaves open the exact details of > how a NAT64 handles incoming IP packets containing fragments, and > simply requires that the external behavior of the NAT64 is compliant > with the following conditions: >=20 > The NAT64 MUST handle fragments arriving out-of-order conditioned > to the following: >=20 > The NAT64 MUST limit the amount of resources devoted to the > storage of fragmented packets in order to prevent from DoS > attack. Grammar:=20 Either s/from/a/ Or s/prevent/protect/ >=20 > The NAT64 MUST allow the fragments to arrive over a time > interval. The time interval MUST be configurable and the > default value MUST be of at least 10 seconds. Not sure how this MUST interacts with the previous paragraph. If you're under attack it may not be feasible to allow fragments to arrive over a 10 second period, since doing so may exhaust all memory. Clarify. >=20 > The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the first fragment. Presumably "first" means the first to arrive, as opposed to first in byte order, yes? Since "first" is used in the other sense in the=20 next paragraph, switching uses is confusing. In addition, why is this sentence present at all? This seems dangerous. >=20 > A NAT64 MAY elect to queue the fragments as they arrive and > translate all fragments at the same time. Alternatively, a NAT64 > MAY translate the fragments as they arrive, by storing > information > that allows it to compute the 5-tuple for fragments other than > the > first. In the latter case, the NAT64 will still need to handle > the situation where subsequent fragments arrive before the first. The last sentence above looks good, although it seems to contradict the MAY I questioned above. -Dave >=20 > Implementers of NAT64 should be aware that there are a number of > well-known attacks against IP fragmentation; see [RFC1858] and > [RFC3128]. Implementers should also be aware of additional > issues > with reassembling packets at high rates, described in [RFC4963] >=20 >=20 >=20 >=20 > The basic idea is that the NAT64 must handle fragments as long as the > conditions hold. does that makes sense? Or should i change if for a > SHOULD and qualify it with the conditions? >=20 > About the timer, i have required it to be configurable, still not > convinced we shoudl propose a lower defualt value with the existent > qualifications of the must. >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Dec 3 17:40:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB063A6893 for ; Thu, 3 Dec 2009 17:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xUI16XWj23B for ; Thu, 3 Dec 2009 17:40:08 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3E96A3A683B for ; Thu, 3 Dec 2009 17:40:08 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAHr3F0urRN+J/2dsb2JhbACKJrQ7l1mEMgSBZw X-IronPort-AV: E=Sophos;i="4.47,338,1257120000"; d="scan'208";a="57489179" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2009 01:40:00 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB41dxRl003771 for ; Fri, 4 Dec 2009 01:39:59 GMT From: "Dan Wing" To: Date: Thu, 3 Dec 2009 17:39:59 -0800 Message-ID: <01cf01ca7482$b10b03a0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp0grCuGufBydUoRFq0K+qPgZz0Gw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [BEHAVE] minutes from IETF76 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:40:09 -0000 Minutes from IETF76 are now posted at: http://www.ietf.org/proceedings/09nov/minutes/behave.txt Please send corrections to behave-chairs@tools.ietf.org -d From lars.eggert@nokia.com Thu Dec 3 18:39:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800463A68AF for ; Thu, 3 Dec 2009 18:39:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrcYt9WJTLvz for ; Thu, 3 Dec 2009 18:39:21 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 4E4993A680B for ; Thu, 3 Dec 2009 18:39:21 -0800 (PST) Received: from [192.168.60.198] (64-129-14-254.static.twtelecom.net [64.129.14.254] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nB42d1X8081498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2009 04:39:04 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-50-266778077; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B163713.8070001@it.uc3m.es> Date: Thu, 3 Dec 2009 16:38:55 -1000 Message-Id: <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> References: <4B163713.8070001@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Fri, 04 Dec 2009 04:39:05 +0200 (EET) Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 02:39:22 -0000 --Apple-Mail-50-266778077 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, a few minor comments: On 2009-12-1, at 23:44, marcelo bagnulo braun wrote: > The NAT64 MUST handle fragments arriving out-of-order conditioned > to the following: >=20 > The NAT64 MUST limit the amount of resources devoted to the > storage of fragmented packets in order to prevent from DoS > attack. I'd add an "under overload conditions" somewhere. While not overloaded, = limiting storage doesn't really serve any purpose but lowers reassembly = chances. > The NAT64 MUST allow the fragments to arrive over a time > interval. The time interval MUST be configurable and the > default value MUST be of at least 10 seconds. Similar to the above comment: a short timeout doesn't really save you = anything unless there's an overload condition. But then you'd use = something else to shed load. I'm wondering if we should simply say "use a good sized fixed buffer = that doesn't drive you into overload when full, and use an oldest-first = (or LFU?) replacement scheme"? > The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the first fragment. The NAT can't really require that. I think what you want to say is that = NATs MAY drop fragment chains where the header is split over multiple = fragments. Lars= --Apple-Mail-50-266778077 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIwNDAyMzg1NlowIwYJKoZIhvcNAQkEMRYEFEBujXa6I77T97YaMmPmnB9EYmZcMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBBxuA3gXuY55Rxun1J36nj1O9mAJhaxLz7uUPDeQEMxWpnkGuXCKyJv34KBYqR8XZouCNw 7dqC0Cy2o9YOre+WJwWRTZPa+OTmVllKcSYY2QX2REsZtQayUI6yS/2EDSNxuj0rwF1g7QzWbxmX vyrUOfdlv5pTtsY+CmvrhCRgpGCBivj6KGcTyfY4I5z84wnlrmE4zmaAigdr1vYzw44S50wskzO/ 3Jf81VIQiIe0bZSsr68972vHlyafp0oo5pw3JJk9/hLlooXqL5TbPsiX3aO8isND7sw1164+lHcb EZWdFZFYTEx5ZeYLWcjxk0qZSqAeGeDO4XLkswsvKDCUAAAAAAAA --Apple-Mail-50-266778077-- From tsirtsis@googlemail.com Fri Dec 4 00:31:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37A83A688C for ; Fri, 4 Dec 2009 00:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_FOLLOW2=0.422, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaRiYV8rdtoB for ; Fri, 4 Dec 2009 00:31:38 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id F2F883A6821 for ; Fri, 4 Dec 2009 00:31:37 -0800 (PST) Received: by fxm10 with SMTP id 10so2460472fxm.14 for ; Fri, 04 Dec 2009 00:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pI1iiIvlR+Svb98EXUxfNeG8cEQ53cTWN5QHv220DV4=; b=L2botofX7VggXxxaduDlt4sDAoJKwvzFAdyCmbmEC7Ypcm/oHHf/bbsMTZ//yiECaq 2ra9+c9zmeUNnsDHv9zyJ98/higODTPIAedZc6Usnnjv/bFYH3vNuzJyVSNNmwRhHyrZ b3iC4T5UjY9QzSq85zLtN0LWf2ETowV1GpchU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ohgBaA+CCRlsz+o5V8vl8zS1SItVqThRCXL1pQj2yeNoGEjDxr3udRnUdwatCcQ/hB TQKEz/zSieuUCjiFviJ0hSInNPAykjbcHbccPynY128eEnqLyeD2ozvYv4Vks9YhxLv8 s9RxL8BGfb4Dlc8nVMTkz4h9+m+P8TONLGVuM= MIME-Version: 1.0 Received: by 10.239.179.94 with SMTP id c30mr272597hbg.159.1259915485824; Fri, 04 Dec 2009 00:31:25 -0800 (PST) In-Reply-To: <4B1803D5.7030003@it.uc3m.es> References: <4B1803D5.7030003@it.uc3m.es> Date: Fri, 4 Dec 2009 08:31:25 +0000 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-stateful-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 08:31:47 -0000 Hi Marcelo, Just for the record, I am satisfied with the way you dealt with most of the comments below. Thanks George On Thu, Dec 3, 2009 at 6:30 PM, marcelo bagnulo braun wrote: > Hi George, > > thanks for the thorough review. > > find my replies below. > > George Tsirtsis escribi=C3=B3: >> >> Hi all, >> >> I have been reviewing this draft in considerable detail. I think the >> document is on the right track but I also I think it needs a fair >> amount of work to make it comprehensible and clear enough to be >> implementable. >> >> Specifically I propose: >> - =C2=A0to more clearly identify the type of mapping and filtering >> (Endpoint-Independent., Address-Dependent, Address and Port-Dependent) >> supported in general and/or described in particular in certain parts >> of the document. This will help put context and reason in some of the >> processing described. >> > > right, will try to do that > >> - to utilise the notation (X',x) <--> (T,t) and =C2=A0(X',x),(Y',y) <--> >> (T,t),(Z,z) when describing the searching or setting of the BIB and >> session table entries. This will help make descriptions much easier to >> understand, because some of them at the moment are little >> mind-twisters. >> >> > > ok > >> I also provide a number of other comments/clarifications/corrections. >> >> Due to the extend of the comments and description style changes I >> propose for Section 3 and below, I stopped the review at section >> 3.2.2. for now, to get some feedback from the WG and the authors. If >> the authors and WG think the comments are reasonable and useful, I >> will continue the review to the rest of the document, and will work >> with the authors as needed. >> >> Regards >> George >> ----------- >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-behave= -v6v4-xlate-stateful-03 >> >> 1. =C2=A0Introduction >> >> ... >> >> 1.1. =C2=A0Features of NAT64 >> >> GT> I think it would be beneficial to state clearly the type of NAT >> mapping and filtering that is supported in this document. The document >> seems to specifically support ONLY Endpoint-Independent Mappings, >> while WRT to filtering types it says it adheres to RFC4787 and >> RFC5382. > > right, it supports both endpoint independent filtering and address depend= ent > filtering for both TCP and UDP. I will state that up front in the feature > description > > >> =C2=A0In practice, however, it is not clear to what extend it does >> that. see below. >> >> > > I am not sure what do you meanby this maybe will become clearer when i > continue reading... > >> =C2=A0 The features of NAT64 and DNS64 are: >> >> =C2=A0 o =C2=A0It enables IPv6-only nodes to initiate a client-server co= nnection >> =C2=A0 =C2=A0 =C2=A0with an IPv4-only server, without needing any change= s on either >> =C2=A0 =C2=A0 =C2=A0IPv4 or IPv6 nodes. =C2=A0This works for roughly the= same class of >> =C2=A0 =C2=A0 =C2=A0applications that work through IPv4-to-IPv4 NATs. >> >> =C2=A0 o =C2=A0It supports peer-to-peer communication between IPv4 and I= Pv6 >> =C2=A0 =C2=A0 =C2=A0nodes, including the ability for IPv4 nodes to initi= ate >> =C2=A0 =C2=A0 =C2=A0communication with IPv6 nodes using peer-to-peer tec= hniques (i.e., >> =C2=A0 =C2=A0 =C2=A0using a rendezvous server and ICE). =C2=A0To this en= d, NAT64 is >> =C2=A0 =C2=A0 =C2=A0compliant with the recommendations for how NATs shou= ld handle UDP >> =C2=A0 =C2=A0 =C2=A0[RFC4787], TCP [RFC4787], and ICMP [RFC5508]. >> >> GT> //TCP [RFC4787]/TCP [RFC5382] >> >> =C2=A0 o =C2=A0NAT64 supports IPv4 initiated communications to a subset = of the >> =C2=A0 =C2=A0 =C2=A0IPv6 hosts through statically configured bindings in= the NAT64 >> =C2=A0 =C2=A0 =C2=A0device. >> >> =C2=A0 o =C2=A0Compatible with ICE. >> >> >> GT> It would be better to spell things out a bit more clearly: >> =C2=A0a) in the *absence* of any state in NAT64 regarding a given IPv6 >> node, only said IPv6 node can initiate sessions to IPv4 nodes >> =C2=A0b) depending on the filtering used (Endpoint-Independent, >> Address-Dependent, Address and Port-Dependent), IPv4-nodes MAY be able >> to initiate sessions to a given IPv6 node, if the NAT64 somehow has an >> appropriate mapping (i.e.,state) for said IPv6 node, via one of the >> following mechanism. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i) the IPv6 node has recently initiate= d a session to the >> same or other external-IPv4 node >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ii) The IPv6 node has used ICE which e= ssentially results in (i) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iii) if static configuration (i.e., ma= pping) exists >> regarding said IPv6 node >> >> =C2=A0 o =C2=A0Supports additional features with some changes on nodes. = =C2=A0These >> =C2=A0 =C2=A0 =C2=A0features include: >> >> =C2=A0 =C2=A0 =C2=A0* =C2=A0Support for DNSSEC >> >> GT> in some cases only though, no? >> >> =C2=A0 =C2=A0 =C2=A0* =C2=A0Some forms of IPsec support >> > > So, i have rephrased the section, used you text and now looks like > > 1.1. =C2=A0Features of NAT64 > > =C2=A0The features of NAT64 are: > > =C2=A0o =C2=A0NAT64 as specified in this document is compliant with the > =C2=A0 =C2=A0 recommendations for how NATs should handle UDP [RFC4787], T= CP > =C2=A0 =C2=A0 [RFC5382], and ICMP [RFC5508]. =C2=A0As such, NAT64 only su= pports > =C2=A0 =C2=A0 Endpoint-Independent mappings and supports both Endpoint- > =C2=A0 =C2=A0 Independent and Address dependent filtering. =C2=A0Because = of the > =C2=A0 =C2=A0 compliance with the aforementioned requirements, NAT64 is > =C2=A0 =C2=A0 compatible with ICE. > > =C2=A0o =C2=A0In the absence of any state in NAT64 regarding a given IPv6= node, > =C2=A0 =C2=A0 only said IPv6 node can initiate sessions to IPv4 nodes. = =C2=A0This > =C2=A0 =C2=A0 works for roughly the same class of applications that work = through > =C2=A0 =C2=A0 IPv4-to-IPv4 NATs. > > =C2=A0o =C2=A0Depending on the filtering policy used (Endpoint-Independen= t, or > =C2=A0 =C2=A0 Address-Dependent), IPv4-nodes MAY be able to initiate sess= ions to > =C2=A0 =C2=A0 a given IPv6 node, if the NAT64 somehow has an appropriate = mapping > =C2=A0 =C2=A0 (i.e.,state) for said IPv6 node, via one of the following > =C2=A0 =C2=A0 mechanism. > > =C2=A0 =C2=A0 * =C2=A0The IPv6 node has recently initiated a session to t= he same or > =C2=A0 =C2=A0 =C2=A0 =C2=A0other external-IPv4 node. > > =C2=A0 =C2=A0 * =C2=A0The IPv6 node has used a NAT-traversal technique (s= uch as ICE) > =C2=A0 =C2=A0 =C2=A0 =C2=A0which essentially results in the previous bull= et point. > > =C2=A0 =C2=A0 * =C2=A0If static configuration (i.e., mapping) exists rega= rding said > =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 node > > > >> 1.2. =C2=A0Overview >> >> =C2=A0 This section provides a non-normative introduction to the mechani= sms >> =C2=A0 of NAT64. >> >> =C2=A0 NAT64 mechanism is implemented in an NAT64 box which has two >> =C2=A0 interfaces, an IPv4 interface connected to the the IPv4 network, = and >> =C2=A0 an IPv6 interface connected to the IPv6 network. >> >> GT> I think this is an overly simplistic view of the world. > > Right, the goal of this section is to provide an introduction of the > behaviour of the nat64, so that people can have an initial approach to th= e > mechanism > I have added a clarification in this respect as follows: > > =C2=A0 This section provides a non-normative introduction to the mecha= nisms > =C2=A0 =C2=A0of NAT64. =C2=A0 =C2=A0This is achieved by describing the NA= T64 behavior involving > a simple > =C2=A0 setup, that involves a single NAT64 box, a single DNS64 box and a = simple > =C2=A0 network topology. The goal of this description is to provide the r= eader > with > =C2=A0 a general view of NAT64. =C2=A0It is not the goal of this > =C2=A0 section to describe all possible configurations nor to provide a n= ormative > =C2=A0 specification of the NAT64 behavior. The normative specification o= f NAT64 > =C2=A0 is provided in . > > >> =C2=A0If for the >> purpose of specification this makes descriptions easier then so be it >> but there should at least be a section towards the end of the document >> dealing with more complex scenarios where more than two interfaces >> exist, IPv4-only, IPv6-only, and dual stack nodes are mixed in a given >> site; identification and handling of packets not needing translation >> etc, if there is interest in clarifying any of this we can discuss >> separately. >> > > Right, several people in the list have previously commented that it would= be > useful to have some operational guidelines of how to handle more complex > scenarios, including multiple nat64 boxes multiple dns64 and so on. My > understanding is that we decided that it would be good to do that, but do= it > in a separated document. > >> =C2=A0 Packets generated >> =C2=A0 in the IPv6 network for a receiver located in the IPv4 network wi= ll >> =C2=A0 be routed within the IPv6 network towards the NAT64 box. =C2=A0Th= e NAT64 >> =C2=A0 box will translate them and forward them as IPv4 packets through = the >> =C2=A0 IPv4 network to the IPv4 receiver. >> >> GT> We should not refer to NAT64 as a "box". Instead it is a function >> that may operate on any interface of any router device. As a function, >> NAT64 may only consider two IFs but a "box" may have many more IFs >> etc. >> > > throughout the document, we use different ways to refer to the NAT64, > including NAT64, NAT64 mechanism, NAT64 function, NAT64 box and NAT64 > device. > It is clearly stated in several places that the NAT64 is a mechanism that= is > executed in a device. > > When we use the expression NAT64 device or NAT64 box is basically because= we > are describing an aspect of the behaviour that is related to a box, for > instance, it is clearer (to me at least) to send packet to a box than to > send packets to a function. > > So, while i agree wihth you that is a bit of an abuse of language, i thin= k > it is useful to refer to the NAT64 box (as a short for the box that is > executing the NAT64 function) > > If there is any particular case where the usage of the expression is real= ly > bothering you, we can discuss the specific case, but i would rather use i= t > in some cases. > > >> The reverse takes place for >> =C2=A0 packets generated in the IPv4 network for an IPv6 receiver. =C2= =A0NAT64, >> =C2=A0 however, is not symmetric. =C2=A0In order to be able to perform I= Pv6 - >> =C2=A0 IPv4 translation NAT64 requires state, binding an IPv6 address an= d >> =C2=A0 port (hereafter called an IPv6 transport address) to an IPv4 addr= ess >> =C2=A0 and port (hereafter called an IPv4 transport address). >> >> =C2=A0 Such binding state is created when the first packet flowing from = the >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 IPv6 network to the IPv4 network is translated. =C2=A0After the b= inding >> =C2=A0 state has been created, packets flowing in either direction on th= at >> =C2=A0 particular flow are translated. =C2=A0The result is that NAT64 on= ly >> =C2=A0 supports communications initiated by the IPv6-only node towards a= n >> =C2=A0 IPv4-only node. =C2=A0Some additional mechanisms, like ICE, can b= e used in >> =C2=A0 combination with NAT64 to provide support for communications >> =C2=A0 initiated by the IPv4-only node to the IPv6-only node. =C2=A0The >> =C2=A0 specification of such mechanisms, however, is out of the scope of >> =C2=A0 this document. >> >> GT> I think the above is inaccurate in multiple levels. >> - static configuration is not mentioned >> - assuming filtering allows it, endpoint independent mappings mean >> that even w/o ICE, an IPv4 node may be able to contact an IPv6 node >> itf the latter has initiated a session to the same or other IPv4 node. >> >> > > Right, i have rephrased the paragrpah as follows, to capture that: > > =C2=A0 =C2=A0Such binding state is either statically configured in the NA= T64 or it is > =C2=A0 =C2=A0created when the first packet flowing from the > =C2=A0 =C2=A0IPv6 network to the IPv4 network is translated. After the bi= nding state > =C2=A0 =C2=A0has been created, and if the filtering policy permits, > =C2=A0 =C2=A0packets flowing in either direction on that particular > =C2=A0 =C2=A0flow are translated. The result is that, in the general case= , NAT64 only > supports > =C2=A0 =C2=A0communications initiated by the IPv6-only node towards an IP= v4-only > =C2=A0 =C2=A0node. Some additional mechanisms (like ICE) or static bindin= g > configuration, can be used > =C2=A0 =C2=A0to provide support for communications initiated by the > =C2=A0 =C2=A0IPv4-only node to the IPv6-only node. > > >> 1.2.1. =C2=A0NAT64 solution elements >> >> =C2=A0 In this section we describe the different elements involved in th= e >> =C2=A0 NAT64 approach. >> >> =C2=A0 The main component of the proposed solution is the translator its= elf. >> =C2=A0 The translator has essentially two main parts, the address >> =C2=A0 translation mechanism and the protocol translation mechanism. >> >> =C2=A0 Protocol translation from IPv4 packet header to IPv6 packet heade= r >> =C2=A0 and vice-versa is performed according to IP/ICMP Translation >> =C2=A0 Algorithm [I-D.ietf-behave-v6v4-xlate]. >> >> =C2=A0 Address translation maps IPv6 transport addresses to IPv4 transpo= rt >> =C2=A0 addresses and vice-versa. =C2=A0In order to create these mappings= the >> =C2=A0 NAT64 box has two pools of addresses i.e. an IPv6 address pool (t= o >> =C2=A0 represent IPv4 addresses in the IPv6 network) and an IPv4 address >> =C2=A0 pool (to represent IPv6 addresses in the IPv4 network). =C2=A0Sin= ce there >> =C2=A0 is enough IPv6 address space, it is possible to map every IPv4 >> =C2=A0 address into a different IPv6 address. >> >> =C2=A0 NAT64 creates the required mappings by using as the IPv6 address = pool >> =C2=A0 an IPv6 IPv6 prefix (hereafter called Pref64::/n). =C2=A0This all= ows each >> =C2=A0 IPv4 address to be mapped into a different IPv6 address by simply >> =C2=A0 concatenating the Pref64::/n prefix assigned as the IPv6 address = pool >> =C2=A0 of the NAT64, with the IPv4 address being mapped and a suffix (i.= e. >> =C2=A0 an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX= ). >> =C2=A0 The NAT64 prefix Pref64::/n is assigned by the administrator of t= he >> =C2=A0 NAT64 box from the global unicast IPv6 address block assigned to = the >> =C2=A0 site. >> >> =C2=A0 The IPv4 address pool is a set of IPv4 addresses, normally a smal= l >> =C2=A0 prefix assigned by the local administrator. =C2=A0Since IPv4 addr= ess space >> =C2=A0 is a scarce resource, the IPv4 address pool is small and typicall= y >> =C2=A0 not sufficient to establish permanent one-to-one mappings with IP= v6 >> =C2=A0 addresses. =C2=A0So, mappings using the IPv4 address pool will be= created >> =C2=A0 and released dynamically. =C2=A0Moreover, because of the IPv4 add= ress >> =C2=A0 scarcity, the usual practice for NAT64 is likely to be the mappin= g of >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 IPv6 transport addresses into IPv4 transport addresses, instead o= f >> =C2=A0 IPv6 addresses into IPv4 addresses directly, which enable a highe= r >> =C2=A0 utilization of the limited IPv4 address pool. >> >> =C2=A0 Because of the dynamic nature of the IPv6 to IPv4 address mapping= and >> =C2=A0 the static nature of the IPv4 to IPv6 address mapping, it is easy= to >> =C2=A0 understand that it is far simpler to allow communication initiate= d >> =C2=A0 from the IPv6 side toward an IPv4 node, which address is permanen= tly >> >> GT> instead of "permanently" maybe use the term "deterministically" or >> maybe =C2=A0"algorithmically"? >> > > ok > >> =C2=A0 mapped into an IPv6 address, than communications initiated from I= Pv4- >> =C2=A0 only nodes to an IPv6 node in which case IPv4 address needs to be >> =C2=A0 associated with it dynamically. =C2=A0For this reason NAT64 suppo= rts only >> =C2=A0 communications initiated from the IPv6 side. >> >> GT> Delete the last statement, which is NOT true given possible static >> configuration as well as some other rather peculiar tricks the >> document supports below for p2p apps etc. >> > > done > >> =C2=A0 An IPv6 initiator can know or derive in advance the IPv6 address >> =C2=A0 representing the IPv4 target and send packets to that address. = =C2=A0The >> =C2=A0 packets are intercepted by the NAT64 device, which associates an = IPv4 >> =C2=A0 transport address of its IPv4 pool to the IPv6 transport address = of >> =C2=A0 the initiator, creating binding state, so that reply packets can = be >> =C2=A0 translated and forwarded back to the initiator. =C2=A0The binding= state is >> =C2=A0 kept while packets are flowing. =C2=A0Once the flow stops, and ba= sed on a >> =C2=A0 timer, the IPv4 transport address is returned to the IPv4 address >> =C2=A0 pool so that it can be reused for other communications. >> >> =C2=A0 To allow an IPv6 initiator to do the standard DNS lookup to learn= the >> =C2=A0 address of the responder, DNS64 [I-D.ietf-behave-dns64] is used t= o >> =C2=A0 synthesize an AAAA RR from the A RR (containing the real IPv4 add= ress >> =C2=A0 of the responder). =C2=A0DNS64 receives the DNS queries generated= by the >> =C2=A0 IPv6 initiator. =C2=A0If there is no AAAA record available for th= e target >> =C2=A0 node (which is the normal case when the target node is an IPv4-on= ly >> =C2=A0 node), DNS64 performs a query for the A record. =C2=A0If an A rec= ord is >> =C2=A0 discovered, DNS64 creates a synthetic AAAA RR that includes the I= Pv6 >> =C2=A0 representations of the IPv4 address created by concatenating the >> =C2=A0 Pref64::/n of a NAT64 to the responder's IPv4 address and a suffi= x >> =C2=A0 (i.e. if the IPv4 node has IPv4 address X, then the synthetic AAA= A RR >> =C2=A0 will contain the IPv6 address formed as Pref64:X:SUFFIX). =C2=A0T= he >> =C2=A0 synthetic AAAA RR is passed back to the IPv6 initiator, which wil= l >> =C2=A0 initiate an IPv6 communication with the IPv6 address associated t= o >> =C2=A0 the IPv4 receiver. =C2=A0The packet will be routed to the NAT64 d= evice, >> =C2=A0 which will create the IPv6 to IPv4 address mapping as described >> =C2=A0 before. >> >> 1.2.2. =C2=A0Walkthrough >> >> =C2=A0 In this example, we consider an IPv6 node located in a IPv6-only = site >> =C2=A0 that initiates a communication to a IPv4 node located in the IPv4 >> =C2=A0 network. >> >> =C2=A0 The notation used is the following: upper case letters are IPv4 >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 addresses; upper case letters with a prime(') are IPv6 addresses; >> =C2=A0 lower case letters are ports; prefixes are indicated by "P::X", w= hich >> =C2=A0 is a IPv6 address built from an IPv4 address X by adding the pref= ix >> =C2=A0 P, mappings are indicated as "(X,x) <--> (Y',y)". >> >> =C2=A0 The scenario for this case is depicted in the following figure: >> >> >> =C2=A0 =C2=A0 +---------------------------------------+ =C2=A0 =C2=A0 = =C2=A0 +---------------+ >> =C2=A0 =C2=A0 |IPv6 network =C2=A0 =C2=A0+-------------+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 | =C2=A0+----+ =C2=A0 =C2=A0 =C2=A0 =C2=A0| Name server | = =C2=A0 +-------+ =C2=A0 =C2=A0| =C2=A0 IPv4 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >> =C2=A0 =C2=A0 | =C2=A0| H1 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| with DNS64 =C2= =A0| =C2=A0 | NAT64 |----| Network =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 | =C2=A0+----+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+ = =C2=A0 +-------+ =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | >> =C2=A0 =C2=A0 | =C2=A0 =C2=A0|IP addr: Y' =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0IP= addr: X =C2=A0 | >> =C2=A0 =C2=A0 | =C2=A0 =C2=A0--------------------------------- =C2=A0| = =C2=A0 =C2=A0 =C2=A0 | =C2=A0+----+ =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 +---------------------------------------+ =C2=A0 =C2=A0 = =C2=A0 | =C2=A0| H2 | =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+----+ =C2=A0 =C2=A0 =C2=A0 = | >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------+ >> >> =C2=A0 The figure shows a IPv6 node H1 which has an IPv6 address Y' and = an >> =C2=A0 IPv4 node H2 with IPv4 address X. >> >> =C2=A0 A NAT64 connects the IPv6 network to the IPv4 network. =C2=A0This= NAT64 >> =C2=A0 has a /n prefix (called Pref64::/n) that it uses to represent IPv= 4 >> =C2=A0 addresses in the IPv6 address space and an IPv4 address T assigne= d to >> =C2=A0 its IPv4 interface. the routing is configured in such a way, that= the >> =C2=A0 IPv6 packets addressed to a destination address containing Pref64= ::/n >> =C2=A0 are routed to the IPv6 interface of the NAT64 box. >> >> GT> I think it might be good to indicate that for this site, >> Pref64::/n is uniquely used for mapping the IPv4 address space =C2=A0to >> IPv6 i.e., no address from Pref64::/n is to be assigned to a native >> IPv6 interface. It should also be said that Pref64::/ should only be >> given to a single NAT64 in a given site. Anything other than that >> requires a lot more explanation. >> > > the reccomendations about how to assign the prefix and what to do with it > are contained in > http://www.ietf.org/id/draft-ietf-behave-address-format-01.txt > > I think they are better there, since they address both stateful and > stateless considerations > >> >> =C2=A0 Also shown is a local name server with DNS64 functionality. =C2= =A0The >> =C2=A0 local name server needs to know the /n prefix assigned to the loc= al >> =C2=A0 NAT64 (Pref64::/n). =C2=A0For the purpose of this example, we ass= ume it >> =C2=A0 learns this through manual configuration. >> >> =C2=A0 For this example, assume the typical DNS situation where IPv6 hos= ts >> =C2=A0 have only stub resolvers and the local name server does the recur= sive >> =C2=A0 lookups. >> >> =C2=A0 The steps by which H1 establishes communication with H2 are: >> >> =C2=A0 1. =C2=A0H1 performs a DNS query for FQDN(H2) and receives the sy= nthetic >> =C2=A0 =C2=A0 =C2=A0 AAAA RR from the local name server that implements = the DNS64 >> =C2=A0 =C2=A0 =C2=A0 functionality. =C2=A0The AAAA record contains an IP= v6 address formed >> =C2=A0 =C2=A0 =C2=A0 by the Pref64::/n associated to the NAT64 box and t= he IPv4 >> =C2=A0 =C2=A0 =C2=A0 address of H2 and a suffix. >> >> =C2=A0 2. =C2=A0H1 sends a packet to H2. =C2=A0The packet is sent from a= source >> =C2=A0 =C2=A0 =C2=A0 transport address of (Y',y) to a destination transp= ort address of >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 =C2=A0 =C2=A0 (Pref64:X:SUFFIX,x), where y and x are ports set by= H1. >> >> =C2=A0 3. =C2=A0The packet is routed to the IPv6 interface of the NAT64 = (since >> =C2=A0 =C2=A0 =C2=A0 the IPv6 routing is configured that way). >> >> =C2=A0 4. =C2=A0The NAT64 receives the packet and performs the following= actions: >> >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 selects an unused port t on its I= Pv4 address T and >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creates the mapping entry (Y',y) <--> = (T,t) >> >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 translates the IPv6 header into a= n IPv4 header using >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP/ICMP Translation Algorithm [I-D.iet= f-behave-v6v4-xlate]. >> >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 includes (T,t) as source transpor= t address in the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet and (X,x) as destination transp= ort address in the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet. =C2=A0Note that X is extracted= directly from the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destination IPv6 address of the receiv= ed IPv6 packet that is >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being translated. >> >> =C2=A0 5. =C2=A0The NAT64 sends the translated packet out its IPv4 inter= face and >> =C2=A0 =C2=A0 =C2=A0 the packet arrives at H2. >> >> =C2=A0 6. =C2=A0H2 node responds by sending a packet with destination tr= ansport >> =C2=A0 =C2=A0 =C2=A0 address (T,t) and source transport address (X,x). >> >> =C2=A0 7. =C2=A0The packet is routed to the NAT64 box, which will look f= or an >> =C2=A0 =C2=A0 =C2=A0 existing mapping containing (T,t). =C2=A0Since the = mapping (Y',y) <--> >> =C2=A0 =C2=A0 =C2=A0 (T,t) exists, the NAT64 performs the following oper= ations: >> >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 translates the IPv4 header into a= n IPv6 header using >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP/ICMP Translation Algorithm [I-D.iet= f-behave-v6v4-xlate]. >> >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 includes (Y',y) as destination tr= ansport address in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the packet and (Pref64:X:SUFFIX,x) as = source transport address >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the packet. =C2=A0Note that X is ex= tracted directly from the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source IPv4 address of the received IP= v4 packet that is being >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0translated. >> >> =C2=A0 8. =C2=A0The translated packet is sent out the IPv6 interface to = H1. >> >> =C2=A0 The packet exchange between H1 and H2 continues and packets are >> =C2=A0 translated in the different directions as previously described. >> >> =C2=A0 It is important to note that the translation still works if the I= Pv6 >> =C2=A0 initiator H1 learns the IPv6 representation of H2's IPv4 address >> =C2=A0 (i.e. =C2=A0Pref64:X:SUFFIX) through some scheme other than a DNS= look-up. >> =C2=A0 This is because the DNS64 processing does NOT result in any state >> =C2=A0 installed in the NAT64 box and because the mapping of the IPv4 >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 address into an IPv6 address is the result of concatenating the >> =C2=A0 prefix defined within the site for this purpose (called Pref64::/= n in >> =C2=A0 this document) to the original IPv4 address and a suffix. >> >> 1.2.3. =C2=A0Filtering >> >> =C2=A0 A NAT64 box may do filtering, which means that it only allows a >> =C2=A0 packet in through an interface if the appropriate permission exis= ts. >> =C2=A0 A NAT64 may do no filtering, or it may filter on its IPv4 interfa= ce. >> =C2=A0 Filtering on the IPv6 interface is not supported, as mappings are >> =C2=A0 only created by packets traveling in the IPv6 --> IPv4 direction. >> >> GT> Again this NOT strictly true given the rest of the document. What >> is it that you mean here by "filtering on the IPv6 interface"? >> > > I have changed the references to IPv6 interface to incoming IPv6 packets. > In addition, i have rewritten the section to account for the comments you > make below > > the reuslt is: > > =C2=A0 =C2=A0 =C2=A0A NAT64 box may do filtering, which means that it = only allows a > =C2=A0 =C2=A0 =C2=A0packet in through an interface if the appropriate per= mission exists. A > =C2=A0 =C2=A0 =C2=A0NAT64 may do no filtering, or it may filter incoming = IPv4 packets. > =C2=A0 =C2=A0 =C2=A0Filtering of incoming IPv6 packets is not described i= n this > specification. > > =C2=A0 =C2=A0 =C2=A0NAT64 filtering is consistent with the recommendat= ions of RFC > =C2=A0 =C2=A0 =C2=A04787 , and the ones o= f > =C2=A0 =C2=A0 =C2=A0 RFC 5382 . Because o= f that, the NAT64 > =C2=A0 =C2=A0 =C2=A0 as specified in this document, supports both Endpoin= t-Independent > filtering > =C2=A0 =C2=A0 =C2=A0 and Address-Dependent filtering, both for TCP and UD= P. > > =C2=A0 =C2=A0 =C2=A0 If a NAT64 performs Endpoint-Independent filterin= g of incoming IPv4 > packets, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then an incoming IPv4 packet is droppe= d unless the NAT64 has state > for the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 destination transport address of the i= ncoming IPv4 packet. > > =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 If a NAT64 performs Address-Dependent filtering of i= ncoming IPv4 > packets, then an incoming IPv4 packet is dropped > =C2=A0 =C2=A0 =C2=A0 unless the NAT64 has state involving the destination= transport address > of the IPv4 incoming packet > =C2=A0 =C2=A0 =C2=A0 and the particular source IP address of the incoming= IPv4 packet. > > >> =C2=A0 If a NAT64 performs address-dependent filtering according to RFC4= 787 >> =C2=A0 [RFC4787] on its IPv4 interface, then an incoming packet is dropp= ed >> =C2=A0 unless a packet has been recently sent out the interface with a >> =C2=A0 source transport address equal to the destination transport addre= ss >> =C2=A0 of the incoming packet and destination IP address equal to the so= urce >> =C2=A0 IP address of the incoming packet. >> >> =C2=A0 NAT64 filtering is consistent with the recommendations of RFC 478= 7 >> =C2=A0 [RFC4787], and the ones of RFC 5382 [RFC5382] >> >> >> GT> I think this section should be re-written. RFCs4787/5382 provide >> very detailed requirements and reasoning for each type of filtering, >> most of which is lost in this section. The brief description of only >> some cases is misleading and over-simplified. Since it is rather >> pointless to repeat the contents of these RFCs, It would be beneficial >> to simply list the known filtering behaviours ("Endpoint-Independent >> Filtering", "Address-Dependent Filtering", "Address and Port-Dependent >> Filtering") and then summarize what the quoted RFCs recommend i.e. use >> Endpoint-Independent Filtering whenever possible, use >> Address-Dependent Filtering when you have to, and avoid using Address >> and Port-Dependent Filtering if at all possible. Then the reader >> should be encourage to really read these quoted RFCs to get all the >> details, w/o which it is actually very difficult to understand the >> rest of this document. >> >> > > right, see above > >> 2. =C2=A0Terminology >> >> =C2=A0 This section provides a definitive reference for all the terms us= ed >> =C2=A0 in document. >> >> =C2=A0 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT= ", >> =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in t= his >> =C2=A0 document are to be interpreted as described in RFC 2119 [RFC2119]= . >> >> =C2=A0 The following terms are used in this document: >> >> =C2=A0 3-Tuple: =C2=A0The tuple (source IP address, destination IP addre= ss, Query >> =C2=A0 =C2=A0 =C2=A0Identifier). =C2=A0A 3-tuple uniquely identifies an = ICMP Query session. >> =C2=A0 =C2=A0 =C2=A0When an ICMP Query session flows through a NAT64, ea= ch session has >> =C2=A0 =C2=A0 =C2=A0two different 3-tuples: one with IPv4 addresses and = one with IPv6 >> =C2=A0 =C2=A0 =C2=A0addresses. >> >> =C2=A0 5-Tuple: =C2=A0The tuple (source IP address, source port, destina= tion IP >> =C2=A0 =C2=A0 =C2=A0address, destination port, transport protocol). =C2= =A0A 5-tuple >> =C2=A0 =C2=A0 =C2=A0uniquely identifies a UDP/TCP session. =C2=A0When a = UDP/TCP session >> =C2=A0 =C2=A0 =C2=A0flows through a NAT64, each session has two differen= t 5-tuples: >> =C2=A0 =C2=A0 =C2=A0one with IPv4 addresses and one with IPv6 addresses. >> >> >> >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 BIB: =C2=A0Binding Information Base. =C2=A0A table of mappings ke= pt by a NAT64. >> =C2=A0 =C2=A0 =C2=A0Each NAT64 has three BIBs, one for TCP, one for UDP = and one for >> =C2=A0 =C2=A0 =C2=A0ICMP Queries. >> >> =C2=A0 DNS64: =C2=A0A logical function that synthesizes AAAA Resource Re= cords >> =C2=A0 =C2=A0 =C2=A0(containing IPv6 addresses) from A Resource Records = (containing >> =C2=A0 =C2=A0 =C2=A0IPv4 addresses). >> >> =C2=A0 Endpoint-Independent Mapping: =C2=A0In NAT64, using the same mapp= ing for >> =C2=A0 =C2=A0 =C2=A0all the sessions involving a given IPv6 transport ad= dress of an >> =C2=A0 =C2=A0 =C2=A0IPv6 host (irrespectively of the transport address o= f the IPv4 >> =C2=A0 =C2=A0 =C2=A0host involved in the communication). =C2=A0Endpoint-= independent mapping >> =C2=A0 =C2=A0 =C2=A0is important for peer-to-peer communication. =C2=A0S= ee [RFC4787] for >> =C2=A0 =C2=A0 =C2=A0the definition of the different types of mappings in= IPv4-to-IPv4 >> =C2=A0 =C2=A0 =C2=A0NATs. >> >> GT> It would probably be useful to also include the terms "Address- >> =C2=A0 =C2=A0 =C2=A0Dependent" and "Address and Port-Dependent" >> > > mmm, in this spec we don't use other forms of mappings (i.e. address > dependent mappings or address and port dependent mappings) > > It would make sense to add a definition of endpoint independent filtering > and address dependent filtering i guess. > I don't think it is worth adding the definition of address and and port > dependent filtering, as it is not supported. > > I have added: > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 filters out incoming IPv4 packets no= t destined to a > transport > =C2=A0 =C2=A0 =C2=A0 =C2=A0address for which there is no state (similar t= o the > Endpoint-Independent > =C2=A0 =C2=A0 =C2=A0 =C2=A0filtering). =C2=A0Additionally, the NAT64 will= filter out incoming > =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 packets coming from IPv4 address X and > =C2=A0 =C2=A0 =C2=A0 =C2=A0destined for a transport address that it has s= tate for if the NAT64 > has not > =C2=A0 =C2=A0 =C2=A0 =C2=A0sent packets to X previously (independently of= the port > =C2=A0 =C2=A0 =C2=A0 =C2=A0used by X). > =C2=A0 =C2=A0 =C2=A0 =C2=A0In other words, for receiving packets from a > =C2=A0 =C2=A0 =C2=A0 =C2=A0specific IPv4 endpoint, it is necessary for th= e IPv6 > =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint to send packets first to that specifi= c IPv4 > =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint's IP address. > >> =C2=A0 Hairpinning: =C2=A0Having a packet do a "U-turn" inside a NAT and= come >> =C2=A0 =C2=A0 =C2=A0back out the same interface as it arrived on. =C2=A0= Hairpinning support >> =C2=A0 =C2=A0 =C2=A0is important for peer-to-peer applications, as there= are cases >> =C2=A0 =C2=A0 =C2=A0when two different hosts on the same side of a NAT c= an only >> =C2=A0 =C2=A0 =C2=A0communicate using sessions that hairpin through the = NAT. >> >> =C2=A0 Mapping: =C2=A0A mapping between an IPv6 transport address and a = IPv4 >> =C2=A0 =C2=A0 =C2=A0transport address. =C2=A0Used to translate the addre= sses and ports of >> =C2=A0 =C2=A0 =C2=A0packets flowing between the IPv6 host and the IPv4 h= ost. =C2=A0In >> =C2=A0 =C2=A0 =C2=A0NAT64, the IPv4 transport address is always a transp= ort address >> =C2=A0 =C2=A0 =C2=A0assigned to the NAT64 itself, while the IPv6 transpo= rt address >> =C2=A0 =C2=A0 =C2=A0belongs to some IPv6 host. >> >> GT> What about the term =C2=A0"Filtering"? >> > > Filtering as the general concept is defined in the previous section > > I have added the definition the both flavours of filtering that we use >> >> =C2=A0 NAT64: =C2=A0A device that translates IPv6 packets to IPv4 packet= s and >> =C2=A0 =C2=A0 =C2=A0vice-versa, with the provision that the communicatio= n must be >> =C2=A0 =C2=A0 =C2=A0initiated from the IPv6 side. =C2=A0The translation = involves not only >> =C2=A0 =C2=A0 =C2=A0the IP header, but also the transport header (TCP or= UDP). >> >> =C2=A0 Session: =C2=A0A TCP, UDP or ICMP Query session. =C2=A0In other w= ords, the bi- >> =C2=A0 =C2=A0 =C2=A0directional flow of packets between two ports on two= different >> =C2=A0 =C2=A0 =C2=A0hosts. =C2=A0In NAT64, typically one host is an IPv4= host, and the >> =C2=A0 =C2=A0 =C2=A0other one is an IPv6 host. >> >> =C2=A0 Session table: =C2=A0A table of sessions kept by a NAT64. =C2=A0E= ach NAT64 has >> =C2=A0 =C2=A0 =C2=A0three session tables, one for TCP, one for UDP and o= ne for ICMP >> =C2=A0 =C2=A0 =C2=A0Queries. >> >> =C2=A0 Synthetic RR: =C2=A0A DNS Resource Record (RR) that is not contai= ned in >> =C2=A0 =C2=A0 =C2=A0any zone data file, but has been synthesized from ot= her RRs. =C2=A0An >> =C2=A0 =C2=A0 =C2=A0example is a synthetic AAAA record created from an A= record. >> >> >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 Transport Address: =C2=A0The combination of an IPv6 or IPv4 addre= ss and a >> =C2=A0 =C2=A0 =C2=A0port. =C2=A0Typically written as (IP address, port);= e.g. (192.0.2.15, >> =C2=A0 =C2=A0 =C2=A08001). >> >> =C2=A0 Tuple: =C2=A0Refers to either a 3-Tuple or a 5-tuple as defined a= bove. >> >> =C2=A0 For a detailed understanding of this document, the reader should = also >> =C2=A0 be familiar with DNS terminology [RFC1035] and current NAT >> =C2=A0 terminology [RFC4787]. >> >> >> 3. =C2=A0NAT64 Normative Specification >> >> =C2=A0 A NAT64 is a device with at least one IPv6 interface and at least= one >> =C2=A0 IPv4 interface. =C2=A0Each NAT64 device MUST have one unicast /n = IPv6 >> =C2=A0 prefix assigned to it, denoted Pref64::/n. =C2=A0Additional consi= deration >> =C2=A0 about the Pref64::/n are presented in Section 3.2.5. =C2=A0Each N= AT64 box >> =C2=A0 MUST have one or more unicast IPv4 addresses assigned to it. >> >> =C2=A0 A NAT64 uses the following dynamic data structures: >> >> =C2=A0 o =C2=A0UDP Binding Information Base >> >> =C2=A0 o =C2=A0UDP Session Table >> >> =C2=A0 o =C2=A0TCP Binding Information Base >> >> =C2=A0 o =C2=A0TCP Session Table >> >> =C2=A0 o =C2=A0ICMP Query Binding Information Base >> >> =C2=A0 o =C2=A0ICMP Query Session Table >> >> =C2=A0 A NAT64 has three Binding Information Bases (BIBs): one for TCP, = one >> =C2=A0 for UDP and one for ICMP Queries. =C2=A0In the case of UDP and TC= P BIBs, >> =C2=A0 each BIB entry specifies a mapping between an IPv6 transport addr= ess >> =C2=A0 and an IPv4 transport address: >> >> =C2=A0 =C2=A0 =C2=A0(X',x) <--> (T,t) >> >> GT> This notation is very useful, I wish you used it much more in the >> descriptions below...see more on that later. >> > > any specific suggestions of were the usage of this notation could be usef= ul? >> >> =C2=A0 where X' is some IPv6 address, T is an IPv4 address, and x and t = are >> =C2=A0 ports. =C2=A0T will always be one of the IPv4 addresses assigned = to the >> =C2=A0 NAT64. =C2=A0A given IPv6 or IPv4 transport address can appear in= at most >> =C2=A0 one entry in a BIB: for example, (2001:db8::17, 4) can appear in = at >> =C2=A0 most one TCP and at most one UDP BIB entry. >> >> GT> Maybe it should be noted that this is what implements/ensure >> "Endpoint-Independent mappings"?. >> > > Right, i have added > > This implementation of the BIBs ensures Endpoint-Independent mappings in = the > NAT64. >> >> =C2=A0 TCP and UDP have >> =C2=A0 separate BIBs because the port number space for TCP and UDP are >> =C2=A0 distinct. >> >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 12] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 In the case of the ICMP Query BIB, each ICMP Query BIB entry spec= ify >> =C2=A0 a mapping between an (IPv6 address, Query Identifier) pair and an >> =C2=A0 (IPv4 address, Query Identifier pair). >> >> =C2=A0 =C2=A0 =C2=A0(X',I1) <--> (T,I2) >> >> =C2=A0 where X' is some IPv6 address, T is an IPv4 address, and I1 and I= 2 >> =C2=A0 are Query Identifiers. =C2=A0T will always be one of the IPv4 add= resses >> =C2=A0 assigned to the NAT64. =C2=A0A given (IPv6 or IPv4 address, Query= Id) pair >> =C2=A0 can appear in at most one entry in the ICMP Query BIB. >> >> =C2=A0 Entries in any of the three BIBs can be created dynamically as th= e >> =C2=A0 result of the flow of packets as described in the section Section= 3.2 >> =C2=A0 but the can also can be created manually by the system administra= tor. >> >> GT> //can also can/can also >> >> > > ok >> >> =C2=A0 NAT64 implementations SHOULD support manually configured BIB entr= ies >> =C2=A0 for any of the three BIBs. =C2=A0Dynamically-created entries are = deleted >> =C2=A0 from the corresponding BIB when the last session associated to th= e >> =C2=A0 BIB entry is removed from the session table. >> >> GT> MUST/SHOULD/MAY??? sounds like a SHOULD to me. or is a MUST if >> associated with a max-wait time. >> >> > > mmm, i think this is how the mechanism work, didn't wanted to abuse on th= e > usage of the normative language, i think it should be either a SHOULD or = a > MUST, but i am not convinced we need to use normative language for this > >> =C2=A0 Manually-configured BIB >> =C2=A0 entries are not deleted when there is no corresponding session ta= ble >> =C2=A0 entry and can only be deleted by the administrator. >> >> >> GT> All of the text above regarding BIBs, says what BIBs are but it >> does not say what BIBs are for. e.g., > > well, BIBs contain the mapping information, and that is mentioned earlier= . > In any case, i have added text stating that endpoint indpeepndet filterin= g > is implemented using the bibs. > > The resulting text is: > > =C2=A0 =C2=A0 =C2=A0A NAT64 has three Binding Information Bases (BIBs)= : one for TCP, one > for > =C2=A0 =C2=A0 =C2=A0UDP and one for ICMP Queries. In the case of UDP and = TCP BIBs, each > =C2=A0 =C2=A0 =C2=A0 =C2=A0BIB entry specifies a mapping between an IPv6 = transport address > =C2=A0 =C2=A0 =C2=A0and an IPv4 transport address: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(X',x) <--> (T,t) > =C2=A0 =C2=A0 =C2=A0 =C2=A0where X' is some IPv6 address, T is an = IPv4 address, and x and > t > =C2=A0 =C2=A0 =C2=A0are ports. T will always be one of the IPv4 addresses= assigned to the > NAT64. > =C2=A0 =C2=A0 =C2=A0A given IPv6 or IPv4 transport address can appear > =C2=A0 =C2=A0 =C2=A0in at most one entry in a BIB: for example, (2001:db8= ::17, 4) can > =C2=A0 =C2=A0 =C2=A0appear in at most one TCP and at most one UDP BIB ent= ry. TCP and UDP > =C2=A0 =C2=A0 =C2=A0have separate BIBs because the port number space for = TCP and UDP are > =C2=A0 =C2=A0 =C2=A0distinct. This implementation of the BIBs ensures End= point-Independent > mappings in the NAT64. > =C2=A0 =C2=A0 =C2=A0 The information in the BIBs is also used to implemen= t > Endpoint-Independent filtering. > =C2=A0 =C2=A0 =C2=A0 (Address-Dependent filtering is implemented using th= e Session tables > described below.) > > >> =C2=A0BIBs implement >> "Endpoint-Independent filtering"....other types of filtering can be >> implemented with session entries. All session table entries MUST have >> corresponding BIB entries. right? >> >> =C2=A0 A NAT64 also has three session tables: one for TCP sessions, one = for >> =C2=A0 UDP sessions and one for ICMP Query sessions. =C2=A0Each entry ke= eps >> =C2=A0 information on the state of the corresponding session. =C2=A0In t= he TCP >> =C2=A0 and UDP session tables, each entry specifies a mapping between a = pair >> =C2=A0 of IPv6 transport address and a pair of IPv4 transport address: >> >> =C2=A0 =C2=A0 =C2=A0(X',x),(Y',y) <--> (T,t),(Z,z) >> >> =C2=A0 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, a= nd >> =C2=A0 x, y, z and t are ports. =C2=A0T will always be one of the IPv4 a= ddresses >> =C2=A0 assigned to the NAT64. =C2=A0Y' is always the IPv6 representation= of the >> =C2=A0 IPv4 address Z, so Y' is obtained from Z using the algorithm appl= ied >> =C2=A0 by the NAT64 to create IPv6 representations of IPv4 addresses. y = is >> =C2=A0 always equal to z. =C2=A0In addition, each session table entry ha= s a >> =C2=A0 lifetime. >> >> GT> Instead of "is" this and "will always be" that, consider using >> normative MUSTs. >> > > ok > > >> >> =C2=A0 In the ICMP query session table, each entry specifies a mapping >> =C2=A0 between a 3-tuple of IPv6 source address, IPv6 destination addres= s >> =C2=A0 and ICMPv6 Query Id and a 3-tuple of IPv4 source address, IPv4 >> =C2=A0 destination address and ICMPv4 Query Id: >> >> =C2=A0 =C2=A0 =C2=A0(X',Y',I1) <--> (T,Z,I2) >> >> =C2=A0 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, a= nd >> =C2=A0 I1 and I2 are ICMP query Ids. T will always be one of the IPv4 >> =C2=A0 addresses assigned to the NAT64. =C2=A0Y' is always the IPv6 >> =C2=A0 representation of the IPv4 address Z, so Y' is obtained from Z us= ing >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 13] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 the algorithm applied by the NAT64 to create IPv6 representations= of >> =C2=A0 IPv4 addresses. =C2=A0In addition, each session table entry has a >> =C2=A0 lifetime. >> >> =C2=A0 The NAT64 uses the session state information to determine when th= e >> =C2=A0 session is completed, and also uses session information for ingre= ss >> =C2=A0 filtering. >> >> GT> what kind? Address-Dependent? Address and Port-Dependent >> Filtering? both? other? >> > > Address dependent filtering, i ahve removed the ingress filtering cause i= s > indeed misleading and stated that this is for address dependent filtering= . > >> =C2=A0A session can be uniquely identified by either an >> =C2=A0 incoming tuple or an outgoing tuple. >> >> GT> what is "ingress" in this context? >> >> > > I have removed the ingress from above > >> =C2=A0 For each session, there is a corresponding BIB entry, uniquely >> =C2=A0 specified by either the source IPv6 transport address or the sour= ce >> =C2=A0 IPv6 address and ICMPv6 Query Id (in the IPv6 --> IPv4 direction)= or >> =C2=A0 the destination IPv4 transport address or the destination IPv4 >> =C2=A0 address and the ICMPv4 Query Id (in the IPv4 --> IPv6 direction). >> >> GT> It is not clear why the above is ICMP specific and why the BIB >> entry can be identified in so many different ways. I am a bit >> confused. >> > > right, the thing is that UDP and TCP sessions are identified in one way, > while ICMP queries sessions are identified in another way. > I have rewritten the paragraph as follows: > > =C2=A0For each TCP or UDP session, there is a corresponding BIB entry, > =C2=A0uniquely specified by either the source IPv6 transport address (in > =C2=A0the IPv6 --> IPv4 direction) or the destination IPv4 transport > =C2=A0address (in the IPv4 --> IPv6 direction). =C2=A0For each ICMP Query > =C2=A0session, there is a corresponding BIB entry, uniquely specified by > =C2=A0either the source IPv6 address and ICMPv6 Query Id (in the IPv6 --> > =C2=A0IPv4 direction) or the destination IPv4 address and the ICMPv4 Quer= y > =C2=A0Id (in the IPv4 --> IPv6 direction). =C2=A0However, for all the BIB= s, a > =C2=A0single BIB entry can have multiple corresponding sessions. =C2=A0Wh= en the > =C2=A0last corresponding session is deleted, if the BIB entry was > =C2=A0dynamically created, the BIB entry is deleted. > > > >> =C2=A0 However, a single BIB entry can have multiple corresponding sessi= ons. >> =C2=A0 When the last corresponding session is deleted, if the BIB entry = was >> =C2=A0 dynamically created, the BIB entry is deleted. >> >> GT> this was said also earlier...see if one instance can be removed. >> >> > > mmm, i would preffer keep this both in the bib description and the sessio= n > table description > If someone else complains, i will remove it > >> =C2=A0 The processing of an incoming IP packet takes the following steps= : >> >> =C2=A0 1. =C2=A0Determining the incoming tuple >> >> =C2=A0 2. =C2=A0Filtering and updating binding and session information >> >> =C2=A0 3. =C2=A0Computing the outgoing tuple >> >> =C2=A0 4. =C2=A0Translating the packet >> >> =C2=A0 5. =C2=A0Handling hairpinning >> >> =C2=A0 The details of these steps are specified in the following >> =C2=A0 subsections. >> >> =C2=A0 This breakdown of the NAT64 behavior into processing steps is don= e >> =C2=A0 for ease of presentation. =C2=A0A NAT64 MAY perform the steps in = a >> =C2=A0 different order, or MAY perform different steps, as long as the >> =C2=A0 externally visible outcome is the same. >> >> 3.1. =C2=A0Determining the Incoming tuple >> >> GT> It would be helpful to make clear what "incoming IP packet" the >> text refers to. Since no IP version is indicated, I assume that this >> section is common to all IPv4, IPv6, and ICMP packets received by the >> NAT64 function. >> >> > > I have added this text: > > =C2=A0 =C2=A0 =C2=A0The NAT64 will receive packet through its interfac= es. These packets > can be either IPv6 > =C2=A0 =C2=A0 =C2=A0 packets or IPv4 packets and they may carry TCP traff= ic, UDP traffic or > ICMP. The processing > =C2=A0 =C2=A0 =C2=A0 of the packets will be described next. In the case t= hat the processing > is common to all the aforementioned > =C2=A0 =C2=A0 =C2=A0 types of packets, we will refer to the packet as the= incoming packet > in general. In case that the processing > =C2=A0 =C2=A0 =C2=A0 is specific to IPv6 packets, we will refer to the in= coming IPv6 packet > and similarly to the IPv4 packets. > >> =C2=A0 This step associates a incoming tuple with every incoming IP pack= et >> =C2=A0 for use in subsequent steps. =C2=A0In the case of TCP, UDP and IC= MP error >> =C2=A0 packets, the tuple is a 5-tuple consisting of source IP address, >> =C2=A0 source port, destination IP address, destination port, transport >> =C2=A0 protocol. =C2=A0In case of ICMP Queries, the tuple is a 3-tuple c= onsisting >> =C2=A0 of the source IP address, destination IP address and Query >> =C2=A0 Identifier. >> >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 14] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 If the incoming IP packet contains a complete (un-fragmented) UDP= or >> =C2=A0 TCP protocol packet, then the 5-tuple is computed by extracting t= he >> =C2=A0 appropriate fields from the packet. >> >> =C2=A0 If the incoming packet is an ICMP query message (i.e. an ICMPv4 Q= uery >> =C2=A0 message or an ICMPv6 Informational message), the 3-tuple is the >> =C2=A0 source IP address. the destination IP address and the ICMP Query >> =C2=A0 Identifier. >> >> =C2=A0 If the incoming IP packet contains a complete (un-fragmented) ICM= P >> =C2=A0 error message, then the 5-tuple is computed by extracting the >> =C2=A0 appropriate fields from the IP packet embedded inside the ICMP er= ror >> =C2=A0 message. =C2=A0However, the role of source and destination is swa= pped when >> =C2=A0 doing this: the embedded source IP address becomes the destinatio= n IP >> =C2=A0 address in the 5-tuple, the embedded source port becomes the >> =C2=A0 destination port in the 5-tuple, etc. =C2=A0If it is not possible= to >> =C2=A0 determine the 5-tuple (perhaps because not enough of the embedded >> =C2=A0 packet is reproduced inside the ICMP message), then the incoming = IP >> =C2=A0 packet is silently discarded. >> >> =C2=A0 =C2=A0 =C2=A0NOTE: The transport protocol is always one of TCP or= UDP, even if >> =C2=A0 =C2=A0 =C2=A0the IP packet contains an ICMP Error message. >> >> GT> I do not understand this note. >> >> > > I have removed it > >> =C2=A0 If the incoming IP packet contains a fragment, then more processi= ng >> =C2=A0 may be needed. =C2=A0This specification leaves open the exact det= ails of >> =C2=A0 how a NAT64 handles incoming IP packets containing fragments, and >> =C2=A0 simply requires that a NAT64 handle fragments arriving out-of-ord= er. >> =C2=A0 A NAT64 MAY elect to queue the fragments as they arrive and trans= late >> =C2=A0 all fragments at the same time. =C2=A0Alternatively, a NAT64 MAY = translate >> =C2=A0 the fragments as they arrive, by storing information that allows = it >> =C2=A0 to compute the 5-tuple for fragments other than the first. =C2=A0= In the >> =C2=A0 latter case, the NAT64 will still need to handle the situation wh= ere >> =C2=A0 subsequent fragments arrive before the first. >> >> GT> Has the option of NAT64 reassembling packets before translating >> been discussed at all? >> > > not sure what the question is here, but i have rewritten this section > already as result from the discussions in the ml and the new text is: > > =C2=A0If the incoming IP packet contains a fragment, then more processing > =C2=A0may be needed. =C2=A0This specification leaves open the exact detai= ls of > =C2=A0how a NAT64 handles incoming IP packets containing fragments, and > =C2=A0simply requires that the external behavior of the NAT64 is complian= t > =C2=A0with the following conditions: > > =C2=A0 =C2=A0 The NAT64 MUST handle fragments arriving out-of-order condi= tioned > =C2=A0 =C2=A0 to the following: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MUST limit the amount of resources d= evoted to the > =C2=A0 =C2=A0 =C2=A0 =C2=A0storage of fragmented packets in order to prev= ent from DoS > =C2=A0 =C2=A0 =C2=A0 =C2=A0attack. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MUST allow the fragments to arrive o= ver a time > =C2=A0 =C2=A0 =C2=A0 =C2=A0interval. =C2=A0The time interval MUST be conf= igurable and the > =C2=A0 =C2=A0 =C2=A0 =C2=A0default value MUST be of at least 10 seconds. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MAY require that the UDP, TCP, or IC= MP header be > =C2=A0 =C2=A0 =C2=A0 =C2=A0completely contained within the first fragment= . > > =C2=A0 =C2=A0 A NAT64 MAY elect to queue the fragments as they arrive and > =C2=A0 =C2=A0 translate all fragments at the same time. =C2=A0Alternative= ly, a NAT64 > =C2=A0 =C2=A0 MAY translate the fragments as they arrive, by storing info= rmation > =C2=A0 =C2=A0 that allows it to compute the 5-tuple for fragments other t= han the > =C2=A0 =C2=A0 first. =C2=A0In the latter case, subsequent fragments may a= rrive before > =C2=A0 =C2=A0 the first. > > =C2=A0 =C2=A0 Implementers of NAT64 should be aware that there are a numb= er of > =C2=A0 =C2=A0 well-known attacks against IP fragmentation; see [RFC1858] = and > =C2=A0 =C2=A0 [RFC3128]. =C2=A0Implementers should also be aware of addit= ional issues > =C2=A0 =C2=A0 with reassembling packets at high rates, described in [RFC4= 963]. > > > > >> GT> On a different note, this section is supposed to be about >> "determining the incoming tuple". I think handling fragments should >> only be discussed in as far as it is needed to determine the >> tuple....other fragmentation concerns (i.e., most of the rest of the >> text) should not be here IMO. >> >> > > but the only difficulty in handling fragments is that fragments other tha= n > the first one do not contain the port information so we need to do extra > work to determine the incoming tuple, so i still think it is a reasonable > match to describe it here, since it is most of the work. > >> =C2=A0 Implementors of NAT64 should be aware that there are a number of >> =C2=A0 well-known attacks against IP fragmentation; see [RFC1858] and >> =C2=A0 [RFC3128]. >> >> =C2=A0 Assuming it otherwise has sufficient resources, a NAT64 MUST allo= w >> =C2=A0 the fragments to arrive over a time interval of at least 10 secon= ds. >> =C2=A0 A NAT64 MAY require that the UDP, TCP, or ICMP header be complete= ly >> =C2=A0 contained within the first fragment. >> >> =C2=A0 Except from the retrieval of 5-tuple information from the incomin= g >> =C2=A0 packets as discussed above, all other fragmentation and PMTUD rel= ated >> =C2=A0 processing performed by the NAT64 device is performed as defined = in >> =C2=A0 [I-D.ietf-behave-v6v4-xlate], including the translation of all >> =C2=A0 related fragmentation fields in the IP header, the determination = of >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 the outgoing packet size, the fragmentation of outgoing packets a= nd >> =C2=A0 the generation and processing of ICMP Packet Too Big errors. >> >> =C2=A0 In particular, the NAT64 must generate ICMP Packet Too Big error >> =C2=A0 messages in the case the outgoing packet does not fit in the outg= oing >> =C2=A0 MTU and needs to be discarded. >> >> GT> Is this correct? Section 2.1 of [I-D.ietf-behave-v6v4-xlate] >> indicates that IPv4 packets can be fragmented further to fit in IPv6 >> packets... why don't we just stay silent on the issue and just point >> to [I-D.ietf-behave-v6v4-xlate]? >> > > will do that i.e. i will simply remove the last paragraph and leave the > previous one with a pointer to the xlate > > >> 3.2. =C2=A0Filtering and Updating Binding and Session Information >> >> =C2=A0 This step updates binding and session information stored in the >> =C2=A0 appropriate tables. =C2=A0This step may also filter incoming pack= ets, if >> =C2=A0 desired. >> >> =C2=A0 Irrespectively of the transport protocol used, the NAT64 must >> =C2=A0 silently discard all incoming IPv6 packets containing a source >> =C2=A0 address that contains the Pref64::/n. =C2=A0This is required in o= rder to >> =C2=A0 prevent hairpinning loops as described in the Security Considerat= ions >> =C2=A0 section. >> >> =C2=A0 The details of this step depend on the protocol (UDP TCP or ICMP >> =C2=A0 Query). >> >> 3.2.1. =C2=A0UDP Session Handling >> >> =C2=A0 The state information stored for a UDP session in the UDP session >> =C2=A0 table includes a timer that tracks the remaining lifetime of the = UDP >> =C2=A0 session. =C2=A0The NAT64 decrements this timer at regular interva= ls. =C2=A0When >> =C2=A0 the timer expires, the UDP session is deleted. =C2=A0If all the U= DP >> =C2=A0 sessions corresponding to a UDP BIB entry are deleted, then the U= DP >> =C2=A0 BIB entry is also deleted (only applies to the case of dynamicall= y >> =C2=A0 created entries). >> >> GT> I commented on this earlier so align any changes you make earlier wi= th >> this. >> > > mmm, i think this text is coherent with the previous text including the > changes, not sure if you think something needs to be changed here... > >> =C2=A0 An IPv6 incoming packet is processed as follows: >> >> GT> Presumably such a packet is only processed if the destination >> address is from Pref64::/n? It would help to state this. >> >> > > right, i have added earlier in the general part common to TCP, UDP and IC= MP > > =C2=A0 =C2=A0NAT64 function will only process incoming > =C2=A0 =C2=A0IPv6 packet that contain a destination address that contains= Pref64::/n. >> >> =C2=A0 =C2=A0 =C2=A0The NAT64 searches for a UDP BIB entry that matches = the IPv6 >> =C2=A0 =C2=A0 =C2=A0source transport address. =C2=A0If such entry does n= ot exists, a new >> =C2=A0 =C2=A0 =C2=A0entry is created. =C2=A0As IPv6 address, the source = IPv6 transport >> =C2=A0 =C2=A0 =C2=A0address of the packet is included and an IPv4 transp= ort address >> =C2=A0 =C2=A0 =C2=A0allocated using the rules defined in Section 3.2.3 i= s included as >> =C2=A0 =C2=A0 =C2=A0IPv4 address. >> >> GT> The last sentence does not read well. It would help to be more >> exact in this and subsequent descriptions. For example: the new BIB >> entry has the form of =C2=A0(Y*,y)<->(T,t), where Y* is set to the sourc= e >> IPv6 address of the packet, y is set to the source port number of the >> packet, T is one of the NAT64's IPv4 addresses used for translation >> and t is set to an unused port number on the selected IPv4 address T. >> > > I have rewritten this. I include all the text below. I have prefered to > explicitly define the fields of the BIB and make refgerecne to that. I ha= ve > used thisnotation for the session table > >> =C2=A0 =C2=A0 =C2=A0The NAT64 searches for the session table entry corre= sponding to >> =C2=A0 =C2=A0 =C2=A0the incoming 5-tuple. >> >> GT> This search, I assume is only meaningful if there was already a >> BIB entry? If the BIB entry was just created based on the last >> paragraph, there is no point in searching the session table, right? >> > > right, not sure it worth adding another conditional if here for this, tho= ugh > (i mean, the condition is trivially met) > >> =C2=A0 =C2=A0 =C2=A0If no such entry is found, a new entry is >> =C2=A0 =C2=A0 =C2=A0created. =C2=A0The information included in the sessi= on table is as >> =C2=A0 =C2=A0 =C2=A0follows: the IPv6 transport source and destination a= ddresses >> =C2=A0 =C2=A0 =C2=A0contained in the received IPv6 packet, the IPv4 tran= sport source >> =C2=A0 =C2=A0 =C2=A0address is extracted from the corresponding UDP BIB = entry and the >> =C2=A0 =C2=A0 =C2=A0IPv4 transport destination address contains the same= port as the >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 16] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 =C2=A0 =C2=A0IPv6 destination transport address and the IPv4 addr= ess that is >> =C2=A0 =C2=A0 =C2=A0algorithmically generated from the IPv6 destination = address using >> =C2=A0 =C2=A0 =C2=A0the reverse algorithm as specified in Section 3.2.5. >> >> GT> Again, reading this makes my head hurt. I think this could be much >> clearer if you use the (X',x),(Y',y) <--> (T,t),(Z,z) and say how >> these values are set based on the incoming packet. >> >> > > done that, or at least i have tried > see below >> >> =C2=A0 =C2=A0 =C2=A0The NAT64 sets or resets the timer in the session ta= ble entry to >> =C2=A0 =C2=A0 =C2=A0maximum session lifetime. =C2=A0By default, the maxi= mum session >> =C2=A0 =C2=A0 =C2=A0lifetime is 5 minutes, but for specific destination = ports in the >> =C2=A0 =C2=A0 =C2=A0Well-Known port range (0..1023), the NAT64 MAY use a= smaller >> =C2=A0 =C2=A0 =C2=A0maximum lifetime. >> >> GT> It would be nice to indicate why a smaller mac lifetime is suggested >> here. >> >> > > right, > > i have added, > > Note: The reason why the lifetime for the sessions involving > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Well-Known ports can be shorter than the recommended > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 default value is to allow greater reutilization of the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 pool of transport addresses of the NAT64 for bindings > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 involving the Well-Known ports, since it is less > likely that > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 the application using these ports will use the NAT > traversal > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 techniques that rely on having a binding alive to > enable incoming > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 communications. > >> =C2=A0The packet is translated and forwarded as >> =C2=A0 =C2=A0 =C2=A0described in the following sections. >> >> =C2=A0 An IPv4 incoming packet is processed as follows: >> >> =C2=A0 =C2=A0 =C2=A0The NAT64 searches for a UDP BIB entry that matches = the IPv4 >> =C2=A0 =C2=A0 =C2=A0destination transport address. >> >> GT> More accurately: Given the BIB entries are of the form >> (Y*,y)<->(T,t), NAT64 attempts to match the destination IPv4 transport >> address to the (T,t) part of the BIB entires. >> > > i ahve rewritten the whole thing, hopefully is clearer noe >> >> =C2=A0 =C2=A0 If such entry does not exists, the >> =C2=A0 =C2=A0 =C2=A0packet is dropped. An ICMP message MAY be sent to th= e original >> =C2=A0 =C2=A0 =C2=A0sender of the packet, unless the discarded packet is= itself an >> =C2=A0 =C2=A0 =C2=A0ICMP message. =C2=A0The ICMP message, if sent, has a= type of 3 >> =C2=A0 =C2=A0 =C2=A0(Destination Unreachable). >> >> =C2=A0 =C2=A0 =C2=A0If the NAT64 filters on its IPv4 interface, >> >> GT> You have to define what this means. if I understand correctly >> below you describes "Address and Port-Dependent Filtering" or is it >> "Address-Dependent Filtering"? it is hard to tell given that you try >> to match "addresses" with "transport addresses" which makes no sense. >> >> > > rephrased as: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the NAT64 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applies Address-Dependent= filters on its IPv4 interface, then > the NAT64 checks to see if > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the incoming packet is al= lowed according to the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0address-dependent filteri= ng rule. > >> then the NAT64 checks >> =C2=A0 =C2=A0 =C2=A0to see if the incoming packet is allowed according t= o the address- >> =C2=A0 =C2=A0 =C2=A0dependent filtering rule. =C2=A0To do this, it searc= hes for a session >> =C2=A0 =C2=A0 =C2=A0table entry with a source IPv4 transport address equ= al to the >> =C2=A0 =C2=A0 =C2=A0destination IPv4 transport address in the incoming 5= -tuple and >> =C2=A0 =C2=A0 =C2=A0destination IPv4 address (in the session table entry= ) equal to the >> =C2=A0 =C2=A0 =C2=A0source IPv4 address in the incoming 5-tuple. >> >> GT> This is really hard to parse. =C2=A0If you use the (X',x),(Y',y) <--= > >> (T,t),(Z,z) notation it all becomes much clearer. For example, here >> the NAT64 could implement "Address and Port-Dependent Filtering" by >> trying to match the destination IPv4 transport address in the packet >> with the (T,t) part, and the source IPv4 transport address of the >> packet with the (Z,z) =C2=A0part, of the entries in the session table. I= s >> this what you mean? If instead you do "Address-Dependent Filtering" >> you simply drop the t and z from the above. >> > > I have rewritttne this using this notation > >> If such an entry is >> =C2=A0 =C2=A0 =C2=A0found (there may be more than one), packet processin= g continues. >> >> GT> I do not get how there can be more than one of these. >> >> =C2=A0 =C2=A0 =C2=A0Otherwise, the packet is discarded. =C2=A0If the pac= ket is discarded, >> =C2=A0 =C2=A0 =C2=A0then an ICMP message MAY be sent to the original sen= der of the >> =C2=A0 =C2=A0 =C2=A0packet, unless the discarded packet is itself an ICM= P message. >> =C2=A0 =C2=A0 =C2=A0The ICMP message, if sent, has a type of 3 (Destinat= ion >> =C2=A0 =C2=A0 =C2=A0Unreachable) and a code of 13 (Communication Adminis= tratively >> =C2=A0 =C2=A0 =C2=A0Prohibited). >> >> GT> Now it gets really confusing. What follows is clearly not a >> continuation from the above. It looks like its a case where a session >> is allowed to be initiated from the IPv4 side; if that is the case >> then it should be clearly stated! Also does the following describe >> processing when NAT64 does NOT filter at all on IPv4? or when it does >> "Endpoint-Independent Filtering"? or " Address-Dependent Filtering"? >> It seems that the description below only assumes a matching BIB entry >> so my guess is that the following is based on "Endpoint-Independent >> Filtering" >> > > In order to link it with the previous paragraph, i have added > > In case the packet is not discarded in the previous processing, then the > NAT64 searches for the session table entry > >> =C2=A0 =C2=A0 =C2=A0The NAT64 searches for the session table entry corre= sponding to >> =C2=A0 =C2=A0 =C2=A0the incoming 5-tuple. >> >> GT> Again you should use the =C2=A0(X',x),(Y',y) <--> (T,t),(Z,z) =C2=A0= notation >> to make clear what "searching" means above, as well as to define how >> the new entry is "created" below. >> >> > > right, see below > >> =C2=A0 =C2=A0 =C2=A0If no such entry is found, a new entry is >> =C2=A0 =C2=A0 =C2=A0created. =C2=A0The UDP session table entry contains = the transport >> =C2=A0 =C2=A0 =C2=A0source and destination address contained in the IPv4= packet and >> =C2=A0 =C2=A0 =C2=A0the source IPv6 transport address (in the IPv6 --> I= Pv4 direction) >> =C2=A0 =C2=A0 =C2=A0contained in the existing UDP BIB entry. =C2=A0The d= estination IPv6 >> =C2=A0 =C2=A0 =C2=A0transport address contains the same port than the de= stination IPv4 >> =C2=A0 =C2=A0 =C2=A0transport address and the IPv6 representation of the= IPv4 address >> =C2=A0 =C2=A0 =C2=A0of the destination IPv4 transport address, generated= using the >> =C2=A0 =C2=A0 =C2=A0algorithm described in Section 3.2.5. >> >> =C2=A0 =C2=A0 =C2=A0The NAT64 sets or resets the timer in the session ta= ble entry to >> =C2=A0 =C2=A0 =C2=A0maximum session lifetime. =C2=A0By default, the maxi= mum session >> >> >> >> Bagnulo, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 25, 2010 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17] >> >> Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NAT64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0November 2009 >> >> >> =C2=A0 =C2=A0 =C2=A0lifetime is 5 minutes, but for specific destination = ports in the >> =C2=A0 =C2=A0 =C2=A0Well-Known port range (0..1023), the NAT64 MAY use a= smaller >> =C2=A0 =C2=A0 =C2=A0maximum lifetime. >> >> >> GT> OK...I am stopping here...lets see if any of the above makes sense >> to people and then I will continue. >> > > I have rewritten the UDP processing section as follwows: > > In the BIB description i have written: > > =C2=A0A NAT64 has three Binding Information Bases (BIBs): one for TCP, on= e > =C2=A0for UDP and one for ICMP Queries. =C2=A0In the case of UDP and TCP = BIBs, > =C2=A0each BIB entry specifies a mapping between an IPv6 transport addres= s > =C2=A0and an IPv4 transport address: > > =C2=A0 =C2=A0 (X',x) <--> (T,t) > > =C2=A0where X' is some IPv6 address, T is an IPv4 address, and x and t ar= e > =C2=A0ports. =C2=A0T will always be one of the IPv4 addresses assigned to= the > =C2=A0NAT64. =C2=A0The BIB has then two columns, the BIB IPv6 transport a= ddress > =C2=A0and the BIB IPv4 transport address. > > In the Session table description is have written: > > =C2=A0For each Session Table Entry (STE), there are then five columns: > > =C2=A0 =C2=A0 The STE source IPv6 transport address, (X',x) in the exampl= e > =C2=A0 =C2=A0 above, > > =C2=A0 =C2=A0 The STE destination IPv6 transport address, (Y',y) in the e= xample > =C2=A0 =C2=A0 above, > > =C2=A0 =C2=A0 The STE source IPv4 transport address, (T,t) in the example= above, > =C2=A0 =C2=A0 and, > > =C2=A0 =C2=A0 The STE destination IPv4 transport address, (Z,z) in the ex= ample > =C2=A0 =C2=A0 above. > > =C2=A0 =C2=A0 The STE lifetime. > > And then, the UDP processing is: > (i need to review the text to make sure that i didn't confuse any source > with destination...) > > > 3.2.1. =C2=A0UDP Session Handling > > =C2=A0The state information stored for a UDP session in the UDP session > =C2=A0table includes a timer that tracks the remaining lifetime of the UD= P > =C2=A0session. =C2=A0The NAT64 decrements this timer at regular intervals= . =C2=A0When > =C2=A0the timer expires, the UDP session is deleted. =C2=A0If all the UDP > =C2=A0sessions corresponding to a UDP BIB entry are deleted, then the UDP > =C2=A0BIB entry is also deleted (only applies to the case of dynamically > =C2=A0created entries). > > =C2=A0An IPv6 incoming packet with source transport address (X',x) and > =C2=A0destination transport address (Y',y) is processed as follows: > > =C2=A0 =C2=A0 The NAT64 searches for a UDP BIB entry that contains an BIB= IPv6 > =C2=A0 =C2=A0 transport address that matches the IPv6 source transport ad= dress > =C2=A0 =C2=A0 (X',x). =C2=A0If such entry does not exists, a new entry is= created. > =C2=A0 =C2=A0 As BIB IPv6 transport address, the source IPv6 transport ad= dress > =C2=A0 =C2=A0 of the packet (X',x) is included and the BIB IPv4 transport > =C2=A0 =C2=A0 address is set to (T,t) which is allocated using the rules = defined > =C2=A0 =C2=A0 in Section 3.2.3. =C2=A0The result is a BIB entry as follow= s: (X',x) > =C2=A0 =C2=A0 <--> (T,t). > > =C2=A0 =C2=A0 The NAT64 searches for the session table entry correspondin= g to > =C2=A0 =C2=A0 the incoming 5-tuple. =C2=A0If no such entry is found, a ne= w entry is > =C2=A0 =C2=A0 created. =C2=A0The information included in the session tabl= e is as > =C2=A0 =C2=A0 follows: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE source IPv6 transport address is set t= o (X',x) the > =C2=A0 =C2=A0 =C2=A0 =C2=A0source IPv6 transport addresses contained in t= he received IPv6 > =C2=A0 =C2=A0 =C2=A0 =C2=A0packet, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE destination IPv6 transport address is = set to (Y',y) the > =C2=A0 =C2=A0 =C2=A0 =C2=A0destination IPv6 transport addresses contained= in the received > =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 packet, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE source IPv4 transport address is extra= cted from the > =C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding UDP BIB entry i.e. is set to (T,= t), > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE destination IPv4 transport is set to (= Z(Y'),y), y being > =C2=A0 =C2=A0 =C2=A0 =C2=A0the same port as the STE destination IPv6 tran= sport address and > =C2=A0 =C2=A0 =C2=A0 =C2=A0Z(Y') being algorithmically generated from the= IPv6 destination > =C2=A0 =C2=A0 =C2=A0 =C2=A0address (i.e. =C2=A0Y') using the reverse algo= rithm as specified in > =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.2.5 . > > =C2=A0 =C2=A0 The result is a Session table entry as follows: (X',x),(Y',= y) <--> > =C2=A0 =C2=A0 (T,t),(Z(Y'),y) > > =C2=A0 =C2=A0 The NAT64 sets or resets the timer in the session table ent= ry to > =C2=A0 =C2=A0 maximum session lifetime. =C2=A0By default, the maximum ses= sion > =C2=A0 =C2=A0 lifetime is 5 minutes, but for specific destination ports i= n the > =C2=A0 =C2=A0 Well-Known port range (0..1023), the NAT64 MAY use a smalle= r > =C2=A0 =C2=A0 maximum lifetime. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Note: The reason why the lifetime for the sess= ions involving > =C2=A0 =C2=A0 =C2=A0 =C2=A0Well-Known ports can be shorter than the recom= mended default > =C2=A0 =C2=A0 =C2=A0 =C2=A0value is to allow greater reutilization of the= pool of > =C2=A0 =C2=A0 =C2=A0 =C2=A0transport addresses of the NAT64 for bindings = involving the > =C2=A0 =C2=A0 =C2=A0 =C2=A0Well-Known ports, since it is less likely that= the application > =C2=A0 =C2=A0 =C2=A0 =C2=A0using these ports will use the NAT traversal t= echniques that > =C2=A0 =C2=A0 =C2=A0 =C2=A0rely on having a binding alive to enable incom= ing > =C2=A0 =C2=A0 =C2=A0 =C2=A0communications. > > =C2=A0 =C2=A0 The packet is translated and forwarded as described in the > =C2=A0 =C2=A0 following sections. > > =C2=A0An IPv4 incoming packet, with source IPv4 transport address (Y,y) a= nd > =C2=A0destination IPv4 transport address (X,x) is processed as follows: > > =C2=A0 =C2=A0 The NAT64 searches for a UDP BIB entry that contains an BIB= IPv4 > =C2=A0 =C2=A0 transport address matches (Y,y) i.e. the IPv4 destination > =C2=A0 =C2=A0 transport address in the incoming IPv4 packet. =C2=A0If suc= h entry does > =C2=A0 =C2=A0 not exists, the packet is dropped. =C2=A0An ICMP message MA= Y be sent to > =C2=A0 =C2=A0 the original sender of the packet, unless the discarded pac= ket is > =C2=A0 =C2=A0 itself an ICMP message. =C2=A0The ICMP message, if sent, ha= s a type of > =C2=A0 =C2=A0 3 (Destination Unreachable). > > =C2=A0 =C2=A0 If the NAT64 applies Address-Dependent filters on its IPv4 > =C2=A0 =C2=A0 interface, then the NAT64 checks to see if the incoming pac= ket is > =C2=A0 =C2=A0 allowed according to the address-dependent filtering rule. = =C2=A0To do > =C2=A0 =C2=A0 this, it searches for a session table entry with a STE sour= ce IPv4 > =C2=A0 =C2=A0 transport address equal to (X,x) (i.e. the destination IPv4 > =C2=A0 =C2=A0 transport address in the incoming packet) and STE destinati= on IPv4 > =C2=A0 =C2=A0 address equal to Y (i.e. the source IPv4 address in the inc= oming > =C2=A0 =C2=A0 packet). =C2=A0If such an entry is found (there may be more= than one), > =C2=A0 =C2=A0 packet processing continues. =C2=A0Otherwise, the packet is= discarded. > =C2=A0 =C2=A0 If the packet is discarded, then an ICMP message MAY be sen= t to > =C2=A0 =C2=A0 the original sender of the packet, unless the discarded pac= ket is > =C2=A0 =C2=A0 itself an ICMP message. =C2=A0The ICMP message, if sent, ha= s a type of > =C2=A0 =C2=A0 3 (Destination Unreachable) and a code of 13 (Communication > =C2=A0 =C2=A0 Administratively Prohibited). > > =C2=A0 =C2=A0 In case the packet is not discarded in the previous process= ing, > =C2=A0 =C2=A0 then the NAT64 searches for the session table entry corresp= onding > =C2=A0 =C2=A0 containing the STE source IPv4 transport address equal to (= X,x) > =C2=A0 =C2=A0 and the STE destination IPv4 transport address equal to (Y,= y). =C2=A0If > =C2=A0 =C2=A0 no such entry is found, a new entry is created. =C2=A0In ca= se a new UDP > =C2=A0 =C2=A0 session table entry is created, it contains the following > =C2=A0 =C2=A0 information: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE source IPv6 transport address is extra= cted from the > =C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding UDP BIB entry > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE destination IPv6 transport address is = set to (Z'(Y),y), > =C2=A0 =C2=A0 =C2=A0 =C2=A0y being the same port y than the destination I= Pv4 transport > =C2=A0 =C2=A0 =C2=A0 =C2=A0address and Z'(Y) being the IPv6 representatio= n of Y, generated > =C2=A0 =C2=A0 =C2=A0 =C2=A0using the algorithm described in Section 3.2.5 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE source IPv4 transport address is set t= o (X,x) the > =C2=A0 =C2=A0 =C2=A0 =C2=A0destination IPv4 transport addresses contained= in the received > =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 packet,, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The STE destination IPv4 transport is set to (= Y,y), the source > =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 transport addresses contained in the rece= ived IPv4 packet. > > =C2=A0 =C2=A0 The NAT64 sets or resets the timer in the session table ent= ry to > =C2=A0 =C2=A0 maximum session lifetime. =C2=A0By default, the maximum ses= sion > =C2=A0 =C2=A0 lifetime is 5 minutes, but for specific destination ports i= n the > =C2=A0 =C2=A0 Well-Known port range (0..1023), the NAT64 MAY use a smalle= r > =C2=A0 =C2=A0 maximum lifetime. > > > > > > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From tsirtsis@googlemail.com Fri Dec 4 01:01:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7E33A6890 for ; Fri, 4 Dec 2009 01:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlTcd1GGJdJ6 for ; Fri, 4 Dec 2009 01:01:28 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 4C6F83A6857 for ; Fri, 4 Dec 2009 01:01:28 -0800 (PST) Received: by fxm10 with SMTP id 10so2479752fxm.14 for ; Fri, 04 Dec 2009 01:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f63LPrTRmjZkjWawZaFNzuom7j6Nr5ZoXSUeNcxcosQ=; b=vuxKhB01/ImRlEYmvNfk1HJRZCatP3wQvpEeWljmQVcvRe/w6QivR4UrQA21WF5BHq t+Eo+ZTr7n+fsN1VEoTJinBe/C2sghGGiVG2AJwU+PaLxhf9uYhAHYaem1KJPSRMP9aY ex8wFQNqv8kNLJbf1CFEPxx/UbtIzhXNyQy0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Eb8r1kMXw8rXnW2B8tj5sM6Y0NcniI+oPgNMGG5iwa2MlDsBtpbR1kJ+wWBbaHGycO mhDKVC9noeOxFN9pG4plRKUAbUOBZoMF7K1OFmfZMU28kYu5zweS9q8wZbNz2n6bIr6D m64xJUq0hltnTngpqWa9NsplMM9tKcBeYw3CU= MIME-Version: 1.0 Received: by 10.239.139.148 with SMTP id t20mr263355hbt.93.1259917275423; Fri, 04 Dec 2009 01:01:15 -0800 (PST) In-Reply-To: <4B163713.8070001@it.uc3m.es> References: <4B163713.8070001@it.uc3m.es> Date: Fri, 4 Dec 2009 09:01:15 +0000 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:01:29 -0000 First of all I agree with comments already stated WRT: 1) 10sec interval or any min value cannot be mandated since the primary purpose of this advice seems to be to protect NAT64 from fragmentation attacks, which means that the NAT64 implementation should be free to drop fragments if it feels threatened. 2) the requirement (even as a MAY) for the full header to be in the first fragment seems unreasonable. Lars's suggestion on this reads better. Also, I brought up the following in my detailed review. Is it not also an option for the NAT64 to reassemble the incoming packet before translating it? Two options are mentioned in the draft already: - "queue fragments and translate all fragments together"...presumably fragments are still translated and transmitted one by one - "translate each fragment as it comes"....presumably by maintaining appropriate state from the full header The state that has to be maintained for either of the above, and especially if the NAT64 decides to deal with the case of the full header arriving out of order, seems to be very similar to the state required for packet reassembly. This, combined, with the fact that the IPv4 and IPv6 sides of the NAT64 might have different MTUs anyway, possibly requiring further fragmentation after translation, reassembling before translation seems like a reasonable option. Has this been discussed before? George On Wed, Dec 2, 2009 at 9:44 AM, marcelo bagnulo braun wrote: > So, based on the comments from Dan, Iljitshc and Reinaldo, I have rewritt= en > the text as follows: > > =C2=A0If the incoming IP packet contains a fragment, then more processing > =C2=A0may be needed. =C2=A0This specification leaves open the exact detai= ls of > =C2=A0how a NAT64 handles incoming IP packets containing fragments, and > =C2=A0simply requires that the external behavior of the NAT64 is complian= t > =C2=A0with the following conditions: > > =C2=A0 =C2=A0 The NAT64 MUST handle fragments arriving out-of-order condi= tioned > =C2=A0 =C2=A0 to the following: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MUST limit the amount of resources d= evoted to the > =C2=A0 =C2=A0 =C2=A0 =C2=A0storage of fragmented packets in order to prev= ent from DoS > =C2=A0 =C2=A0 =C2=A0 =C2=A0attack. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MUST allow the fragments to arrive o= ver a time > =C2=A0 =C2=A0 =C2=A0 =C2=A0interval. =C2=A0The time interval MUST be conf= igurable and the > =C2=A0 =C2=A0 =C2=A0 =C2=A0default value MUST be of at least 10 seconds. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0The NAT64 MAY require that the UDP, TCP, or IC= MP header be > =C2=A0 =C2=A0 =C2=A0 =C2=A0completely contained within the first fragment= . > > =C2=A0 =C2=A0 A NAT64 MAY elect to queue the fragments as they arrive and > =C2=A0 =C2=A0 translate all fragments at the same time. =C2=A0Alternative= ly, a NAT64 > =C2=A0 =C2=A0 MAY translate the fragments as they arrive, by storing info= rmation > =C2=A0 =C2=A0 that allows it to compute the 5-tuple for fragments other t= han the > =C2=A0 =C2=A0 first. =C2=A0In the latter case, the NAT64 will still need = to handle > =C2=A0 =C2=A0 the situation where subsequent fragments arrive before the = first. > > =C2=A0 =C2=A0 Implementers of NAT64 should be aware that there are a numb= er of > =C2=A0 =C2=A0 well-known attacks against IP fragmentation; see [RFC1858] = and > =C2=A0 =C2=A0 [RFC3128]. =C2=A0Implementers should also be aware of addit= ional issues > =C2=A0 =C2=A0 with reassembling packets at high rates, described in [RFC4= 963] > > > > > The basic idea is that the NAT64 must handle fragments as long as the > conditions hold. does that makes sense? Or should i change if for a SHOUL= D > and qualify it with the conditions? > > About the timer, i have required it to be configurable, still not convinc= ed > we shoudl propose a lower defualt value with the existent qualifications = of > the must. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From simon.perreault@viagenie.ca Fri Dec 4 04:24:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660893A6A00 for ; Fri, 4 Dec 2009 04:24:21 -0800 (PST) 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.101, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mU6DHVmKCo4 for ; Fri, 4 Dec 2009 04:24:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 78FD53A6841 for ; Fri, 4 Dec 2009 04:24:20 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id A49A420E00 for ; Fri, 4 Dec 2009 07:24:11 -0500 (EST) Message-ID: <4B18FF6B.1010103@viagenie.ca> Date: Fri, 04 Dec 2009 07:24:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B163713.8070001@it.uc3m.es> <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> In-Reply-To: <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 12:24:21 -0000 Lars Eggert wrote, on 2009-12-03 21:38: >> The NAT64 MUST limit the amount of resources devoted to the >> storage of fragmented packets in order to prevent from DoS >> attack. > > I'd add an "under overload conditions" somewhere. While not overloaded, limiting storage doesn't really serve any purpose but lowers reassembly chances. >From an implementor's point of view, this is too fuzzy. What exactly are "overload conditions"? What behavior would be different from just a hard threshold? Do you mean "put the threshold as high as you can without causing overload"? > I'm wondering if we should simply say "use a good sized fixed buffer that doesn't drive you into overload when full, and use an oldest-first (or LFU?) replacement scheme"? No. That's crossing into the implementor's land. Only specify externally-observable behavior. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From marcelo@it.uc3m.es Fri Dec 4 06:31:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1892D3A6924 for ; Fri, 4 Dec 2009 06:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9iCM4qlwyTn for ; Fri, 4 Dec 2009 06:31:02 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D39413A6922 for ; Fri, 4 Dec 2009 06:31:01 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 7E4056C308D; Fri, 4 Dec 2009 15:30:51 +0100 (CET) Message-ID: <4B191D1B.2050301@it.uc3m.es> Date: Fri, 04 Dec 2009 15:30:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Thaler References: <4B163713.8070001@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17048.007 Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:31:03 -0000 Dave Thaler escribió: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of marcelo bagnulo braun >> Sent: Wednesday, December 02, 2009 1:45 AM >> To: Behave WG >> Subject: [BEHAVE] handling packet with fragments, second try >> >> So, based on the comments from Dan, Iljitshc and Reinaldo, I have >> rewritten the text as follows: >> >> If the incoming IP packet contains a fragment, then more processing >> may be needed. This specification leaves open the exact details of >> how a NAT64 handles incoming IP packets containing fragments, and >> simply requires that the external behavior of the NAT64 is compliant >> with the following conditions: >> >> The NAT64 MUST handle fragments arriving out-of-order conditioned >> to the following: >> >> The NAT64 MUST limit the amount of resources devoted to the >> storage of fragmented packets in order to prevent from DoS >> attack. >> > > Grammar: > Either s/from/a/ > Or s/prevent/protect/ > > >> The NAT64 MUST allow the fragments to arrive over a time >> interval. The time interval MUST be configurable and the >> default value MUST be of at least 10 seconds. >> > > Not sure how this MUST interacts with the previous paragraph. > If you're under attack it may not be feasible to allow fragments > to arrive over a 10 second period, since doing so may exhaust all > memory. Clarify. > Right, what about: As long as the NAT64 has available resources, the NAT64 MUST allow the fragments to arrive over a time interval. > >> The NAT64 MAY require that the UDP, TCP, or ICMP header be >> completely contained within the first fragment. >> > > Presumably "first" means the first to arrive, as opposed to first in > byte order, yes? No, it means the first packet in byte order. (so yes, it needs clarification) So, i will add: The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the first fragment (first fragment meaning the fragment that contains OFFSET equal to zero). The reason for this is that the tiny fragments attack rely on sending the TCP header fragmented. > Since "first" is used in the other sense in the > next paragraph, switching uses is confusing. > > In addition, why is this sentence present at all? This seems dangerous. > > the goal of this is to allow to deal with tiny fragments attacks, If people feel we shoudl drop this, i don't have a strong preference. >> A NAT64 MAY elect to queue the fragments as they arrive and >> translate all fragments at the same time. Alternatively, a NAT64 >> MAY translate the fragments as they arrive, by storing >> information >> that allows it to compute the 5-tuple for fragments other than >> the >> first. In the latter case, the NAT64 will still need to handle >> the situation where subsequent fragments arrive before the first. >> > > The last sentence above looks good, although it seems to contradict the > MAY I questioned above. > > I hope with the clarification i made, there is no longer a contradiction Regards, marcelo > -Dave > > >> Implementers of NAT64 should be aware that there are a number of >> well-known attacks against IP fragmentation; see [RFC1858] and >> [RFC3128]. Implementers should also be aware of additional >> issues >> with reassembling packets at high rates, described in [RFC4963] >> >> >> >> >> The basic idea is that the NAT64 must handle fragments as long as the >> conditions hold. does that makes sense? Or should i change if for a >> SHOULD and qualify it with the conditions? >> >> About the timer, i have required it to be configurable, still not >> convinced we shoudl propose a lower defualt value with the existent >> qualifications of the must. >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > From marcelo@it.uc3m.es Fri Dec 4 06:34:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1993A689C for ; Fri, 4 Dec 2009 06:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBfeUR8prGwa for ; Fri, 4 Dec 2009 06:34:17 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 305F23A6824 for ; Fri, 4 Dec 2009 06:34:17 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id E395D7F406C; Fri, 4 Dec 2009 15:34:06 +0100 (CET) Message-ID: <4B191DDE.5070809@it.uc3m.es> Date: Fri, 04 Dec 2009 15:34:06 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4B163713.8070001@it.uc3m.es> <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> In-Reply-To: <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:34:18 -0000 Lars Eggert escribió: > Hi, > > a few minor comments: > > On 2009-12-1, at 23:44, marcelo bagnulo braun wrote: > >> The NAT64 MUST handle fragments arriving out-of-order conditioned >> to the following: >> >> The NAT64 MUST limit the amount of resources devoted to the >> storage of fragmented packets in order to prevent from DoS >> attack. >> > > I'd add an "under overload conditions" somewhere. While not overloaded, limiting storage doesn't really serve any purpose but lowers reassembly chances. > > not sure about this one, i will wait to see the output of the disucssion with Simon. >> The NAT64 MUST allow the fragments to arrive over a time >> interval. The time interval MUST be configurable and the >> default value MUST be of at least 10 seconds. >> > > Similar to the above comment: a short timeout doesn't really save you anything unless there's an overload condition. But then you'd use something else to shed load. > > well, we state that there at least 10 seconds, so having the nat having a higher timer when it can is allowed. I will wait for the output of the discussion about the overload and see > I'm wondering if we should simply say "use a good sized fixed buffer that doesn't drive you into overload when full, and use an oldest-first (or LFU?) replacement scheme"? > > >> The NAT64 MAY require that the UDP, TCP, or ICMP header be >> completely contained within the first fragment. >> > > The NAT can't really require that. I think what you want to say is that NATs MAY drop fragment chains where the header is split over multiple fragments. > > Right, i will change it to this. Regards, marcelo > Lars From marcelo@it.uc3m.es Fri Dec 4 06:37:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B8A3A6A1F for ; Fri, 4 Dec 2009 06:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA0BKgcI+hyQ for ; Fri, 4 Dec 2009 06:37:39 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 4B2FB3A6922 for ; Fri, 4 Dec 2009 06:37:38 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 10683BA8906; Fri, 4 Dec 2009 15:37:29 +0100 (CET) Message-ID: <4B191EA9.80208@it.uc3m.es> Date: Fri, 04 Dec 2009 15:37:29 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Tsirtsis References: <4B163713.8070001@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:37:40 -0000 George Tsirtsis escribió: > First of all I agree with comments already stated WRT: > > 1) 10sec interval or any min value cannot be mandated since the > primary purpose of this advice seems to be to protect NAT64 from > fragmentation attacks, which means that the NAT64 implementation > should be free to drop fragments if it feels threatened. > Right, this has been captured by stating that if the nat64 has the resoruces, then it does this... > 2) the requirement (even as a MAY) for the full header to be in the > first fragment seems unreasonable. Lars's suggestion on this reads > better. > > done > Also, I brought up the following in my detailed review. > > Is it not also an option for the NAT64 to reassemble the incoming > packet before translating it? Two options are mentioned in the draft > already: > - "queue fragments and translate all fragments together"...presumably > fragments are still translated and transmitted one by one > - "translate each fragment as it comes"....presumably by maintaining > appropriate state from the full header > > The state that has to be maintained for either of the above, and > especially if the NAT64 decides to deal with the case of the full > header arriving out of order, seems to be very similar to the state > required for packet reassembly. > > This, combined, with the fact that the IPv4 and IPv6 sides of the > NAT64 might have different MTUs anyway, possibly requiring further > fragmentation after translation, reassembling before translation seems > like a reasonable option. > > Has this been discussed before? > > yes, and it seems it will be discussed in the next interim meeting. So far, i heard that this should be open for the implementers to do what they preffer and that is what is captured in the draft. Regards, marcelo > George > > > On Wed, Dec 2, 2009 at 9:44 AM, marcelo bagnulo braun > wrote: > >> So, based on the comments from Dan, Iljitshc and Reinaldo, I have rewritten >> the text as follows: >> >> If the incoming IP packet contains a fragment, then more processing >> may be needed. This specification leaves open the exact details of >> how a NAT64 handles incoming IP packets containing fragments, and >> simply requires that the external behavior of the NAT64 is compliant >> with the following conditions: >> >> The NAT64 MUST handle fragments arriving out-of-order conditioned >> to the following: >> >> The NAT64 MUST limit the amount of resources devoted to the >> storage of fragmented packets in order to prevent from DoS >> attack. >> >> The NAT64 MUST allow the fragments to arrive over a time >> interval. The time interval MUST be configurable and the >> default value MUST be of at least 10 seconds. >> >> The NAT64 MAY require that the UDP, TCP, or ICMP header be >> completely contained within the first fragment. >> >> A NAT64 MAY elect to queue the fragments as they arrive and >> translate all fragments at the same time. Alternatively, a NAT64 >> MAY translate the fragments as they arrive, by storing information >> that allows it to compute the 5-tuple for fragments other than the >> first. In the latter case, the NAT64 will still need to handle >> the situation where subsequent fragments arrive before the first. >> >> Implementers of NAT64 should be aware that there are a number of >> well-known attacks against IP fragmentation; see [RFC1858] and >> [RFC3128]. Implementers should also be aware of additional issues >> with reassembling packets at high rates, described in [RFC4963] >> >> >> >> >> The basic idea is that the NAT64 must handle fragments as long as the >> conditions hold. does that makes sense? Or should i change if for a SHOULD >> and qualify it with the conditions? >> >> About the timer, i have required it to be configurable, still not convinced >> we shoudl propose a lower defualt value with the existent qualifications of >> the must. >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From simon.perreault@viagenie.ca Fri Dec 4 06:54:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8AB3A6767 for ; Fri, 4 Dec 2009 06:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf7t5toRlVv5 for ; Fri, 4 Dec 2009 06:54:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 839673A692B for ; Fri, 4 Dec 2009 06:54:34 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 9B8452151B; Fri, 4 Dec 2009 09:54:25 -0500 (EST) Message-ID: <4B1922A1.9080007@viagenie.ca> Date: Fri, 04 Dec 2009 09:54:25 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: draft-ietf-behave-v6v4-xlate@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: [BEHAVE] Handling of fragmented UDP packets with zero checksum X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:54:35 -0000 Hello, In draft-ietf-behave-v6v4-xlate-04, section 2.2, we have the following: When a stateful translator receives fragmented UDP IPv4 packets and the checksum field is zero, if the translator has enough resource to reassemble the packets, the stateful translator SHOULD reassemble the packets and SHOULD calculate the checksum. Otherwise, the stateful translator MAY drop the packets. - Any reason the second SHOULD in the second paragrah ("SHOULD calculate the checksum") isn't a MUST? - In the second paragraph, doesn't the first SHOULD ("SHOULD reassemble") conflicts with the MAY ("MAY drop")? Suggestion: Change to the following: When a stateful translator receives fragmented UDP IPv4 packets and the checksum field is zero, if the translator has enough resource to reassemble the packets, the stateful translator SHOULD reassemble the packets. In that case, it MUST calculate the checksum. Otherwise, the stateful translator MUST drop the packets. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Fri Dec 4 08:41:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB60D3A6848 for ; Fri, 4 Dec 2009 08:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-klEJIwsbou for ; Fri, 4 Dec 2009 08:41:34 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6F6633A680D for ; Fri, 4 Dec 2009 08:41:34 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGvKGEurRN+J/2dsb2JhbACKJrVslzGEMwSBZw X-IronPort-AV: E=Sophos;i="4.47,342,1257120000"; d="scan'208";a="57818181" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2009 16:41:25 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB4GfPjA028162; Fri, 4 Dec 2009 16:41:25 GMT From: "Dan Wing" To: Date: Fri, 4 Dec 2009 08:41:25 -0800 Message-ID: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp1AJ6W8ogipIRqQuCO52ETA2TukA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:41:35 -0000 As a reminder, we have an interim WebEx teleconference on Wednesday, December 16, at 7am Pacific Time. The December 16 teleconference will resolve all open issues with the following documents so they may be immediately WGLC'd (dates are Behave's milestone dates from our charter): Dec 2009 - Submit to IESG: framework for IPv6/IPv4 translation (info) http://tools.ietf.org/html/draft-ietf-behave-address-format Dec 2009 - Submit to IESG: stateless IPv6/IPv4 translation (std) http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate Dec 2009 - Submit to IESG: stateful IPv6/IPv4 translation (std) http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) http://tools.ietf.org/html/draft-ietf-behave-dns64 Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) http://tools.ietf.org/html/draft-ietf-behave-address-format Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) http://tools.ietf.org/id/draft-ietf-behave-ftp64 (currently http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06) REVIEWERS ARE NEEDED! Please volunteer to review one, two, or all documents. WGLC is expected to start on December 17 and end December 31. To finish WGLC, we need 5 reviews indicating the document is ready. One person has volunteered so far (thanks, Flemming). If you are willing to review, please send information to Dan. Agenda for the interim is at: http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart If you have additional agenda items, which we should discuss to prepare those documents for WGLC, please email the chairs. -d From dwing@cisco.com Fri Dec 4 09:38:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC133A6955 for ; Fri, 4 Dec 2009 09:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdiX9hpckRdU for ; Fri, 4 Dec 2009 09:38:07 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3B7653A676A for ; Fri, 4 Dec 2009 09:38:07 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEvMGEurRN+K/2dsb2JhbACKJrV/ly+EMwSBZw X-IronPort-AV: E=Sophos;i="4.47,343,1257120000"; d="scan'208";a="114193250" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2009 17:37:58 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB4HbwYI012831; Fri, 4 Dec 2009 17:37:58 GMT From: "Dan Wing" To: Date: Fri, 4 Dec 2009 09:37:58 -0800 Message-ID: <03bd01ca7508$84fe58d0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp1CITAy3J0950uTtWLf7rPL0nICg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-turn-uri@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-turn-uri-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:38:08 -0000 Announcing a second WGLC on draft-ietf-behave-turn-uri-05, which finishes on Friday, December 11. Based on feedback received during IETF last call, draft-ietf-behave-turn-uri no longer defines a URI; rather, it only defines a resolution mechanism to assist with configuring a TURN client. Side by side differences: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-turn-uri-05.txt Red-line differences: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-behave-turn-ur i-05.txt Document: http://tools.ietf.org/html/draft-ietf-behave-turn-uri-05 Please send your comments / feedback to the list or the author by Friday, December 11. Thanks, -d From lars.eggert@nokia.com Fri Dec 4 14:31:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561503A6359 for ; Fri, 4 Dec 2009 14:31:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQoU+mVPZDh9 for ; Fri, 4 Dec 2009 14:31:26 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 37CFC3A6862 for ; Fri, 4 Dec 2009 14:31:26 -0800 (PST) Received: from [192.168.60.198] (64-129-14-254.static.twtelecom.net [64.129.14.254] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nB4MV5rH032415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 5 Dec 2009 00:31:08 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-30-338302016; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B18FF6B.1010103@viagenie.ca> Date: Fri, 4 Dec 2009 12:30:59 -1000 Message-Id: References: <4B163713.8070001@it.uc3m.es> <8BE2E7C0-1A26-4DC7-9D6D-AA9AAEC68778@nokia.com> <4B18FF6B.1010103@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Sat, 05 Dec 2009 00:31:10 +0200 (EET) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:31:27 -0000 --Apple-Mail-30-338302016 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2009-12-4, at 2:24, Simon Perreault wrote: > Lars Eggert wrote, on 2009-12-03 21:38: >>> The NAT64 MUST limit the amount of resources devoted to the >>> storage of fragmented packets in order to prevent from DoS >>> attack. >>=20 >> I'd add an "under overload conditions" somewhere. While not = overloaded, limiting storage doesn't really serve any purpose but lowers = reassembly chances. >=20 > =46rom an implementor's point of view, this is too fuzzy. What exactly = are > "overload conditions"? What behavior would be different from just a = hard > threshold? Do you mean "put the threshold as high as you can without = causing > overload"? well, overload is an implementation-specific event. If you want a = definition, I'd say "a state in which fragmentation handling is = negatively impacting overall performance and operation." >> I'm wondering if we should simply say "use a good sized fixed buffer = that doesn't drive you into overload when full, and use an oldest-first = (or LFU?) replacement scheme"? >=20 > No. That's crossing into the implementor's land. Only specify > externally-observable behavior. I fail to see how a 10-second timeout is any different. Lars= --Apple-Mail-30-338302016 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIwNDIyMzA2MFowIwYJKoZIhvcNAQkEMRYEFHCyeM+dbRQPWHJMHYlPathmk3k8MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAU//Rp/E5z8UssMKmSpCM200053sv7kfBqEA/flEP7YTGal2ykWDs9XR1Wu7U3JHIKk9gA DJXJYizwzB3VXhxRHKEOgaiqx8eVzTNYPE3o1eqzHSvOLG4TpghNYD4HCNr/O7p4/3Or45bn41qH z+tGmI3Q+2r/uovD8Be4lj9YipU/Lg2+M52FX5gTEcoKmIZaJOWiDTgPFab5TCxSv0sIc3TR+B8F J5tFWW8P4/s5l0pokVBzy9rB6pAFroXV2jFyPch9S5O49kroA1y+jQC16bGXbNrERZVBEwkSyavo ntTR6+pnQueUfPyd6jRSK4B8hB3rVff/QTTrQynhzOGwAAAAAAAA --Apple-Mail-30-338302016-- From dthaler@microsoft.com Fri Dec 4 16:16:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5893A6A6F for ; Fri, 4 Dec 2009 16:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyiOlHyY232n for ; Fri, 4 Dec 2009 16:16:15 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B6E2C3A6867 for ; Fri, 4 Dec 2009 16:16:15 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Dec 2009 16:16:34 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Fri, 4 Dec 2009 16:16:06 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 4 Dec 2009 16:16:00 -0800 From: Dave Thaler To: marcelo bagnulo braun Thread-Topic: [BEHAVE] handling packet with fragments, second try Thread-Index: AQHKczQx0kk98B7SHUOhMFGdHK/yv5FT4TaggAGbP4CAABzMgA== Date: Sat, 5 Dec 2009 00:16:00 +0000 Message-ID: References: <4B163713.8070001@it.uc3m.es> <4B191D1B.2050301@it.uc3m.es> In-Reply-To: <4B191D1B.2050301@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 00:16:16 -0000 [...] > >> The NAT64 MUST allow the fragments to arrive over a time > >> interval. The time interval MUST be configurable and the > >> default value MUST be of at least 10 seconds. > >> > > > > Not sure how this MUST interacts with the previous paragraph. > > If you're under attack it may not be feasible to allow fragments > > to arrive over a 10 second period, since doing so may exhaust all > > memory. Clarify. > > > Right, what about: >=20 > As long as the NAT64 has available resources, the NAT64 MUST allow the > fragments to arrive over a time interval. Ok. > > > >> The NAT64 MAY require that the UDP, TCP, or ICMP header be > >> completely contained within the first fragment. > >> > > > > Presumably "first" means the first to arrive, as opposed to first in > > byte order, yes? >=20 > No, it means the first packet in byte order. (so yes, it needs > clarification) >=20 > So, i will add: >=20 > The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the first fragment (first fragment > meaning the fragment that contains OFFSET equal to zero). Ok that answers the rest of my comments. (So rest of discussion on this omitted) However I'd suggest wordsmithing for brevity: > The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the fragment that contains=20 > OFFSET equal to zero. [...] > I hope with the clarification i made, there is no longer a > contradiction Right. -Dave From rpenno@juniper.net Sat Dec 5 00:34:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA923A681F for ; Sat, 5 Dec 2009 00:34:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVwod37nP9N6 for ; Sat, 5 Dec 2009 00:34:00 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 4363A3A6774 for ; Sat, 5 Dec 2009 00:33:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSxoa5uEsM0mj/jj5T6rI65SH2RhuVMdB@postini.com; Sat, 05 Dec 2009 00:33:51 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 5 Dec 2009 00:27:38 -0800 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; Sat, 5 Dec 2009 03:27:38 -0500 From: Reinaldo Penno To: Simon Perreault Date: Sat, 5 Dec 2009 03:27:33 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: Acp0ZAZpBaJ+ST6SRVG/t5m2buoIgwBIMREP Message-ID: In-Reply-To: <4B1834F8.3020903@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Xu, Cameron Byrne , "behave@ietf.org" , Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 08:34:01 -0000 A few comments inline... On 12/3/09 2:00 PM, "Simon Perreault" wrote: >=20 >> I re-read a _single_ section of NAT64 (3.2.4. ICMP Query Session Handli= ng). >> I found that developers have the following choices (and this does not go >> into implementation details): >>=20 >> * Local Security Policy can drop ICMPv6 packets (yes/no) >> * Local Security Policy can drop ICMPv6 packets configurable per >> interface/rule/etc (yes/no for each one)> * ICMPv4 message will be sen= t >> back to sender (yes/no/configurable) >> * ICMPv4 message will be sent back to sender per configuration >> interface/nat rule/etc (yes/no each one) >> * ICMPv4 message will be sent back to sender in case of filtering >> (yes/no/configurable) >> * ICMPv4 message will be sent back to sender per configuration >> (interface/rule/etc) >=20 > These do not affect state. Why not? If a certain mapping on NAT64-A does not send ICMPv4 packets back for unsolicited sessions and another mapping does, this behavior must remai= n the same on the fail-over box. NAT state is the mapping state + ICMP behavior (discussed above) + filterin= g behavior + timer settings (discussed below for ICMP) + log behavior (yes/no/format) + others not discussed. Each of these can be different for different NAT entries. >=20 >> * ICMPv6 lifetime can be configurable (yes/no) >> * ICMPv6 lifetime can be configurable within a certain range (yes/no) >> * ICMPv6 lifetime can be configurable with a granularity of ms/seconds/e= tc >> (yes/no) >> * ICMPv4 lifetime can be configurable (yes/no) >> * ICMPv4 lifetime can be configurable within a certain range (yes/no) >> * ICMPv4 lifetime can be configurable with a granularity of ms/seconds/e= tc >> (yes/no) >=20 >=20 >=20 >> Can you elaborate on which tests need to be done in order to guarantee t= hat >> this scenario will work between two different vendors? >=20 > So you mean that because vendor A and vendor B will not swear that each > other's This=20 > statement > has nothing to do with NATs and applies in many other cases you know... >=20 Some people made the opposite case and it brings to some of the basics. NAT operational complexity is high and therefore brings special requirements to the table. Based on your statement it seems you think there are similar cases.=20 Can you give an example that has the same characteristics as hot-standby fo= r NATs based on the few things that were discussed? If there are we should look into how hot-standy across different devices & vendors was achieved in that case. >> Finally, If you pin down all specific behavior you need within all possi= ble >> permutations of different vendors, weigh the operational cost of a >> multi-dimensional testing to find two boxes that can provide the High >> Availability with the NAT behavior you need, I think you will find out t= hat >> NAT64-A and NAT64-B are made by the same vendor. >=20 > That could very well be true. It is also often the case for e.g. BGP spea= kers. > But some people like to run stuff from multiple vendors. And it works, an= d it > has advantages and disadvantages. Tradeoffs, etc. >=20 > Thanks, > Simon From simon.perreault@viagenie.ca Sat Dec 5 03:50:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C4C3A6855 for ; Sat, 5 Dec 2009 03:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pia+MTHJIbv for ; Sat, 5 Dec 2009 03:50:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F2D3C3A659C for ; Sat, 5 Dec 2009 03:50:45 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94C7921106; Sat, 5 Dec 2009 06:50:36 -0500 (EST) Message-ID: <4B1A490C.7090104@viagenie.ca> Date: Sat, 05 Dec 2009 06:50:36 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 11:50:47 -0000 On 12/05/2009 03:27 AM, Reinaldo Penno wrote: > If a certain mapping on NAT64-A does not send ICMPv4 packets back > for unsolicited sessions and another mapping does, this behavior must remain > the same on the fail-over box. This is arguable. IMHO, this behaviour could be different without negative impact in many situations. But the point is that the state sync protocol is completely unconcerned with this. > NAT state is the mapping state + ICMP behavior (discussed above) + filtering > behavior + timer settings (discussed below for ICMP) + log behavior > (yes/no/format) + others not discussed. Each of these can be different for > different NAT entries. We have different definitions of state it seems. ICMP behaviour, filtering behaviour, timer settings, log behaviour, and others do not vary over time. (Or we could impose the constraint that the state sync connection be renegotiated when they do vary.) The state sync protocol is only concerned with stuff that varies over time, i.e. bindings and sessions. That's it. > Some people made the opposite case and it brings to some of the basics. NAT > operational complexity is high and therefore brings special requirements to > the table. Based on your statement it seems you think there are similar > cases. "NAT operational complexity is high" is a blanket statement. For example, nowadays most everyone has a NAT at home without even knowing it. > Can you give an example that has the same characteristics as hot-standby for > NATs based on the few things that were discussed? If there are we should > look into how hot-standy across different devices& vendors was achieved in > that case. I don't know. But are you saying we shouldn't do something because nobody has done it before? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xing@cernet.edu.cn Sun Dec 6 01:52:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D8A3A6908 for ; Sun, 6 Dec 2009 01:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.119 X-Spam-Level: X-Spam-Status: No, score=0.119 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUrOYZWw5qlw for ; Sun, 6 Dec 2009 01:52:05 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id B3DBE3A681F for ; Sun, 6 Dec 2009 01:52:01 -0800 (PST) Received: from [192.168.1.100]([123.112.81.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b1b8e52; Sun, 06 Dec 2009 17:51:31 +0800 Message-ID: <4B1B7E9A.2050506@cernet.edu.cn> Date: Sun, 06 Dec 2009 17:51:22 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' , Behave Chairs Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: lOHmNRXB Subject: [BEHAVE] address-format: variable-length prefix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 09:52:05 -0000 Hi, All, In the draft-ietf-behave-address-format-01.txt, we defined variable length approach of the address format. The reasons are: (1) Different networks may have different length (/32, /48, /56, /64, etc) of the network-specific prefix. (2) The trade-offs for the routing efficiency, security and IPv6 address consumption should be considered. (3) The prefix lengths which across octet boundaries are not allowed. The question asked to the audience in the behave meeting are: "Should we recommend a default address format? Should it be let to the SPs to decide? Do we allow other prefix lengths?" There is no objections and questions, so we will keep the current recommendations. Choice of Prefix for Stateless Translation Deployments o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 prefix for an ISP holding a /32 allocation, and a /56 prefix for a site holding a /48 allocation. o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 (an IPv4 network to an IPv6 network), we recommend using a /64 prefix. Choice of Prefix for Stateful Translation Deployments o For the WKP, the consensus is /96. Please confirm. Regards, xing From xing@cernet.edu.cn Sun Dec 6 01:57:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AA23A681F for ; Sun, 6 Dec 2009 01:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_20=-0.74, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPq8NyEmngGD for ; Sun, 6 Dec 2009 01:57:08 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 082393A6403 for ; Sun, 6 Dec 2009 01:57:06 -0800 (PST) Received: from [192.168.1.100]([123.112.81.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4b1b8f88; Sun, 06 Dec 2009 17:56:41 +0800 Message-ID: <4B1B7FDF.4050503@cernet.edu.cn> Date: Sun, 06 Dec 2009 17:56:47 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' , Behave Chairs Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: l6HrNRXB Subject: [BEHAVE] address-format: checksum-neutral prefix/suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 09:57:08 -0000 Hi, All, In the draft-ietf-behave-address-format-01.txt, it reads: we picked the simplest alternative, to not specify neutrality checksum. The reasons are: (1) The neutrality checksum alone does eliminate checksums computation during stateful translation, as only one of the two addresses would be checksum neutral. (2) For the stateless translation, the checksum-neutral translation allows non-TCP/UDP/ICMP protocols which use 1's complement checksums without protocol awareness added to the translator. (3) The checksum-neutral translation makes the handling of the fragmented packets easier. (4) However, the stateless translators may want to recomputed the checksum anyhow, to verify the validity of the translated datagrams. Please confirm if we should keep the current conclusion. Regards, xing From xing@cernet.edu.cn Sun Dec 6 01:59:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636533A67AE for ; Sun, 6 Dec 2009 01:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkmaVI9Z+b6B for ; Sun, 6 Dec 2009 01:59:25 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 92F9F3A6403 for ; Sun, 6 Dec 2009 01:59:23 -0800 (PST) Received: from [192.168.1.100]([123.112.81.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm174b1b900e; Sun, 06 Dec 2009 17:58:55 +0800 Message-ID: <4B1B8065.3040203@cernet.edu.cn> Date: Sun, 06 Dec 2009 17:59:01 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' , Behave Chairs Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: lmRtNRXB Subject: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 09:59:26 -0000 Hi, All, In the draft-ietf-behave-address-format-01.txt, the document reads: When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt Please confirm if we should keep the current conclusion. Regards, xing From maxpassion@gmail.com Sun Dec 6 04:19:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BFD3A67D3 for ; Sun, 6 Dec 2009 04:19:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vXcJ1Ql0o9b for ; Sun, 6 Dec 2009 04:19:25 -0800 (PST) Received: from mail-px0-f180.google.com (mail-px0-f180.google.com [209.85.216.180]) by core3.amsl.com (Postfix) with ESMTP id B95C43A679C for ; Sun, 6 Dec 2009 04:19:25 -0800 (PST) Received: by pxi10 with SMTP id 10so1156609pxi.31 for ; Sun, 06 Dec 2009 04:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JhiXuSxLPhhoEnaKkB9ot7FwRDSWBBmE0a61bFfgqK8=; b=v25F7RqVspMwEb10CaeplqHJhUs9ovfqKmnGINbtUOhL3sn0PiZRN/TKvanvPeV86B JPzuL3qbe1oR4nveUHRAZBzOAPykMsTKRoFpwUGqRsdS2yDydkbwgBZT7hvmnh5zluuP dRGOHgbTznLuAH/to6SSv007hPBP3yuROLJgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gw2wUtp/68ozNnXm4zHRZFMzUjePmwR1RAuX86WkvFahY6CSJiZvCnCnx+HGRqET39 lUBOXj33GZg4b5tqJe5g8uTUwacj0FcopYHPHNk1PmpI6qDklzm4EQ5GITmcT7270Kok RBvrgZukRZb6ifQlYHkHwEVk9wKAhClT+UUy0= MIME-Version: 1.0 Received: by 10.142.151.14 with SMTP id y14mr549563wfd.125.1260101952219; Sun, 06 Dec 2009 04:19:12 -0800 (PST) In-Reply-To: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> Date: Sun, 6 Dec 2009 20:19:12 +0800 Message-ID: <25e1aaa40912060419v7d971335g4ce790aef065b675@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 12:19:27 -0000 Hi Dan, I would like volunteer to review FTP ALG for IPv6/IPv4 translation document if it is possible. Best regards, Dapeng Liu 2009/12/5, Dan Wing : > As a reminder, we have an interim WebEx teleconference on Wednesday, > December > 16, at 7am Pacific Time. The December 16 teleconference will resolve all > open > issues with the following documents so they may be immediately WGLC'd (dates > are Behave's milestone dates from our charter): > > Dec 2009 - Submit to IESG: framework for IPv6/IPv4 translation (info) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Dec 2009 - Submit to IESG: stateless IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > Dec 2009 - Submit to IESG: stateful IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-dns64 > Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > http://tools.ietf.org/id/draft-ietf-behave-ftp64 > (currently http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06) > > REVIEWERS ARE NEEDED! Please volunteer to review one, two, or all > documents. > WGLC is expected to start on December 17 and end December 31. To finish > WGLC, > we need 5 reviews indicating the document is ready. One person has > volunteered so far (thanks, Flemming). If you are willing to review, please > send information to Dan. > > Agenda for the interim is at: > http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart > > If you have additional agenda items, which we should discuss to prepare > those > documents for WGLC, please email the chairs. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Sun Dec 6 05:40:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214883A67FB for ; Sun, 6 Dec 2009 05:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4mH0qqhs4S4 for ; Sun, 6 Dec 2009 05:40:22 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 3628A3A67E3 for ; Sun, 6 Dec 2009 05:40:20 -0800 (PST) Received: from [192.168.1.100]([125.34.42.148]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jma4b1bc3e6; Sun, 06 Dec 2009 21:40:07 +0800 Message-ID: <4B1BB437.4010009@cernet.edu.cn> Date: Sun, 06 Dec 2009 21:40:07 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4B1592E7.2030104@viagenie.ca> In-Reply-To: <4B1592E7.2030104@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: l2VVRRXB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, Xing Li , behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 13:40:23 -0000 Simon Perreault 写é“: > Hello again, > > In section 3.2 we have the following: > > Parameter Problem (Type 4) If the Code is 1, translate this to an > ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set > the Type to 12 and the Code to zero. The Pointer needs to be > updated to point to the corresponding field in the translated > inner IP header. > > Question: How is that pointer updating performed? Do I have to establish > correspondences between IPv6 and IPv4 fields? If so, shouldn't this be in the text? > Pointer is used to Identify the octet offset within the invoking packet where the error was detected. Due to the different format of the Parameter Problem Message between IPv6 and IPv4, the octet offset needs to be changed in order to point to the same position of the error. Regards, xing > Thanks, > Simon > From dwing@cisco.com Sun Dec 6 06:24:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDC23A6853 for ; Sun, 6 Dec 2009 06:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2sIksXLinbS for ; Sun, 6 Dec 2009 06:24:08 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1F2A23A6827 for ; Sun, 6 Dec 2009 06:24:08 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAE5NG0urRN+J/2dsb2JhbACIfoEWtFKWB4QzBIFn X-IronPort-AV: E=Sophos;i="4.47,350,1257120000"; d="scan'208";a="445693490" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2009 14:23:58 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB6ENwe0000447; Sun, 6 Dec 2009 14:23:58 GMT From: "Dan Wing" To: "'liu dapeng'" References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> <25e1aaa40912060419v7d971335g4ce790aef065b675@mail.gmail.com> Date: Sun, 6 Dec 2009 06:23:53 -0800 Message-ID: <06d501ca767f$bd0a3f50$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp2blGKd3B1n/meT1is1uQ1pYvEUAAENp/A In-Reply-To: <25e1aaa40912060419v7d971335g4ce790aef065b675@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 14:24:09 -0000 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com] > Sent: Sunday, December 06, 2009 4:19 AM > To: Dan Wing > Cc: behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim > meeting, Dec 16 > > Hi Dan, > > I would like volunteer to review FTP ALG for IPv6/IPv4 translation > document if it is possible. I added you to http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart#wglc -d > Best regards, > Dapeng Liu > 2009/12/5, Dan Wing : > > As a reminder, we have an interim WebEx teleconference on Wednesday, > > December > > 16, at 7am Pacific Time. The December 16 teleconference > will resolve all > > open > > issues with the following documents so they may be > immediately WGLC'd (dates > > are Behave's milestone dates from our charter): > > > > Dec 2009 - Submit to IESG: framework for IPv6/IPv4 > translation (info) > > http://tools.ietf.org/html/draft-ietf-behave-address-format > > Dec 2009 - Submit to IESG: stateless IPv6/IPv4 translation (std) > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > > Dec 2009 - Submit to IESG: stateful IPv6/IPv4 translation (std) > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > > Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 > translation (std) > > http://tools.ietf.org/html/draft-ietf-behave-dns64 > > Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 > translator (std) > > http://tools.ietf.org/html/draft-ietf-behave-address-format > > Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std) > > http://tools.ietf.org/id/draft-ietf-behave-ftp64 > > (currently > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06) > > > > REVIEWERS ARE NEEDED! Please volunteer to review one, two, or all > > documents. > > WGLC is expected to start on December 17 and end December > 31. To finish > > WGLC, > > we need 5 reviews indicating the document is ready. One person has > > volunteered so far (thanks, Flemming). If you are willing > to review, please > > send information to Dan. > > > > Agenda for the interim is at: > > http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart > > > > If you have additional agenda items, which we should > discuss to prepare > > those > > documents for WGLC, please email the chairs. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From simon.perreault@viagenie.ca Sun Dec 6 07:21:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607673A683E for ; Sun, 6 Dec 2009 07:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDDYrvamxPqn for ; Sun, 6 Dec 2009 07:21:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 467F83A6889 for ; Sun, 6 Dec 2009 07:21:33 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 71FF420E03; Sun, 6 Dec 2009 10:21:23 -0500 (EST) Message-ID: <4B1BCBF2.1090407@viagenie.ca> Date: Sun, 06 Dec 2009 10:21:22 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Xing Li References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> In-Reply-To: <4B1BB437.4010009@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 15:21:34 -0000 On 12/06/2009 08:40 AM, Xing Li wrote: >> Parameter Problem (Type 4) If the Code is 1, translate this to an >> ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set >> the Type to 12 and the Code to zero. The Pointer needs to be >> updated to point to the corresponding field in the translated >> inner IP header. >> >> Question: How is that pointer updating performed? Do I have to establish >> correspondences between IPv6 and IPv4 fields? If so, shouldn't this be >> in the text? > > Pointer is used to Identify the octet offset within the invoking packet > where the error was detected. Due to the different format of the > Parameter Problem Message > between IPv6 and IPv4, the octet offset needs to be changed in order to > point to the same position of the error. Yes but the pointer points inside an IPv6 header before translation, and it points inside an IPv4 header after translation. There is more to it than just updating the offset. It's a completely different header and the fields don't have 1:1 mapping. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From huitema@microsoft.com Sun Dec 6 10:21:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9D83A68C3 for ; Sun, 6 Dec 2009 10:21:22 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpSbPn0Qv7MV for ; Sun, 6 Dec 2009 10:21:21 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D42983A68FB for ; Sun, 6 Dec 2009 10:21:21 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 6 Dec 2009 10:21:36 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Sun, 6 Dec 2009 10:21:12 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 6 Dec 2009 10:21:12 -0800 From: Christian Huitema To: Xing Li , 'Behave WG' , Behave Chairs Thread-Topic: [BEHAVE] address-format: variable-length prefix, consensus check Thread-Index: AQHKdlnKmtAvjsZC8kmdi2uMvoSYYZFYUuaQ Date: Sun, 6 Dec 2009 18:21:08 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F2E0D@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1B7E9A.2050506@cernet.edu.cn> In-Reply-To: <4B1B7E9A.2050506@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: variable-length prefix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:21:22 -0000 There is just one point that I wonder, the usefulness of the current /64 de= finition, compared to /96. Specifically, when mapping isolated networks, I = may be tempted to recommend /96, or at least consider it. That would mean: - for stateless deployments, adding a discussion item: We propose here a compromise, based on using no more than 1/256th of an organization's allocation of IPv6 addresses for the IPv4/IPv6 translation service. For example, if the organization is an ISP, with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. An end site with a /48 allocation could dedicate a /56 prefix to the translation service, or possibly a /96 prefix if all IPv4 Translatable IPv4 Addresses are located on the same link. - for stateless deployment recommendations, adding an option: o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 (an IPv4 network to an IPv6 network), we recommend using a /64 or /96 prefix. - for stateful deployments, adding an option: o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to an IPv4 network), as this would lead to using the Well-Known Prefix with non global IPv4 addresses. That means a Network Specific Prefix MUST be used in that scenario, for example a /96 prefix compatible with the Well Known prefix=20 format. -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Xing Li Sent: Sunday, December 06, 2009 1:51 AM To: 'Behave WG'; Behave Chairs Subject: [BEHAVE] address-format: variable-length prefix, consensus check Hi, All, In the draft-ietf-behave-address-format-01.txt, we defined variable length approach of the address format. The reasons are: (1) Different networks may have different length (/32, /48, /56, /64, etc) of the network-specific prefix. (2) The trade-offs for the routing efficiency, security and IPv6 address consumption should be considered. (3) The prefix lengths which across octet boundaries are not allowed. The question asked to the audience in the behave meeting are: "Should we recommend a default address format? Should it be let to the SPs to decide? Do we allow other prefix lengths?" There is no objections and questions, so we will keep the current recommendations. Choice of Prefix for Stateless Translation Deployments o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 prefix for an ISP holding a /32 allocation, and a /56 prefix for a site holding a /48 allocation. o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 (an IPv4 network to an IPv6 network), we recommend using a /64 prefix. Choice of Prefix for Stateful Translation Deployments o For the WKP, the consensus is /96. Please confirm. Regards, xing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Sun Dec 6 10:24:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAFD3A68C3 for ; Sun, 6 Dec 2009 10:24:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-xUxhzu0kne for ; Sun, 6 Dec 2009 10:24:16 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5DB893A688B for ; Sun, 6 Dec 2009 10:24:16 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 6 Dec 2009 10:24:31 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Sun, 6 Dec 2009 10:24:06 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 6 Dec 2009 10:24:07 -0800 From: Christian Huitema To: Xing Li , 'Behave WG' , Behave Chairs Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdlra5vNbCwCh3EmLNErZhGqem5FYVVAA Date: Sun, 6 Dec 2009 18:24:03 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1B8065.3040203@cernet.edu.cn> In-Reply-To: <4B1B8065.3040203@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:24:17 -0000 I actually changed that text in the rev2 draft. The last text says: When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (This issue does not exist for prefixes larger than 32 bits, such as the /40, /56 and /64 prefixes that we recommend in section 3.3.) -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Xing Li Sent: Sunday, December 06, 2009 1:59 AM To: 'Behave WG'; Behave Chairs Subject: [BEHAVE] address-format: null suffix, consensus check Hi, All, In the draft-ietf-behave-address-format-01.txt, the document reads: When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt Please confirm if we should keep the current conclusion. Regards, xing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Sun Dec 6 12:55:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FA43A69AF for ; Sun, 6 Dec 2009 12:55:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUiOINm1aXZD for ; Sun, 6 Dec 2009 12:55:06 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id C2BEE3A67B0 for ; Sun, 6 Dec 2009 12:55:06 -0800 (PST) Received: by pzk6 with SMTP id 6so3510700pzk.29 for ; Sun, 06 Dec 2009 12:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dJ9RWDZjGsrczkLqRn9ue3NAor3/dTblnOSsYdI6FRo=; b=FmK//PhKyGZOmuuC4BXW1JTcLGG6OYml8PIP2WpBoWEGDUTZZpQydrfo1792XXrDZw 2Se8n1M5KjUQa9thaPpi0okpEmZl6jfKmh6RH7jBCg0oYdKK+qZgOQXaSfUAlQ/DVYJu 00nuQtcANr2bG+QhHKao9Z743UDHz+3FoQm3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=czwjdjhF2kZGGDDMpYCIka5Xvx2LONh74wZ9krw9s59XfKosGrNiZcAcHEUlGiZXtg peLenZijjdvs7sdy9PrZpDpI7LEfZS4myhqXlXH0icN5yI5i3lOYN4ukpDn9u6MJybrG lc/FBO1+2Gm9gywUTm/cz5DvPj7clktx35NDw= Received: by 10.114.6.25 with SMTP id 25mr9763090waf.25.1260132894654; Sun, 06 Dec 2009 12:54:54 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm4565654pzk.13.2009.12.06.12.54.53 (version=SSLv3 cipher=RC4-MD5); Sun, 06 Dec 2009 12:54:54 -0800 (PST) Message-ID: <4B1C1A1C.1060004@gmail.com> Date: Mon, 07 Dec 2009 09:54:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xing Li References: <4B1B7E9A.2050506@cernet.edu.cn> In-Reply-To: <4B1B7E9A.2050506@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' Subject: Re: [BEHAVE] address-format: variable-length prefix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 20:55:07 -0000 On 2009-12-06 22:51, Xing Li wrote: > Hi, All, > > In the draft-ietf-behave-address-format-01.txt, we defined variable > length approach of the address format. The reasons are: ... > Choice of Prefix for Stateful Translation Deployments > o For the WKP, the consensus is /96. No problem with this, but should it be stated somewhere that the u/g bit retains its significance in this case? This isn't 100% clear from the text in section 2. Brian From huitema@microsoft.com Sun Dec 6 13:45:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D633A67F1 for ; Sun, 6 Dec 2009 13:45:53 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cE1GOapKAsy for ; Sun, 6 Dec 2009 13:45:52 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id AB6783A6831 for ; Sun, 6 Dec 2009 13:45:52 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 6 Dec 2009 13:46:08 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Sun, 6 Dec 2009 13:45:42 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 6 Dec 2009 13:45:23 -0800 From: Christian Huitema To: Brian E Carpenter , Xing Li Thread-Topic: [BEHAVE] address-format: variable-length prefix, consensus check Thread-Index: AQHKdlnKmtAvjsZC8kmdi2uMvoSYYZFZBh8A//+GMDA= Date: Sun, 6 Dec 2009 21:45:17 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F2EBC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1B7E9A.2050506@cernet.edu.cn> <4B1C1A1C.1060004@gmail.com> In-Reply-To: <4B1C1A1C.1060004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Behave WG' Subject: Re: [BEHAVE] address-format: variable-length prefix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 21:45:53 -0000 > > Choice of Prefix for Stateful Translation Deployments > > o For the WKP, the consensus is /96. >=20 > No problem with this, but should it be stated somewhere that > the u/g bit retains its significance in this case? This isn't > 100% clear from the text in section 2. It is actually stated in the draft, section 2: ... When using a 96 prefix, the administrators MUST ensure that the bits 64 to 71 are compatible with the IPv6 addressing architecture. We could add text, e.g. "A simple way to achieve that is to construct the /= 96 prefix by picking a /64 prefix, and then add four octets set to zero." The u/g bits are not technically required if the WKP is picked in the 0::/8= range, since the requirement is only stated for the 2000::/3 range. But le= aving the bits null in the WKP does not hurt. -- Christian Huitema From brian.e.carpenter@gmail.com Sun Dec 6 14:37:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D50128C0EC for ; Sun, 6 Dec 2009 14:37:53 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-PNfg8l8Xl2 for ; Sun, 6 Dec 2009 14:37:52 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id D24B73A6953 for ; Sun, 6 Dec 2009 14:37:52 -0800 (PST) Received: by pwi20 with SMTP id 20so824122pwi.29 for ; Sun, 06 Dec 2009 14:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4n0OB/Nplq2wT625niu8BVtc2yVNUzn5Kzy2KJPEiMw=; b=Hl6b0UiXzedhGo0+7Tih4cx+4cIkuoc4pZvHiwRb1h6SY5C2ldjp+hutWkT21JfZvq mMlZDazATZwhoKjA6zpoIiXv5H9x9X9pkpyXLC6ispkxDjOtaq4rDxHFe64K9uOvYH/3 88xJ1XUgwh6hRdxuU2vo85ZXEHIvJLX3eFS4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=a7lesJ8ge0ZwUzKh4B2cXh901FJwFnvQMX3d8qrv9bUSYW+FSH5LQdsKMRQ5VN91vz OjIlG7uNWrF6cGcWj2niBLxGfklj2mlXbQhQ8djV1vTkPJUSfhEpJl2G11SRiXPEsBGM Fgb8NM7GiuEBROT6oIJrgYE+1grJMUdHmnhLM= Received: by 10.115.100.4 with SMTP id c4mr10027660wam.13.1260139060978; Sun, 06 Dec 2009 14:37:40 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm4640107pzk.6.2009.12.06.14.37.39 (version=SSLv3 cipher=RC4-MD5); Sun, 06 Dec 2009 14:37:40 -0800 (PST) Message-ID: <4B1C3232.7040808@gmail.com> Date: Mon, 07 Dec 2009 11:37:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Huitema References: <4B1B7E9A.2050506@cernet.edu.cn> <4B1C1A1C.1060004@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211F2EBC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F2EBC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , Xing Li Subject: Re: [BEHAVE] address-format: variable-length prefix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 22:37:53 -0000 On 2009-12-07 10:45, Christian Huitema wrote: >>> Choice of Prefix for Stateful Translation Deployments >>> o For the WKP, the consensus is /96. >> No problem with this, but should it be stated somewhere that >> the u/g bit retains its significance in this case? This isn't >> 100% clear from the text in section 2. > > It is actually stated in the draft, section 2: > > ... When using a 96 prefix, the administrators > MUST ensure that the bits 64 to 71 are compatible with the IPv6 > addressing architecture. Ah, OK, thanks. > > We could add text, e.g. "A simple way to achieve that is to construct the /96 prefix by picking a /64 prefix, and then add four octets set to zero." Sure. > The u/g bits are not technically required if the WKP is picked in the 0::/8 range, since the requirement is only stated for the 2000::/3 range. But leaving the bits null in the WKP does not hurt. Correct, that is still a little vague in the IANA Considerations of version 01. Maybe it is time to tighten up the language there? Brian From xing@cernet.edu.cn Sun Dec 6 15:34:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9157D3A695A for ; Sun, 6 Dec 2009 15:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOPLWFXkGMYY for ; Sun, 6 Dec 2009 15:34:02 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 3EDFF3A689F for ; Sun, 6 Dec 2009 15:34:01 -0800 (PST) Received: from [192.168.1.100]([125.34.43.147]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4b1c816d; Mon, 07 Dec 2009 07:33:39 +0800 Message-ID: <4B1C3F46.3040808@cernet.edu.cn> Date: Mon, 07 Dec 2009 07:33:26 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christian Huitema References: <4B1B8065.3040203@cernet.edu.cn> <6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: wmjb0RXB Cc: 'Behave WG' , Behave Chairs Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 23:34:03 -0000 Christian Huitema 写é“: > I actually changed that text in the rev2 draft. The last text says: > > When a /32 prefix is used, an all-zero suffix results in an all-zero > interface identifier. We understand the conflict with Section 2.6.1 > of RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (This issue does not exist for prefixes larger > than 32 bits, such as the /40, /56 and /64 prefixes that we recommend > in section 3.3.) > Agree. Thanks. xing > > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Xing Li > Sent: Sunday, December 06, 2009 1:59 AM > To: 'Behave WG'; Behave Chairs > Subject: [BEHAVE] address-format: null suffix, consensus check > > Hi, All, > > In the draft-ietf-behave-address-format-01.txt, the document reads: > > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) > > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt > > Please confirm if we should keep the current conclusion. > > Regards, > > xing > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From shengjiang@huawei.com Sun Dec 6 19:25:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A3D28C0CF; Sun, 6 Dec 2009 19:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=2.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2KBrtvk40KH; Sun, 6 Dec 2009 19:25:33 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B914C3A659A; Sun, 6 Dec 2009 19:25:32 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU900713IU971@szxga03-in.huawei.com>; Mon, 07 Dec 2009 11:25:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU900LZOIU9P3@szxga03-in.huawei.com>; Mon, 07 Dec 2009 11:25:21 +0800 (CST) Received: from j66104a ([10.111.12.74]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU9004Z7IU8DD@szxml06-in.huawei.com>; Mon, 07 Dec 2009 11:25:21 +0800 (CST) Date: Mon, 07 Dec 2009 11:25:20 +0800 From: Sheng Jiang In-reply-to: To: 'Sri Gundavelli' , 'Hui Deng' Message-id: <008801ca76ec$e82e7a80$4a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp1yuKoIL6o5DK3v0Kc0sraTiXqVQBH0z5g Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 03:25:34 -0000 > -----Original Message----- > From: Sri Gundavelli > As I said and to repeat one more time, I'm not convinced > about that use-case. This is not a legacy issue, there are no > deployed applications currently operating in that mode. We > talked to many operators, every one is planning to use IPv6 > transport for the UE to UE scenario. This argument that both > the hosts are IPv6-only capable, but they cant use IPv6 > transport is not going to go any where. Hi, Sri, I believe you have talked to many operators and understand their requirements. But I am also sure you have NOT talked with EVERY operators and understand ALL requirements. From this thread, what I read is an operator is taking about its requirement scenario, then you guys tried to say there are different solutions meet other different requirements. For my understanding, you can not shrug off the requirement from legacy applications as easy as you said. Apple may be able to put considerable efforts to update and recompile all there legacy applications since they are in a walled garden and most of their applications are under their direct development. That's not a general case. Actually, apple is so special, we should consider it the last. Here, we are talking about thousands different applications from thousands different ICPs. Could you make sure they all have the extra budget for IPv6? I cannot. So, there are such reality requirements. Host-based translation approach actually helps these legacy applications be able to extend their services to IPv6 network. It helps to convence people IPv6 does not hurt you, it only brings you advantages. Eventually, it makes IPv6 migration smoother. BTW, this discuss should mainly be in behave wg, so I cc to both behave and softwire. Cheers, Sheng > We are talking about four lines of code change to use an IPv6 > socket. As some one pointed out, when Apple released the new > 3GS, all most 80K applications required a re-compile. I don't > get the point that you have an > IPv4 app, binaries only, but that will run on some future > platform with out recompile and talk to a future IPv6 > application. May be your app development process is broken, > this is not a technical or a industry problem. > > I'm not deviating from this point, as I said many times, we > don't deal with this case, its not realistic and there is a > work around. If you have any advantages in the host-based > translation approach that help in IPv6 migration besides this > artificial use-case, let me know. > > > Regards > Sri > > > > On 12/5/09 6:39 AM, "Hui Deng" wrote: > > > Hi Sri, > > > > 2009/12/5 Sri Gundavelli : > >> Hi Hui, > >> > >> > >>>> > >>>> 1. DS-lite has an important property, making IPv4 > address some what > >>>> irrelevant in the context of IP routing and just make it > a simple > >>>> state in two places, the mobile node and the NAT44 gateway. Its > >>>> allowing the network to migrate to IPv6 day-1, remove traces of > >>>> IPv4 in the core and access network, but continue to > offer IPv4 services. > >>> DS-Lite is providing unlimited IPv4 address to the UE, > partly modify > >>> the small part of the bear network which could be constructed by > >>> multiple technologies such as GRE, L2TP, > >>> IPv6 tunnel. I don't see > >>> those tunnels have big difference. > >>> > >>>> If this is not migration what is it ? Now, if the technology is > >>>> also > >>> It is "Save IPv4" as Bo said before, > >> > >> Hmm ... I cant beat this defense. > >> > >> I don't see you disagreeing with my technical points and the > >> similarities I have shown in both the approaches. But, I > see that you > >> do not want to agree and so you summarize it to say, its > still just a > >> solution for IPv4-exhaust and not a step towards > migration, with no > >> backing by any technical arguments. That is fine. We agree or not, > >> its just translation vs., tunneling, a scheme that was > adopted in the > >> earlier versions of DS-lite and made a conscious decision > not to go with host-based translation scheme. > > We are discussing 4-6 scenario here, it sounds strange that it is > > always deviated to another direction. > > I don't see how it is related to translation vs tunneling. > > > >> > >> Bottom line, we touched about the core aspects and also > one use-case > >> that you say is the key motivation for your chosen approach, which > >> the use-case itself is debatable and a clear solution > exists as many > >> folks pointed out, enable dual-stack on the server, or use > IPv6. We > >> also talked about the key resulting benefits in each of the > >> solutions. As far I see it, when > > As far as I can see, the technical argument about our motivation > > hasn't been questioned any more. > > And for solutions, you already agreed that you are no > supporting that. > > > >> DS-lite/GI-DS-lite is applied to mobile architectures, we have all > >> the required tools for migration. > > I guess that this is only said by one people, every other > people has > > different opinion on this. > > > > -Hui > > > >> > >> > >> Regards > >> Sri > >> > >> > >> > >> > >> > >> On 12/4/09 6:46 AM, "Hui Deng" wrote: > >> > >>> Hi, Sri, > >>> > >>> Thanks for the discussion, inline please > >>> > >>> 2009/12/4 Sri Gundavelli : > >>>> Hi Hui: > >>>> > >>>> You and Bo touched a very important point. Your point is that > >>>> DS-lite is just about IPv4 address exhaust and not about > migration. > >>>> You already heard from Alain and that's the best source. > But, I'll > >>>> comment in the context of mobile architectures and > application of GI-DS-lite. > >>>> > >>>> 1. DS-lite has an important property, making IPv4 > address some what > >>>> irrelevant in the context of IP routing and just make it > a simple > >>>> state in two places, the mobile node and the NAT44 gateway. Its > >>>> allowing the network to migrate to IPv6 day-1, remove traces of > >>>> IPv4 in the core and access network, but continue to > offer IPv4 services. > >>> DS-Lite is providing unlimited IPv4 address to the UE, > partly modify > >>> the small part of the bear network which could be constructed by > >>> multiple technologies such as GRE, L2TP, > >>> IPv6 tunnel. I don't see > >>> those tunnels have big difference. > >>> > >>>> If this is not migration what is it ? Now, if the technology is > >>>> also > >>> It is "Save IPv4" as Bo said before, > >>> > >>>> allowing multiplicity assignment of the same IPv4 address to all > >>>> mobile nodes (since, the address is just a state on the > gateway and > >>>> is not used for IP routing), that's a side affect and solves the > >>>> address exhaust problem to some extent. But, there is still > >>>> limitation w.r.t the public address usage on the NAT44 gateway. > >>> yes, this is really a smart technology which could save IPv4. > >>> > >>>> > >>>> 2. Lets look at PNAT. Your single biggest motivation is to allow > >>>> your legacy > >>>> IPv4 applications to work on an IPv6 host that has only IPv6 > >>>> transport and on IPv6-only core network. How are you > achieving this > >>>> ? Your IPv4 > >>> It has already happened, and you already see our slides. > >>> > >>>> application is using an IPv4 address (valid or invalid) > and there > >>>> is a socket and translation state that is getting created on the > >>>> host and on the > >>>> NAT44 gateway, your routing is all based on IPv6. You are making > >>>> IPv4 just a state in the host and on the gateway. > >>>> > >>>> What is the difference between #1 and #2 ? PNAT is > solving all that > >>>> DS-lite solves and also has an indirect property of solving the > >>>> IPv4 address exhaust issue. But, its coming at a huge cost and > >>>> baggage i.e., Host changes. > >>> We spend two weeks here, and you admit that you don't support our > >>> first scenario. > >>> do u need I point out the mailing list link about what you said? > >>> everybody is changing his host everyday by installing new > software, > >>> you may be scared to change your laptop, but I am not that afraid. > >>> > >>>> 3. When I apply DS-lite to mobile architectures which > already have > >>>> good support for dual-stack and the ability to carry > both IPv4 and > >>>> IPv6 on mobility tunnels, its allowing an operator to > migrate their > >>>> network to IPv6-only and is also solving the address > exhaust issue. > >>>> > >>>> - No changes to UE > >>>> - UE can be IPv4-only or IPv6-only > >>>> - Access network can IPv6-only > >>>> - Core network (PGW-CGN) can be IPv6-only > >>>> - Allow IPv6 for UE to UE communication. Allow IPv4 to > IPv4 UE to > >>>> communication when using non-overlapping IP addresses. > Allow IPv6 > >>>> applications to communicate with IPv4 end node using NAT64. > >>>> - Allow access network and core network to migrate to IPv6 at > >>>> different point of time. > >>> I would say that you made a fantastic invention which > really saves > >>> IPv4, good work. > >>> I come out of a good idea that during next IETF, we would > better to > >>> propose a BoF about "Save IPv4" > >>> Bo could become the BoF chair (if AD allows), then invite > >>> GW-Init-DS-Lite ... to join. > >>> > >>>> But, its missing one hypothetical case, which the > scenario is not > >>>> realistic and even otherwise, one can always enable > dual-stack on > >>>> the other peer, or use IPv6 transport. > >>>> > >>>> So, my friend, Dear Hui, there is no difference between what you > >>>> want to solve and what is on the table. Tell me, what > I'm missing. > >>> Dear Sri, I really don't want to point to that link where > you said a > >>> few days ago that you don't support it. > >>> > >>> Thanks > >>> > >>> -Hui > >>> > >>>> > >>>> > >>>> Regards > >>>> Sri > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 12/3/09 4:43 AM, "Hui Deng" wrote: > >>>> > >>>>> Hi, Sri, > >>>> > >>>>>> But, don't deal with the case of IPv4 legacy application > >>>>>> communicating with a IPv6 future application using IPv4. By > >>>>>> allowing that one case which has no justification, you have to > >>>>>> deal with the resulting baggage of host translation and UE > >>>>>> changes. Instead use IPv6 for host to host as you say. > >>>>>> This is not a legacy issue. > >>>>> You are making two different seperated world, it won't success. > >>>>> You didn't answer my previous two emails in seperated line. > >>>>> I could ask here again, you are assigning unlimited > IPv4 address > >>>>> to the host, and encouraging me to install IPv4 > appliation server, > >>>>> I feel what you proposed is more like prolong IPv4 world and > >>>>> solveing the problem of IPv4 address exhaustion but not IPv6 > >>>>> migration. > >>>>> Based on your proposal, IETF would better to setup a > working group > >>>>> about > >>>>> IPv4 address exhaustion about it, other than IPv6 migration. > >>>>> > >>>>> thanks > >>>>> > >>>>> -Hui > >>>>> > >>>> > >>>> > >> > >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sgundave@cisco.com Sun Dec 6 20:34:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D093A659C for ; Sun, 6 Dec 2009 20:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJU7ZBxIn6rb for ; Sun, 6 Dec 2009 20:34:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 691B53A67B3 for ; Sun, 6 Dec 2009 20:34:12 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIcUHEurR7Hu/2dsb2JhbADAM5V6gjWBfgSBZw X-IronPort-AV: E=Sophos;i="4.47,352,1257120000"; d="scan'208";a="445843996" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2009 04:34:02 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB74Y2Kc017827; Mon, 7 Dec 2009 04:34:02 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 20:34:02 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Dec 2009 04:34:01 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 06 Dec 2009 20:34:33 -0800 From: Sri Gundavelli To: Sheng Jiang Message-ID: Thread-Topic: [Softwires] Host based translation: v4-v6 Thread-Index: Acp1yuKoIL6o5DK3v0Kc0sraTiXqVQBH0z5gAAMYyVY= In-Reply-To: <008801ca76ec$e82e7a80$4a0c6f0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Dec 2009 04:34:02.0703 (UTC) FILETIME=[80B79DF0:01CA76F6] Cc: behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 04:34:13 -0000 Hi Sheng, Removing the cross posting. Moving it to behave as you suggested. > Hi, Sri, > > I believe you have talked to many operators and understand their > requirements. But I am also sure you have NOT talked with EVERY operators > and understand ALL requirements. From this thread, what I read is an > operator is taking about its requirement scenario, then you guys tried to > say there are different solutions meet other different requirements. > > For my understanding, you can not shrug off the requirement from legacy > applications as easy as you said. Apple may be able to put considerable > efforts to update and recompile all there legacy applications since they are > in a walled garden and most of their applications are under their direct > development. That's not a general case. Actually, apple is so special, we > should consider it the last. Here, we are talking about thousands different > applications from thousands different ICPs. Could you make sure they all > have the extra budget for IPv6? I cannot. So, there are such reality > requirements. > Sure, I agree, the Apple example may be an example of a very well managed and controlled application development environment. However, the use-case does not appear to be a common or a industry problem, its very hard to believe any operator have to deal with it. May be its unique to only one operator. My argument is that, this is not a legacy issue. If there is a legacy mobile application that you have only binaries, its hard to believe that you can run that mobile application without even compiling on a newer platform a year or two later which will have IPv6-only stack. If you have to re-compile that for a platform that you will support, say a year from now, its matter of making that 4 line change to use IPv6 sockets. Second, you can always set a a requirement for newer applications to be able to use sockets in a version independent manner. This is about a application acceptance process and else these applications will be retired and cannot run on your IPv6-only network and on a host with IPv6-only stack. You also have the option to enable IPv4 on the peers and allow those applications to survive till they are phased out, or migrated to IPv6. But, brining a complex set of host stack changes for this may not a good idea. Its too much of baggage and a very expensive solution. You are talking about managing modified stacks on many operating systems and versions along with a set of ALG's (assuming twice translation is required in some cases). > Host-based translation approach actually helps these legacy applications be > able to extend their services to IPv6 network. It helps to convence people > IPv6 does not hurt you, it only brings you advantages. Eventually, it makes > IPv6 migration smoother. > Not sure. I agree. You really don't want to bring 464. DS-lite in the early stages reviewed that approach and moved away from it. Even if this is real, there can be network based approaches, or an implicit peer to peer generic IPv6 tunneling modes, as Dan suggested. I'm not sure, about host-based translation approaches. > BTW, this discuss should mainly be in behave wg, so I cc to both behave and > softwire. > Ok. Thanks ! Regards Sri > Cheers, > > Sheng > From dwing@cisco.com Sun Dec 6 22:09:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460643A6A03; Sun, 6 Dec 2009 22:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1T-PCpnNzCh; Sun, 6 Dec 2009 22:09:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2E4AC3A67F6; Sun, 6 Dec 2009 22:09:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,352,1257120000"; d="scan'208";a="72466314" Received: from sj-core-3.cisco.com ([171.68.223.137]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2009 06:09:35 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB769YFF029868; Mon, 7 Dec 2009 06:09:34 GMT From: "Dan Wing" To: "'Sheng Jiang'" , "'Sri Gundavelli'" , "'Hui Deng'" References: <008801ca76ec$e82e7a80$4a0c6f0a@china.huawei.com> Date: Sun, 6 Dec 2009 22:09:34 -0800 Message-ID: <079701ca7703$d9500df0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp1yuKoIL6o5DK3v0Kc0sraTiXqVQBH0z5gAAYhanA= In-Reply-To: <008801ca76ec$e82e7a80$4a0c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 06:09:48 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: Sunday, December 06, 2009 7:25 PM > To: 'Sri Gundavelli'; 'Hui Deng' > Cc: softwires@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 > > > -----Original Message----- > > From: Sri Gundavelli > > > As I said and to repeat one more time, I'm not convinced > > about that use-case. This is not a legacy issue, there are no > > deployed applications currently operating in that mode. We > > talked to many operators, every one is planning to use IPv6 > > transport for the UE to UE scenario. This argument that both > > the hosts are IPv6-only capable, but they cant use IPv6 > > transport is not going to go any where. > > Hi, Sri, > > I believe you have talked to many operators and understand their > requirements. But I am also sure you have NOT talked with > EVERY operators > and understand ALL requirements. From this thread, what I read is an > operator is taking about its requirement scenario, then you > guys tried to > say there are different solutions meet other different requirements. > > For my understanding, you can not shrug off the requirement > from legacy > applications as easy as you said. Apple may be able to put > considerable > efforts to update and recompile all there legacy applications > since they are > in a walled garden and most of their applications are under > their direct development. My iPhone has approximately 22 applications written by Apple. The other ~80,000 applications available for the iPhone are not written by Apple. > That's not a general case. Actually, apple is so > special, we > should consider it the last. Here, we are talking about > thousands different > applications from thousands different ICPs. That is how the iTunes store works; most of the applications are developed independently. The source code is not owned or seen by Apple. Yet, when Apple changed the iPhone OS between version 2 and version 3, tens of thousands of the applications were upgraded to work with version 3 of the iPhone OS. Hundreds weren't, and some of those still work fine, and some don't work anymore. > Could you make sure they all > have the extra budget for IPv6? I cannot. So, there are such reality > requirements. > > Host-based translation approach actually helps these legacy > applications be > able to extend their services to IPv6 network. It helps to > convence people > IPv6 does not hurt you, it only brings you advantages. If the original application developer is not investing in their application's support for IPv6, some other organization has to make that investment instead. That is, some other organization has to "pull along" an application into the modern IPv6 era. That is the pushback we are seeing here: the investment to "pull along" an application can not be carried, successfully and in perpetuity, by another organization. The incentives are in the wrong place, and there are high barriers to success. This is why the industry, as a whole, has been adding NAT traversal to applications (e.g., SIP, Skype, RTSP, and others) rather than building and specifying ALG, and rather than solely relying on UPnP IGD / NAT-PMP. -d > Eventually, it makes IPv6 migration smoother. > > BTW, this discuss should mainly be in behave wg, so I cc to > both behave and softwire. > > Cheers, > > Sheng > > > We are talking about four lines of code change to use an IPv6 > > socket. As some one pointed out, when Apple released the new > > 3GS, all most 80K applications required a re-compile. I don't > > get the point that you have an > > IPv4 app, binaries only, but that will run on some future > > platform with out recompile and talk to a future IPv6 > > application. May be your app development process is broken, > > this is not a technical or a industry problem. > > > > I'm not deviating from this point, as I said many times, we > > don't deal with this case, its not realistic and there is a > > work around. If you have any advantages in the host-based > > translation approach that help in IPv6 migration besides this > > artificial use-case, let me know. > > > > > > Regards > > Sri > > > > > > > > On 12/5/09 6:39 AM, "Hui Deng" wrote: > > > > > Hi Sri, > > > > > > 2009/12/5 Sri Gundavelli : > > >> Hi Hui, > > >> > > >> > > >>>> > > >>>> 1. DS-lite has an important property, making IPv4 > > address some what > > >>>> irrelevant in the context of IP routing and just make it > > a simple > > >>>> state in two places, the mobile node and the NAT44 > gateway. Its > > >>>> allowing the network to migrate to IPv6 day-1, remove > traces of > > >>>> IPv4 in the core and access network, but continue to > > offer IPv4 services. > > >>> DS-Lite is providing unlimited IPv4 address to the UE, > > partly modify > > >>> the small part of the bear network which could be > constructed by > > >>> multiple technologies such as GRE, L2TP, > > >>> IPv6 tunnel. I don't see > > >>> those tunnels have big difference. > > >>> > > >>>> If this is not migration what is it ? Now, if the > technology is > > >>>> also > > >>> It is "Save IPv4" as Bo said before, > > >> > > >> Hmm ... I cant beat this defense. > > >> > > >> I don't see you disagreeing with my technical points and the > > >> similarities I have shown in both the approaches. But, I > > see that you > > >> do not want to agree and so you summarize it to say, its > > still just a > > >> solution for IPv4-exhaust and not a step towards > > migration, with no > > >> backing by any technical arguments. That is fine. We > agree or not, > > >> its just translation vs., tunneling, a scheme that was > > adopted in the > > >> earlier versions of DS-lite and made a conscious decision > > not to go with host-based translation scheme. > > > We are discussing 4-6 scenario here, it sounds strange that it is > > > always deviated to another direction. > > > I don't see how it is related to translation vs tunneling. > > > > > >> > > >> Bottom line, we touched about the core aspects and also > > one use-case > > >> that you say is the key motivation for your chosen > approach, which > > >> the use-case itself is debatable and a clear solution > > exists as many > > >> folks pointed out, enable dual-stack on the server, or use > > IPv6. We > > >> also talked about the key resulting benefits in each of the > > >> solutions. As far I see it, when > > > As far as I can see, the technical argument about our motivation > > > hasn't been questioned any more. > > > And for solutions, you already agreed that you are no > > supporting that. > > > > > >> DS-lite/GI-DS-lite is applied to mobile architectures, > we have all > > >> the required tools for migration. > > > I guess that this is only said by one people, every other > > people has > > > different opinion on this. > > > > > > -Hui > > > > > >> > > >> > > >> Regards > > >> Sri > > >> > > >> > > >> > > >> > > >> > > >> On 12/4/09 6:46 AM, "Hui Deng" wrote: > > >> > > >>> Hi, Sri, > > >>> > > >>> Thanks for the discussion, inline please > > >>> > > >>> 2009/12/4 Sri Gundavelli : > > >>>> Hi Hui: > > >>>> > > >>>> You and Bo touched a very important point. Your point is that > > >>>> DS-lite is just about IPv4 address exhaust and not about > > migration. > > >>>> You already heard from Alain and that's the best source. > > But, I'll > > >>>> comment in the context of mobile architectures and > > application of GI-DS-lite. > > >>>> > > >>>> 1. DS-lite has an important property, making IPv4 > > address some what > > >>>> irrelevant in the context of IP routing and just make it > > a simple > > >>>> state in two places, the mobile node and the NAT44 > gateway. Its > > >>>> allowing the network to migrate to IPv6 day-1, remove > traces of > > >>>> IPv4 in the core and access network, but continue to > > offer IPv4 services. > > >>> DS-Lite is providing unlimited IPv4 address to the UE, > > partly modify > > >>> the small part of the bear network which could be > constructed by > > >>> multiple technologies such as GRE, L2TP, > > >>> IPv6 tunnel. I don't see > > >>> those tunnels have big difference. > > >>> > > >>>> If this is not migration what is it ? Now, if the > technology is > > >>>> also > > >>> It is "Save IPv4" as Bo said before, > > >>> > > >>>> allowing multiplicity assignment of the same IPv4 > address to all > > >>>> mobile nodes (since, the address is just a state on the > > gateway and > > >>>> is not used for IP routing), that's a side affect and > solves the > > >>>> address exhaust problem to some extent. But, there is still > > >>>> limitation w.r.t the public address usage on the NAT44 gateway. > > >>> yes, this is really a smart technology which could save IPv4. > > >>> > > >>>> > > >>>> 2. Lets look at PNAT. Your single biggest motivation > is to allow > > >>>> your legacy > > >>>> IPv4 applications to work on an IPv6 host that has only IPv6 > > >>>> transport and on IPv6-only core network. How are you > > achieving this > > >>>> ? Your IPv4 > > >>> It has already happened, and you already see our slides. > > >>> > > >>>> application is using an IPv4 address (valid or invalid) > > and there > > >>>> is a socket and translation state that is getting > created on the > > >>>> host and on the > > >>>> NAT44 gateway, your routing is all based on IPv6. You > are making > > >>>> IPv4 just a state in the host and on the gateway. > > >>>> > > >>>> What is the difference between #1 and #2 ? PNAT is > > solving all that > > >>>> DS-lite solves and also has an indirect property of > solving the > > >>>> IPv4 address exhaust issue. But, its coming at a huge cost and > > >>>> baggage i.e., Host changes. > > >>> We spend two weeks here, and you admit that you don't > support our > > >>> first scenario. > > >>> do u need I point out the mailing list link about what you said? > > >>> everybody is changing his host everyday by installing new > > software, > > >>> you may be scared to change your laptop, but I am not > that afraid. > > >>> > > >>>> 3. When I apply DS-lite to mobile architectures which > > already have > > >>>> good support for dual-stack and the ability to carry > > both IPv4 and > > >>>> IPv6 on mobility tunnels, its allowing an operator to > > migrate their > > >>>> network to IPv6-only and is also solving the address > > exhaust issue. > > >>>> > > >>>> - No changes to UE > > >>>> - UE can be IPv4-only or IPv6-only > > >>>> - Access network can IPv6-only > > >>>> - Core network (PGW-CGN) can be IPv6-only > > >>>> - Allow IPv6 for UE to UE communication. Allow IPv4 to > > IPv4 UE to > > >>>> communication when using non-overlapping IP addresses. > > Allow IPv6 > > >>>> applications to communicate with IPv4 end node using NAT64. > > >>>> - Allow access network and core network to migrate to IPv6 at > > >>>> different point of time. > > >>> I would say that you made a fantastic invention which > > really saves > > >>> IPv4, good work. > > >>> I come out of a good idea that during next IETF, we would > > better to > > >>> propose a BoF about "Save IPv4" > > >>> Bo could become the BoF chair (if AD allows), then invite > > >>> GW-Init-DS-Lite ... to join. > > >>> > > >>>> But, its missing one hypothetical case, which the > > scenario is not > > >>>> realistic and even otherwise, one can always enable > > dual-stack on > > >>>> the other peer, or use IPv6 transport. > > >>>> > > >>>> So, my friend, Dear Hui, there is no difference > between what you > > >>>> want to solve and what is on the table. Tell me, what > > I'm missing. > > >>> Dear Sri, I really don't want to point to that link where > > you said a > > >>> few days ago that you don't support it. > > >>> > > >>> Thanks > > >>> > > >>> -Hui > > >>> > > >>>> > > >>>> > > >>>> Regards > > >>>> Sri > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On 12/3/09 4:43 AM, "Hui Deng" wrote: > > >>>> > > >>>>> Hi, Sri, > > >>>> > > >>>>>> But, don't deal with the case of IPv4 legacy application > > >>>>>> communicating with a IPv6 future application using IPv4. By > > >>>>>> allowing that one case which has no justification, > you have to > > >>>>>> deal with the resulting baggage of host translation and UE > > >>>>>> changes. Instead use IPv6 for host to host as you say. > > >>>>>> This is not a legacy issue. > > >>>>> You are making two different seperated world, it > won't success. > > >>>>> You didn't answer my previous two emails in seperated line. > > >>>>> I could ask here again, you are assigning unlimited > > IPv4 address > > >>>>> to the host, and encouraging me to install IPv4 > > appliation server, > > >>>>> I feel what you proposed is more like prolong IPv4 world and > > >>>>> solveing the problem of IPv4 address exhaustion but not IPv6 > > >>>>> migration. > > >>>>> Based on your proposal, IETF would better to setup a > > working group > > >>>>> about > > >>>>> IPv4 address exhaustion about it, other than IPv6 migration. > > >>>>> > > >>>>> thanks > > >>>>> > > >>>>> -Hui > > >>>>> > > >>>> > > >>>> > > >> > > >> > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From shengjiang@huawei.com Sun Dec 6 22:32:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D3228C10D for ; Sun, 6 Dec 2009 22:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkCZD1Bd77Ix for ; Sun, 6 Dec 2009 22:32:46 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2048A28C117 for ; Sun, 6 Dec 2009 22:32:39 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU9007FARDHH8@szxga04-in.huawei.com> for behave@ietf.org; Mon, 07 Dec 2009 14:29:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU900KD1RDHRF@szxga04-in.huawei.com> for behave@ietf.org; Mon, 07 Dec 2009 14:29:41 +0800 (CST) Received: from j66104a ([10.111.12.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU900BHVRDG3A@szxml04-in.huawei.com> for behave@ietf.org; Mon, 07 Dec 2009 14:29:41 +0800 (CST) Date: Mon, 07 Dec 2009 14:29:39 +0800 From: Sheng Jiang In-reply-to: To: 'Sri Gundavelli' Message-id: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp1yuKoIL6o5DK3v0Kc0sraTiXqVQBH0z5gAAMYyVYAAzmmkA== Cc: behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 06:32:47 -0000 Hi, Sri, I believe we share many common opinions and have minimum different here: eventually, all networks, devices, applications should be IPv6-enabled, even IPv6-only. Before that, there would be a long period of IPv6/IPv4 co-existing. That's why we are here discussing transition mechanisms. That means we already admire some of networks, devices, applications could stay in IPv4-only for a while. I agree that your code change requirement can solve the issues we discuss here. However, it is just like we say if everyone going to IPv6-only, we won't have transition issues. My argument here is that you cannot assume every application providers can accept your code change requirement. Between 2001 and 2004, I had experience made applications (like Grid middleware) IPv6-enabled. It is much more complicated than your "4 line change". Depending on the original applications, java application could be much easier than c/c++ based application. Some of applications even need independent driver to be IPv6-enabled. So, as one of transition mechanisms, PNAT meets the requirements that some applications would stay in IPv4-only but want to connect to the whole world, include IPv6 world. For the transition period, changing protocol stacks (embeded tens different OS) is much easier than changing all applications (probably millions). Cheers, Sheng > > I believe you have talked to many operators and understand their > > requirements. But I am also sure you have NOT talked with EVERY > > operators and understand ALL requirements. From this thread, what I > > read is an operator is taking about its requirement > scenario, then you > > guys tried to say there are different solutions meet other > different requirements. > > > > For my understanding, you can not shrug off the requirement from > > legacy applications as easy as you said. Apple may be able to put > > considerable efforts to update and recompile all there legacy > > applications since they are in a walled garden and most of their > > applications are under their direct development. That's not > a general > > case. Actually, apple is so special, we should consider it > the last. > > Here, we are talking about thousands different applications from > > thousands different ICPs. Could you make sure they all have > the extra > > budget for IPv6? I cannot. So, there are such reality requirements. > > > > Sure, I agree, the Apple example may be an example of a very > well managed and controlled application development > environment. However, the use-case does not appear to be a > common or a industry problem, its very hard to believe any > operator have to deal with it. May be its unique to only one operator. > > My argument is that, this is not a legacy issue. If there is > a legacy mobile application that you have only binaries, its > hard to believe that you can run that mobile application > without even compiling on a newer platform a year or two > later which will have IPv6-only stack. If you have to > re-compile that for a platform that you will support, say a > year from now, its matter of making that 4 line change to use > IPv6 sockets. > > Second, you can always set a a requirement for newer > applications to be able to use sockets in a version > independent manner. This is about a application acceptance > process and else these applications will be retired and > cannot run on your IPv6-only network and on a host with > IPv6-only stack. > > You also have the option to enable IPv4 on the peers and > allow those applications to survive till they are phased out, > or migrated to IPv6. But, brining a complex set of host stack > changes for this may not a good idea. > Its too much of baggage and a very expensive solution. You > are talking about managing modified stacks on many operating > systems and versions along with a set of ALG's (assuming > twice translation is required in some cases). > > > > Host-based translation approach actually helps these legacy > > applications be able to extend their services to IPv6 network. It > > helps to convence people > > IPv6 does not hurt you, it only brings you advantages. > Eventually, it > > makes > > IPv6 migration smoother. > > > > Not sure. I agree. You really don't want to bring 464. > DS-lite in the early stages reviewed that approach and moved > away from it. > > Even if this is real, there can be network based approaches, > or an implicit peer to peer generic IPv6 tunneling modes, as > Dan suggested. I'm not sure, about host-based translation approaches. > > > BTW, this discuss should mainly be in behave wg, so I cc to both > > behave and softwire. > > > > Ok. Thanks ! > > Regards > Sri > > > > > Cheers, > > > > Sheng > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Sun Dec 6 23:15:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754753A6886 for ; Sun, 6 Dec 2009 23:15:39 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMjHIHXKPR7o for ; Sun, 6 Dec 2009 23:15:36 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id A5AE63A6863 for ; Sun, 6 Dec 2009 23:15:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSxyrh8+KtL7LmUMPxDpwXmzKFcRwp0Uy@postini.com; Sun, 06 Dec 2009 23:15:26 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 6 Dec 2009 23:15:09 -0800 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; Mon, 7 Dec 2009 02:15:08 -0500 From: Reinaldo Penno To: Simon Perreault Date: Mon, 7 Dec 2009 02:15:05 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: Acp1oSpPek+deTTTTW2Mbpm7+srzFwBa9WV8 Message-ID: In-Reply-To: <4B1A490C.7090104@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Xu, Cameron Byrne , "behave@ietf.org" , Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:15:39 -0000 On 12/5/09 3:50 AM, "Simon Perreault" wrote: > On 12/05/2009 03:27 AM, Reinaldo Penno wrote: >> If a certain mapping on NAT64-A does not send ICMPv4 packets back >> for unsolicited sessions and another mapping does, this behavior must re= main >> the same on the fail-over box. >=20 > This is arguable. IMHO, this behaviour could be different without > negative impact in many situations. This is a vague statement. Can you please elaborate which situations are these without negative impact? In my experience there are usually negative impacts ranging from from legal requirements, DDoS & security and last but not least performance. >=20 >> NAT state is the mapping state + ICMP behavior (discussed above) + filte= ring >> behavior + timer settings (discussed below for ICMP) + log behavior >> (yes/no/format) + others not discussed. Each of these can be different f= or >> different NAT entries. >=20 > We have different definitions of state it seems. >=20 > ICMP behaviour, filtering behaviour, timer settings, log behaviour, and > others do not vary over time. (Or we could impose the constraint that > the state sync connection be renegotiated when they do vary.) >=20 > The state sync protocol is only concerned with stuff that varies over > time, i.e. bindings and sessions. That's it. Can you explain what exactly and how is your definition of 'vary over time'= ? When a NAT binding is created with certain parameters, do you foresee the same NAT binding varying over time before the session is over? I certainly foresee that the same private address can get a different bindings when it goes to different destinations over time. But then it can also get a different ICMP handling, filtering, logging and timer behavior. Therefore this state also needs to be synched with each new different binding.=20 >=20 >> Some people made the opposite case and it brings to some of the basics. = NAT >> operational complexity is high and therefore brings special requirements= to >> the table. Based on your statement it seems you think there are similar >> cases. >=20 > "NAT operational complexity is high" is a blanket statement. For > example, nowadays most everyone has a NAT at home without even knowing it= . Right, one vendor, one box, one interface in-out, box wide knobs for most NAT behavior. Is that how you see service providers NAT boxes? Because that would explain where you are coming from in relation to NAT state, filtering, etc. Thanks, Reinaldo PS: One thing NAT home devices have that is very useful is UPnP and NAT-PMP (but that is being implemented in some large NAT boxes). Thinking about tha= t makes me wonder if the protocol will synch dynamic NAT port forwarding stat= e established through UPNP and NAT-PMP across boxes. From xing@cernet.edu.cn Mon Dec 7 02:28:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28AE83A6917 for ; Mon, 7 Dec 2009 02:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0p3KMdgzGYn for ; Mon, 7 Dec 2009 02:27:59 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 1966A3A67BD for ; Mon, 7 Dec 2009 02:27:57 -0800 (PST) Received: from [59.66.24.60]([59.66.24.60]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b1d1ab9; Mon, 07 Dec 2009 18:27:43 +0800 Message-ID: <4B1CD899.8010402@cernet.edu.cn> Date: Mon, 07 Dec 2009 18:27:37 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> <4B1BCBF2.1090407@viagenie.ca> In-Reply-To: <4B1BCBF2.1090407@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: wwhoaRXB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 10:28:00 -0000 Simon Perreault 写é“: > On 12/06/2009 08:40 AM, Xing Li wrote: >>> Parameter Problem (Type 4) If the Code is 1, translate this to an >>> ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set >>> the Type to 12 and the Code to zero. The Pointer needs to be >>> updated to point to the corresponding field in the translated >>> inner IP header. >>> >>> Question: How is that pointer updating performed? Do I have to >>> establish >>> correspondences between IPv6 and IPv4 fields? If so, shouldn't this be >>> in the text? >> >> Pointer is used to Identify the octet offset within the invoking packet >> where the error was detected. Due to the different format of the >> Parameter Problem Message >> between IPv6 and IPv4, the octet offset needs to be changed in order to >> point to the same position of the error. > > Yes but the pointer points inside an IPv6 header before translation, > and it points inside an IPv4 header after translation. There is more > to it than just updating the offset. It's a completely different > header and the fields don't have 1:1 mapping. In the current draft, this is discussed in ICMP Error Payload section. It reads, if the received ICMPv6 packet contains an ICMP Extension [RFC4884], the translation of the ICMPv6 packet will cause the ICMPv6 packet to change length. For extensions not defined in RFC4884, the translator passes the extensions as opaque bit strings and those containing IPv6 address literals will not have those addresses translated to IPv4 address literals; this is likely to cause problems with processing of those ICMP extensions. So for anything defined in RFC4884, converting the addresses, otherwise passing the strings. The pointer is updated based on this rule. Regards, xing > > Simon From simon.perreault@viagenie.ca Mon Dec 7 05:00:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B297F3A67DF for ; Mon, 7 Dec 2009 05:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndAMnTgj+tnd for ; Mon, 7 Dec 2009 05:00:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A8FCF3A67A3 for ; Mon, 7 Dec 2009 05:00:09 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 77F2A20E53; Mon, 7 Dec 2009 07:59:59 -0500 (EST) Message-ID: <4B1CFC4E.1080808@viagenie.ca> Date: Mon, 07 Dec 2009 07:59:58 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Xing Li References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> <4B1BCBF2.1090407@viagenie.ca> <4B1CD899.8010402@cernet.edu.cn> In-Reply-To: <4B1CD899.8010402@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 13:00:10 -0000 Xing Li wrote, on 2009-12-07 05:27: > Simon Perreault 写é“: >> On 12/06/2009 08:40 AM, Xing Li wrote: >>>> Parameter Problem (Type 4) If the Code is 1, translate this to an >>>> ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set >>>> the Type to 12 and the Code to zero. The Pointer needs to be >>>> updated to point to the corresponding field in the translated >>>> inner IP header. >>>> >>>> Question: How is that pointer updating performed? Do I have to >>>> establish >>>> correspondences between IPv6 and IPv4 fields? If so, shouldn't this be >>>> in the text? >>> >>> Pointer is used to Identify the octet offset within the invoking packet >>> where the error was detected. Due to the different format of the >>> Parameter Problem Message >>> between IPv6 and IPv4, the octet offset needs to be changed in order to >>> point to the same position of the error. >> >> Yes but the pointer points inside an IPv6 header before translation, >> and it points inside an IPv4 header after translation. There is more >> to it than just updating the offset. It's a completely different >> header and the fields don't have 1:1 mapping. > > In the current draft, this is discussed in ICMP Error Payload section. > It reads, if the received ICMPv6 packet contains an ICMP Extension > [RFC4884], the translation of the ICMPv6 packet will cause the ICMPv6 > packet to change length. This is not what I mean. I will try again. Suppose I have an ICMPv6 with type 4, code 0, and pointer value 3. This would mean that there is a problem with the Flow Label field in the IPv6 header. To translate to IPv4 I can't just offset the pointer: the Flow Label field doesn't exist in IPv4. Another example: suppose the pointer value is 7, which points to the Hop Limit field. This corresponds to the TTL field in IPv4 (if this is true, it would need to be in the text). But since the fields are not at the same place in the header, we need to adjust the pointer by more than just an offset based on the header length. Third example: suppose the pointer points beyond the IP header, into the transport header. This would be easy for TCP and UDP: just offset the pointer based on the header length. But suppose also that the transport protocol is ICMPv6. This is going to be translated to ICMPv4, and we have the same problems as above because there is no 1:1 mapping between the two. I suggest that we do not attempt to translate the pointer, for two reasons: - There is no 1:1 mapping between IPv4 and IPv6 parameters. - The error would often be of interest only to the translator, since it would be the one having generated the erroneous parameter. Therefore, I suggest to change the text to this: Parameter Problem (Type 4) If the Code is 1, translate this to an ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise, silently drop. And in section 2.3: Parameter Problem (Type 12) Silently drop. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Mon Dec 7 05:29:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED47C3A67CF for ; Mon, 7 Dec 2009 05:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCagXqovaeEM for ; Mon, 7 Dec 2009 05:29:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A63553A6828 for ; Mon, 7 Dec 2009 05:29:36 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 42CC120E53; Mon, 7 Dec 2009 08:29:26 -0500 (EST) Message-ID: <4B1D0335.6070601@viagenie.ca> Date: Mon, 07 Dec 2009 08:29:25 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 13:29:38 -0000 Reinaldo Penno wrote, on 2009-12-07 02:15: > On 12/5/09 3:50 AM, "Simon Perreault" wrote: >> On 12/05/2009 03:27 AM, Reinaldo Penno wrote: >>> If a certain mapping on NAT64-A does not send ICMPv4 packets back >>> for unsolicited sessions and another mapping does, this behavior must remain >>> the same on the fail-over box. >> >> This is arguable. IMHO, this behaviour could be different without >> negative impact in many situations. > > This is a vague statement. Can you please elaborate which situations are > these without negative impact? The situation: Two NATs, state synced, one sending ICMP errors and the other not. To elaborate further: Suppose I'm talking about a small/medium enterprise with the two NATs in sync sitting at the border of the Internet and their LAN. There are people working in the LAN, with, say, web browsers. They absolutely don't care about the difference in ICMP behaviours. > In my experience there are usually negative impacts ranging from from legal > requirements, DDoS & security and last but not least performance. Sure, I don't disagree. But there are tons of other cases where it doesn't matter. So we could want the sync protocol to negotiate or not these differences in behaviour. >> The state sync protocol is only concerned with stuff that varies over >> time, i.e. bindings and sessions. That's it. > > Can you explain what exactly and how is your definition of 'vary over time'? > When a NAT binding is created with certain parameters, do you foresee the > same NAT binding varying over time before the session is over? Example: You power up the NAT and put it in service. It has no bindings/sessions. As packets traverse it, bindings and sessions get created, deleted, etc. So the binding and session tables vary over time. Also known as "dynamic". The behaviours such as "sends ICMP errors" do not vary. They are always the same (or at least, remain constant during the lifetime of a NAT state sync session). Therefore the state sync protocol has nothing to do with them. It may need to be restarted to renegotiate their values if they change, but that's it. Also known as "static". > I certainly foresee that the same private address can get a different > bindings when it goes to different destinations over time. But then it can > also get a different ICMP handling, filtering, logging and timer behavior. > Therefore this state also needs to be synched with each new different > binding. No. This is not dynamic state, it's static configuration. The static configuration needs to be the same, or could also be negotiated at the beginning. It is completely separate from state sync and does not run under the same constraints. For example, the state sync protocol needs to be very efficient. But to negotiate static configuration this constraint is relaxed. If you want to do this "at random" then yes it would be dynamic and need to be synchronized. But I suggest this be out of scope. >> "NAT operational complexity is high" is a blanket statement. For >> example, nowadays most everyone has a NAT at home without even knowing it. > > Right, one vendor, one box, one interface in-out, box wide knobs for most > NAT behavior. Is that how you see service providers NAT boxes? I suppose that the correct answer is "no." Note that a NAT state sync protocol would be useful to much more than just service providers. > Because that would explain where you are coming from in relation to NAT > state, filtering, etc. I'm feeling that this discussion is becoming less constructive. > PS: One thing NAT home devices have that is very useful is UPnP and NAT-PMP > (but that is being implemented in some large NAT boxes). Thinking about that > makes me wonder if the protocol will synch dynamic NAT port forwarding state > established through UPNP and NAT-PMP across boxes. Sure, why not? It's just a matter of propagating changes to the binding/session tables. To recap our discussion: - An eventual state sync protocol would need an init phase where static configuration and behaviours would be negotiated. - The level to which the static stuff needs to be similar (or made similar) will differ in different cases. - After the negotiation is successful, only dynamic state updates will be propagated. Is this right? Does anything else need to be said at this point? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From wwwrun@core3.amsl.com Mon Dec 7 07:56:51 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 662F93A6A45; Mon, 7 Dec 2009 07:56:51 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091207155651.662F93A6A45@core3.amsl.com> Date: Mon, 7 Dec 2009 07:56:51 -0800 (PST) Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Document Action: 'NAT Behavior Discovery Using STUN' to Experimental RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:56:51 -0000 The IESG has approved the following document: - 'NAT Behavior Discovery Using STUN ' as an Experimental RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-08.txt Technical Summary This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. Working Group Summary The original intent was to publish this specification as Informational, but the working group decided Experimental would be a better track in order to more clearly convey the risky nature of attempting to determine a NAT's behavior. Document Quality Two vendors are known to implement it. The IETF last call draw a number of comments about its applicability and a number of details. My review of them looks like they have been resolved in a reasonable way. Personnel Dan Wing, dwing@cisco.com is the WG shepherd and Magnus Westerlund, magnus.westerlund@ericsson.com the responsible AD. RFC Editor Note Section 1, second and third paragraph: OLD: The primary uses envisioned for the STUN attributes included in this draft are diagnostics and real-time tuning of applications. The techniques possible with this usage are powerful diagnostic tools in the hands of a network administrator or system programmer trying to determine the causes of network failure; particularly when behavior varies by load, destination, or other factors that may be related to NAT behavior. This draft also proposes experimental usage of these attributes for real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in P2P networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. If a node trying to join an overlay as a full peer when its NAT prevents sufficient connectivity and then withdrawing is expensive or leads to unreliable or poorly performing operation, then even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure. NEW: The uses envisioned for the STUN attributes included in this document are diagnostics and real-time tuning of applications. For example determine what may work and should be tried first compared to more expensive methods. The attributes can also be used to observe behaviors that causes an application's communication to fail, thus enabling better selection of methods of recovery. The STUN attributes could also be a basis for a network technican's diagnostics tool to observe NAT behavior. This draft proposes experimental usage of these attributes for ^ real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in P2P networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. If a node trying to join an overlay as a full peer when its NAT prevents sufficient connectivity and then withdrawing is expensive or leads to unreliable or poorly performing operation, then even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure. Section 2.3: Section title OLD: Experimental Success NEW: Experimental Goals From eric.burgey@orange-ftgroup.com Mon Dec 7 09:07:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388A33A67FB for ; Mon, 7 Dec 2009 09:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsQ-34cHy5wC for ; Mon, 7 Dec 2009 09:07:01 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id B3D823A67D4 for ; Mon, 7 Dec 2009 09:06:59 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 18:06:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA775F.A958AF48" Date: Mon, 7 Dec 2009 18:06:47 +0100 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B1B8065.3040203@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: Acp2WsfWO+CMVUaSSQiHobp952ZXtAA/iIag References: <4B1B8065.3040203@cernet.edu.cn> From: To: , , X-OriginalArrivalTime: 07 Dec 2009 17:06:49.0529 (UTC) FILETIME=[AA3E5290:01CA775F] Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 17:07:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA775F.A958AF48 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 If i truly understand the slides the scope of the document is covering = both: "IPv4 translatable" IPv6 address "IPv4 converted" IPv6 address. =20 In slide 4 you say that both must use the same prefix and I agree. =20 But in my humble opinion there is no need to have the same suffix = requirement for all different cases. For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a = good solution. =20 But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, = such IPv6 address can be assigned on a local network to an host that is = not a routers but a simple end host. In such case, it may be interesting = to use the most significant part of the IPv6 address as local network = prefix (usually a /64 prefix). In that case the least significant part = of the address is not the Ethernet interface address (U=3D0) but in = accordance with RFC4291 this part may be used with the link local prefix = instead of the local network prefix. But if the suffix is 0 this address = is not unique on the local network. This problem can be solved by = copying the part of the IPv4 address that is in the prefix (in the 64 = most significant bit) in the suffix and adding a 24 bit long host = identifier if the IPv4 address is not unique. I suggest to put the = redundant part of the IPv4 address in the lest significant bit and the = host identifier between the non redundant part of IPv4 address and the = redundant part so that the host identifier can be used also as = sub-network identifier to route the packet toward the appropriate host = if needed. =20 Example : =20 = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| = 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127 = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | Host ID | V4 (32) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | Host ID |V4 = (16)| = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | Host ID = |(8)| = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | Host ID = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix | v4(32) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ =20 =20 =20 So for "IPv4 converted" IPv6 address used with a NAT64 translator the = suffix should be 0. But for "IPv4 translatable" address I think that the choice of the = suffix must be open and must be chosen according the "IPv4 translatable" = address usage. =20 Having different suffix value may be helpful, it can be used in a = referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 = translatable" address if the length of the prefix is known and different = from /96 (this is needed to extract the IPv4 address from the format). =20 Best regards, =20 =20 Eric BURGEY Orange Labs =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Xing Li Envoy=E9 : dimanche 6 d=E9cembre 2009 10:59 =C0 : 'Behave WG'; Behave Chairs Objet : [BEHAVE] address-format: null suffix, consensus check =20 Hi, All, =20 In the draft-ietf-behave-address-format-01.txt, the document reads: =20 When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) =20 An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt =20 Please confirm if we should keep the current conclusion. =20 Regards, =20 xing =20 =20 =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01CA775F.A958AF48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

If i truly understand the slides the scope of the document is covering = both:

"IPv4 = translatable" IPv6 address

"IPv4 = converted" IPv6 address.

 

In slide 4 you say = that both must use the same prefix and I agree.

 

But in my humble = opinion there is no need to have the same suffix requirement for all different = cases.

For "IPv4 = converted" IPv6 address used by a NAT64 the null suffix is a good = solution.

 

But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, such IPv6 address can be assigned on a local network to an = host that is not a routers but a simple end host. In such case, it may be = interesting to use the most significant part of the IPv6 address as local network = prefix (usually a /64 prefix). In that case the least significant part of the address is = not the Ethernet interface address (U=3D0) but in accordance with RFC4291 this = part may be used with the link local prefix instead of the local network prefix. = But if the suffix is 0 this address is not unique on the local network. This = problem can be solved by copying the part of the IPv4 address that is in the = prefix (in the 64 most significant bit) in the suffix = and adding a 24 bit long host identifier if the IPv4 address is not unique. I = suggest to put the redundant part of the IPv4 address in the lest significant bit = and the host identifier between the non redundant part of IPv4 address and the = redundant part so that the host identifier can be used also as sub-network = identifier to route the packet toward the appropriate host if = needed.

 

Example = :

 

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/32 |=A0=A0=A0=A0 prefix=A0=A0=A0 |v4(32)=A0=A0=A0=A0=A0=A0=A0=A0 | u | =A0=A0Host ID |=A0=A0=A0=A0 V4 (32)=A0=A0 = |

=A0=A0=A0 = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/40 |=A0=A0=A0=A0 prefix=A0=A0=A0=A0=A0=A0=A0 = |v4(24)=A0=A0=A0=A0 | u |(8)| =A0Host ID =A0| V4 (24) =A0=A0|

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/48 |=A0=A0=A0=A0 prefix=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |v4(16) | u | (16)=A0 | Host ID=A0=A0 |V4 = (16)|

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/56 |=A0=A0=A0=A0 prefix=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |(8)| u |=A0 = v4(24)=A0=A0 | Host ID=A0=A0 |(8)|

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/64 |=A0=A0=A0=A0 prefix=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 | u |=A0=A0 v4(32)=A0=A0=A0=A0=A0 | Host ID=A0=A0 |

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

=A0=A0=A0 |/96 |=A0=A0=A0=A0 prefix=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A0 v4(32)=A0=A0=A0=A0=A0 |

=A0=A0=A0 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+

 

 

 

So for "IPv4 converted" IPv6 address used with a NAT64 translator the suffix = should be 0.

But for "IPv4 translatable" address I think that the choice of the suffix must be = open and must be chosen according the "IPv4 translatable" address = usage.

 

Having different = suffix value may be helpful, it can be used in a referral to distinguish an = "IPv4 converted" IPv6 address from an "IPv4 translatable" = address if the length of the prefix is known and different from /96 (this is needed = to extract the IPv4 address from the format).

 

Best = regards,

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Eric = BURGEY

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Orange Labs

 

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de Xing Li
Envoy=E9 : dimanche 6 d=E9cembre 2009 10:59
=C0 : 'Behave WG'; Behave Chairs
Objet : [BEHAVE] address-format: null suffix, consensus = check

 

Hi, All,

 

In the draft-ietf-behave-address-format-01.txt, the document = reads:

 

When a /32 prefix is used, the null suffix results in a = null

identifier. We understand the conflict with Section 2.6.1 = of

RFC4291, which specifies that all zeroes are used for the = subnet-

router anycast address. However, in our specification, there = would

be only one IPv4 translatable host in the /64 subnet, and the = anycast

semantic would not create confusion. We thus decided to keep = the

null suffix for now. (Different authors of this document = have

different opinions.)

 

An example which support the above argument is presented in page = 18 of

http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt

 

Please confirm if we should keep the current = conclusion.

 

Regards,

 

xing

 

 

 

_______________________________________________=

Behave mailing list

Behave@ietf.org

https://www.ietf.org/mailman/listinfo/behave

------_=_NextPart_001_01CA775F.A958AF48-- From dwing@cisco.com Mon Dec 7 09:12:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2933A6A85 for ; Mon, 7 Dec 2009 09:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+NYZl2SPEMh for ; Mon, 7 Dec 2009 09:12:30 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C1833A68DB for ; Mon, 7 Dec 2009 09:12:30 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAKfGHEurRN+J/2dsb2JhbACIfoEWuSmWI4QzBA X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208";a="115356175" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2009 17:12:20 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB7HCK0P016946; Mon, 7 Dec 2009 17:12:20 GMT From: "Dan Wing" To: "'behave mailing list'" , "'Derek MacDonald'" , "'Bruce Lowekamp'" References: <20091207155651.662F93A6A45@core3.amsl.com> Date: Mon, 7 Dec 2009 09:12:20 -0800 Message-ID: <092901ca7760$6f6caf80$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp3VeYbAQM9iUFPT+OloewkVTWwTwACl8QQ In-Reply-To: <20091207155651.662F93A6A45@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] Document Action: 'NAT Behavior Discovery Using STUN' to Experimental RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 17:12:32 -0000 Thanks to everyone's efforts on this document, especially Derek and Bruce that saw it through! -d > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Monday, December 07, 2009 7:57 AM > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor; behave mailing > list; behave chair > Subject: Document Action: 'NAT Behavior Discovery Using STUN' > to Experimental RFC > > The IESG has approved the following document: > > - 'NAT Behavior Discovery Using STUN ' > as an > Experimental RFC > > > This document is the product of the Behavior Engineering for > Hindrance Avoidance Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-beha > vior-discovery-08.txt > > Technical Summary > > This specification defines an experimental usage of the Simple > Traversal Underneath Network Address Translators (NAT) (STUN) > Protocol that discovers the presence and current behaviour of NATs > and firewalls between the STUN client and the STUN server. > > Working Group Summary > > The original intent was to publish this specification as > Informational, > but the working group decided Experimental would be a better track in > order to more clearly convey the risky nature of attempting to > determine a NAT's behavior. > > Document Quality > > Two vendors are known to implement it. The IETF last call > draw a number > of comments about its applicability and a number of details. > My review > of them looks like they have been resolved in a reasonable way. > > Personnel > > Dan Wing, dwing@cisco.com is the WG shepherd and Magnus Westerlund, > magnus.westerlund@ericsson.com the responsible AD. > > RFC Editor Note > > Section 1, second and third paragraph: > > OLD: > > The primary uses envisioned for the STUN attributes > included in this > draft are diagnostics and real-time tuning of applications. The > techniques possible with this usage are powerful > diagnostic tools in > the hands of a network administrator or system programmer trying to > determine the causes of network failure; particularly when behavior > varies by load, destination, or other factors that may be > related to > NAT behavior. > > This draft also proposes experimental usage of these attributes for > real-time optimization of parameters for protocols in situations > where a publicly accessible rendezvous service is not available. > Such a use of these techniques is only possible when the > results are > applied as an optimization and a reliable fallback is available in > case the NAT's behavior becomes more restrictive than determined by > the Behavior Discovery tests. One possible application is role > selection in P2P networks based on statistical experience with > establishing direct connections and diagnosing NAT behavior with a > variety of peers. The experimental question is whether such a test > is useful. If a node trying to join an overlay as a full peer when > its NAT prevents sufficient connectivity and then withdrawing is > expensive or leads to unreliable or poorly performing > operation, then > even if the behavior discovery check is only "correct" 75% of the > time, its relative cheapness may make it very useful for optimizing > the behavior of the overlay network. Section 2.2 describes this > experimental application in more detail and discusses how > to evaluate > its success or failure. > > > NEW: > > The uses envisioned for the STUN attributes included in > this document > > are diagnostics and real-time tuning of applications. For example > determine what may work and should be tried first compared to more > expensive methods. The attributes can also be used to observe > behaviors that causes an application's communication to fail, thus > enabling better selection of methods of recovery. The STUN > attributes > could also be a basis for a network technican's > diagnostics tool to > observe NAT behavior. > > This draft proposes experimental usage of these attributes for > ^ > real-time optimization of parameters for protocols in situations > where a publicly accessible rendezvous service is not available. > Such a use of these techniques is only possible when the > results are > applied as an optimization and a reliable fallback is available in > case the NAT's behavior becomes more restrictive than determined by > the Behavior Discovery tests. One possible application is role > selection in P2P networks based on statistical experience with > establishing direct connections and diagnosing NAT behavior with a > variety of peers. The experimental question is whether such a test > is useful. If a node trying to join an overlay as a full peer when > its NAT prevents sufficient connectivity and then withdrawing is > expensive or leads to unreliable or poorly performing > operation, then > even if the behavior discovery check is only "correct" 75% of the > time, its relative cheapness may make it very useful for optimizing > the behavior of the overlay network. Section 2.2 describes this > experimental application in more detail and discusses how > to evaluate > its success or failure. > > > Section 2.3: Section title > > OLD: Experimental Success > > NEW: Experimental Goals > From huitema@microsoft.com Mon Dec 7 10:52:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388723A67EC for ; Mon, 7 Dec 2009 10:52:53 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6GVG20kea6U for ; Mon, 7 Dec 2009 10:52:52 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 19B7E3A67A8 for ; Mon, 7 Dec 2009 10:52:51 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Dec 2009 10:53:07 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 7 Dec 2009 10:52:33 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 7 Dec 2009 10:52:21 -0800 From: Christian Huitema To: "eric.burgey@orange-ftgroup.com" , "xing@cernet.edu.cn" , "behave@ietf.org" , "behave-chairs@tools.ietf.org" Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdlra5vNbCwCh3EmLNErZhGqem5FaWLiA//+UaZA= Date: Mon, 7 Dec 2009 18:52:15 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:52:53 -0000 Eric, We did consider this type of design before writing the current proposal. Fo= r example, one proposal was to always copy the IPv4 address in bits 96-127 = of the embedded address, even if that copy was a duplicate. That proposal w= as discarded for two reasons: 1) Duplicating data is generally a bad idea, as it forces the translators t= o deal with a new class or errors, when the supposedly duplicated values do= n't match. 2) Using the bits rather than reserving them precludes future extensions, a= nd we are not certain enough of our choices to want to do that. Note that administrators who want the addresses copied in the last bits can= achieve that by selecting the /96 prefix of their choice. Administrators w= ho want fine grain control on the mappings can also statically configure st= ateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" funct= ions of the current crop of NAT44. -- Christian Huitema From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= eric.burgey@orange-ftgroup.com Sent: Monday, December 07, 2009 9:07 AM To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] address-format: null suffix, consensus check Hello, If i truly understand the slides the scope of the document is covering both= : "IPv4 translatable" IPv6 address "IPv4 converted" IPv6 address. In slide 4 you say that both must use the same prefix and I agree. But in my humble opinion there is no need to have the same suffix requireme= nt for all different cases. For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a good= solution. But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, suc= h IPv6 address can be assigned on a local network to an host that is not a = routers but a simple end host. In such case, it may be interesting to use t= he most significant part of the IPv6 address as local network prefix (usual= ly a /64 prefix). In that case the least significant part of the address is= not the Ethernet interface address (U=3D0) but in accordance with RFC4291 = this part may be used with the link local prefix instead of the local netwo= rk prefix. But if the suffix is 0 this address is not unique on the local n= etwork. This problem can be solved by copying the part of the IPv4 address = that is in the prefix (in the 64 most significant bit) in the suffix and ad= ding a 24 bit long host identifier if the IPv4 address is not unique. I sug= gest to put the redundant part of the IPv4 address in the lest significant = bit and the host identifier between the non redundant part of IPv4 address = and the redundant part so that the host identifier can be used also as sub-= network identifier to route the packet toward the appropriate host if neede= d. Example : +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-12= 7 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | Host ID | V4 (32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | Host ID |V4 (16)| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | Host ID |(8)| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | Host ID | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix | v4(32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ So for "IPv4 converted" IPv6 address used with a NAT64 translator the suffi= x should be 0. But for "IPv4 translatable" address I think that the choice of the suffix m= ust be open and must be chosen according the "IPv4 translatable" address us= age. Having different suffix value may be helpful, it can be used in a referral = to distinguish an "IPv4 converted" IPv6 address from an "IPv4 translatable"= address if the length of the prefix is known and different from /96 (this = is needed to extract the IPv4 address from the format). Best regards, Eric BURGEY Orange Labs -----Message d'origine----- De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Xing Li Envoy=E9=A0: dimanche 6 d=E9cembre 2009 10:59 =C0=A0: 'Behave WG'; Behave Chairs Objet=A0: [BEHAVE] address-format: null suffix, consensus check Hi, All, In the draft-ietf-behave-address-format-01.txt, the document reads: When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt Please confirm if we should keep the current conclusion. Regards, xing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Mon Dec 7 11:03:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3E33A67EC for ; Mon, 7 Dec 2009 11:03:01 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjPTmy7uq8X2 for ; Mon, 7 Dec 2009 11:03:00 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id BFB6F3A68CB for ; Mon, 7 Dec 2009 11:02:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSx1RUQ1Kd1dKH5jkBZ3HDNL7NVYuHaLv@postini.com; Mon, 07 Dec 2009 11:02:50 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 7 Dec 2009 10:57:39 -0800 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; Mon, 7 Dec 2009 13:57:37 -0500 From: Reinaldo Penno To: Simon Perreault Date: Mon, 7 Dec 2009 13:57:34 -0500 Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 Thread-Index: Acp3QU3DDhdonmPRQJWhqySULn81BgALdTkZ Message-ID: In-Reply-To: <4B1D0335.6070601@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Xu, Cameron Byrne , "behave@ietf.org" , Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:03:01 -0000 Thanks for the reply. Comments inline... On 12/7/09 5:29 AM, "Simon Perreault" wrote: > Reinaldo Penno wrote, on 2009-12-07 02:15: >> On 12/5/09 3:50 AM, "Simon Perreault" wrot= e: >>=20 >> This is a vague statement. Can you please elaborate which situations are >> these without negative impact? >=20 > The situation: Two NATs, state synced, one sending ICMP errors and the ot= her > not. >=20 > To elaborate further: Suppose I'm talking about a small/medium enterprise= with > the two NATs in sync sitting at the border of the Internet and their LAN. > There > are people working in the LAN, with, say, web browsers. They absolutely d= on't > care about the difference in ICMP behaviours. I'm not sure about the people in the LAN but the enterprise operating the NAT boxes cares.=20 >=20 >> Can you explain what exactly and how is your definition of 'vary over ti= me'? >> When a NAT binding is created with certain parameters, do you foresee th= e >> same NAT binding varying over time before the session is over? >=20 > Example: You power up the NAT and put it in service. It has no > bindings/sessions. As packets traverse it, bindings and sessions get crea= ted, > deleted, etc. So the binding and session tables vary over time. Also know= n as > "dynamic". >=20 > The behaviours such as "sends ICMP errors" do not vary. They are always t= he > same > (or at least, remain constant during the lifetime of a NAT state sync > session). > Therefore the state sync protocol has nothing to do with them. It may nee= d to > be > restarted to renegotiate their values if they change, but that's it. Also > known > as "static". If all you send to the slave NAT is the private (IP address, port) protocol= , public (IP address and port), how will the slave box know which ICMP and filtering behavior to apply to a certain NAT binding? Example: =20 In vendors' 1 box the NAT mapping is SRC IP 2000::1, SRC PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port 2000=20 That mapping was a result of a 'rule match' in which amongst many rules there was one saying: From: incoming interface 1, SRC IP 2000::/96 SRC PORT 10000-10500, protocol UDP To: outgoing interface 2, DST IP 2001::2, NAT pool: 200.1.1.20-200.1.1.30, Log: outgoing, binary Timeout 30 seconds, ICMP: no ICMPv4 for unsolicited Filtering: allow incoming from 100.1.1.1-100.1.1.100, syslog Port: Port parity. The part that you proposing to synch is the mapping ( SRC IP 2000::1, SRC PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port 2000 ), correct? So, how will NAT slave determine all other behavior for each different mapping as it receives the NAT state from the master? >=20 >> I certainly foresee that the same private address can get a different >> bindings when it goes to different destinations over time. But then it c= an >> also get a different ICMP handling, filtering, logging and timer behavio= r. >> Therefore this state also needs to be synched with each new different >> binding.=20 >=20 >=20 > To recap our discussion: >=20 > - An eventual state sync protocol would need an init phase where static > configuration and behaviours would be negotiated. Scope clarification question based on what you said above: Since each vendors' boxes are configured differently are you saying you will come up with a configuration scheme common and acceptable by all vendors as part of this effort so negotiation (configuration and behaviors) can succeed? >=20 > - The level to which the static stuff needs to be similar (or made simila= r) > will > differ in different cases. >=20 > - After the negotiation is successful, only dynamic state updates will be > propagated. See question in beginning with example. >=20 > Is this right? Does anything else need to be said at this point? > A few things come to mind as discussed. * Need to mention how the protocol will synch UPNP and NAT-PMP info * How the protocol will synch ALG info. * IPSEc and other VPN/VRF issues * others that will discuss later. Thanks, Reinaldo > Thanks, > Simon From simon.perreault@viagenie.ca Mon Dec 7 16:53:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2EB28C13A for ; Mon, 7 Dec 2009 16:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5QmvdZ20GB7 for ; Mon, 7 Dec 2009 16:53:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1980F3A6896 for ; Mon, 7 Dec 2009 16:53:04 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5A2A520DFB; Mon, 7 Dec 2009 19:52:53 -0500 (EST) Message-ID: <4B1DA364.5040505@viagenie.ca> Date: Mon, 07 Dec 2009 19:52:52 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , "behave@ietf.org" , 'Xu Xiaohu' , Dan Wing Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 00:53:05 -0000 On 12/07/2009 01:57 PM, Reinaldo Penno wrote: >> To elaborate further: Suppose I'm talking about a small/medium enterprise with >> the two NATs in sync sitting at the border of the Internet and their LAN. >> There >> are people working in the LAN, with, say, web browsers. They absolutely don't >> care about the difference in ICMP behaviours. > > I'm not sure about the people in the LAN but the enterprise operating the > NAT boxes cares. Actually in my mind I was referring to the people running the network. I think most of the time they will not care. I agree that someone could care, and that there should be a way to negotiate this as part of the protocol. > If all you send to the slave NAT is the private (IP address, port) protocol, > public (IP address and port), how will the slave box know which ICMP and > filtering behavior to apply to a certain NAT binding? > > Example: > > In vendors' 1 box the NAT mapping is > > SRC IP 2000::1, SRC PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port > 2000 > > That mapping was a result of a 'rule match' in which amongst many rules > there was one saying: > > From: incoming interface 1, SRC IP 2000::/96 SRC PORT 10000-10500, protocol > UDP > To: outgoing interface 2, DST IP 2001::2, > NAT pool: 200.1.1.20-200.1.1.30, > Log: outgoing, binary > Timeout 30 seconds, > ICMP: no ICMPv4 for unsolicited > Filtering: allow incoming from 100.1.1.1-100.1.1.100, syslog > Port: Port parity. > > The part that you proposing to synch is the mapping ( SRC IP 2000::1, SRC > PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port 2000 ), correct? Correct. (BTW, very good example!) > So, how will NAT slave determine all other behavior for each different > mapping as it receives the NAT state from the master? By ensuring that both NATs are configured with the same static configuration? > Scope clarification question based on what you said above: Since each > vendors' boxes are configured differently are you saying you will come up > with a configuration scheme common and acceptable by all vendors as part of > this effort so negotiation (configuration and behaviors) can succeed? Yes, it is very important to get the scope right. I think the scope should be limited to the choices that are present in the NAT64 spec. In your example above, the following would be out of scope: - Logging - Filtering (Not talking about NAT filtering behaviour. The example above is part of firewall functionality, not NAT.) How about that? > * Need to mention how the protocol will synch UPNP and NAT-PMP info You mean static configuration or just the bindings? I don't see how bindings would be synchronized differently that those created by outbound connection initiation. > * How the protocol will synch ALG info. > * IPSEc and other VPN/VRF issues In my mind the protocol would need to be extensible. The base spec would focus on NAT64. Extensions could be written for ALGs/IPsec/... Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xuxh@huawei.com Tue Dec 8 00:55:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A3528C0DD for ; Tue, 8 Dec 2009 00:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W16ZmS9kZTtx for ; Tue, 8 Dec 2009 00:55:25 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 51A7728C0D8 for ; Tue, 8 Dec 2009 00:55:25 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUB00FP6SQHJW@szxga03-in.huawei.com> for behave@ietf.org; Tue, 08 Dec 2009 16:54:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUB001YMSQHST@szxga03-in.huawei.com> for behave@ietf.org; Tue, 08 Dec 2009 16:54:17 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUB00C6HSQGV5@szxml06-in.huawei.com> for behave@ietf.org; Tue, 08 Dec 2009 16:54:17 +0800 (CST) Date: Tue, 08 Dec 2009 16:54:16 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, behave@ietf.org, behave-chairs@tools.ietf.org Message-id: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: AQHKdlra5vNbCwCh3EmLNErZhGqem5FaWLiA//+UaZCAAOilcA== Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 08:55:26 -0000 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > Christian Huitema > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B412=E6=9C=888=E6=97=A5 2:52 > =E6=94=B6=E4=BB=B6=E4=BA=BA: eric.burgey@orange-ftgroup.com; = xing@cernet.edu.cn; behave@ietf.org; > behave-chairs@tools.ietf.org > =E4=B8=BB=E9=A2=98: Re: [BEHAVE] address-format: null suffix, = consensus check >=20 > Eric, >=20 > We did consider this type of design before writing the current = proposal. For > example, one proposal was to always copy the IPv4 address in bits = 96-127 of > the embedded address, even if that copy was a duplicate. That proposal = was > discarded for two reasons: >=20 > 1) Duplicating data is generally a bad idea, as it forces the = translators to > deal with a new class or errors, when the supposedly duplicated values = don't > match. >=20 > 2) Using the bits rather than reserving them precludes future = extensions, and > we are not certain enough of our choices to want to do that. >=20 > Note that administrators who want the addresses copied in the last = bits can > achieve that by selecting the /96 prefix of their choice. = Administrators who > want fine grain control on the mappings can also statically configure = stateful > mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" = functions of > the current crop of NAT44. Hi Christian, I noticed the following statement in your draft "...Bits 64 to 71 of the = address are reserved for compatibility with the host identifier format = defined in the IPv6 addressing architecture. These bits MUST be set to = zero. The corresponding octet is noted "u" in the above diagram. When = using a 96 prefix, the administrators MUST ensure that the bits 64 to 71 = are compatible with the IPv6 addressing architecture..." My question is: Should the IPv4-embeded IPv6 address still be in = accordance with the specification defined in RFC4291 as "...For all = unicast addresses, except those that start with the binary value 000, = Interface IDs are required to be 64 bits long and to be constructed in = Modified EUI-64 format..."? If the answer is yes, why? (In other words, = is there any practical meaning/usage for that constraint in the = IPv4/IPv6 translation process?) Xiaohu >=20 >=20 >=20 >=20 > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On = Behalf Of > eric.burgey@orange-ftgroup.com > Sent: Monday, December 07, 2009 9:07 AM > To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] address-format: null suffix, consensus check >=20 > Hello, >=20 > If i truly understand the slides the scope of the document is covering = both: > "IPv4 translatable" IPv6 address > "IPv4 converted" IPv6 address. >=20 > In slide 4 you say that both must use the same prefix and I agree. >=20 > But in my humble opinion there is no need to have the same suffix = requirement > for all different cases. > For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a = good > solution. >=20 > But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 = hosts, such > IPv6 address can be assigned on a local network to an host that is not = a routers > but a simple end host. In such case, it may be interesting to use the = most > significant part of the IPv6 address as local network prefix (usually = a /64 > prefix). In that case the least significant part of the address is not = the > Ethernet interface address (U=3D0) but in accordance with RFC4291 this = part may > be used with the link local prefix instead of the local network = prefix. But > if the suffix is 0 this address is not unique on the local network. = This problem > can be solved by copying the part of the IPv4 address that is in the = prefix > (in the 64 most significant bit) in the suffix and adding a 24 bit = long host > identifier if the IPv4 address is not unique. I suggest to put the = redundant > part of the IPv4 address in the lest significant bit and the host = identifier > between the non redundant part of IPv4 address and the redundant part = so that > the host identifier can be used also as sub-network identifier to = route the > packet toward the appropriate host if needed. >=20 > Example : >=20 > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |PLEN| > 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127 > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/32 | prefix |v4(32) | u | Host ID | V4 (32) = | > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) = | > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/48 | prefix |v4(16) | u | (16) | Host ID |V4 = (16)| > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/56 | prefix |(8)| u | v4(24) | Host ID = |(8)| > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/64 | prefix | u | v4(32) | Host ID = | > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |/96 | prefix | v4(32) = | > = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >=20 >=20 >=20 > So for "IPv4 converted" IPv6 address used with a NAT64 translator the = suffix > should be 0. > But for "IPv4 translatable" address I think that the choice of the = suffix must > be open and must be chosen according the "IPv4 translatable" address = usage. >=20 > Having different suffix value may be helpful, it can be used in a = referral to > distinguish an "IPv4 converted" IPv6 address from an "IPv4 = translatable" > address if the length of the prefix is known and different from /96 = (this is > needed to extract the IPv4 address from the format). >=20 > Best regards, >=20 >=20 > Eric BURGEY > Orange Labs >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de > Xing Li > Envoy=C3=A9 : dimanche 6 d=C3=A9cembre 2009 10:59 > =C3=80 : 'Behave WG'; Behave Chairs > Objet : [BEHAVE] address-format: null suffix, consensus check >=20 > Hi, All, >=20 > In the draft-ietf-behave-address-format-01.txt, the document reads: >=20 > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) >=20 > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt >=20 > Please confirm if we should keep the current conclusion. >=20 > Regards, >=20 > xing >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From eric.burgey@orange-ftgroup.com Tue Dec 8 01:31:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA613A6991 for ; Tue, 8 Dec 2009 01:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNQnFQdI1Cxa for ; Tue, 8 Dec 2009 01:31:30 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D284F3A6872 for ; Tue, 8 Dec 2009 01:31:28 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 10:31:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA77E9.2FC2D3F6" Date: Tue, 8 Dec 2009 10:31:14 +0100 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1A788A8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdlra5vNbCwCh3EmLNErZhGqem5FaWLiA//+UaZCAAO0JUA== References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> From: To: , , , X-OriginalArrivalTime: 08 Dec 2009 09:31:15.0597 (UTC) FILETIME=[305D0BD0:01CA77E9] Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 09:31:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA77E9.2FC2D3F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Christian, I fully agree with you for addresses allocated to state-full translators = like NAT64.=20 For load balancing and resilience an operator may need to have more than = one translators (usually 2, located in different area for security = consideration) synchronized and able to serve the same customers.=20 In my humble opinion suffix should be 0 because this address is really = an anycast address representing the sub-network of all synchronized = translators (2 in my example) sharing the same states and serving the = same customers. But the problem I want to raise is different and specific to some = stateless translator. So I will give an example: If an operator want to migrate the network toward a pure Pv6 network = (for example to solve problem of overlapping private IPv4 address plan, = the operator of a corporate network may migrate to a pure IPv6 = addressing plan). But this operator needs to install a web server on = this network with a public IPv4 address so that it can be reached also = by IPv4 users through state-less translator. So what is the best = translatable IPv6 address for this IPv4/IPv6 web server ? * Is it a translatable IPv6 address with a null suffix and a /96 prefix, = but routing /96 prefix in the corporate network is heavy? * Is it a translatable IPv6 address with a null suffix and a prefix = shorter than 64, but the link local prefix cannot be used for local = management? * Is it a the IPv6 6RD address format described in = http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-01 but this = format is designed to allocate IPv6 addresses to IPv4 host and not for = IPv4 hosts on IPv6 network ? Best regards. Eric BURGEY=20 -----Message d'origine----- De : Christian Huitema [mailto:huitema@microsoft.com]=20 Envoy=E9 : lundi 7 d=E9cembre 2009 19:52 =C0 : BURGEY Eric RD-CORE-ISS; xing@cernet.edu.cn; behave@ietf.org; = behave-chairs@tools.ietf.org Objet : RE: [BEHAVE] address-format: null suffix, consensus check Eric, We did consider this type of design before writing the current proposal. = For example, one proposal was to always copy the IPv4 address in bits = 96-127 of the embedded address, even if that copy was a duplicate. That = proposal was discarded for two reasons: 1) Duplicating data is generally a bad idea, as it forces the = translators to deal with a new class or errors, when the supposedly = duplicated values don't match. 2) Using the bits rather than reserving them precludes future = extensions, and we are not certain enough of our choices to want to do = that. Note that administrators who want the addresses copied in the last bits = can achieve that by selecting the /96 prefix of their choice. = Administrators who want fine grain control on the mappings can also = statically configure stateful mappings for some IPv4/IPv6 pairs, much = like the "DMZ mapping" functions of the current crop of NAT44. -- Christian Huitema From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of eric.burgey@orange-ftgroup.com Sent: Monday, December 07, 2009 9:07 AM To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] address-format: null suffix, consensus check Hello, If i truly understand the slides the scope of the document is covering = both: "IPv4 translatable" IPv6 address "IPv4 converted" IPv6 address. In slide 4 you say that both must use the same prefix and I agree. But in my humble opinion there is no need to have the same suffix = requirement for all different cases. For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a = good solution. But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, = such IPv6 address can be assigned on a local network to an host that is = not a routers but a simple end host. In such case, it may be interesting = to use the most significant part of the IPv6 address as local network = prefix (usually a /64 prefix). In that case the least significant part = of the address is not the Ethernet interface address (U=3D0) but in = accordance with RFC4291 this part may be used with the link local prefix = instead of the local network prefix. But if the suffix is 0 this address = is not unique on the local network. This problem can be solved by = copying the part of the IPv4 address that is in the prefix (in the 64 = most significant bit) in the suffix and adding a 24 bit long host = identifier if the IPv4 address is not unique. I suggest to put the = redundant part of the IPv4 address in the lest significant bit and the = host identifier between the non redundant part of IPv4 address and the = redundant part so that the host identifier can be used also as = sub-network identifier to route the packet toward the appropriate host = if needed. Example : = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| = 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127 = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | Host ID | V4 (32) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | Host ID |V4 = (16)| = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | Host ID = |(8)| = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | Host ID = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix | v4(32) = | = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ So for "IPv4 converted" IPv6 address used with a NAT64 translator the = suffix should be 0. But for "IPv4 translatable" address I think that the choice of the = suffix must be open and must be chosen according the "IPv4 translatable" = address usage. Having different suffix value may be helpful, it can be used in a = referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 = translatable" address if the length of the prefix is known and different = from /96 (this is needed to extract the IPv4 address from the format). Best regards, Eric BURGEY Orange Labs -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Xing Li Envoy=E9 : dimanche 6 d=E9cembre 2009 10:59 =C0 : 'Behave WG'; Behave Chairs Objet : [BEHAVE] address-format: null suffix, consensus check Hi, All, In the draft-ietf-behave-address-format-01.txt, the document reads: When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt Please confirm if we should keep the current conclusion. Regards, xing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01CA77E9.2FC2D3F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [BEHAVE] address-format: null suffix, consensus check

Hello Christian,

I fully agree with you for addresses allocated to state-full = translators like NAT64. =

For load balancing and resilience an operator may need = to have more than one translators (usually 2, located in different area for security = consideration) synchronized and able to serve the same customers. =

In my humble opinion suffix should be 0 = because this address is really an anycast address representing the = sub-network of all synchronized translators (2 in my example) sharing the same states and serving the same customers.

But the problem I want to raise is different and specific to = some stateless translator. So = I will give an = example:

If an operator want to migrate the = network toward a pure Pv6 = network (for example to solve problem = of overlapping private IPv4 address plan, the operator of a corporate network = may migrate to a pure IPv6 = addressing plan). But this operator needs to = install = a web server on this network with a public IPv4 address so = that it can be reached also by IPv4 users through state-less translator. So what is the best translatable IPv6 = address for this IPv4/IPv6 web server ?

·       = Is it a translatable = IPv6 address with a null suffix and a /96 = prefix, but routing /96 prefix in the corporate network is heavy?

·       = Is it a translatable IPv6 address = with a null suffix and a prefix shorter = than 64, but the link local prefix cannot be used for local management?

·       = Is it a the IPv6 6RD = address format described = in  http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-01  but this = format is designed to allocate IPv6 addresses to IPv4 host and not for = IPv4 hosts on IPv6 network = ?

Best regards.

        Eric BURGEY =

-----Message d'origine-----
De=A0: Christian Huitema [mailto:huitema@microsoft.com] Envoy=E9=A0: lundi 7 d=E9cembre 2009 19:52
=C0=A0: BURGEY = Eric RD-CORE-ISS; xing@cernet.edu.cn; behave@ietf.org; = behave-chairs@tools.ietf.org
Objet=A0: RE: [BEHAVE] address-format: null suffix, = consensus check

Eric,

We = did consider this type of design before writing the current proposal. = For example, one proposal was to always copy the IPv4 address in bits = 96-127 of the embedded address, even if that copy was a duplicate. That = proposal was discarded for two reasons:

1) = Duplicating data is generally a bad idea, as it forces the translators = to deal with a new class or errors, when the supposedly duplicated = values don't match.

2) = Using the bits rather than reserving them precludes future extensions, = and we are not certain enough = of our choices to want to do that.

Note = that administrators who want the addresses copied in the last bits can = achieve that by selecting the /96 prefix of their choice. Administrators = who want fine grain control on the mappings can also = statically configure stateful = mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" = functions of the current crop of NAT44.

-- = Christian Huitema








From: = behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of eric.burgey@orange-ftgroup.com

Sent: = Monday, December 07, 2009 9:07 AM

To: = xing@cernet.edu.cn; behave@ietf.org; = behave-chairs@tools.ietf.org

Subject: Re: [BEHAVE] address-format: null suffix, consensus = check

Hello,

If i = truly understand the slides the scope of the document is covering both:

"IPv4 translatable" IPv6 address

"IPv4 converted" IPv6 address.

In = slide 4 you say that both must use the same prefix and I = agree.

But = in my humble opinion there is no need to have the same suffix = requirement for all different cases.

For = "IPv4 converted" IPv6 address used by a NAT64 the null suffix = is a good solution.

But = as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 = hosts, such IPv6 address can be assigned on a local network to an host = that is not a routers but a simple end host. In such case, it may be interesting to use the most = significant part of the IPv6 address as local network prefix (usually a = /64 prefix). In that case the least significant part of the address is = not the Ethernet interface address (U=3D0) but in accordance with RFC4291 this part may be used with the link local = prefix instead of the local network prefix. But if the suffix is 0 this = address is not unique on the local network. This problem can be solved = by copying the part of the IPv4 address that is in the = prefix (in the 64 most significant bit) in the suffix and adding a 24 = bit long host identifier if the IPv4 address is not unique. I suggest to = put the redundant part of the IPv4 address in the lest significant bit = and the host identifier between the non redundant part of = IPv4 address and the redundant part so that the host identifier can be = used also as sub-network identifier to route the packet toward the = appropriate host if needed.

Example :

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |PLEN| = 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127<= /SPAN>

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/32 |     = prefix    = |v4(32)         | u = |   Host ID |     V4 (32)   = |

    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/40 |     = prefix        = |v4(24)     | u |(8)|  Host ID  | V4 = (24)   |

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/48 |     = prefix            = |v4(16) | u | (16)  | = Host ID   |V4 (16)|

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/56 |     = prefix           &= nbsp;    |(8)| u |  v4(24)   | Host = ID   |(8)|

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/64 |     = prefix           &= nbsp;        | u |   = v4(32)      | Host ID   = |

    = +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    |/96 |     = prefix           &= nbsp;           &n= bsp;            = |   v4(32)      |

    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



So = for "IPv4 converted" IPv6 address used with a NAT64 translator = the suffix should be 0.

But = for "IPv4 translatable" address I think that the choice of the = suffix must be open and must be chosen according the "IPv4 translatable" address = usage.

Having different suffix value may be helpful, it can be used in a = referral to distinguish an "IPv4 converted" IPv6 address from = an "IPv4 translatable" address if the length of the prefix is = known and different from /96 (this is needed to extract the IPv4 = address from the format).

Best = regards,


        =         Eric BURGEY

            = Orange Labs

-----Message d'origine-----

De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Xing Li

Envoy=E9=A0: dimanche 6 = d=E9cembre 2009 10:59

=C0=A0: 'Behave WG'; = Behave = Chairs

Objet=A0: [BEHAVE] address-format: null suffix, consensus = check

Hi, = All,

In = the draft-ietf-behave-address-format-01.txt, the document = reads:

When = a /32 prefix is used, the null suffix results in a = null

identifier. We understand the conflict with Section 2.6.1 of

RFC4291, which specifies that all zeroes are used for the = subnet-

router anycast address. However, in our specification, there = would

be = only one IPv4 translatable host in the /64 subnet, and the = anycast

semantic would not create confusion. We thus decided to keep the

null = suffix for now. (Different authors of this document = have

different opinions.)

An = example which support the above argument is presented in page 18 = of

http:/= /www.ietf.org/proceedings/09nov/slides/behave-5.ppt

=

Please confirm if we should keep the current = conclusion.

Regards,

xing



_______________________________________________

Behave mailing list

Behave@ietf.org

https://www.ietf.or= g/mailman/listinfo/behave

------_=_NextPart_001_01CA77E9.2FC2D3F6-- From remi.despres@free.fr Tue Dec 8 03:26:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6190D3A69E9; Tue, 8 Dec 2009 03:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-B5Q1ffRHzz; Tue, 8 Dec 2009 03:26:51 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 348B13A68CF; Tue, 8 Dec 2009 03:26:46 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id A6581E0803A; Tue, 8 Dec 2009 12:26:31 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3556AE08028; Tue, 8 Dec 2009 12:26:26 +0100 (CET) Message-ID: <4B1E37E0.9070505@free.fr> Date: Tue, 08 Dec 2009 12:26:24 +0100 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: behave@ietf.org, ipv6@ietf.org References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> In-Reply-To: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Xu Xiaohu Subject: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 11:26:52 -0000 Hi all, Xu Xiaohu wrote (in the Behave discussion thread) : > My question is: Should the IPv4-embeded IPv6 address still be in > accordance with the specification defined in RFC4291 as "...For all > unicast addresses, except those that start with the binary value 000, > Interface IDs are required to be 64 bits long and to be constructed > in Modified EUI-64 format..."? > If the answer is yes, why? +1 in favor of this question being answered by those who know the history. (This question is a recurring one, AFAIK not answered so far.) > (In other words, is there any practical meaning/usage for that > constraint in the IPv4/IPv6 translation process?) If no reason for the current constraint is reported, the real constraint could be weaker, becoming for example: "...For all unicast addresses other than those that start with the binary value 000, and that are used as destinations on IPv6 links having /64 subnet prefixes, Interface IDs are required to be constructed in Modified EUI-64 format." To be complete, it could be added that: "If new formats are defined in the future for such Interface IDs, they should be distinguishable from the Modified EUI-64 format, i.e. should have their two lower bits of the first octet both set to 1" NOTE: IPv4-translatable and IPv4-converted IPv6 address formats are being defined in conformance with the Modified EUI-64 format constraint. *This doesn't need to change.* (Even if not technically necessary, this conformance permits to freeze the specification, which is urgent, without waiting for the above question to be resolved.) Regards, RD From xing@cernet.edu.cn Tue Dec 8 06:13:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BF23A6405 for ; Tue, 8 Dec 2009 06:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj8iydCekhwQ for ; Tue, 8 Dec 2009 06:13:03 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id CB1F528C12C for ; Tue, 8 Dec 2009 06:13:00 -0800 (PST) Received: from [192.168.1.100]([123.112.75.227]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4b1e9955; Tue, 08 Dec 2009 22:12:28 +0800 Message-ID: <4B1E5D2E.2000501@cernet.edu.cn> Date: Tue, 08 Dec 2009 22:05:34 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christian Huitema References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: hRknASXB Cc: "eric.burgey@orange-ftgroup.com" , "behave@ietf.org" , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:13:06 -0000 Christian Huitema =E5=86=99=E9=81=93: > Eric, > > We did consider this type of design before writing the current proposal= =2E For example, one proposal was to always copy the IPv4 address in bits= 96-127 of the embedded address, even if that copy was a duplicate. That = proposal was discarded for two reasons: > > 1) Duplicating data is generally a bad idea, as it forces the translato= rs to deal with a new class or errors, when the supposedly duplicated val= ues don't match. > > 2) Using the bits rather than reserving them precludes future extension= s, and we are not certain enough of our choices to want to do that. > > Note that administrators who want the addresses copied in the last bits= can achieve that by selecting the /96 prefix of their choice. Administra= tors who want fine grain control on the mappings can also statically conf= igure stateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapp= ing" functions of the current crop of NAT44. > > -- Christian Huitema > > > =20 Agree. xing > > > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behal= f Of eric.burgey@orange-ftgroup.com > Sent: Monday, December 07, 2009 9:07 AM > To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] address-format: null suffix, consensus check > > Hello, > > If i truly understand the slides the scope of the document is covering = both: > "IPv4 translatable" IPv6 address > "IPv4 converted" IPv6 address. > > In slide 4 you say that both must use the same prefix and I agree. > > But in my humble opinion there is no need to have the same suffix requi= rement for all different cases. > For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a = good solution. > > But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts,= such IPv6 address can be assigned on a local network to an host that is = not a routers but a simple end host. In such case, it may be interesting = to use the most significant part of the IPv6 address as local network pre= fix (usually a /64 prefix). In that case the least significant part of th= e address is not the Ethernet interface address (U=3D0) but in accordance= with RFC4291 this part may be used with the link local prefix instead of= the local network prefix. But if the suffix is 0 this address is not uni= que on the local network. This problem can be solved by copying the part = of the IPv4 address that is in the prefix (in the 64 most significant bit= ) in the suffix and adding a 24 bit long host identifier if the IPv4 addr= ess is not unique. I suggest to put the redundant part of the IPv4 addres= s in the lest significant bit and the host identifier between the non red= undant part of IPv4 address and the redundant part so that the host ident= ifier can be used also as sub-network identifier to route the packet towa= rd the appropriate host if needed. > > Example : > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-12= 0-127 > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/32 | prefix |v4(32) | u | Host ID | V4 (32) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/48 | prefix |v4(16) | u | (16) | Host ID |V4 (1= 6)| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/56 | prefix |(8)| u | v4(24) | Host ID |(= 8)| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/64 | prefix | u | v4(32) | Host ID = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/96 | prefix | v4(32) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > > > > So for "IPv4 converted" IPv6 address used with a NAT64 translator the s= uffix should be 0. > But for "IPv4 translatable" address I think that the choice of the suff= ix must be open and must be chosen according the "IPv4 translatable" addr= ess usage. > > Having different suffix value may be helpful, it can be used in a refer= ral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 transla= table" address if the length of the prefix is known and different from /9= 6 (this is needed to extract the IPv4 address from the format). > > Best regards, > > > Eric BURGEY > Orange Labs > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la par= t de Xing Li > Envoy=C3=A9 : dimanche 6 d=C3=A9cembre 2009 10:59 > =C3=80 : 'Behave WG'; Behave Chairs > Objet : [BEHAVE] address-format: null suffix, consensus check > > Hi, All, > > In the draft-ietf-behave-address-format-01.txt, the document reads: > > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) > > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt > > Please confirm if we should keep the current conclusion. > > Regards, > > xing > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > =20 From xing@cernet.edu.cn Tue Dec 8 06:14:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DBC28C137 for ; Tue, 8 Dec 2009 06:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.219 X-Spam-Level: X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZWmF53e8UFK for ; Tue, 8 Dec 2009 06:14:08 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 39E853A6405 for ; Tue, 8 Dec 2009 06:14:06 -0800 (PST) Received: from [192.168.1.100]([123.112.75.227]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104b1e9952; Tue, 08 Dec 2009 22:12:26 +0800 Message-ID: <4B1E5CD9.6080009@cernet.edu.cn> Date: Tue, 08 Dec 2009 22:04:09 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: eric.burgey@orange-ftgroup.com References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: hQinASXB Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:14:09 -0000 eric.burgey@orange-ftgroup.com 写é“: > > Hello, > > If i truly understand the slides the scope of the document is covering > both: > > "IPv4 translatable" IPv6 address > > "IPv4 converted" IPv6 address. > > In slide 4 you say that both must use the same prefix and I agree. > > But in my humble opinion there is no need to have the same suffix > requirement for all different cases. > > For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a > good solution. > > But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 > hosts, such IPv6 address can be assigned on a local network to an host > that is not a routers but a simple end host. In such case, it may be > interesting to use the most significant part of the IPv6 address as > local network prefix (usually a /64 prefix). In that case the least > significant part of the address is not the Ethernet interface address > (U=0) but in accordance with RFC4291 this part may be used with the > link local prefix instead of the local network prefix. But if the > suffix is 0 this address is not unique on the local network. This > problem can be solved by copying the part of the IPv4 address that is > in the prefix (in the 64 most significant bit) in the suffix and > adding a 24 bit long host identifier if the IPv4 address is not > unique. I suggest to put the redundant part of the IPv4 address in the > lest significant bit and the host identifier between the non redundant > part of IPv4 address and the redundant part so that the host > identifier can be used also as sub-network identifier to route the > packet toward the appropriate host if needed. > > Example : > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127 > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/32 | prefix |v4(32) | u | Host ID | V4 (32) | > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) | > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/48 | prefix |v4(16) | u | (16) | Host ID |V4 (16)| > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/56 | prefix |(8)| u | v4(24) | Host ID |(8)| > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/64 | prefix | u | v4(32) | Host ID | > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |/96 | prefix | v4(32) | > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > So for "IPv4 converted" IPv6 address used with a NAT64 translator the > suffix should be 0. > > But for "IPv4 translatable" address I think that the choice of the > suffix must be open and must be chosen according the "IPv4 > translatable" address usage. > Then this will cause the referral problem again, similar to the one when IPv4-translatable address and IPv4-converted address are using different prefixes. The details of the discussion can be found in http://www.ietf.org/proceedings/75/slides/behave-11.pdf. regards, xing > Having different suffix value may be helpful, it can be used in a > referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 > translatable" address if the length of the prefix is known and > different from /96 (this is needed to extract the IPv4 address from > the format). > > Best regards, > > Eric BURGEY > > Orange Labs > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la > part de Xing Li > Envoyé : dimanche 6 décembre 2009 10:59 > À : 'Behave WG'; Behave Chairs > Objet : [BEHAVE] address-format: null suffix, consensus check > > Hi, All, > > In the draft-ietf-behave-address-format-01.txt, the document reads: > > When a /32 prefix is used, the null suffix results in a null > > identifier. We understand the conflict with Section 2.6.1 of > > RFC4291, which specifies that all zeroes are used for the subnet- > > router anycast address. However, in our specification, there would > > be only one IPv4 translatable host in the /64 subnet, and the anycast > > semantic would not create confusion. We thus decided to keep the > > null suffix for now. (Different authors of this document have > > different opinions.) > > An example which support the above argument is presented in page 18 of > > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt > > Please confirm if we should keep the current conclusion. > > Regards, > > xing > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From huitema@microsoft.com Tue Dec 8 07:42:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6F528C157 for ; Tue, 8 Dec 2009 07:42:46 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDBu9v2yuF0n for ; Tue, 8 Dec 2009 07:42:35 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C873928C152 for ; Tue, 8 Dec 2009 07:42:35 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Dec 2009 07:42:25 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Tue, 8 Dec 2009 07:42:25 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 8 Dec 2009 07:42:15 -0800 From: Christian Huitema To: "eric.burgey@orange-ftgroup.com" , "xing@cernet.edu.cn" , "behave@ietf.org" , "behave-chairs@tools.ietf.org" Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdlra5vNbCwCh3EmLNErZhGqem5FaWLiA//+UaZCAAO0JUIAAcmZg Date: Tue, 8 Dec 2009 15:42:10 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F44B3@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <08BA2C59E081884DB2AAE4A0BE9D6DC1A788A8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1A788A8@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B55F0F93C3E9D45AF283313B8D342BA211F44B3TK5EX14MBXW652w_" MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 15:42:46 -0000 --_000_6B55F0F93C3E9D45AF283313B8D342BA211F44B3TK5EX14MBXW652w_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In practice, the "web server" that you describe is not a single server, but= a set of servers managed by some load balancing system. We can speculate a= bout the best way to manage that, but it would be nice to get actual implem= entation reports, including the load balancing aspects. From: eric.burgey@orange-ftgroup.com [mailto:eric.burgey@orange-ftgroup.com= ] Sent: Tuesday, December 08, 2009 1:31 AM To: Christian Huitema; xing@cernet.edu.cn; behave@ietf.org; behave-chairs@t= ools.ietf.org Subject: RE: [BEHAVE] address-format: null suffix, consensus check Hello Christian, I fully agree with you for addresses allocated to state-full translators li= ke NAT64. For load balancing and resilience an operator may need to have more than on= e translators (usually 2, located in different area for security considerat= ion) synchronized and able to serve the same customers. In my humble opinion suffix should be 0 because this address is really an a= nycast address representing the sub-network of all synchronized translators= (2 in my example) sharing the same states and serving the same customers. But the problem I want to raise is different and specific to some stateless= translator. So I will give an example: If an operator want to migrate the network toward a pure Pv6 network (for e= xample to solve problem of overlapping private IPv4 address plan, the opera= tor of a corporate network may migrate to a pure IPv6 addressing plan). But= this operator needs to install a web server on this network with a public = IPv4 address so that it can be reached also by IPv4 users through state-les= s translator. So what is the best translatable IPv6 address for this IPv4/I= Pv6 web server ? * Is it a translatable IPv6 address with a null suffix and a /96 pref= ix, but routing /96 prefix in the corporate network is heavy? * Is it a translatable IPv6 address with a null suffix and a prefix s= horter than 64, but the link local prefix cannot be used for local manageme= nt? * Is it a the IPv6 6RD address format described in http://tools.ietf= .org/html/draft-ietf-softwire-ipv6-6rd-01 but this format is designed to a= llocate IPv6 addresses to IPv4 host and not for IPv4 hosts on IPv6 network = ? Best regards. Eric BURGEY -----Message d'origine----- De : Christian Huitema [mailto:huitema@microsoft.com] Envoy=E9 : lundi 7 d=E9cembre 2009 19:52 =C0 : BURGEY Eric RD-CORE-ISS; xing@cernet.edu.cn; behave@ietf.org; behave-= chairs@tools.ietf.org Objet : RE: [BEHAVE] address-format: null suffix, consensus check Eric, We did consider this type of design before writing the current proposal. Fo= r example, one proposal was to always copy the IPv4 address in bits 96-127 = of the embedded address, even if that copy was a duplicate. That proposal w= as discarded for two reasons: 1) Duplicating data is generally a bad idea, as it forces the translators t= o deal with a new class or errors, when the supposedly duplicated values do= n't match. 2) Using the bits rather than reserving them precludes future extensions, a= nd we are not certain enough of our choices to want to do that. Note that administrators who want the addresses copied in the last bits can= achieve that by selecting the /96 prefix of their choice. Administrators w= ho want fine grain control on the mappings can also statically configure st= ateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" funct= ions of the current crop of NAT44. -- Christian Huitema From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= eric.burgey@orange-ftgroup.com Sent: Monday, December 07, 2009 9:07 AM To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] address-format: null suffix, consensus check Hello, If i truly understand the slides the scope of the document is covering both= : "IPv4 translatable" IPv6 address "IPv4 converted" IPv6 address. In slide 4 you say that both must use the same prefix and I agree. But in my humble opinion there is no need to have the same suffix requireme= nt for all different cases. For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a good= solution. But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, suc= h IPv6 address can be assigned on a local network to an host that is not a = routers but a simple end host. In such case, it may be interesting to use t= he most significant part of the IPv6 address as local network prefix (usual= ly a /64 prefix). In that case the least significant part of the address is= not the Ethernet interface address (U=3D0) but in accordance with RFC4291 = this part may be used with the link local prefix instead of the local netwo= rk prefix. But if the suffix is 0 this address is not unique on the local n= etwork. This problem can be solved by copying the part of the IPv4 address = that is in the prefix (in the 64 most significant bit) in the suffix and ad= ding a 24 bit long host identifier if the IPv4 address is not unique. I sug= gest to put the redundant part of the IPv4 address in the lest significant = bit and the host identifier between the non redundant part of IPv4 address = and the redundant part so that the host identifier can be used also as sub-= network identifier to route the packet toward the appropriate host if neede= d. Example : +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-12= 7 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | Host ID | V4 (32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | Host ID |V4 (16)| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | Host ID |(8)| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | Host ID | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix | v4(32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ So for "IPv4 converted" IPv6 address used with a NAT64 translator the suffi= x should be 0. But for "IPv4 translatable" address I think that the choice of the suffix m= ust be open and must be chosen according the "IPv4 translatable" address us= age. Having different suffix value may be helpful, it can be used in a referral = to distinguish an "IPv4 converted" IPv6 address from an "IPv4 translatable"= address if the length of the prefix is known and different from /96 (this = is needed to extract the IPv4 address from the format). Best regards, Eric BURGEY Orange Labs -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Xing Li Envoy=E9 : dimanche 6 d=E9cembre 2009 10:59 =C0 : 'Behave WG'; Behave Chairs Objet : [BEHAVE] address-format: null suffix, consensus check Hi, All, In the draft-ietf-behave-address-format-01.txt, the document reads: When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.) An example which support the above argument is presented in page 18 of http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt Please confirm if we should keep the current conclusion. Regards, xing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_6B55F0F93C3E9D45AF283313B8D342BA211F44B3TK5EX14MBXW652w_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [BEHAVE] address-format: null suffix, consensus check

In practice, the “web server” that you describe = is not a single server, but a set of servers managed by some load balancing system. We can speculate about the best way to manage that, but it would be nice to get ac= tual implementation reports, including the load balancing aspects.

 

From: eric.burgey@orange-ftgroup.com [mailto:eric.burgey@orange-ftgroup.com]
Sent: Tuesday, December 08, 2009 1:31 AM
To: Christian Huitema; xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org
Subject: RE: [BEHAVE] address-format: null suffix, consensus check

 

= Hello Christian,

= I fully agree with you for addresses allocated to = state-ful= l translators like NAT64.

= For load balancing and resilience an operator may need to have m= ore than one translators (usually = 2, located in different area for security consideration) synchron= ized and able to serve the same customers.

= In my humble opinion suffix should be 0 because this address is really an anycast address representing the sub-network of all synchronized translators (2 in = my example) sharing the same states and serving the same customers.

= But the problem I want to raise is diffe= rent and specific to some stateless translator. So= I will give an example:

= If an operator want to migrate the network toward a pure Pv6 network (for example to solve = problem of overlapping private I= Pv4 address plan, the opera= tor of a corporate network may migrate to a pure IPv6 addressing plan).= But this = operator needs to install a web serve= r on this network with a public IPv4 address so that <= /span>it can be= reached also by IPv4 users through state-less translator.= So what i= s the best translatable IPv6 address for this IPv4/IPv6 web server ?<= /o:p>

=B7 &nb= sp;     Is it a translatable IPv6 address with a null suffix and a /96 pre= fix, but routing /96 prefix in the corporate network is heavy?

=B7 &nb= sp;     Is it a translatable IPv6 address with a null suffix and a prefix shorter than= 64, but the link local prefix cannot be used for loc= al management?

=B7 &nb= sp;     Is it a the IPv6 6RD address format described in  http://to= ols.ietf.org/html/draft-ietf-softwire-ipv6-6rd-01  bu= t this format is designed to allocate IPv6 addresses to IPv4 host and not for IPv4 hosts on IPv6 network ?

= Best regards.

        Eric BURG= EY

---= --Message d'origine-----
De : Christian Huitema [mailto:huitema@microsoft.com]
Envoy=E9 : lundi 7 d=E9cembre 2009 19:52
=C0 : BURGEY Eric RD-CORE-ISS; xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org
Objet : RE: [BEHAVE] address-format: null suffix, consensus check

Eri= c,

We = did consider this type of design before writing the current proposal. For examp= le, one proposal was to always copy the IPv4 address in bits 96-127 of the embe= dded address, even if that copy was a duplicate. That proposal was discarded for= two reasons:

1) Duplicating data is generally a bad idea, as it forces the translators to d= eal with a new class or errors, when the supposedly duplicated values don't mat= ch.

2) = Using the bits rather than reserving them precludes future extensions, and we are= not certain enough of our choices to want to do that.

Not= e that administrators who want the addresses copied in the last bits can achieve t= hat by selecting the /96 prefix of their choice. Administrators who want fine g= rain control on the mappings can also statically configure stateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" functions of th= e current crop of NAT44.

-- Christian Huitema







Fro= m: behave-bounces@ietf.org [mailto:= behave-bounces@ietf.org] On Behalf Of eric.burgey@orange-ftgroup.com

Sen= t: Monday, December 07, 2009 9:07 AM

To:= xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org

Sub= ject: Re: [BEHAVE] address-format: null suffix, consensus check=

Hel= lo,

If = i truly understand the slides the scope of the document is covering both:

&qu= ot;IPv4 translatable" IPv6 address

&qu= ot;IPv4 converted" IPv6 address.

In = slide 4 you say that both must use the same prefix and I agree.

But= in my humble opinion there is no need to have the same suffix requirement for all different cases.

For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is = a good solution.

But= as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, = such IPv6 address can be assigned on a local network to an host that is not a routers but a simple end host. In such case, it may be interesting to use t= he most significant part of the IPv6 address as local network prefix (usually = a /64 prefix). In that case the least significant part of the address is not = the Ethernet interface address (U=3D0) but in accordance w= ith RFC4291 this part may be used with the link local prefix instead of the loc= al network prefix. But if the suffix is 0 this address is not unique on the lo= cal network. This problem can be solved by copying the part of the IPv4 address that is in the prefix (in the 64 most significant bit) i= n the suffix and adding a 24 bit long host identifier if the IPv4 address is = not unique. I suggest to put the redundant part of the IPv4 address in the lest significant bit and the host identifier between the non redundant part of I= Pv4 address and the redundant part so that the host identifier can be used also= as sub-network identifier to route the packet toward the appropriate host if needed.

Exa= mple :

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/32 |     prefix    |v4(32)         | u |   H= ost ID |     V4 (32)   |

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/40 |     prefix      &n= bsp; |v4(24)     | u |(8)|  Host ID  | V4 (24)   |

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/48 |     prefix            |v4(16) | u | (16)  | Host ID   |V4 (16)|<= /p>

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/56 |     prefix           &nb= sp;    |(8)| u |  v4(24)   | Host ID   |(8)|<= /o:p>

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/64 |     prefix           &nb= sp;        | u |   v4(32)      | Host ID  = ; |

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

&nb= sp;   |/96 |     prefix           &nb= sp;            =             |   v4(32)      |

&nb= sp;   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

 

So = for "IPv4 converted" IPv6 address used with a NAT64 translator the su= ffix should be 0.

But= for "IPv4 translatable" address I think that the choice of the suffix must be open and must be chosen according the "IPv4 translatable" address usage.

Hav= ing different suffix value may be helpful, it can be used in a referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 translatable" address if the length of the prefix is known and differe= nt from /96 (this is needed to extract the IPv4 = address from= the format).

Bes= t regards,

 

                Eric BURGEY

&nb= sp;           Orange Labs

---= --Message d'origine-----

De&= nbsp;: behave-bounces@ietf.org [mailto:= behave-bounces@ietf.org] De la part de Xing Li

Env= oy=E9 : dimanche 6 d=E9cembre 2009 10:59

=C0=  : 'Behave WG'; Behave Chairs

Obj= et : [BEHAVE] address-format: null suffix, consensus check

Hi,= All,

In = the draft-ietf-behave-address-format-01.txt, the document reads:

Whe= n a /32 prefix is used, the null suffix results in a null

ide= ntifier. We understand the conflict with Section 2.6.1 of

RFC= 4291, which specifies that all zeroes are used for the subnet-<= /p>

rou= ter anycast address. However, in our specification, there would

be = only one IPv4 translatable host in the /64 subnet, and the anycast=

sem= antic would not create confusion. We thus decided to kee= p the

nul= l suffix for now. (Different authors of this document have

dif= ferent opinions.)

An = example which support the above argument is presented in page 18 of

http://w= ww.ietf.org/proceedings/09nov/slides/behave-5.ppt

Ple= ase confirm if we should keep the current conclusion.

Reg= ards,

xin= g

 

___= ____________________________________________

Beh= ave mailing list

Beh= ave@ietf.org

https://www.ietf.org/= mailman/listinfo/behave

--_000_6B55F0F93C3E9D45AF283313B8D342BA211F44B3TK5EX14MBXW652w_-- From phdgang@gmail.com Tue Dec 8 07:50:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F54B28C11F for ; Tue, 8 Dec 2009 07:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oqXfAPcwvED for ; Tue, 8 Dec 2009 07:50:01 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 801773A63D3 for ; Tue, 8 Dec 2009 07:50:01 -0800 (PST) Received: by iwn33 with SMTP id 33so4022239iwn.29 for ; Tue, 08 Dec 2009 07:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yRV2y39KAa4LSthJhbeMeXy4MFXqhhatJNiv67AYFD4=; b=bVRRf0QVmdIuzM/COD1o6NkCOdeqv+hU6PoDWQVbs/f6DtSmWBcgkSbiDzKQjI3jfh ZYZ0LJHPS19J9BYHKELTlG3LnJwmsGOZI15+jvw3tIU8izKeiGYIof8Dd13B8DSIuNnL +crQ8FWOjZ78DtOCq/XQGGMdFnMC+VT50Mi68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gjSQ+Z9sz1C/iNGkNjF2eoQtfOUH5mWsenRjuomrmjiSElMO14vTK8YXn7lRi/mmRp TwKc6L0j8U/mCyePJYLhUp0UYiWid19dX0AX5W4VJuTSg0M9+Tl9+qFRPRe2hwKAJufA PTf5eoDkkL/qTNbSr38CnqWfoVg0bLKZMlUL4= MIME-Version: 1.0 Received: by 10.231.167.212 with SMTP id r20mr1155490iby.7.1260287386797; Tue, 08 Dec 2009 07:49:46 -0800 (PST) In-Reply-To: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> Date: Tue, 8 Dec 2009 23:49:46 +0800 Message-ID: <36ba02b00912080749t1c404ea2paa631f09f31ed466@mail.gmail.com> From: GangChen To: Dan Wing Content-Type: multipart/alternative; boundary=001636c5a4bd014592047a3986b6 Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 15:50:03 -0000 --001636c5a4bd014592047a3986b6 Content-Type: text/plain; charset=ISO-8859-1 Hello Dan, I found the title of "framework for IPv6/IPv4" might have mismatched hyperlink, which is address format link. And I would like to review the "framework for IPv6/IPv4" if it is possible. Thanks Gang 2009/12/5 Dan Wing > As a reminder, we have an interim WebEx teleconference on Wednesday, > December > 16, at 7am Pacific Time. The December 16 teleconference will resolve all > open > issues with the following documents so they may be immediately WGLC'd > (dates > are Behave's milestone dates from our charter): > > Dec 2009 - Submit to IESG: framework for IPv6/IPv4 translation (info) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Dec 2009 - Submit to IESG: stateless IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > Dec 2009 - Submit to IESG: stateful IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-dns64 > Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > http://tools.ietf.org/id/draft-ietf-behave-ftp64 > (currently http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06) > > REVIEWERS ARE NEEDED! Please volunteer to review one, two, or all > documents. > WGLC is expected to start on December 17 and end December 31. To finish > WGLC, > we need 5 reviews indicating the document is ready. One person has > volunteered so far (thanks, Flemming). If you are willing to review, > please > send information to Dan. > > Agenda for the interim is at: > http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart > > If you have additional agenda items, which we should discuss to prepare > those > documents for WGLC, please email the chairs. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --001636c5a4bd014592047a3986b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Dan,
=A0
I found the title of "framework=A0for IPv6/IPv4" might have = mismatched hyperlink, which is address format link.
=A0
And I would like to review the "framework for IPv6/IPv4" if = it is possible.
=A0
Thanks
=A0
Gang
=A0
=A0
=A0
2009/12/5 Dan Wing <dwing@cisco.com>
As a reminder, we have an interi= m WebEx teleconference on Wednesday, December
16, at 7am Pacific Time. = =A0The December 16 teleconference will resolve all open
issues with the following documents so they may be immediately WGLC'd (= dates
are Behave's milestone dates from our charter):

=A0Dec = 2009 - Submit to IESG: =A0framework for IPv6/IPv4 translation (info)
=A0= http://tools.ietf.org/html/draft-ietf-behave-address-format<= /a>
=A0Dec 2009 - Submit to IESG: =A0stateless IPv6/IPv4 translation (std)
= =A0http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate=A0Dec 2009 - Submit to IESG: =A0stateful IPv6/IPv4 translation (std)
=A0http://tools.ietf.org/html/draft-ietf-behave-v6v4-xl= ate-stateful
=A0Dec 2009 - Submit to IESG: =A0DNS rewriting for IPv6= /IPv4 translation (std)
=A0http://tools.ietf.org/html/draft-ietf-behave-dns64
=A0Jan 2= 010 - Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 translator (std)
=A0<= a href=3D"http://tools.ietf.org/html/draft-ietf-behave-address-format" targ= et=3D"_blank">http://tools.ietf.org/html/draft-ietf-behave-address-format
=A0Jan 2010 - Submit to IESG: =A0FTP ALG for IPv6/IPv4 translation (std)=A0http://tools.ietf.org/id/draft-ietf-behave-ftp64
=A0(current= ly http://tools.ietf.org/html/draft-van-beijnum-behave-ftp6= 4-06)

REVIEWERS ARE NEEDED! =A0Please volunteer to review one, two, or all do= cuments.
WGLC is expected to start on December 17 and end December 31. = =A0To finish WGLC,
we need 5 reviews indicating the document is ready. = =A0One person has
volunteered so far (thanks, Flemming). =A0If you are willing to review, ple= ase
send information to Dan.

Agenda for the interim is at:
=A0= http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart
If you have additional agenda items, which we should discuss to prepare= those
documents for WGLC, please email the chairs.

-d

___= ____________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.= org/mailman/listinfo/behave

--001636c5a4bd014592047a3986b6-- From dwing@cisco.com Tue Dec 8 09:15:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6F528C227 for ; Tue, 8 Dec 2009 09:15:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyZcxciBi6X3 for ; Tue, 8 Dec 2009 09:15:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C728C28C22A for ; Tue, 8 Dec 2009 09:14:50 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAJ4YHktAZnwN/2dsb2JhbACIe4EWuB+XGoQyBIFo X-IronPort-AV: E=Sophos;i="4.47,363,1257120000"; d="scan'208";a="59571642" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2009 17:14:38 +0000 Received: from dwingwxp01 ([10.32.240.195]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB8HEaYu013869; Tue, 8 Dec 2009 17:14:37 GMT From: "Dan Wing" To: "'GangChen'" References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> <36ba02b00912080749t1c404ea2paa631f09f31ed466@mail.gmail.com> Date: Tue, 8 Dec 2009 09:14:36 -0800 Message-ID: <0da401ca7829$ebe02cd0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp4HhICUKKS0AC5Tv2yawt2HdtUYAAC4ymw In-Reply-To: <36ba02b00912080749t1c404ea2paa631f09f31ed466@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 17:15:09 -0000 > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Tuesday, December 08, 2009 7:50 AM > To: Dan Wing > Cc: behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim > meeting, Dec 16 > > Hello Dan, > > I found the title of "framework for IPv6/IPv4" might have > mismatched hyperlink, which is address format link. Thanks for noticing. I had actuallly listed address-format twice. I fixed that. > And I would like to review the "framework for IPv6/IPv4" if > it is possible. Added. -d > Thanks > > Gang > > > > 2009/12/5 Dan Wing > > > As a reminder, we have an interim WebEx teleconference > on Wednesday, December > 16, at 7am Pacific Time. The December 16 > teleconference will resolve all open > issues with the following documents so they may be > immediately WGLC'd (dates > are Behave's milestone dates from our charter): > > Dec 2009 - Submit to IESG: framework for IPv6/IPv4 > translation (info) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Dec 2009 - Submit to IESG: stateless IPv6/IPv4 > translation (std) > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > Dec 2009 - Submit to IESG: stateful IPv6/IPv4 > translation (std) > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > Dec 2009 - Submit to IESG: DNS rewriting for > IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-dns64 > Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 > translator (std) > http://tools.ietf.org/html/draft-ietf-behave-address-format > Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std) > http://tools.ietf.org/id/draft-ietf-behave-ftp64 > (currently > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06) > > REVIEWERS ARE NEEDED! Please volunteer to review one, > two, or all documents. > WGLC is expected to start on December 17 and end > December 31. To finish WGLC, > we need 5 reviews indicating the document is ready. > One person has > volunteered so far (thanks, Flemming). If you are > willing to review, please > send information to Dan. > > Agenda for the interim is at: > http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart > > If you have additional agenda items, which we should > discuss to prepare those > documents for WGLC, please email the chairs. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > From brian.e.carpenter@gmail.com Tue Dec 8 13:39:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FD43A6988 for ; Tue, 8 Dec 2009 13:39:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23psoU9At-42 for ; Tue, 8 Dec 2009 13:39:51 -0800 (PST) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 365943A6807 for ; Tue, 8 Dec 2009 13:39:51 -0800 (PST) Received: by pxi7 with SMTP id 7so249616pxi.31 for ; Tue, 08 Dec 2009 13:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GrkHhTZO8dyU1jJfv86I+8XLRLzxzRBBpFu3IRAeqAg=; b=OfVfh51bulOXuPPXmQNDcW6Uxyp3uWmf3GfXGLmnv2t/zLbvJ1EiSIpGZwkeKoU8nz pl7tkQxLJLTRKnffstSDAf4gtYv9i6zDA7xRvHSI6yf8UQIrYzS9TdGT+JE1IGwLSijD wIThHrnYslCDbP9Qg27u7ZXIUpEcZFOpntgNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=YKPmRut+9z1S5CSx0ay18ASmA0pk1hgJU37fSnb1btJH+q8LL7GGD4uVn28iaHPI9M EkwGsMvudSu2AjcvV6qVpz1AhuVq88I7S4cYLVz9/sfU2Ges6Yb388a4nka8S2HPJsS0 ENIgyokEo5h+mvYJuMwykIM0qrf4PFwCSPFoI= Received: by 10.114.87.9 with SMTP id k9mr2141136wab.36.1260308377399; Tue, 08 Dec 2009 13:39:37 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm6301176pzk.10.2009.12.08.13.39.35 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 13:39:36 -0800 (PST) Message-ID: <4B1EC795.7040407@gmail.com> Date: Wed, 09 Dec 2009 10:39:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xu Xiaohu References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> In-Reply-To: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, behave@ietf.org Subject: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 21:39:52 -0000 On 2009-12-08 21:54, Xu Xiaohu wrote: >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org [mailto:behave-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 >> Christian Huitema >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=888=E6=97=A5= 2:52 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: eric.burgey@orange-ftgroup.com; xing@cern= et.edu.cn; behave@ietf.org; >> behave-chairs@tools.ietf.org >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] address-format: null suffix, consensu= s check =2E.. > Hi Christian, >=20 > I noticed the following statement in your draft "...Bits 64 to 71 of th= e address are reserved for compatibility with the host identifier format = defined in the IPv6 addressing architecture. These bits MUST be set to ze= ro. The corresponding octet is noted "u" in the above diagram. When usi= ng a 96 prefix, the administrators MUST ensure that the bits 64 to 71 are= compatible with the IPv6 addressing architecture..." >=20 > My question is: Should the IPv4-embeded IPv6 address still be in accord= ance with the specification defined in RFC4291 as "...For all unicast add= resses, except those that start with the binary value 000, Interface IDs = are required to be 64 bits long and to be constructed in Modified EUI-64 = format..."? If the answer is yes, why? (In other words, is there any pra= ctical meaning/usage for that constraint in the IPv4/IPv6 translation pro= cess?) I thought we'd discussed that a lot. Maybe it was not on the BEHAVE list.= The idea of protecting the semantics of the u/g bit (which is most cleanl= y done by skipping the whole byte) is that it is a very fundamental part of= the IPv6 design and we simply do not know when or how it might be relied on. It may have no value in currently understood cases of 1:1 communicati= on via a NAT64, but we don't know where it might be important in p2p communi= cations, referrals, etc. Also, this WG doesn't own the address format. Changing this would need th= e consensus of 6man. Brian From xuxh@huawei.com Tue Dec 8 17:52:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DE83A6AA5; Tue, 8 Dec 2009 17:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAeaOShbGvkM; Tue, 8 Dec 2009 17:52:30 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 530493A6AA4; Tue, 8 Dec 2009 17:52:30 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00J9B3UX88@szxga03-in.huawei.com>; Wed, 09 Dec 2009 09:52:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD005BD3UXWP@szxga03-in.huawei.com>; Wed, 09 Dec 2009 09:52:09 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD00ESJ3UWKX@szxml04-in.huawei.com>; Wed, 09 Dec 2009 09:52:09 +0800 (CST) Date: Wed, 09 Dec 2009 09:52:14 +0800 From: Xu Xiaohu In-reply-to: <4B1EC795.7040407@gmail.com> To: 'Brian E Carpenter' Message-id: <003701ca7872$3b1c3670$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp4Tvn3l5gFHcn3SpOJXNialWI9BwAHeR7Q Cc: behave@ietf.org, eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, ipv6@ietf.org Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 01:52:31 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Brian > E Carpenter > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 5:40 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: eric.burgey@orange-ftgroup.com; xing@cernet.edu.cn; = behave@ietf.org > =D6=F7=CC=E2: [BEHAVE] address-format: bits 64 to 71 >=20 > On 2009-12-08 21:54, Xu Xiaohu wrote: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > >> Christian Huitema > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C28=C8=D5 2:52 > >> =CA=D5=BC=FE=C8=CB: eric.burgey@orange-ftgroup.com; = xing@cernet.edu.cn; > behave@ietf.org; > >> behave-chairs@tools.ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] address-format: null suffix, consensus = check >=20 > ... > > Hi Christian, > > > > I noticed the following statement in your draft "...Bits 64 to 71 of = the > address are reserved for compatibility with the host identifier format defined > in the IPv6 addressing architecture. These bits MUST be set to zero. = The > corresponding octet is noted "u" in the above diagram. When using a = 96 prefix, > the administrators MUST ensure that the bits 64 to 71 are compatible = with the > IPv6 addressing architecture..." > > > > My question is: Should the IPv4-embeded IPv6 address still be in accordance > with the specification defined in RFC4291 as "...For all unicast addresses, > except those that start with the binary value 000, Interface IDs are required > to be 64 bits long and to be constructed in Modified EUI-64 = format..."? If > the answer is yes, why? (In other words, is there any practical meaning/usage > for that constraint in the IPv4/IPv6 translation process?) >=20 > I thought we'd discussed that a lot. Maybe it was not on the BEHAVE = list. Yes, we had discussed that in both SOFTWIRE and BEHAVE WG mailing-lists = (see the previous discussion thread: http://www.ietf.org/mail-archive/web/softwires/current/msg00850.html.). However, we have not got any reasonable enough answer. > The idea of protecting the semantics of the u/g bit (which is most = cleanly > done by skipping the whole byte) is that it is a very fundamental part = of > the IPv6 design and we simply do not know when or how it might be = relied > on. It may have no value in currently understood cases of 1:1 communication > via a NAT64, but we don't know where it might be important in p2p communications, > referrals, etc. =20 The following statement is quoted from RFC 4291: "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique. The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope." Till now, we haven't known the real usage of this constraint yet. So we should reverently obey such a constraint whose future usage is still uncertain.=20 Maybe a compromised way is to release this constraint on the = IPv4-embeded IPv6 addresses which can be used for stateless IPv4/IPv6 translation and 6over4 automatic tunneling while remaining it for native IPv6 address auto-configuration in case using a /64 prefix. > Also, this WG doesn't own the address format. Changing this would need = the > consensus of 6man. OK, I have added the 6man in the cc. Look forward to a clear conclusion after discussing it in the 6man mailing-list. Xiaohu >=20 > Brian >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Tue Dec 8 18:18:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9BF3A6833; Tue, 8 Dec 2009 18:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.583 X-Spam-Level: X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkL-rcWVIcn6; Tue, 8 Dec 2009 18:18:17 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B954D3A672F; Tue, 8 Dec 2009 18:18:17 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00GUT523HP@szxga01-in.huawei.com>; Wed, 09 Dec 2009 10:18:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD0082D523A4@szxga01-in.huawei.com>; Wed, 09 Dec 2009 10:18:03 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD00BGD522GV@szxml04-in.huawei.com>; Wed, 09 Dec 2009 10:18:03 +0800 (CST) Date: Wed, 09 Dec 2009 10:18:10 +0800 From: Xu Xiaohu In-reply-to: <4B1E37E0.9070505@free.fr> To: =?gb2312?B?J1Kopm1pIERlc3ByqKZzJw==?= , behave@ietf.org, ipv6@ietf.org Message-id: <003e01ca7875$dacdfd40$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp3+WukBCTOMDmHQvO7AfYBAkMvtQAegCqw Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 02:18:18 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED R=A8=A6 mi > Despr=A8=A6s > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C28=C8=D5 19:26 > =CA=D5=BC=FE=C8=CB: behave@ietf.org; ipv6@ietf.org > =B3=AD=CB=CD: Xu Xiaohu > =D6=F7=CC=E2: [BEHAVE] Reason(s) for Modified EUI-64 format to apply = to ALL non-0::/3 > IPv6 addresses ? >=20 > Hi all, >=20 > Xu Xiaohu wrote (in the Behave discussion thread) : >=20 > > My question is: Should the IPv4-embeded IPv6 address still be in > > accordance with the specification defined in RFC4291 as "...For all > > unicast addresses, except those that start with the binary value = 000, > > Interface IDs are required to be 64 bits long and to be constructed > > in Modified EUI-64 format..."? >=20 > > If the answer is yes, why? >=20 > +1 in favor of this question being answered by those who know the = history. > (This question is a recurring one, AFAIK not answered so far.) Yes, we had discussed that in both SOFTWIRE and BEHAVE WG mailing-lists = (see the previous discussion thread: http://www.ietf.org/mail-archive/web/softwires/current/msg00850.html.). > > (In other words, is there any practical meaning/usage for that > > constraint in the IPv4/IPv6 translation process?) >=20 > If no reason for the current constraint is reported, the real = constraint > could be weaker, becoming for example: Agree. > "...For all unicast addresses other than those that start with the > binary value 000, and that are used as destinations on IPv6 links = having > /64 subnet prefixes, Interface IDs are required to be constructed in > Modified EUI-64 format." How about the IPv4 translatable addresses for IPv6 hosts in the = stateless translation case? Obey the constraint or not? > To be complete, it could be added that: >=20 > "If new formats are defined in the future for such Interface IDs, they > should be distinguishable from the Modified EUI-64 format, i.e. should > have their two lower bits of the first octet both set to 1" >=20 > NOTE: IPv4-translatable and IPv4-converted IPv6 address formats are > being defined in conformance with the Modified EUI-64 format = constraint. > *This doesn't need to change.* > (Even if not technically necessary, this conformance permits to freeze > the specification, which is urgent, without waiting for the above > question to be resolved.) It seems ok to redefine the specification once the constraint on IPv4-embeded IPv6 addresses has been removed, just as what we are now = doing on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and = IPv4-Mapped IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6 address respectively). Xiaohu > Regards, >=20 > RD >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Tue Dec 8 18:26:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35473A696C; Tue, 8 Dec 2009 18:26:39 -0800 (PST) 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+FmsB+D6IlB; Tue, 8 Dec 2009 18:26:39 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 27DE03A68F9; Tue, 8 Dec 2009 18:26:39 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Dec 2009 18:26:54 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Tue, 8 Dec 2009 18:26:28 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 8 Dec 2009 18:26:27 -0800 From: Christian Huitema To: Xu Xiaohu , =?iso-8859-1?Q?=27R=E9mi_Despr=E9s=27?= , "behave@ietf.org" , "ipv6@ietf.org" Thread-Topic: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? Thread-Index: AQHKeHYAIeQXcoIsrUOLriWgAmoCJ5Fb/Gtw Date: Wed, 9 Dec 2009 02:26:22 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B1E37E0.9070505@free.fr> <003e01ca7875$dacdfd40$d40c6f0a@china.huawei.com> In-Reply-To: <003e01ca7875$dacdfd40$d40c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 02:26:40 -0000 > It seems ok to redefine the specification once the constraint on > IPv4-embeded IPv6 addresses has been removed, just as what we are now doi= ng > on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and IPv4-Mappe= d > IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6 > address respectively). Any revision of the IPv6 addressing rules in 6MAN is going to take a long t= ime. Maybe several years. I would rather not wait that long before we publi= sh the addressing format document. Beside, complying with the rule is not t= hat hard. So why bother? -- Christian Huitema =20 From xuxh@huawei.com Tue Dec 8 19:48:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A713A69D3; Tue, 8 Dec 2009 19:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.579 X-Spam-Level: X-Spam-Status: No, score=0.579 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjfpQIAJAgE4; Tue, 8 Dec 2009 19:48:20 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1753C3A696C; Tue, 8 Dec 2009 19:48:20 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD003ED98778@szxga01-in.huawei.com>; Wed, 09 Dec 2009 11:48:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00M2Q987WQ@szxga01-in.huawei.com>; Wed, 09 Dec 2009 11:48:07 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD003XX98696@szxml06-in.huawei.com>; Wed, 09 Dec 2009 11:48:07 +0800 (CST) Date: Wed, 09 Dec 2009 11:48:06 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , =?gb2312?B?J1Kopm1pIERlc3ByqKZzJw==?= , behave@ietf.org, ipv6@ietf.org Message-id: <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AQHKeHYAIeQXcoIsrUOLriWgAmoCJ5Fb/GtwgAAC/TA= Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 03:48:21 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 10:26 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'R=A8=A6mi Despr=A8=A6s'; = behave@ietf.org; ipv6@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > > It seems ok to redefine the specification once the constraint on > > IPv4-embeded IPv6 addresses has been removed, just as what we are = now doing > > on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and IPv4-Mapped > > IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted = IPv6 > > address respectively). >=20 > Any revision of the IPv6 addressing rules in 6MAN is going to take a = long time. > Maybe several years. I would rather not wait that long before we = publish the > addressing format document. Beside, complying with the rule is not = that hard. > So why bother? I wonder whether one could use that octet (bit 64 to 71) of IPv4-embeded IPv6 address for identifying different types of IPv4-embeded IPv6 = address than just using it to obey a constraint whose future usage is still uncertain. That is to say, the IPv4-embeded IPv6 addresses can be = identified by some bits (e.g. the binary value of bit 64 to 66 is a specific value, which is not conflicted with any used OUIs). Furthermore, different = types can also be distinguished by the remaining bits for that octet (e.g., = bit 67 to 71). At least the former usage has some certain applications. For example, in case of NAT64, if a dual-stack host could distinguish synthesized IPv6 addresses from native IPv6 addresses, it will not prefer a synthesized = IPv6 address to an IPv4 address for initiating a communication with an IPv4 = host. Another usage is to avoid routing loops when using ISATAP and 6to4 (for = more details, please see http://www.ietf.org/proceedings/09nov/slides/v6ops-2.ppt). Xiaohu From huitema@microsoft.com Tue Dec 8 21:21:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07A73A68D5; Tue, 8 Dec 2009 21:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2KzTBUafQsz; Tue, 8 Dec 2009 21:21:06 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 317A73A6881; Tue, 8 Dec 2009 21:21:06 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Dec 2009 21:21:21 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Tue, 8 Dec 2009 21:20:55 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 8 Dec 2009 21:20:32 -0800 From: Christian Huitema To: Xu Xiaohu , =?iso-8859-1?Q?=27R=E9mi_Despr=E9s=27?= , "behave@ietf.org" , "ipv6@ietf.org" Thread-Topic: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? Thread-Index: AQHKeHYAIeQXcoIsrUOLriWgAmoCJ5Fb/GtwgAAC/TCAAC060A== Date: Wed, 9 Dec 2009 05:20:27 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F5095@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> In-Reply-To: <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 05:21:07 -0000 > At least the former usage has some certain applications. For example, in > case of NAT64, if a dual-stack host could distinguish synthesized IPv6 > addresses from native IPv6 addresses, it will not prefer a synthesized IP= v6 > address to an IPv4 address for initiating a communication with an IPv4 ho= st. The well known prefix is easy to recognize, so there is no problem there. F= or stateless, the design makes sure that the IPv4 translatable addresses ca= n be routed natively, which means there is no reason to not prefer them. Th= at leaves a pretty small domain of applicability for any scheme that would = reserve identifier patterns... -- Christian Huitema From ssenthil@cisco.com Tue Dec 8 22:37:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9343A6AD1 for ; Tue, 8 Dec 2009 22:37:21 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUUtl0fDGEsy for ; Tue, 8 Dec 2009 22:37:20 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6375A3A68EF for ; Tue, 8 Dec 2009 22:37:20 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB/UHkurRN+J/2dsb2JhbAC/R5dBgjuBcQSBYg X-IronPort-AV: E=Sophos;i="4.47,366,1257120000"; d="scan'208";a="59956797" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 09 Dec 2009 06:37:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB96b9TC012637 for ; Wed, 9 Dec 2009 06:37:09 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 22:37:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Dec 2009 22:37:07 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> In-Reply-To: <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-behave-v6v4-xlate-04 Thread-Index: AQHKeHYAIeQXcoIsrUOLriWgAmoCJ5Fb/GtwgAAC/TCAADXwoA== References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> From: "Senthil Sivakumar (ssenthil)" To: X-OriginalArrivalTime: 09 Dec 2009 06:37:09.0693 (UTC) FILETIME=[088856D0:01CA789A] Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 06:37:21 -0000 General Comments Overall, the document is in a good shape and is ready for last call. Some general comments/behavior. 1. An example flow either in sections 2 & 3 or in the appendix would help understand the translation process easily. I believe something like this was in the initial ivi document. Abstract: Paragraph starting "Significant issues exist..." I don't know what issues are being referred to here but there is no description of the issues nor there is a pointer to a document that describes/addresses the issues. I think we should either drop this paragraph or describe the issues or point it to another relevant document. It is like saying "There are significant issues with stateful & stateless modes, we wont tell you what they are but we don't plan to address them in this document". That doesn't give me a good feeling when I start to read this document. Editorial comments. 1. Section 1.2 Para "The translating function specified in ..." There is a reference to RFC2765 that is hanging here. I don't know what is the intention of bringing in the reference without properly relating it to the context. 2. Section 1.2 Para "Fragmented IPv4 UDP packet...." "use over wide-areas in the Internet" - did you mean over wide-area networks? If not, what does wide-areas mean here? 3. Section 1.4 Para 1. s/must send packet to big/must send packet too big 4. Section 2 Para "However, when the IPv4 sender does..." s/needed should the packet pass through an IP/ICMP translator/needed should the packet pass through another IP/ICMP translator 5.Section 2.1=20 Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." Why is this a MUST? Isnt this upto the implementation? How can you verify the conformance? How can you detect if the nat64 device fragments it and translates it or translates it and fragments it? 6. Section 2.1=20 Hop Limit: I think the recommendation should be to decrement the TTL and send ICMP TTL exceeded before translation. Translating the packet and decrementing TTL to find out the TTL expired and restoring the packet to its original form seems to be unnecessarily complicating things. We shouldn't even suggest that. 7. Section 2.2=20 Para 2 "When a stateless translator...." The text says "translator SHOULD drop the packet and generate a system management event specifying at least" Is the SHOULD for dropping the packet and generating the event? I think generating the event should be optional/MAY. 8. Section 3.1 Time to Live - Same comment as hoplimit for IPv6. 9. Section 5 - Security considerations. This document does not address any potential issues that might arise by extracting a IPv4 address from the IPv6 address - particularly addresses like broadcast or loopback addresses etc. I think adding some text around that might be of help. Senthil From sgundave@cisco.com Tue Dec 8 23:02:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08F73A691F for ; Tue, 8 Dec 2009 23:02:56 -0800 (PST) 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.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N-xp9YJ-+NB for ; Tue, 8 Dec 2009 23:02:55 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C26883A659C for ; Tue, 8 Dec 2009 23:02:55 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALnaHkurRN+J/2dsb2JhbAC/UJc9hCwEgWI X-IronPort-AV: E=Sophos;i="4.47,366,1257120000"; d="scan'208";a="116544677" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2009 07:02:45 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB972jWw025132; Wed, 9 Dec 2009 07:02:45 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 23:02:45 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Dec 2009 07:02:44 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 08 Dec 2009 23:03:21 -0800 From: Sri Gundavelli To: Sheng Jiang Message-ID: Thread-Topic: [BEHAVE] [Softwires] Host based translation: v4-v6 Thread-Index: Acp1yuKoIL6o5DK3v0Kc0sraTiXqVQBH0z5gAAMYyVYAAzmmkABmje/a In-Reply-To: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 07:02:45.0126 (UTC) FILETIME=[9BB8D260:01CA789D] Cc: behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 07:02:56 -0000 Hi Sheng, If you decide to support such legacy IPv4 applications on future platforms, its rather logical to go with a dual-stack network till you migrate those applications to IPv6, or till you retire them. If your expectation is that you will have millions of such applications that you need to carry forward and without code recompilation on future platforms, may be the choice of IPv6-only network as the first step in IPv6 migration is not the right step. A much more logical step would be to retain the IPv4 network and possibly use Dual-stack lite to solve the IPv4 exhaust issue, then you don't have to deal with these weird cases and introduce significant changes to all host stacks. If I may ask, which out of the two is a cost affective approach ? (1) Dealing with the development and maintenance of ALG's, modified host stacks and translation functions on a zillion operating systems, Windows Mobile, Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure all the roaming scenarios are not impacted, OR (2) just simply keep your existing IPv4 network, don't turn it off on one fine morning in 2011 ? Are the efforts even in the same order of magnitude ? May be the migration strategy of that operator requires some re-thinking ? Regards Sri On 12/6/09 10:29 PM, "Sheng Jiang" wrote: > Hi, Sri, > > I believe we share many common opinions and have minimum different here: > eventually, all networks, devices, applications should be IPv6-enabled, even > IPv6-only. Before that, there would be a long period of IPv6/IPv4 > co-existing. That's why we are here discussing transition mechanisms. That > means we already admire some of networks, devices, applications could stay > in IPv4-only for a while. > > I agree that your code change requirement can solve the issues we discuss > here. However, it is just like we say if everyone going to IPv6-only, we > won't have transition issues. My argument here is that you cannot assume > every application providers can accept your code change requirement. Between > 2001 and 2004, I had experience made applications (like Grid middleware) > IPv6-enabled. It is much more complicated than your "4 line change". > Depending on the original applications, java application could be much > easier than c/c++ based application. Some of applications even need > independent driver to be IPv6-enabled. > > So, as one of transition mechanisms, PNAT meets the requirements that some > applications would stay in IPv4-only but want to connect to the whole world, > include IPv6 world. For the transition period, changing protocol stacks > (embeded tens different OS) is much easier than changing all applications > (probably millions). > From remi.despres@free.fr Wed Dec 9 01:08:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0669928C112; Wed, 9 Dec 2009 01:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOYQZw5plxdT; Wed, 9 Dec 2009 01:08:29 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 2A02528C186; Wed, 9 Dec 2009 01:08:24 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6CE8BE0806D; Wed, 9 Dec 2009 10:08:07 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1373EE0810D; Wed, 9 Dec 2009 10:08:04 +0100 (CET) Message-ID: <4B1F68F1.5040900@free.fr> Date: Wed, 09 Dec 2009 10:08:01 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090319) MIME-Version: 1.0 To: Christian Huitema References: <4B1E37E0.9070505@free.fr> <003e01ca7875$dacdfd40$d40c6f0a@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "behave@ietf.org" , Xu Xiaohu Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 09:08:30 -0000 Christian Huitema wrote : > Xu Xiaohu wrote : >> It seems ok to redefine the specification once the constraint on >> IPv4-embeded IPv6 addresses has been removed, just as what we are >> now doing on SIIT. (E.g., replacing the IPv4-Compatible IPv6 >> Address and IPv4-Mapped IPv6 Address with IPv4-translatable IPv6 >> address and IPv4-converted IPv6 address respectively). This may be possible then... or not (one never knows). To avoid unnecessary discussions, it is IMHO wiser not to try to decide anything about this now. > Any revision of the IPv6 addressing rules in 6MAN is going to take a > long time. Maybe several years. Doing better should be a goal, at least to reach consensus. This discussion started long ago, but so far without real attempts to reach conclusion. It seems to be the time do deal with it. Christian, as you are one of those who have lived the early history of IPv6, do you know any *technical objection*, from any one, for the following which, as new address formats are and will be defined, should be more appropriate than the current text: "For all unicast addresses other than those that start with the binary value 000, and that are used as destinations on IPv6 links having /64 subnet prefixes, Interface IDs are required to be constructed in Modified EUI-64 format. If new formats are defined in the future for such Interface IDs, they must be distinguishable from the Modified EUI-64 format, i.e. must have their two lower bits of the first octet both set to 1" > I would rather not wait that long before we publish the addressing > format document. Agreed. > Beside, complying with the rule is not that hard. So > why bother? Bothering about this question now is better to avoid coming back to the same subject over and over again, and to permit simpler designs in the future. Regards, RD From xuxh@huawei.com Wed Dec 9 01:59:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012F33A6944; Wed, 9 Dec 2009 01:59:22 -0800 (PST) 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.814, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwX92Y1tD743; Wed, 9 Dec 2009 01:59:21 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D7CA73A6926; Wed, 9 Dec 2009 01:59:20 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00E75QE15C@szxga04-in.huawei.com>; Wed, 09 Dec 2009 17:58:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00KWKQE1MN@szxga04-in.huawei.com>; Wed, 09 Dec 2009 17:58:49 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD00HVAQE0X1@szxml04-in.huawei.com>; Wed, 09 Dec 2009 17:58:49 +0800 (CST) Date: Wed, 09 Dec 2009 17:58:48 +0800 From: Xu Xiaohu In-reply-to: To: 'Brian E Carpenter' Message-id: <006501ca78b6$346dc2f0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp4Tvn3l5gFHcn3SpOJXNialWI9BwAHeR7QABI8zoA= Cc: behave@ietf.org, eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, ipv6@ietf.org Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 09:59:22 -0000 Since the following email is not successfully received by some = subscribers, so I resend it. Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Brian=20 > E Carpenter > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 5:40 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: eric.burgey@orange-ftgroup.com; xing@cernet.edu.cn;=20 > behave@ietf.org > =D6=F7=CC=E2: [BEHAVE] address-format: bits 64 to 71 >=20 > On 2009-12-08 21:54, Xu Xiaohu wrote: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > >> Christian Huitema > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C28=C8=D5 2:52 > >> =CA=D5=BC=FE=C8=CB: eric.burgey@orange-ftgroup.com; = xing@cernet.edu.cn; > behave@ietf.org; > >> behave-chairs@tools.ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] address-format: null suffix, consensus = check >=20 > ... > > Hi Christian, > > > > I noticed the following statement in your draft "...Bits 64 to 71 of = > > the > address are reserved for compatibility with the host identifier format = > defined in the IPv6 addressing architecture. These bits MUST be set to = > zero. The corresponding octet is noted "u" in the above diagram. =20 > When using a 96 prefix, the administrators MUST ensure that the bits = 64 to 71 are compatible with the > IPv6 addressing architecture..." > > > > My question is: Should the IPv4-embeded IPv6 address still be in=20 > > accordance > with the specification defined in RFC4291 as "...For all unicast=20 > addresses, except those that start with the binary value 000,=20 > Interface IDs are required to be 64 bits long and to be constructed in = > Modified EUI-64 format..."? If the answer is yes, why? (In other=20 > words, is there any practical meaning/usage for that constraint in the = > IPv4/IPv6 translation process?) >=20 > I thought we'd discussed that a lot. Maybe it was not on the BEHAVE = list. Yes, we had discussed that in both SOFTWIRE and BEHAVE WG mailing-lists = (see the previous discussion thread: http://www.ietf.org/mail-archive/web/softwires/current/msg00850.html.). However, we have not got any reasonable enough answer. > The idea of protecting the semantics of the u/g bit (which is most=20 > cleanly done by skipping the whole byte) is that it is a very=20 > fundamental part of the IPv6 design and we simply do not know when or=20 > how it might be relied on. It may have no value in currently=20 > understood cases of 1:1 communication via a NAT64, but we don't know=20 > where it might be important in p2p communications, referrals, etc. =20 The following statement is quoted from RFC 4291: "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique. The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope." Till now, we haven't known the real usage of this constraint yet. So we should reverently obey such a constraint whose future usage is still uncertain.=20 Maybe a compromised way is to release this constraint on the = IPv4-embeded IPv6 addresses which can be used for stateless IPv4/IPv6 translation and 6over4 automatic tunneling while remaining it for native IPv6 address auto-configuration in case using a /64 prefix. > Also, this WG doesn't own the address format. Changing this would need = > the consensus of 6man. OK, I have added the 6man in the cc. Look forward to a clear conclusion after discussing it in the 6man mailing-list. Xiaohu From remi.despres@free.fr Wed Dec 9 02:06:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09383A67EC; Wed, 9 Dec 2009 02:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyqS2X2HnbwN; Wed, 9 Dec 2009 02:06:33 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 434113A6781; Wed, 9 Dec 2009 02:06:30 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 97C6CE081C1; Wed, 9 Dec 2009 11:06:14 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id A53AFE0812E; Wed, 9 Dec 2009 11:06:10 +0100 (CET) Message-ID: <4B1F768F.9050704@free.fr> Date: Wed, 09 Dec 2009 11:06:07 +0100 From: =?GB2312?B?UqimbWkgRGVzcHKopnM=?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090319) MIME-Version: 1.0 To: Xu Xiaohu References: <003701ca7872$3b1c3670$d40c6f0a@china.huawei.com> In-Reply-To: <003701ca7872$3b1c3670$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: xing@cernet.edu.cn, eric.burgey@orange-ftgroup.com, behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 10:06:34 -0000 Xu Xiaohu wrote : > The following statement is quoted from RFC 4291: "IPv6 nodes are not > required to validate that interface identifiers created with modified > EUI-64 tokens with the "u" bit set to universal are unique. > > The use of the universal/local bit in the Modified EUI-64 format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope." > > Till now, we haven't known the real usage of this constraint yet. So > we should reverently obey such a constraint whose future usage is > still uncertain. Two points: 1. This sentence doesn't concern addresses that, like IPv4-mappable addresses, are never subject to any neighbor discovery protocol. 2. Relevance of this sentence seems negated in RFC 2462 where, in the specification of IPv6 stateless autoconfiguration, we have (upper cases added): "To insure that all configured addresses are likely to be unique on a given link, NODES RUN a "duplicate address detection" algorithm on addresses before assigning them to an interface. The Duplicate ddress Detection algorithm is performed on ALL addresses, independent of whether they are obtained via stateless or stateful autoconfiguration." Indeed, not checking uniqueness of IPv6 addresses when they are MAC-address derived would be a bad idea: MAC addresses cannot be assumed to be really universal because they can be administratively configured in some hosts. > Look forward to a clear conclusion after discussing it in the 6man > mailing-list. Agreed. Best regards, RD From remi.despres@free.fr Wed Dec 9 04:41:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C9E3A687B; Wed, 9 Dec 2009 04:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm7iON9VjvUH; Wed, 9 Dec 2009 04:41:42 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6C6583A67E2; Wed, 9 Dec 2009 04:41:39 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 274E4E08091; Wed, 9 Dec 2009 13:41:21 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id B762BE08016; Wed, 9 Dec 2009 13:41:18 +0100 (CET) Message-ID: <4B1F9AED.2090406@free.fr> Date: Wed, 09 Dec 2009 13:41:17 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090319) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" References: <003701ca7872$3b1c3670$d40c6f0a@china.huawei.com> <4B1F768F.9050704@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Xu Xiaohu , xing@cernet.edu.cn, ipv6@ietf.org, eric.burgey@orange-ftgroup.com Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 12:41:43 -0000 Wojciech Dec (wdec) wrote: >> Indeed, not checking uniqueness of IPv6 addresses when they are >> MAC-address derived would be a bad idea: MAC addresses cannot be >> assumed to be really universal because they can be administratively >> configured in some hosts. > > Under the EUI-64 scheme, a non unique IPv6 address is the result of a > non-unique MAC address. When having the latter in a shared bridge > domain is a bit of a problem to say the least and doing or not doing > IPv6 DAD doesn't change things. Right: it's only where there is no shared bridge to detect the problem that the DAD is alone to do the job and, since hosts ignore whether there is such a bridge, it's logical that, as required by the introduction of RFC 2462, address uniqueness be always checked. > Where checking for uniquness makes sense is whenever there is some > involvment of randomness or administrative fiat in > configuring/creating the IPv6 address. > Hence in a perfect world where > the EUI-64 interface-id rules apply, checking for uniquness wouldn't > be needed. In mandating the check the authors evidently thought of > the cases where the EUI-64 rule doesn't hold. Yes. To be on the safe side in the real world, they were right to do so . RD From marcelo@it.uc3m.es Wed Dec 9 05:04:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0F93A696B for ; Wed, 9 Dec 2009 05:04:29 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JruRqZRjfcvz for ; Wed, 9 Dec 2009 05:04:28 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id EA74A28C111 for ; Wed, 9 Dec 2009 05:04:27 -0800 (PST) Received: from r190-135-58-86.dialup.adsl.anteldata.net.uy (r190-135-58-86.dialup.adsl.anteldata.net.uy [190.135.58.86]) by smtp01.uc3m.es (Postfix) with ESMTP id C252EBA6911; Wed, 9 Dec 2009 14:04:13 +0100 (CET) Message-ID: <4B1FA04C.1080802@it.uc3m.es> Date: Wed, 09 Dec 2009 14:04:12 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Thaler References: <4B163713.8070001@it.uc3m.es> <4B191D1B.2050301@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: Behave WG Subject: Re: [BEHAVE] handling packet with fragments, second try X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:04:29 -0000 Dave Thaler escribió: > [...] > >>>> The NAT64 MUST allow the fragments to arrive over a time >>>> interval. The time interval MUST be configurable and the >>>> default value MUST be of at least 10 seconds. >>>> >>>> >>> Not sure how this MUST interacts with the previous paragraph. >>> If you're under attack it may not be feasible to allow fragments >>> to arrive over a 10 second period, since doing so may exhaust all >>> memory. Clarify. >>> >>> >> Right, what about: >> >> As long as the NAT64 has available resources, the NAT64 MUST allow the >> fragments to arrive over a time interval. >> > > Ok. > > >>>> The NAT64 MAY require that the UDP, TCP, or ICMP header be >>>> completely contained within the first fragment. >>>> >>>> >>> Presumably "first" means the first to arrive, as opposed to first in >>> byte order, yes? >>> >> No, it means the first packet in byte order. (so yes, it needs >> clarification) >> >> So, i will add: >> >> The NAT64 MAY require that the UDP, TCP, or ICMP header be >> completely contained within the first fragment (first fragment >> meaning the fragment that contains OFFSET equal to zero). >> > > Ok that answers the rest of my comments. > (So rest of discussion on this omitted) > > However I'd suggest wordsmithing for brevity: > >> The NAT64 MAY require that the UDP, TCP, or ICMP header be >> completely contained within the fragment that contains >> OFFSET equal to zero. >> > > done thanks, marcelo > [...] > >> I hope with the clarification i made, there is no longer a >> contradiction >> > > Right. > > -Dave > > > From marcelo@it.uc3m.es Wed Dec 9 05:18:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE15B28C18E for ; Wed, 9 Dec 2009 05:18:33 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGVM4ZJjysKH for ; Wed, 9 Dec 2009 05:18:32 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6650328C193 for ; Wed, 9 Dec 2009 05:18:31 -0800 (PST) Received: from r190-135-58-86.dialup.adsl.anteldata.net.uy (r190-135-58-86.dialup.adsl.anteldata.net.uy [190.135.58.86]) by smtp02.uc3m.es (Postfix) with ESMTP id 8FA5365A443; Wed, 9 Dec 2009 14:18:16 +0100 (CET) Message-ID: <4B1FA396.6010406@it.uc3m.es> Date: Wed, 09 Dec 2009 14:18:14 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Huitema References: <4B1B8065.3040203@cernet.edu.cn> <08BA2C59E081884DB2AAE4A0BE9D6DC1A78718@ftrdmel0.rd.francetelecom.fr> <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F3B45@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17058.007 Cc: "behave@ietf.org" , "eric.burgey@orange-ftgroup.com" , "xing@cernet.edu.cn" , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:18:33 -0000 Christian Huitema escribi=F3: > Eric, > > We did consider this type of design before writing the current proposal= =2E For example, one proposal was to always copy the IPv4 address in bits= 96-127 of the embedded address, even if that copy was a duplicate. FWIW, the proposal of embedding the IPv4 address twice int he IPv6=20 address was discussed at rhe hiroshima meeting (on the context of=20 decimal representations) and the chairs took a consensus check on this=20 issue in the hiroshima meeting and there was a strong consensus agaisnt = it, as far as i recall. Regards, marcelo > That proposal was discarded for two reasons: > > 1) Duplicating data is generally a bad idea, as it forces the translato= rs to deal with a new class or errors, when the supposedly duplicated val= ues don't match. > > 2) Using the bits rather than reserving them precludes future extension= s, and we are not certain enough of our choices to want to do that. > > Note that administrators who want the addresses copied in the last bits= can achieve that by selecting the /96 prefix of their choice. Administra= tors who want fine grain control on the mappings can also statically conf= igure stateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapp= ing" functions of the current crop of NAT44. > > -- Christian Huitema > > > > > > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behal= f Of eric.burgey@orange-ftgroup.com > Sent: Monday, December 07, 2009 9:07 AM > To: xing@cernet.edu.cn; behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] address-format: null suffix, consensus check > > Hello, > > If i truly understand the slides the scope of the document is covering = both: > "IPv4 translatable" IPv6 address > "IPv4 converted" IPv6 address. > > In slide 4 you say that both must use the same prefix and I agree. > > But in my humble opinion there is no need to have the same suffix requi= rement for all different cases. > For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a = good solution. > > But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts,= such IPv6 address can be assigned on a local network to an host that is = not a routers but a simple end host. In such case, it may be interesting = to use the most significant part of the IPv6 address as local network pre= fix (usually a /64 prefix). In that case the least significant part of th= e address is not the Ethernet interface address (U=3D0) but in accordance= with RFC4291 this part may be used with the link local prefix instead of= the local network prefix. But if the suffix is 0 this address is not uni= que on the local network. This problem can be solved by copying the part = of the IPv4 address that is in the prefix (in the 64 most significant bit= ) in the suffix and adding a 24 bit long host identifier if the IPv4 addr= ess is not unique. I suggest to put the redundant part of the IPv4 addres= s in the lest significant bit and the host identifier between the non red= undant part of IPv4 address and the redundant part so that the host ident= ifier can be used also as sub-network identifier to route the packet towa= rd the appropriate host if needed. > > Example : > > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-12= 0-127 > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/32 | prefix |v4(32) | u | Host ID | V4 (32) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/40 | prefix |v4(24) | u |(8)| Host ID | V4 (24) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/48 | prefix |v4(16) | u | (16) | Host ID |V4 (1= 6)| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/56 | prefix |(8)| u | v4(24) | Host ID |(= 8)| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/64 | prefix | u | v4(32) | Host ID = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > |/96 | prefix | v4(32) = | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-= --+ > > > > So for "IPv4 converted" IPv6 address used with a NAT64 translator the s= uffix should be 0. > But for "IPv4 translatable" address I think that the choice of the suff= ix must be open and must be chosen according the "IPv4 translatable" addr= ess usage. > > Having different suffix value may be helpful, it can be used in a refer= ral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 transla= table" address if the length of the prefix is known and different from /9= 6 (this is needed to extract the IPv4 address from the format). > > Best regards, > > > Eric BURGEY > Orange Labs > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la par= t de Xing Li > Envoy=E9 : dimanche 6 d=E9cembre 2009 10:59 > =C0 : 'Behave WG'; Behave Chairs > Objet : [BEHAVE] address-format: null suffix, consensus check > > Hi, All, > > In the draft-ietf-behave-address-format-01.txt, the document reads: > > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) > > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt > > Please confirm if we should keep the current conclusion. > > Regards, > > xing > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > =20 From marcelo@it.uc3m.es Wed Dec 9 05:24:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7123A28C117; Wed, 9 Dec 2009 05:24:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qyBd+NSkvBf; Wed, 9 Dec 2009 05:24:43 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5868D3A6895; Wed, 9 Dec 2009 05:24:43 -0800 (PST) Received: from r190-135-58-86.dialup.adsl.anteldata.net.uy (r190-135-58-86.dialup.adsl.anteldata.net.uy [190.135.58.86]) by smtp01.uc3m.es (Postfix) with ESMTP id D020BBA6139; Wed, 9 Dec 2009 14:24:28 +0100 (CET) Message-ID: <4B1FA50B.8010302@it.uc3m.es> Date: Wed, 09 Dec 2009 14:24:27 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Huitema References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA211F5095@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F5095@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: "behave@ietf.org" , Xu Xiaohu , "ipv6@ietf.org" Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:24:44 -0000 Christian Huitema escribió: >> At least the former usage has some certain applications. For example, in >> case of NAT64, if a dual-stack host could distinguish synthesized IPv6 >> addresses from native IPv6 addresses, it will not prefer a synthesized IPv6 >> address to an IPv4 address for initiating a communication with an IPv4 host. >> > > The well known prefix is easy to recognize, so there is no problem there. For stateless, the design makes sure that the IPv4 translatable addresses can be routed natively, which means there is no reason to not prefer them. That leaves a pretty small domain of applicability for any scheme that would reserve identifier patterns... > > In addition, in the NSP case, the host can configure the RFC3484 policy table to preffer native connectivity. Regards, marcelo > -- Christian Huitema > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Wed Dec 9 05:26:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39AC28C19A; Wed, 9 Dec 2009 05:26:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCgfwtvvT0z5; Wed, 9 Dec 2009 05:26:35 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 922A128C197; Wed, 9 Dec 2009 05:26:35 -0800 (PST) Received: from r190-135-58-86.dialup.adsl.anteldata.net.uy (r190-135-58-86.dialup.adsl.anteldata.net.uy [190.135.58.86]) by smtp02.uc3m.es (Postfix) with ESMTP id 5389B6BB64A; Wed, 9 Dec 2009 14:26:21 +0100 (CET) Message-ID: <4B1FA57B.8060204@it.uc3m.es> Date: Wed, 09 Dec 2009 14:26:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Huitema References: <4B1E37E0.9070505@free.fr> <003e01ca7875$dacdfd40$d40c6f0a@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17058.007 Cc: "behave@ietf.org" , Xu Xiaohu , "ipv6@ietf.org" Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:26:36 -0000 Christian Huitema escribió: >> It seems ok to redefine the specification once the constraint on >> IPv4-embeded IPv6 addresses has been removed, just as what we are now doing >> on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and IPv4-Mapped >> IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6 >> address respectively). >> > > Any revision of the IPv6 addressing rules in 6MAN is going to take a long time. Maybe several years. I would rather not wait that long before we publish the addressing format document. Beside, complying with the rule is not that hard. So why bother? > fully agree. We have discussed this issue before. The conclusion in behave was AFAICT: " go to 6man, disucss there and we will do whatever 6man decides" So far, AFAIU, 6man has not updated the IPv6 address architecture, so the reasonable thing to do in behave is to honour the current address architecture. Regards, marcelo > -- Christian Huitema > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From xing@cernet.edu.cn Wed Dec 9 05:27:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DF228C117 for ; Wed, 9 Dec 2009 05:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BflamT8sCXx4 for ; Wed, 9 Dec 2009 05:27:48 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id EB5973A69E6 for ; Wed, 9 Dec 2009 05:27:46 -0800 (PST) Received: from [192.168.1.100]([125.34.43.102]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b2024de; Wed, 09 Dec 2009 21:27:32 +0800 Message-ID: <4B1FA5BD.20900@cernet.edu.cn> Date: Wed, 09 Dec 2009 21:27:25 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> <4B1BCBF2.1090407@viagenie.ca> <4B1CD899.8010402@cernet.edu.cn> <4B1CFC4E.1080808@viagenie.ca> In-Reply-To: <4B1CFC4E.1080808@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: ouo9WSXB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:27:49 -0000 Simon Perreault 写é“: > Xing Li wrote, on 2009-12-07 05:27: > >> Simon Perreault 写é“: >> >>> On 12/06/2009 08:40 AM, Xing Li wrote: >>> >>>>> Parameter Problem (Type 4) If the Code is 1, translate this to an >>>>> ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set >>>>> the Type to 12 and the Code to zero. The Pointer needs to be >>>>> updated to point to the corresponding field in the translated >>>>> inner IP header. >>>>> >>>>> Question: How is that pointer updating performed? Do I have to >>>>> establish >>>>> correspondences between IPv6 and IPv4 fields? If so, shouldn't this be >>>>> in the text? >>>>> >>>> Pointer is used to Identify the octet offset within the invoking packet >>>> where the error was detected. Due to the different format of the >>>> Parameter Problem Message >>>> between IPv6 and IPv4, the octet offset needs to be changed in order to >>>> point to the same position of the error. >>>> >>> Yes but the pointer points inside an IPv6 header before translation, >>> and it points inside an IPv4 header after translation. There is more >>> to it than just updating the offset. It's a completely different >>> header and the fields don't have 1:1 mapping. >>> >> In the current draft, this is discussed in ICMP Error Payload section. >> It reads, if the received ICMPv6 packet contains an ICMP Extension >> [RFC4884], the translation of the ICMPv6 packet will cause the ICMPv6 >> packet to change length. >> > > This is not what I mean. I will try again. > > Suppose I have an ICMPv6 with type 4, code 0, and pointer value 3. This would > mean that there is a problem with the Flow Label field in the IPv6 header. To > translate to IPv4 I can't just offset the pointer: the Flow Label field doesn't > exist in IPv4. > > Another example: suppose the pointer value is 7, which points to the Hop Limit > field. This corresponds to the TTL field in IPv4 (if this is true, it would need > to be in the text). But since the fields are not at the same place in the > header, we need to adjust the pointer by more than just an offset based on the > header length. > > Third example: suppose the pointer points beyond the IP header, into the > transport header. This would be easy for TCP and UDP: just offset the pointer > based on the header length. But suppose also that the transport protocol is > ICMPv6. This is going to be translated to ICMPv4, and we have the same problems > as above because there is no 1:1 mapping between the two. > > I suggest that we do not attempt to translate the pointer, for two reasons: > - There is no 1:1 mapping between IPv4 and IPv6 parameters. > - The error would often be of interest only to the translator, since it would > be the one having generated the erroneous parameter. > > Therefore, I suggest to change the text to this: > > Parameter Problem (Type 4) If the Code is 1, translate this to an > ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise, silently > drop. > > And in section 2.3: > > Parameter Problem (Type 12) Silently drop. > Got the idea, thanks. So the question for the mailing-list is: For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if there is a one-to-one relationship (defined in the xlate document) between IPv4 and IPv6 headers of the invoking packet where the error was detected, the translator should translate the packets from one address family to the other address family. Otherwise, Option 1: The translator passes the invoking packet where the error was detected as opaque bit strings; this is likely to cause problems with processing of those ICMPv6/ICMP Error messages. Option 2: The translator silently drops the ICMP/ICMPv6 Error messages. Which option should we choose? Please comment. Regards, xing, congxiao > Simon > From marcelo@it.uc3m.es Wed Dec 9 05:32:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA22D28C197 for ; Wed, 9 Dec 2009 05:32:20 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxXe+FOEWduL for ; Wed, 9 Dec 2009 05:32:20 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E8C0D3A69DC for ; Wed, 9 Dec 2009 05:32:19 -0800 (PST) Received: from r190-135-58-86.dialup.adsl.anteldata.net.uy (r190-135-58-86.dialup.adsl.anteldata.net.uy [190.135.58.86]) by smtp01.uc3m.es (Postfix) with ESMTP id 6ECA2BA673E for ; Wed, 9 Dec 2009 14:32:06 +0100 (CET) Message-ID: <4B1FA6D4.9000909@it.uc3m.es> Date: Wed, 09 Dec 2009 14:32:04 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Subject: [BEHAVE] decimal representation of embedded IPv4 addresses in the IPv6 representation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:32:20 -0000 Hi, During the hiroshima meeting, we discussed about when to use decimal representation for IPv4 addresses embedded in IPv6 addresses. As currently defined, decimal representation can only be used when the IPv4 address is embedded in the last 32 bits of the IPv6 address. My understanding of the consensus call during the meeting is to keep this unchanged i.e. we will only use decimal representation if the IPv4 address is embedded in the last 32 bits. (Maybe the chairs can confirm that my reading of the consensus is correct?) In terms of the draft-ietf-behave-address-format, we could simply remain silent about this issue, since we are not modifying anything of the current specifications. Please commnent if you have issues with this, if not we will move forward with the consensus obtained in hiroshima. Regards, marcelo From simon.perreault@viagenie.ca Wed Dec 9 05:59:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582423A69E7 for ; Wed, 9 Dec 2009 05:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2cXs-TCg+IR for ; Wed, 9 Dec 2009 05:59:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 87A333A67F8 for ; Wed, 9 Dec 2009 05:59:10 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 3942721512; Wed, 9 Dec 2009 08:58:59 -0500 (EST) Message-ID: <4B1FAD22.5040907@viagenie.ca> Date: Wed, 09 Dec 2009 08:58:58 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Xing Li References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> <4B1BCBF2.1090407@viagenie.ca> <4B1CD899.8010402@cernet.edu.cn> <4B1CFC4E.1080808@viagenie.ca> <4B1FA5BD.20900@cernet.edu.cn> In-Reply-To: <4B1FA5BD.20900@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 13:59:11 -0000 Xing Li wrote, on 2009-12-09 08:27: > For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if > there is a one-to-one relationship (defined in the xlate document) Do you mean that it is already defined, or that it will eventually be defined? Because I don't see it in the draft right now. > between IPv4 and IPv6 headers of the invoking packet where the error was > detected, the translator should translate the packets from one address > family to the other address family. Otherwise, > > Option 1: > The translator passes the invoking packet where the error was detected > as opaque bit strings; this is likely to cause problems with processing > of those ICMPv6/ICMP Error messages. > > Option 2: > The translator silently drops the ICMP/ICMPv6 Error messages. > > Which option should we choose? Please comment. My opinion: Option 2. Doing otherwise would be useless. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From denghui02@gmail.com Wed Dec 9 07:50:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2033C28C12C for ; Wed, 9 Dec 2009 07:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v4ddXGdywLA for ; Wed, 9 Dec 2009 07:50:26 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 1FC4328C0FF for ; Wed, 9 Dec 2009 07:50:26 -0800 (PST) Received: by pwi20 with SMTP id 20so2817019pwi.29 for ; Wed, 09 Dec 2009 07:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b1IaNQtvnstRe3VTbwqTSTjCX1CEBA0W2nv+MW5G9yc=; b=tWmRUkT3/jRO9yCYSzmeH6diI6L+o1ButoIsNQjyYEsL40dclNWwceRaaoiQ5Ml97B UxEtqbbiiFBwJUECXRbIlxUoxkTRG6OwKl0WTPh1ecMagY014if1d0nyaEW8jIbhR+We fprT2g16aMYG4FGlRqvmDef52wniHywQBqaRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wLXOSbgqe7KVlOBMaALmTw1jo90piVCpeHO5ye7vWmD93CK8NvUZ00wtP1xZER16pX axrvG2YJtp5D5PLZ1HAjEf+kf7GJE52pqJh8t57xZ248jHrc3aTZ6wxJNCVX/AMBuq5U dON3+v1qPhsGhAxRMDueo2v6rUBYMLi6HRvac= MIME-Version: 1.0 Received: by 10.141.89.18 with SMTP id r18mr307942rvl.107.1260373812641; Wed, 09 Dec 2009 07:50:12 -0800 (PST) In-Reply-To: References: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> Date: Wed, 9 Dec 2009 23:50:12 +0800 Message-ID: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:50:27 -0000 fundamental difference here: 1) u r doing IPv4 and solving ipv4 problem 2) we are doing IPv6 and solving IPv6 problem -Hui 2009/12/9 Sri Gundavelli : > Hi Sheng, > > If you decide to support such legacy IPv4 applications on future platform= s, > its rather logical to go with a dual-stack network till you migrate those > applications to IPv6, or till you retire them. If your expectation is tha= t > you will have millions of such applications that you need to carry forwar= d > and without code recompilation on future platforms, =A0may be the choice = of > IPv6-only network as the first step in IPv6 migration is not the right st= ep. > A much more logical step would be to retain the IPv4 network and possibly > use Dual-stack lite to solve the IPv4 exhaust issue, then you don't have = to > deal with these weird cases and introduce significant changes to all host > stacks. > > If I may ask, which out of the two is a cost affective approach ? (1) > Dealing with the development and maintenance of ALG's, modified host stac= ks > and translation functions on a zillion operating systems, Windows Mobile, > Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure al= l > the roaming scenarios are not impacted, OR (2) just simply keep your > existing IPv4 network, don't turn it off on one fine morning in 2011 ? Ar= e > the efforts even in the same order of magnitude ? May be the migration > strategy of that operator requires some re-thinking ? > > Regards > Sri > > > On 12/6/09 10:29 PM, "Sheng Jiang" wrote: > >> Hi, Sri, >> >> I believe we share many common opinions and have minimum different here: >> eventually, all networks, devices, applications should be IPv6-enabled, = even >> IPv6-only. Before that, there would be a long period of IPv6/IPv4 >> co-existing. That's why we are here discussing transition mechanisms. Th= at >> means we already admire some of networks, devices, applications could st= ay >> in IPv4-only for a while. >> >> I agree that your code change requirement can solve the issues we discus= s >> here. However, it is just like we say if everyone going to IPv6-only, we >> won't have transition issues. My argument here is that you cannot assume >> every application providers can accept your code change requirement. Bet= ween >> 2001 and 2004, I had experience made applications (like Grid middleware) >> IPv6-enabled. It is much more complicated than your "4 line change". >> Depending on the original applications, java application could be much >> easier than c/c++ based application. Some of applications even need >> independent driver to be IPv6-enabled. >> >> So, as one of transition mechanisms, PNAT meets the requirements that so= me >> applications would stay in IPv4-only but want to connect to the whole wo= rld, >> include IPv6 world. For the transition period, changing protocol stacks >> (embeded tens different OS) is much easier than changing all application= s >> (probably millions). >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From sgundave@cisco.com Wed Dec 9 08:17:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DBB3A6A6F for ; Wed, 9 Dec 2009 08:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztrixOF+YZfb for ; Wed, 9 Dec 2009 08:17:03 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6D05A28C13D for ; Wed, 9 Dec 2009 08:17:03 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4FAIdcH0urR7Hu/2dsb2JhbACaIRSmL5cjgjOBeQSBYg X-IronPort-AV: E=Sophos;i="4.47,369,1257120000"; d="scan'208";a="73031115" Received: from sj-core-5.cisco.com ([171.71.177.238]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2009 16:16:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB9GEUl6013877; Wed, 9 Dec 2009 16:16:51 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 08:16:49 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Dec 2009 16:16:46 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 09 Dec 2009 08:17:21 -0800 From: Sri Gundavelli To: Hui Deng Message-ID: Thread-Topic: [BEHAVE] [Softwires] Host based translation: v4-v6 Thread-Index: Acp46xWwUP89SJQpR0Kc4G21eMOOhg== In-Reply-To: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Dec 2009 16:16:49.0392 (UTC) FILETIME=[02D93F00:01CA78EB] Cc: Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:17:05 -0000 You are deploying IPv6 on the network and have IPv6-only hosts: - but your applications still use IPv4. - they won't use IPv6 natively which is available So, turning of IPv4, not sure, how its helping and what is migrated. And this solution comes at a cost of making significant host stack changes and having to maintain that code base for years to come. And we are deploying IPv6, removing IPv4 routing from the network, but stil= l enabling support for IPv4 services and we are not modifying hosts. Sri On 12/9/09 7:50 AM, "Hui Deng" wrote: > fundamental difference here: > 1) u r doing IPv4 and solving ipv4 problem > 2) we are doing IPv6 and solving IPv6 problem >=20 > -Hui >=20 > 2009/12/9 Sri Gundavelli : >> Hi Sheng, >>=20 >> If you decide to support such legacy IPv4 applications on future platfor= ms, >> its rather logical to go with a dual-stack network till you migrate thos= e >> applications to IPv6, or till you retire them. If your expectation is th= at >> you will have millions of such applications that you need to carry forwa= rd >> and without code recompilation on future platforms, =A0may be the choice o= f >> IPv6-only network as the first step in IPv6 migration is not the right s= tep. >> A much more logical step would be to retain the IPv4 network and possibl= y >> use Dual-stack lite to solve the IPv4 exhaust issue, then you don't have= to >> deal with these weird cases and introduce significant changes to all hos= t >> stacks. >>=20 >> If I may ask, which out of the two is a cost affective approach ? (1) >> Dealing with the development and maintenance of ALG's, modified host sta= cks >> and translation functions on a zillion operating systems, Windows Mobile= , >> Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure a= ll >> the roaming scenarios are not impacted, OR (2) just simply keep your >> existing IPv4 network, don't turn it off on one fine morning in 2011 ? A= re >> the efforts even in the same order of magnitude ? May be the migration >> strategy of that operator requires some re-thinking ? >>=20 >> Regards >> Sri >>=20 >>=20 From wdec@cisco.com Wed Dec 9 03:00:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB353A690B; Wed, 9 Dec 2009 03:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=-2.740, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYzHkUWMAZ3c; Wed, 9 Dec 2009 03:00:51 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8913F3A67A6; Wed, 9 Dec 2009 03:00:50 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8AAM0RH0uQ/uCWiWdsb2JhbACbYgEBAQoLERMGomeXJYQsBIFi X-IronPort-AV: E=Sophos;i="4.47,367,1257120000"; d="scan'208";a="911863" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 09 Dec 2009 10:34:21 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB9B0cOV005712; Wed, 9 Dec 2009 11:00:38 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 12:00:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Dec 2009 12:00:04 +0100 Message-ID: In-Reply-To: <4B1F768F.9050704@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] address-format: bits 64 to 71 Thread-Index: Acp4t0ssY1P7funwSPqtwAjyGcxzMQABcItw References: <003701ca7872$3b1c3670$d40c6f0a@china.huawei.com> <4B1F768F.9050704@free.fr> From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Xu Xiaohu" X-OriginalArrivalTime: 09 Dec 2009 11:00:38.0039 (UTC) FILETIME=[D70A8270:01CA78BE] X-Mailman-Approved-At: Wed, 09 Dec 2009 08:26:53 -0800 Cc: behave@ietf.org, eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, ipv6@ietf.org Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 11:00:52 -0000 =20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of R=E9mi Despr=E9s > Sent: 09 December 2009 11:06 > To: Xu Xiaohu > Cc: xing@cernet.edu.cn; eric.burgey@orange-ftgroup.com;=20 > behave@ietf.org; 'Brian E Carpenter'; ipv6@ietf.org > Subject: Re: [BEHAVE] address-format: bits 64 to 71 >=20 > Xu Xiaohu wrote : >=20 > > The following statement is quoted from RFC 4291: "IPv6=20 > nodes are not=20 > > required to validate that interface identifiers created=20 > with modified > > EUI-64 tokens with the "u" bit set to universal are unique. > >=20 > > The use of the universal/local bit in the Modified EUI-64 format=20 > > identifier is to allow development of future technology=20 > that can take =20 > > advantage of interface identifiers with universal scope." > >=20 > > Till now, we haven't known the real usage of this=20 > constraint yet. So=20 > > we should reverently obey such a constraint whose future usage is=20 > > still uncertain. >=20 > Two points: >=20 > 1. > This sentence doesn't concern addresses that, like=20 > IPv4-mappable addresses, are never subject to any neighbor=20 > discovery protocol. >=20 >=20 > 2. > Relevance of this sentence seems negated in RFC 2462 where,=20 > in the specification of IPv6 stateless autoconfiguration, we=20 > have (upper cases > added): >=20 > "To insure that all configured addresses are likely to be=20 > unique on a given link, NODES RUN a "duplicate address=20 > detection" algorithm on addresses before assigning them to an=20 > interface. The Duplicate ddress Detection algorithm is=20 > performed on ALL addresses, independent of whether they are=20 > obtained via stateless or stateful autoconfiguration." >=20 > Indeed, not checking uniqueness of IPv6 addresses when they=20 > are MAC-address derived would be a bad idea: MAC addresses=20 > cannot be assumed to be really universal because they can be=20 > administratively configured in some hosts. Under the EUI-64 scheme, a non unique IPv6 address is the result of a = non-unique MAC address. When having the latter in a shared bridge domain = is a bit of a problem to say the least and doing or not doing IPv6 DAD = doesn't change things. Where checking for uniquness makes sense is = whenever there is some involvment of randomness or administrative fiat = in configuring/creating the IPv6 address. Hence in a perfect world where = the EUI-64 interface-id rules apply, checking for uniquness wouldn't be = needed. In mandating the check the authors evidently thought of the = cases where the EUI-64 rule doesn't hold. -Woj. >=20 > > Look forward to a clear conclusion after discussing it in the 6man=20 > > mailing-list. >=20 > Agreed. >=20 > Best regards, >=20 > RD > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From dwing@cisco.com Wed Dec 9 08:51:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9148C3A6853 for ; Wed, 9 Dec 2009 08:51:47 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJb+qjKpy63m for ; Wed, 9 Dec 2009 08:51:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 63FD13A683E for ; Wed, 9 Dec 2009 08:51:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALtkH0tAZnwN/2dsb2JhbACIfIEWtiWXJIQsBIFi X-IronPort-AV: E=Sophos;i="4.47,369,1257120000"; d="scan'208";a="73058869" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2009 16:51:34 +0000 Received: from dwingwxp01 ([10.32.240.195]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB9GpXlM008231; Wed, 9 Dec 2009 16:51:34 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , "'Behave WG'" References: <4B1FA6D4.9000909@it.uc3m.es> Date: Wed, 9 Dec 2009 08:51:33 -0800 Message-ID: <111a01ca78ef$ddd21510$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp41AN2a+fVVxELRrO7xPPOHxldIgAGqGpQ In-Reply-To: <4B1FA6D4.9000909@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] decimal representation of embedded IPv4 addresses in theIPv6 representation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:51:47 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Wednesday, December 09, 2009 5:32 AM > To: Behave WG > Subject: [BEHAVE] decimal representation of embedded IPv4 > addresses in theIPv6 representation > > Hi, > > During the hiroshima meeting, we discussed about when to use decimal > representation for IPv4 addresses embedded in IPv6 addresses. > As currently defined, decimal representation can only be used > when the > IPv4 address is embedded in the last 32 bits of the IPv6 address. > > My understanding of the consensus call during the meeting is to keep > this unchanged i.e. we will only use decimal representation > if the IPv4 > address is embedded in the last 32 bits. (Maybe the chairs > can confirm > that my reading of the consensus is correct?) Yes, see section titled "Turn over to Marcelo for Stateful translation", http://www.ietf.org/proceedings/09nov/minutes/behave.txt > > In terms of the draft-ietf-behave-address-format, we could simply > remain silent about this issue, since we are not modifying > anything of > the current specifications. http://tools.ietf.org/html/rfc4291#section-2.2 only shows examples of dotted-decimal with the IPv4-mapped prefix (::FFFF). It seems beneficial for draft-ietf-behave-address-format to show an example of dotted-decimal with the WKP prefix and with an NSP prefix. -d > Please commnent if you have issues with this, if not we will move > forward with the consensus obtained in hiroshima. > > Regards, marcelo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@shinkuro.com Wed Dec 9 09:01:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EBF28C197 for ; Wed, 9 Dec 2009 09:01:00 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3+7AbES9WYy for ; Wed, 9 Dec 2009 09:00:59 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 120BA28C13D for ; Wed, 9 Dec 2009 09:00:59 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8565B2FE8CB8 for ; Wed, 9 Dec 2009 17:00:46 +0000 (UTC) Date: Wed, 9 Dec 2009 12:00:44 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091209170044.GD2613@shinkuro.com> References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [BEHAVE] preparing dns64 for last call (was: WGLC prep for 6 documents: interim meeting, Dec 16) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 17:01:00 -0000 On Fri, Dec 04, 2009 at 08:41:25AM -0800, Dan Wing wrote: > Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > http://tools.ietf.org/html/draft-ietf-behave-dns64 In http://www.ietf.org/mail-archive/web/behave/current/msg07342.html, I proposed a change to the text. As far as I know, that's the only outstanding issue with the draft as it stands. I received (supportive) comments from Brian Carpenter about the proposed change. I haven't heard anything else. Unless anyone has any objection, I plan to go ahead with this. Ok? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dthaler@microsoft.com Wed Dec 9 12:38:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081683A67AE for ; Wed, 9 Dec 2009 12:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwPFB0Zc6Kj8 for ; Wed, 9 Dec 2009 12:38:20 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 18B973A6980 for ; Wed, 9 Dec 2009 12:38:20 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Dec 2009 12:38:35 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 9 Dec 2009 12:35:36 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 9 Dec 2009 12:35:19 -0800 From: Dave Thaler To: Andrew Sullivan , "behave@ietf.org" Thread-Topic: [BEHAVE] preparing dns64 for last call (was: WGLC prep for 6 documents: interim meeting, Dec 16) Thread-Index: AQHKePGHp+i16R3UcES5EfguwIUoIJFdKaYQ Date: Wed, 9 Dec 2009 20:35:18 +0000 Message-ID: References: <036b01ca7500$9ed6af80$5ba36b80@cisco.com> <20091209170044.GD2613@shinkuro.com> In-Reply-To: <20091209170044.GD2613@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] preparing dns64 for last call (was: WGLC prep for 6 documents: interim meeting, Dec 16) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 20:38:21 -0000 Comments on the proposed new text, below... > 6.3 DNS64 and multihomed and dual-stack hosts > > 6.3.1 IPv6 multihomed hosts > > Synthetic AAAA records may be constructed on the basis of the > network context in which they were constructed. If a host has > multiple interfaces, it is possible that some of them will receive s/host has multiple interfaces/host sends queries to DNS resolvers in multiple networks/ Just because a host has multiple interfaces doesn't necessarily mean it chooses to send queries on multiple. Also, the same problem happens if you have a single interface with two routers on it attached to different networks, and you've managed to (e.g. manually) configure DNS resolvers from both. And if you have two interfaces attached to the _same_ network, then there's no=20 real problem treating them both the same. Hence it's not so much about having multiple interfaces, but rather being multihomed to _different networks_. > answers from a DNS64 without all of them being connected via a > NAT64. For instance, suppose a system has two interfaces, i1 and > i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 has > native IPv6 connectivity only. I1 might receive a AAAA answer from > a DNS64 that is configured for a particular NAT64; the IPv6 address > contained in that AAAA answer will not connect with anything via > i2. > > This example illustrates why it is generally preferable that hosts > treat DNS answers from one interface as local to that interface. > The answer received on one interface will not work on the other > interface. Hosts that attempt to use DNS answers globally may > encounter surprising failures in these cases. For more discussion > of this topic, see [I-D.savolainen-mif-dns-server-selection]. > > 6.3.2 Accidental dual-stack DNS64 use > > Similarly, suppose that i1 has IPv6 connectivity and can connect to > the IPv4 Internet through NAT64, but i2 has IPv4 native transit. > In this case, i1 could receive an IPv6 address from a synthetic > AAAA that would better be reached via native IPv4 transit. Again this example would be better described as "network 1" and "network 2", not "interface 1" and "interface 2". > > Since it is most likely that the host will attempt AAAA resolution > first, in this arrangement the host will often use the NAT64 when a > native IPv4 would be preferable. For this reason, hosts with IPv4 > connectivity to the Internet should avoid using DNS64. This can be > partly resolved by ISPs when providing DNS resolvers to clients, > but that is not a guarantee that the NAT64 will never be used when > a native IPv4 connection should be used. There is no > general-purpose mechanism to ensure that native IPv4 transit will > always be preferred, because to a DNS64-oblivious host, the DNS64 > looks just like an ordinary DNS server. Operators of a NAT64 > should expect traffic to pass through the NAT64 even when it is not > necessary. > > 6.3.3 Intentional dual-stack DNS64 use > > Finally, consider the case where the IPv4 connectivity on i2 is > only to a LAN, with an IPv6-only connection on i1 to the Internet, > connecting to the IPv4 Internet via NAT64. Traffic to the LAN may > not be routable from the global Internet, as is often the case (for > instance) with LANs using RFC1918 addresses. In this case, it is > critical that the DNS64 not synthesize AAAA responses for hosts in > the LAN, or else that the DNS64 be aware of hosts in the LAN and > provide context-sensitive answers ("split view" DNS answers) for > hosts inside the LAN. As with any split view DNS arrangement, > operators must be prepared for data to leak from one context to > another, and for failures to occur because nodes accessible from > one context are not accessible from the other. -Dave From dthaler@microsoft.com Wed Dec 9 16:36:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDAD3A67F2 for ; Wed, 9 Dec 2009 16:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.287 X-Spam-Level: X-Spam-Status: No, score=-10.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcmoRj0bSHD4 for ; Wed, 9 Dec 2009 16:36:02 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3D5073A684C for ; Wed, 9 Dec 2009 16:36:02 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Dec 2009 16:36:17 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 9 Dec 2009 16:35:51 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 9 Dec 2009 16:35:51 -0800 From: Dave Thaler To: Christian Huitema , Xing Li , 'Behave WG' , Behave Chairs Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdqFWUvF8lhJYD0id0Bh1Dus4fZFdc0Kw Date: Thu, 10 Dec 2009 00:35:50 +0000 Message-ID: References: <4B1B8065.3040203@cernet.edu.cn> <6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 00:36:03 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Christian Huitema > Sent: Sunday, December 06, 2009 10:24 AM > To: Xing Li; 'Behave WG'; Behave Chairs > Subject: Re: [BEHAVE] address-format: null suffix, consensus check >=20 > I actually changed that text in the rev2 draft. The last text says: >=20 > When a /32 prefix is used, an all-zero suffix results in an all-zero > interface identifier. We understand the conflict with Section 2.6.1 > of RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the s/host/node/ It's not relevant whether there's only one "host" in the /64 subnet. What's relevant is whether there's only one *node* in the /64 subnet (a router is a node but not a host). > anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (This issue does not exist for prefixes larger > than 32 bits, such as the /40, /56 and /64 prefixes that we > recommend > in section 3.3.) >=20 >=20 >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Xing Li > Sent: Sunday, December 06, 2009 1:59 AM > To: 'Behave WG'; Behave Chairs > Subject: [BEHAVE] address-format: null suffix, consensus check >=20 > Hi, All, >=20 > In the draft-ietf-behave-address-format-01.txt, the document reads: >=20 > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) >=20 > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt >=20 > Please confirm if we should keep the current conclusion. >=20 > Regards, >=20 > xing >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Wed Dec 9 17:21:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B423A6891; Wed, 9 Dec 2009 17:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z259-IeANY8I; Wed, 9 Dec 2009 17:21:39 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 91DB73A6803; Wed, 9 Dec 2009 17:21:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUE003S0X3H6Z@szxga03-in.huawei.com>; Thu, 10 Dec 2009 09:21:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUE0064DX3H8T@szxga03-in.huawei.com>; Thu, 10 Dec 2009 09:21:17 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUE00FFHX3HF2@szxml04-in.huawei.com>; Thu, 10 Dec 2009 09:21:17 +0800 (CST) Date: Thu, 10 Dec 2009 09:21:17 +0800 From: Xu Xiaohu In-reply-to: <4B1FA50B.8010302@it.uc3m.es> To: 'marcelo bagnulo braun' , 'Christian Huitema' Message-id: <002201ca7937$12b4ee50$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp40wwaJtU1jC5HSPuarNE0pxypjQAYubEA Cc: ipv6@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 01:21:40 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > marcelo bagnulo braun > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 21:24 > =CA=D5=BC=FE=C8=CB: Christian Huitema > =B3=AD=CB=CD: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > Christian Huitema escribi=A8=AE: > >> At least the former usage has some certain applications. For = example, in > >> case of NAT64, if a dual-stack host could distinguish synthesized = IPv6 > >> addresses from native IPv6 addresses, it will not prefer a = synthesized IPv6 > >> address to an IPv4 address for initiating a communication with an = IPv4 host. > >> > > > > The well known prefix is easy to recognize, so there is no problem there. > For stateless, the design makes sure that the IPv4 translatable = addresses can > be routed natively, which means there is no reason to not prefer them. That > leaves a pretty small domain of applicability for any scheme that = would reserve > identifier patterns... > > > > > In addition, in the NSP case, the host can configure the RFC3484 = policy > table to preffer native connectivity. However, when one configures such a policy that native IPv6 connectivity should be preferred to IPv4 connectivity. How could the dual-stack host distinguish synthesized IPv6 addresses from native IPv6 addresses? If = there are some bits to tell whether it is an IPv4-embeded IPv6 address or not (even which type of IPv4-embeded IPv6 address), the above issue can be solved easily. Xiaohu > Regards, marcelo >=20 >=20 > > -- Christian Huitema > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Wed Dec 9 17:26:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDCC3A69A2; Wed, 9 Dec 2009 17:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uatcwXg7VJwe; Wed, 9 Dec 2009 17:26:03 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C2EA83A6877; Wed, 9 Dec 2009 17:26:01 -0800 (PST) Received: from r190-135-5-200.dialup.adsl.anteldata.net.uy (r190-135-5-200.dialup.adsl.anteldata.net.uy [190.135.5.200]) by smtp02.uc3m.es (Postfix) with ESMTP id 119D16C287B; Thu, 10 Dec 2009 02:25:46 +0100 (CET) Message-ID: <4B204E18.9070502@it.uc3m.es> Date: Thu, 10 Dec 2009 02:25:44 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Xu Xiaohu References: <002201ca7937$12b4ee50$d40c6f0a@china.huawei.com> In-Reply-To: <002201ca7937$12b4ee50$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17060.003 Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 01:26:04 -0000 Xu Xiaohu escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] ´ú±í >> marcelo bagnulo braun >> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ9ÈÕ 21:24 >> ÊÕ¼þÈË: Christian Huitema >> ³­ËÍ: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org >> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> Christian Huitema escribi¨®: >> >>>> At least the former usage has some certain applications. For example, >>>> > in > >>>> case of NAT64, if a dual-stack host could distinguish synthesized IPv6 >>>> addresses from native IPv6 addresses, it will not prefer a synthesized >>>> > IPv6 > >>>> address to an IPv4 address for initiating a communication with an IPv4 >>>> > host. > >>> The well known prefix is easy to recognize, so there is no problem >>> > there. > >> For stateless, the design makes sure that the IPv4 translatable addresses >> > can > >> be routed natively, which means there is no reason to not prefer them. >> > That > >> leaves a pretty small domain of applicability for any scheme that would >> > reserve > >> identifier patterns... >> >>> >> In addition, in the NSP case, the host can configure the RFC3484 policy >> table to preffer native connectivity. >> > > However, when one configures such a policy that native IPv6 connectivity > should be preferred to IPv4 connectivity. How could the dual-stack host > distinguish synthesized IPv6 addresses from native IPv6 addresses? If there > are some bits to tell whether it is an IPv4-embeded IPv6 address or not > (even which type of IPv4-embeded IPv6 address), the above issue can be > solved easily. > for the NSP, what the host needs to know is the NSP itself, that is what needs to be included in the policy table Regards, marcelo > Xiaohu > > >> Regards, marcelo >> >> >> >>> -- Christian Huitema >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > From xuxh@huawei.com Wed Dec 9 17:36:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323233A69A2; Wed, 9 Dec 2009 17:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtWKB4UqRS1e; Wed, 9 Dec 2009 17:36:04 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4556D3A6877; Wed, 9 Dec 2009 17:36:04 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUE006OZXRRLW@szxga01-in.huawei.com>; Thu, 10 Dec 2009 09:35:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUE00JF7XRRIK@szxga01-in.huawei.com>; Thu, 10 Dec 2009 09:35:51 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUE00HK1XRQPO@szxml04-in.huawei.com>; Thu, 10 Dec 2009 09:35:51 +0800 (CST) Date: Thu, 10 Dec 2009 09:35:50 +0800 From: Xu Xiaohu In-reply-to: <4B204E18.9070502@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <002501ca7939$1b19c190$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp5N78dotGwwsB5QbadTEs3kj5sHQAAI7Zw Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 01:36:05 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C210=C8=D5 9:26 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > Xu Xiaohu escribi=A8=AE: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > >> marcelo bagnulo braun > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 21:24 > >> =CA=D5=BC=FE=C8=CB: Christian Huitema > >> =B3=AD=CB=CD: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> Christian Huitema escribi=A8=AE: > >> > >>>> At least the former usage has some certain applications. For = example, > >>>> > > in > > > >>>> case of NAT64, if a dual-stack host could distinguish synthesized IPv6 > >>>> addresses from native IPv6 addresses, it will not prefer a synthesized > >>>> > > IPv6 > > > >>>> address to an IPv4 address for initiating a communication with an IPv4 > >>>> > > host. > > > >>> The well known prefix is easy to recognize, so there is no problem > >>> > > there. > > > >> For stateless, the design makes sure that the IPv4 translatable addresses > >> > > can > > > >> be routed natively, which means there is no reason to not prefer = them. > >> > > That > > > >> leaves a pretty small domain of applicability for any scheme that = would > >> > > reserve > > > >> identifier patterns... > >> > >>> > >> In addition, in the NSP case, the host can configure the RFC3484 = policy > >> table to preffer native connectivity. > >> > > > > However, when one configures such a policy that native IPv6 = connectivity > > should be preferred to IPv4 connectivity. How could the dual-stack = host > > distinguish synthesized IPv6 addresses from native IPv6 addresses? = If there > > are some bits to tell whether it is an IPv4-embeded IPv6 address or = not > > (even which type of IPv4-embeded IPv6 address), the above issue can = be > > solved easily. > > > for the NSP, what the host needs to know is the NSP itself, that is = what > needs to be included in the policy table Even so, if a dual-stack host obtains a synthesized IPv6 address as a response to its DNS query for AAAA record at first, will it send a DNS = query for A record later due to the above policy table? Xiaohu > > > > > >> Regards, marcelo > >> > >> > >> > >>> -- Christian Huitema > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www.ietf.org/mailman/listinfo/behave > >>> > >>> > >>> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > > > > > > From zhouboyj@gmail.com Wed Dec 9 19:32:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752733A694F for ; Wed, 9 Dec 2009 19:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVVdm9GOWdKe for ; Wed, 9 Dec 2009 19:32:33 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 0A6E33A6359 for ; Wed, 9 Dec 2009 19:32:32 -0800 (PST) Received: by iwn33 with SMTP id 33so5323834iwn.29 for ; Wed, 09 Dec 2009 19:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DtxAgDPOZ/tcrKEv9KWmNHtfh1+iPzzVeySRKGTAVMM=; b=RPIYPsopjtesTIIx2wxefldChfWB2eqcb2mKztNyS9g5nwnfwvqVgV+KtPvKIW7fPI G0Z8ik4Mpuou6GqZ+1Irvc5SAJw5drH8vbUSl736NQaexR8wDuo/kV6IAczRY8/zzSP0 PDJHEQSn4EkwStwb5P7K3lnk3N7+GVBQYNn8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ForUeDfvWvvXE3fqHe1xPNFWes1eFrbscUJRUWPuUwwmDG+P4G1dFpo8TdldbRoGy5 eib6UUcmsFxqq9OPHwBQqQ39Rgjw/l68iQlDCIWYQgMLuxf4bLOyiEDwVx/7yWXnlHNb SyIE0HtKreCX8V0RSApoCNk26axCZh03sUL1g= MIME-Version: 1.0 Received: by 10.231.158.205 with SMTP id g13mr605167ibx.30.1260415939326; Wed, 09 Dec 2009 19:32:19 -0800 (PST) In-Reply-To: References: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> Date: Thu, 10 Dec 2009 11:32:19 +0800 Message-ID: <36a593230912091932k1a02dbbem84ad49b0c7665d10@mail.gmail.com> From: bo zhou To: Sri Gundavelli Content-Type: multipart/alternative; boundary=00504501416d5536a0047a5774a2 Cc: Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 03:32:34 -0000 --00504501416d5536a0047a5774a2 Content-Type: text/plain; charset=ISO-8859-1 Dear Sri, Reply inline. On Wed, Dec 9, 2009 at 3:03 PM, Sri Gundavelli wrote: > Hi Sheng, > > If you decide to support such legacy IPv4 applications on future platforms, > its rather logical to go with a dual-stack network till you migrate those > applications to IPv6, or till you retire them. If your expectation is that > you will have millions of such applications that you need to carry forward > and without code recompilation on future platforms, may be the choice of > IPv6-only network as the first step in IPv6 migration is not the right > step. > A much more logical step would be to retain the IPv4 network and possibly > use Dual-stack lite to solve the IPv4 exhaust issue, then you don't have to > deal with these weird cases and introduce significant changes to all host > stacks. > > If I may ask, which out of the two is a cost affective approach ? (1) > Dealing with the development and maintenance of ALG's, [bo] I saw few words mentioned ALG inside DS-lite. And from Behave charter, it clarified we only consider existed ALG issues, for future potential ALG issue should be considered out of scope. > modified host stacks > and translation functions on a zillion operating systems, Windows Mobile, > Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure all > the roaming scenarios are not impacted, OR (2) just simply keep your > existing IPv4 network, don't turn it off on one fine morning in 2011 ? [bo] I guess you are talking using IPv4 forever, I agree DS-lite is a good solution for solving IPv4 exhaustion issue, but not good for IPv6. > Are > the efforts even in the same order of magnitude ? May be the migration > strategy of that operator requires some re-thinking ? > > Regards > Sri > > > On 12/6/09 10:29 PM, "Sheng Jiang" wrote: > > > Hi, Sri, > > > > I believe we share many common opinions and have minimum different here: > > eventually, all networks, devices, applications should be IPv6-enabled, > even > > IPv6-only. Before that, there would be a long period of IPv6/IPv4 > > co-existing. That's why we are here discussing transition mechanisms. > That > > means we already admire some of networks, devices, applications could > stay > > in IPv4-only for a while. > > > > I agree that your code change requirement can solve the issues we discuss > > here. However, it is just like we say if everyone going to IPv6-only, we > > won't have transition issues. My argument here is that you cannot assume > > every application providers can accept your code change requirement. > Between > > 2001 and 2004, I had experience made applications (like Grid middleware) > > IPv6-enabled. It is much more complicated than your "4 line change". > > Depending on the original applications, java application could be much > > easier than c/c++ based application. Some of applications even need > > independent driver to be IPv6-enabled. > > > > So, as one of transition mechanisms, PNAT meets the requirements that > some > > applications would stay in IPv4-only but want to connect to the whole > world, > > include IPv6 world. For the transition period, changing protocol stacks > > (embeded tens different OS) is much easier than changing all applications > > (probably millions). > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Regards, Bo Zhou China Mobile --00504501416d5536a0047a5774a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Sri,
=A0
Reply inline.

On Wed, Dec 9, 2009 at 3:03 PM, Sri Gundavelli <= span dir=3D"ltr"><sgundave@cisco.c= om> wrote:
Hi Sheng,

If you decide t= o support such legacy IPv4 applications on future platforms,
its rather = logical to go with a dual-stack network till you migrate those
applications to IPv6, or till you retire them. If your expectation is that<= br>you will have millions of such applications that you need to carry forwa= rd
and without code recompilation on future platforms, =A0may be the cho= ice of
IPv6-only network as the first step in IPv6 migration is not the right step= .
A much more logical step would be to retain the IPv4 network and possi= bly
use Dual-stack lite to solve the IPv4 exhaust issue, then you don= 9;t have to
deal with these weird cases and introduce significant changes to all hoststacks.

If I may ask, which out of the two is a cost affective app= roach ? (1)
Dealing with the development and maintenance of ALG's, <= /blockquote>
[bo] I saw few words mentioned ALG inside DS-lite. And from Behave cha= rter, it clarified we only=A0consider existed ALG issues, for future potent= ial ALG issue should be considered out of scope.
=A0
modified host stacks
and tran= slation functions on a zillion operating systems, Windows Mobile,
Linux,= Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure all
the roaming scenarios are not impacted, OR (2) just simply keep your
exi= sting IPv4 network, don't turn it off on one fine morning in 2011 ?
[bo] I guess you are talking using IPv4 forever, I agree DS-lite is a = good solution for solving IPv4 exhaustion issue, but not good for IPv6.
Are
the efforts even in the s= ame order of magnitude ? May be the migration
strategy of that operator = requires some re-thinking ?

Regards
Sri


On 12/6/09 10:29 PM, "Sheng Jiang" <= shengjiang@huawei.com> wrot= e:

> Hi, Sri,
>
> I believe we share many common opin= ions and have minimum different here:
> eventually, all networks, devices, applications should be IPv6-enabled= , even
> IPv6-only. Before that, there would be a long period of IPv6= /IPv4
> co-existing. That's why we are here discussing transition= mechanisms. That
> means we already admire some of networks, devices, applications could = stay
> in IPv4-only for a while.
>
> I agree that your co= de change requirement can solve the issues we discuss
> here. However= , it is just like we say if everyone going to IPv6-only, we
> won't have transition issues. My argument here is that you cannot = assume
> every application providers can accept your code change requ= irement. Between
> 2001 and 2004, I had experience made applications = (like Grid middleware)
> IPv6-enabled. It is much more complicated than your "4 line chang= e".
> Depending on the original applications, java application c= ould be much
> easier than c/c++ based application. Some of applicati= ons even need
> independent driver to be IPv6-enabled.
>
> So, as one of t= ransition mechanisms, PNAT meets the requirements that some
> applica= tions would stay in IPv4-only but want to connect to the whole world,
> include IPv6 world. For the transition period, changing protocol stack= s
> (embeded tens different OS) is much easier than changing all appl= ications
> (probably millions).
>

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



--
Regards,
Bo Zhou
China Mobile
--00504501416d5536a0047a5774a2-- From zhouboyj@gmail.com Wed Dec 9 19:44:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DAD3A6999 for ; Wed, 9 Dec 2009 19:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IVrVxap7s2k for ; Wed, 9 Dec 2009 19:44:11 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id D43CC3A6911 for ; Wed, 9 Dec 2009 19:44:10 -0800 (PST) Received: by iwn33 with SMTP id 33so5328721iwn.29 for ; Wed, 09 Dec 2009 19:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=o+hN/88YQxoWKQllKZPVjj6HOp/sOOnRaCuSyTTZvmg=; b=EQUF3F+5IoNJBUjaQyZXqu+aC11YOSXIN1K//iTdG/soD/wb7s0IdCKxtYU3mi4Okj B+dcK41u90wgELkYUSxq0m7onkcBDqVjIJkDBWcRczCz+w7luhUQfBaErYUddQ6Dpm/h bpiUtUvXCeGKgESLds+XscSSprJYUoEsgh9/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ab5AXmEmQGJXzELAOCFMcRNsIYmjGUBcClLIUmSA4vNwtRJHzTEBnyFAk2gDD4EkDi L+urbketcGuBvZFXX6Aw4oQk/W+sZbdif5sK451lXQXN93wVgF1RZlKGlHm0DVH9jEbD TVX3TGi/DKVL6zF0IX5uQ51ghcl57lgBMR1PY= MIME-Version: 1.0 Received: by 10.231.182.130 with SMTP id a44mr590011iba.18.1260416636872; Wed, 09 Dec 2009 19:43:56 -0800 (PST) In-Reply-To: References: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> Date: Thu, 10 Dec 2009 11:43:56 +0800 Message-ID: <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> From: bo zhou To: Sri Gundavelli Content-Type: multipart/alternative; boundary=0016364d309be8eb3f047a579dcd Cc: Hui Deng , Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 03:44:12 -0000 --0016364d309be8eb3f047a579dcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sri, Reply inline. On Thu, Dec 10, 2009 at 12:17 AM, Sri Gundavelli wrote= : > You are deploying IPv6 on the network and have IPv6-only hosts: > > - but your applications still use IPv4. > - they won't use IPv6 natively which is available > [bo] Can you ask application developer do something. Maybe not, what you ca= n do is recommend them do something. We cannot predict their behaviour, maybe 5=EF=BC=90% follow your recommendation, 50% not. > > So, turning of IPv4, not sure, how its helping and what is migrated. And > this solution comes at a cost of making significant host stack changes an= d > having to maintain that code base for years to come. > > And we are deploying IPv6, removing IPv4 routing from the network, but > still > enabling support for IPv4 services and we are not modifying hosts. > [bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solution for IPv4 exhaustion. But I cannot see any motivation for existed IPv4 application developer upgrade their application to support IPv6, because base on your solution, IPv4 working very well. So maybe in many ages, we cannot see any application relies on IPv6. > > Sri > > > > > On 12/9/09 7:50 AM, "Hui Deng" wrote: > > > fundamental difference here: > > 1) u r doing IPv4 and solving ipv4 problem > > 2) we are doing IPv6 and solving IPv6 problem > > > > -Hui > > > > 2009/12/9 Sri Gundavelli : > >> Hi Sheng, > >> > >> If you decide to support such legacy IPv4 applications on future > platforms, > >> its rather logical to go with a dual-stack network till you migrate > those > >> applications to IPv6, or till you retire them. If your expectation is > that > >> you will have millions of such applications that you need to carry > forward > >> and without code recompilation on future platforms, may be the choice > of > >> IPv6-only network as the first step in IPv6 migration is not the right > step. > >> A much more logical step would be to retain the IPv4 network and > possibly > >> use Dual-stack lite to solve the IPv4 exhaust issue, then you don't ha= ve > to > >> deal with these weird cases and introduce significant changes to all > host > >> stacks. > >> > >> If I may ask, which out of the two is a cost affective approach ? (1) > >> Dealing with the development and maintenance of ALG's, modified host > stacks > >> and translation functions on a zillion operating systems, Windows > Mobile, > >> Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure > all > >> the roaming scenarios are not impacted, OR (2) just simply keep your > >> existing IPv4 network, don't turn it off on one fine morning in 2011 ? > Are > >> the efforts even in the same order of magnitude ? May be the migration > >> strategy of that operator requires some re-thinking ? > >> > >> Regards > >> Sri > >> > >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --=20 Regards, Bo Zhou China Mobile --0016364d309be8eb3f047a579dcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sri,
=C2=A0
Reply inline.

On Thu, Dec 10, 2009 at 12:17 AM, Sri Gundavelli= <sgundave@cisco= .com> wrote:
You are deploying IPv6 on the ne= twork and have IPv6-only hosts:

- but your applications still use IP= v4.
- they won't use IPv6 natively which is available
[bo] Can you ask application developer do something. Maybe not, what y= ou can do is recommend them do something. We=C2=A0cannot predict their beha= viour, maybe 5=EF=BC=90% follow your recommendation, 50% not.

So, turning of IPv4, not sur= e, how its helping and what is migrated. And
this solution comes at a co= st of making significant host stack changes and
having to maintain that code base for years to come.

And we are depl= oying IPv6, removing IPv4 routing from the network, but still
enabling s= upport for IPv4 services and we are not modifying hosts.
[bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solu= tion for IPv4 exhaustion. But I cannot see any motivation for existed IPv4 = application developer upgrade their application to support IPv6, because ba= se on your solution, IPv4 working very well. So maybe in many ages, we cann= ot see any application relies on IPv6.

Sri<= br>




On 12/9/09 7:50 AM, "Hui Deng" = <denghui02@gmail.com> wrot= e:

> fundamental difference here:
> 1) u r doing IPv4 and s= olving ipv4 problem
> 2) we are doing IPv6 and solving IPv6 problem
>
> -Hui
= >
> 2009/12/9 Sri Gundavelli <sgundave@cisco.com>:
>> Hi Sheng,
>>
>&= gt; If you decide to support such legacy IPv4 applications on future platfo= rms,
>> its rather logical to go with a dual-stack network till you migrat= e those
>> applications to IPv6, or till you retire them. If your = expectation is that
>> you will have millions of such applications= that you need to carry forward
>> and without code recompilation on future platforms, =C2=A0may be t= he choice of
>> IPv6-only network as the first step in IPv6 migrat= ion is not the right step.
>> A much more logical step would be to= retain the IPv4 network and possibly
>> use Dual-stack lite to solve the IPv4 exhaust issue, then you don&= #39;t have to
>> deal with these weird cases and introduce signifi= cant changes to all host
>> stacks.
>>
>> If I m= ay ask, which out of the two is a cost affective approach ? (1)
>> Dealing with the development and maintenance of ALG's, modifie= d host stacks
>> and translation functions on a zillion operating = systems, Windows Mobile,
>> Linux, Android, iphone, BSD, Symbion .= .., add changes to NAT64, ensure all
>> the roaming scenarios are not impacted, OR (2) just simply keep yo= ur
>> existing IPv4 network, don't turn it off on one fine mor= ning in 2011 ? Are
>> the efforts even in the same order of magnit= ude ? May be the migration
>> strategy of that operator requires some re-thinking ?
>><= br>>> Regards
>> Sri
>>
>>

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



--
Regards,
Bo Zhou
China Mobile
--0016364d309be8eb3f047a579dcd-- From sgundave@cisco.com Wed Dec 9 20:21:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3140E3A6966 for ; Wed, 9 Dec 2009 20:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MqRt1kG7nFS for ; Wed, 9 Dec 2009 20:21:24 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 663BA3A693C for ; Wed, 9 Dec 2009 20:21:24 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPoFIEurRN+J/2dsb2JhbAC+G5cWhCwEgWI X-IronPort-AV: E=Sophos;i="4.47,372,1257120000"; d="scan'208";a="60484226" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Dec 2009 04:21:13 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBA4LD5N014036; Thu, 10 Dec 2009 04:21:13 GMT Date: Wed, 9 Dec 2009 20:21:13 -0800 (PST) From: Sri Gundavelli To: bo zhou In-Reply-To: <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> Message-ID: References: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Hui Deng , Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 04:21:25 -0000 Hi Bo: > [bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solution > for IPv4 exhaustion. But I cannot see any motivation for existed IPv4 > application developer upgrade their application to support IPv6, because > base on your solution, IPv4 working very well. So maybe in many ages, we > cannot see any application relies on IPv6. > :) When PNAT is deployed, what is the motivation for the developer to use IPv6 ? You plan to support their legacy IPv4 applications for ever. IPv4 is "working very well", and on IPv6 transport too. App developers can continue to use IPv4-only sockets and can interact with potentially IPv6 future peers. My point is, do not make those applications that use IPv4-only sockets written for legacy platforms and have binaries only, to magically work on new platforms that have IPv6-only transport. Let them migrate or retire those applications. Let applications behave normally and don't give special incentives there. Sri From zhouboyj@gmail.com Wed Dec 9 23:02:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3073A6999 for ; Wed, 9 Dec 2009 23:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrNIjB2BMopW for ; Wed, 9 Dec 2009 23:02:26 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id B78D53A6840 for ; Wed, 9 Dec 2009 23:02:25 -0800 (PST) Received: by iwn33 with SMTP id 33so5413053iwn.29 for ; Wed, 09 Dec 2009 23:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WF1HaO42Q7y5HAYAucnHCoIsvnfG3WOx4wOLnzdIJbM=; b=Rk/2zTMwh544aD30jX1emmpnV3XueDRTT7h4G4bs2Aq0iDmbuepekW1Q9EvLIGyupD MJgCJjk5mFNpSbB689TJe6cuuTSfxzoXGBpryrtleMlgwsyg0lmRBzhCsbUKuaEhDJWC 8f9aTIgvnh6e6ahMG1FMebUM9I0Neu2GrqIss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vcvNlM07oPGgF6W4yNjVtCtN7OdLL6CpdDcSFghd2LZmxxb+7yUF99aMCSkmX/9TsZ ukt4Nn39Wjj+HPBJ5Q1s29QcQ3jUwX4ezhehObKdZ4YzneqSDSEgUXY9hrnAFnPOxFt7 FEQObYX6i+VZMXnb2YQshMH2a4eP7oXfmZAAQ= MIME-Version: 1.0 Received: by 10.231.122.139 with SMTP id l11mr915366ibr.53.1260428532027; Wed, 09 Dec 2009 23:02:12 -0800 (PST) In-Reply-To: References: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> Date: Thu, 10 Dec 2009 15:02:11 +0800 Message-ID: <36a593230912092302q4f70c9dbqf11e3008f63d71dc@mail.gmail.com> From: bo zhou To: Sri Gundavelli Content-Type: multipart/alternative; boundary=001485f99caaea93f8047a5a6257 Cc: Hui Deng , Sheng Jiang , behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 07:02:27 -0000 --001485f99caaea93f8047a5a6257 Content-Type: text/plain; charset=ISO-8859-1 Hi Sri, I thought I caught a cold, hope it is not swine flu. But it make my brain stop working. But I will still reply you inline. On Thu, Dec 10, 2009 at 12:21 PM, Sri Gundavelli wrote: > Hi Bo: > > > > [bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solution >> for IPv4 exhaustion. But I cannot see any motivation for existed IPv4 >> application developer upgrade their application to support IPv6, because >> base on your solution, IPv4 working very well. So maybe in many ages, we >> cannot see any application relies on IPv6. >> >> > :) When PNAT is deployed, what is the motivation for the developer to use > IPv6 ? You plan to support their legacy IPv4 applications for ever. IPv4 > is "working very well", and on IPv6 transport too. App developers can > continue to use IPv4-only sockets and can interact with potentially IPv6 > future peers. [bo] At least, we allow 4-6 communication, allow the v4 client visit v6 server. > > My point is, do not make those applications that use IPv4-only sockets > written for legacy platforms and have binaries only, to magically work > on new platforms that have IPv6-only transport. Let them migrate or > retire those applications. Let applications behave normally and don't > give special incentives there. > [bo] Good point. But I remember you mentioned couple days ago, operators do not want their customers experience the breakup of services. Do you think any operator can take the risk to throw away some "already-run" services from the network because these services could not support new IPv6 transport platform? > > > Sri > > > -- Regards, Bo Zhou China Mobile --001485f99caaea93f8047a5a6257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sri,
=A0
I thought I caught a cold, hope it is not swine flu.
But it make my brain stop working.
But I will still reply you inlin= e.
On Thu, Dec 10, 2009 at 12:21 PM, Sri Gundavelli= <sgundave@cisco= .com> wrote:
Hi Bo:=20



[bo] Well, you introduce IPv6 as= a tunnel, I believe it is a good solution
for IPv4 exhaustion. But I ca= nnot see any motivation for existed IPv4
application developer upgrade their application to support IPv6, becausebase on your solution, IPv4 working very well. So maybe in many ages, wecannot see any application relies on IPv6.


:) When PNAT is deployed, what is the motivation for the developer to useIPv6 ? You plan to support their legacy IPv4 applications for ever. IPv4<= br>is "working very well", and on IPv6 transport too. App develop= ers can
continue to use IPv4-only sockets and can interact with potentially IPv6future peers.
[bo] At least, we allow 4-6 communication, allow the v4 client visit v= 6 server.

My point is, do not make tho= se applications that use IPv4-only sockets
written for legacy platforms = and have binaries only, to magically work
on new platforms that have IPv6-only transport. Let them migrate or
reti= re those applications. Let applications behave normally and don't
gi= ve special incentives there.
[bo] Good point. But I remember you mentioned couple days ago, operato= rs do not want their customers experience the breakup of services. Do you t= hink any operator can=A0take the risk to throw away some "already-run&= quot; services from the network because these services=A0 could not support= new IPv6 transport platform?
=A0


= Sri





--
R= egards,

Bo Zhou
China Mobile
--001485f99caaea93f8047a5a6257-- From ebisawa@sablenetworks.net Thu Dec 10 00:54:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8E43A689F for ; Thu, 10 Dec 2009 00:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6NTdif1-Lym for ; Thu, 10 Dec 2009 00:54:43 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 4F6823A67FA for ; Thu, 10 Dec 2009 00:54:43 -0800 (PST) Received: (qmail 12407 invoked by SAV 20091209.055 by uid 0); 10 Dec 2009 17:54:30 +0900 Received: from unknown (HELO ?192.168.14.50?) (ebisawa@122.220.29.26) by dc12.etius.jp (202.229.133.90) with ESMTPA; 10 Dec 2009 17:54:30 +0900 Date: Thu, 10 Dec 2009 17:54:07 +0900 From: Kentaro Ebisawa To: Behave WG Message-Id: <20091210174724.8323.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Subject: [BEHAVE] Translating code of ICMPv4 Parameter Problem (Type 12) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 08:54:44 -0000 Hi, draft-ietf-behave-xlate-04 [Page 14] says to translate ICMPv4 Type 12 (Parameter Problem) to ICMPv6 Type 4, but there are nothing mentioned about the Code to use. | Parameter Problem (Type 12) Set the Type field to 4. The | Pointer needs to be updated to point to the corresponding | field in the translated include IP header. It would be helpfull if we can clearly mention what code to use. Looking below, maybe we can translate all v4 codes to 0 ? Codes for ICMPv4 Type 12 : 0 - Pointer indicates the error 1 - Missing a Required Option 2 - Bad Length Codes for ICMPv6 Type 4 : 0 - Erroneous header field encountered 1 - Unrecognized Next Header type encountered 2 - Unrecognized IPv6 option encountered Regards, -- Kentaro Ebisawa , Skype: ebiken-skype From eric.burgey@orange-ftgroup.com Thu Dec 10 02:02:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C9B3A690D for ; Thu, 10 Dec 2009 02:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR5gapmNDkyw for ; Thu, 10 Dec 2009 02:02:50 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id D5FAE3A688F for ; Thu, 10 Dec 2009 02:02:49 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:02:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 11:02:34 +0100 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1A7928E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdqFWUvF8lhJYD0id0Bh1Dus4fZFdc0KwgACZ5nA= References: <4B1B8065.3040203@cernet.edu.cn><6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> From: To: , , , X-OriginalArrivalTime: 10 Dec 2009 10:02:35.0101 (UTC) FILETIME=[E57618D0:01CA797F] Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 10:02:51 -0000 Hello, I have a question about this IPv4 translatable IPv6 address: Is possible to use this address on a real node interface or is just the = IPv6 address of a virtual interface ? If it is just for virtual interfaces, it is not really one node in the = subnet but just one virtual interface in a virtual subnet inside a node = connected to the real network through a different global unicast IPv6 = address and acting as router toward this virtual subnet and i fully = support the proposed format. If it can assign to a real interface, the proposed sentence means that = this interface must be the only one interface on the link, so it means = that it is a point to point link. I have the feeling that it is a little = bit too much restrictive.=20 An alternative solution may be to write that this format is reserved for = virtual interface and that, if there is a need to allocate an IPv4 = translatable IPv6 to a real interface, another suffix value may be = considered. Best regards Eric BURGEY -----Message d'origine----- De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de Dave Thaler Envoy=E9=A0: jeudi 10 d=E9cembre 2009 01:36 =C0=A0: Christian Huitema; Xing Li; 'Behave WG'; Behave Chairs Objet=A0: Re: [BEHAVE] address-format: null suffix, consensus check > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Christian Huitema > Sent: Sunday, December 06, 2009 10:24 AM > To: Xing Li; 'Behave WG'; Behave Chairs > Subject: Re: [BEHAVE] address-format: null suffix, consensus check >=20 > I actually changed that text in the rev2 draft. The last text says: >=20 > When a /32 prefix is used, an all-zero suffix results in an = all-zero > interface identifier. We understand the conflict with Section = 2.6.1 > of RFC4291, which specifies that all zeroes are used for the = subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the s/host/node/ It's not relevant whether there's only one "host" in the /64 subnet. What's relevant is whether there's only one *node* in the /64 subnet (a router is a node but not a host). > anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (This issue does not exist for prefixes = larger > than 32 bits, such as the /40, /56 and /64 prefixes that we > recommend > in section 3.3.) >=20 >=20 >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Xing Li > Sent: Sunday, December 06, 2009 1:59 AM > To: 'Behave WG'; Behave Chairs > Subject: [BEHAVE] address-format: null suffix, consensus check >=20 > Hi, All, >=20 > In the draft-ietf-behave-address-format-01.txt, the document reads: >=20 > When a /32 prefix is used, the null suffix results in a null > identifier. We understand the conflict with Section 2.6.1 of > RFC4291, which specifies that all zeroes are used for the subnet- > router anycast address. However, in our specification, there would > be only one IPv4 translatable host in the /64 subnet, and the anycast > semantic would not create confusion. We thus decided to keep the > null suffix for now. (Different authors of this document have > different opinions.) >=20 > An example which support the above argument is presented in page 18 of > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt >=20 > Please confirm if we should keep the current conclusion. >=20 > Regards, >=20 > xing >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Thu Dec 10 09:38:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155E93A6ADE; Thu, 10 Dec 2009 09:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUnJWCNkwLGz; Thu, 10 Dec 2009 09:38:25 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C53373A699D; Thu, 10 Dec 2009 09:38:24 -0800 (PST) Received: from r190-135-28-192.dialup.adsl.anteldata.net.uy (r190-135-28-192.dialup.adsl.anteldata.net.uy [190.135.28.192]) by smtp03.uc3m.es (Postfix) with ESMTP id 1AD117F3252; Thu, 10 Dec 2009 18:38:09 +0100 (CET) Message-ID: <4B211690.6020403@it.uc3m.es> Date: Thu, 10 Dec 2009 16:41:04 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Xu Xiaohu References: <002501ca7939$1b19c190$d40c6f0a@china.huawei.com> In-Reply-To: <002501ca7939$1b19c190$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:38:26 -0000 Xu Xiaohu escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ10ÈÕ 9:26 >> ÊÕ¼þÈË: Xu Xiaohu >> ³­ËÍ: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org >> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> Xu Xiaohu escribi¨®: >> >>>> -----ÓʼþÔ­¼þ----- >>>> ·¢¼þÈË: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] ´ú±í >>>> marcelo bagnulo braun >>>> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ9ÈÕ 21:24 >>>> ÊÕ¼þÈË: Christian Huitema >>>> ³­ËÍ: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org >>>> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >>>> non-0::/3 IPv6 addresses ? >>>> >>>> Christian Huitema escribi¨®: >>>> >>>> >>>>>> At least the former usage has some certain applications. For example, >>>>>> >>>>>> >>> in >>> >>> >>>>>> case of NAT64, if a dual-stack host could distinguish synthesized >>>>>> > IPv6 > >>>>>> addresses from native IPv6 addresses, it will not prefer a >>>>>> > synthesized > >>> IPv6 >>> >>> >>>>>> address to an IPv4 address for initiating a communication with an >>>>>> > IPv4 > >>> host. >>> >>> >>>>> The well known prefix is easy to recognize, so there is no problem >>>>> >>>>> >>> there. >>> >>> >>>> For stateless, the design makes sure that the IPv4 translatable >>>> > addresses > >>> can >>> >>> >>>> be routed natively, which means there is no reason to not prefer them. >>>> >>>> >>> That >>> >>> >>>> leaves a pretty small domain of applicability for any scheme that would >>>> >>>> >>> reserve >>> >>> >>>> identifier patterns... >>>> >>>> >>>> In addition, in the NSP case, the host can configure the RFC3484 policy >>>> table to preffer native connectivity. >>>> >>>> >>> However, when one configures such a policy that native IPv6 connectivity >>> should be preferred to IPv4 connectivity. How could the dual-stack host >>> distinguish synthesized IPv6 addresses from native IPv6 addresses? If >>> > there > >>> are some bits to tell whether it is an IPv4-embeded IPv6 address or not >>> (even which type of IPv4-embeded IPv6 address), the above issue can be >>> solved easily. >>> >>> >> for the NSP, what the host needs to know is the NSP itself, that is what >> needs to be included in the policy table >> > > Even so, if a dual-stack host obtains a synthesized IPv6 address as a > response to its DNS query for AAAA record at first, will it send a DNS query > for A record later due to the above policy table? > mmm two comments about this. First in general, except some rare excpetions, the dual stack hosts should not have a dns64 capable server as their dns server, so in general this should not happen Second, you don't solve this problem by adding some bits in the middle for recognizing the synthetic addresses. The point is that i am making is that having them in the rpefix or in the iid achieve the same capability (and have the same limitations) Regards, marcelo > Xiaohu > > >>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>>> -- Christian Huitema >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>> >>> > > > From charliep@wichorus.com Thu Dec 10 09:59:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC903A6B0B for ; Thu, 10 Dec 2009 09:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MpkwkmSOhMx for ; Thu, 10 Dec 2009 09:59:23 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id EFBD13A6AFD for ; Thu, 10 Dec 2009 09:59:15 -0800 (PST) Received: from [12.204.153.98] (helo=[10.166.254.201]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NInI8-0007Vx-Eb; Thu, 10 Dec 2009 12:59:04 -0500 Message-ID: <4B2136E6.3080503@wichorus.com> Date: Thu, 10 Dec 2009 09:59:02 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: bo zhou References: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> <36a593230912091932k1a02dbbem84ad49b0c7665d10@mail.gmail.com> In-Reply-To: <36a593230912091932k1a02dbbem84ad49b0c7665d10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52da0deefc24f41611fa0b98e546fc636d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "behave@ietf.org" , Sri Gundavelli Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:59:23 -0000 Hello Bo, One question: why do you think DS-Lite is a good solution for IPv4 address exhaustion? I mean, why is it better than, say, existing NAT solutions? bo zhou wrote: > Dear Sri, > > > > A much more logical step would be to retain the IPv4 network and > possibly > use Dual-stack lite to solve the IPv4 exhaust issue, > ... > [bo] I guess you are talking using IPv4 forever, I agree DS-lite is a > good solution for solving IPv4 exhaustion issue, but not good for IPv6. As far as I have understood, DS-Lite doesn't really help very much compared to existing NAT in most cases. But it does allow IPv6 and IPv4 applications on the same host, and (from the standpoint of the existing Internet) allows larger "privately addressed" domains to be attached without the limitations of IPv4 private address spaces. Is there something more? On the downside, at least in some proposals as are being discussed in this thread, host modifications might be required for the ALGs... right? Regards, Charlie P. From A.Hoenes@TR-Sys.de Wed Dec 9 16:01:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719D63A6856 for ; Wed, 9 Dec 2009 16:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.129 X-Spam-Level: *** X-Spam-Status: No, score=3.129 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl51cv+xVZRj for ; Wed, 9 Dec 2009 16:01:11 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C4FCD3A684C for ; Wed, 9 Dec 2009 16:01:10 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA002603197; Thu, 10 Dec 2009 00:59:58 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA06299; Thu, 10 Dec 2009 00:59:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200912092359.AAA06299@TR-Sys.de> To: draft-ietf-behave-address-format@cabernet.tools.IETF.ORG Date: Thu, 10 Dec 2009 00:59:56 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 10 Dec 2009 10:01:00 -0800 Cc: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 00:01:12 -0000 Folks, I got stuck in section 2 of draft-ietf-behave-address-format. How did you manage to get >>>> 17-octet prefixes <<<< (sic!) (as shown in the table/diagram)? Perhaps, in the 'ruler headline' "127-" needs to be deleted since bit #127 is the last bit of the 16yh octet and not the starting bit of the 17th octet.. In the first 5 main table rows, perhaps the 'u' octet can and should be removed, the corresponding octet in the last table row, and the subsequent text needs to be adjusted accordingly (removing 'u' and adjusting bit numbers). Note: This way, the table also will better fit into the margins. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From huitema@microsoft.com Thu Dec 10 10:12:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5C83A6B20 for ; Thu, 10 Dec 2009 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqX2TesaHJwF for ; Thu, 10 Dec 2009 10:12:49 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2246428C12C for ; Thu, 10 Dec 2009 10:12:49 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Dec 2009 10:12:37 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 10 Dec 2009 10:12:30 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 10 Dec 2009 10:12:09 -0800 From: Christian Huitema To: "ah@TR-Sys.de" , "draft-ietf-behave-address-format@cabernet.tools.IETF.ORG" Thread-Topic: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! Thread-Index: AQHKecM1OBNvKhGSE0SbcP2e3+XHJpFelMoQ Date: Thu, 10 Dec 2009 18:12:08 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F73B3@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <200912092359.AAA06299@TR-Sys.de> In-Reply-To: <200912092359.AAA06299@TR-Sys.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:12:55 -0000 Yes, this was an editing error in the 01 draft. It will be fixed in the 02 = draft. -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= ah@TR-Sys.de Sent: Wednesday, December 09, 2009 4:00 PM To: draft-ietf-behave-address-format@cabernet.tools.IETF.ORG Cc: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! Folks, I got stuck in section 2 of draft-ietf-behave-address-format. How did you manage to get >>>> 17-octet prefixes <<<< (sic!) (as shown in the table/diagram)? Perhaps, in the 'ruler headline' "127-" needs to be deleted since bit #127 is the last bit of the 16yh octet and not the starting bit of the 17th octet.. In the first 5 main table rows, perhaps the 'u' octet can and should be removed, the corresponding octet in the last table row, and the subsequent text needs to be adjusted accordingly (removing 'u' and adjusting bit numbers). Note: This way, the table also will better fit into the margins. Kind regards, Alfred H=CEnes. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Thu Dec 10 12:18:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81A43A6940 for ; Thu, 10 Dec 2009 12:18:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWKSvMQIJOza for ; Thu, 10 Dec 2009 12:18:05 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id B7D953A6907 for ; Thu, 10 Dec 2009 12:18:04 -0800 (PST) Received: from drugs.dv.isc.org (unknown [IPv6:2001:4f8:3:65:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0A884E601C; Thu, 10 Dec 2009 20:17:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBAKHoor006460; Fri, 11 Dec 2009 07:17:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912102017.nBAKHoor006460@drugs.dv.isc.org> To: "Charles E. Perkins" From: Mark Andrews References: <00a301ca7706$a75d9e40$4a0c6f0a@china.huawei.com> <36a593230912091932k1a02dbbem84ad49b0c7665d10@mail.gmail.com> <4B2136E6.3080503@wichorus.com> In-reply-to: Your message of "Thu, 10 Dec 2009 09:59:02 -0800." <4B2136E6.3080503@wichorus.com> Date: Fri, 11 Dec 2009 07:17:50 +1100 Sender: marka@isc.org Cc: bo zhou , "behave@ietf.org" , Sri Gundavelli Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:18:06 -0000 In message <4B2136E6.3080503@wichorus.com>, "Charles E. Perkins" writes: > > Hello Bo, > > One question: why do you think DS-Lite is a good solution > for IPv4 address exhaustion? I mean, why is it better than, > say, existing NAT solutions? You have a million customers each with a around 5 clients machines using 1 public address today with home CPE NAT's. DS lite gives you 200+ client machines per public address and puts IPv6 into the the home with without using NAT for IPv6. In both cases this is with one level of NAT. > bo zhou wrote: > > Dear Sri, > > > > > > > > A much more logical step would be to retain the IPv4 network and > > possibly > > use Dual-stack lite to solve the IPv4 exhaust issue, > > > ... > > > [bo] I guess you are talking using IPv4 forever, I agree DS-lite is a > > good solution for solving IPv4 exhaustion issue, but not good for IPv6. > > As far as I have understood, DS-Lite doesn't really > help very much compared to existing NAT in most > cases. But it does allow IPv6 and IPv4 applications > on the same host, and (from the standpoint of the existing > Internet) allows larger "privately addressed" domains to > be attached without the limitations of IPv4 private > address spaces. Is there something more? > > On the downside, at least in some proposals as are > being discussed in this thread, host modifications might > be required for the ALGs... right? > > Regards, > Charlie P. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dthaler@microsoft.com Thu Dec 10 13:11:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133273A63D3 for ; Thu, 10 Dec 2009 13:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.304 X-Spam-Level: X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM89F5GZR0YP for ; Thu, 10 Dec 2009 13:11:51 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id EE94C3A6907 for ; Thu, 10 Dec 2009 13:11:50 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Dec 2009 13:11:39 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 10 Dec 2009 13:11:39 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 10 Dec 2009 13:11:20 -0800 From: Dave Thaler To: "eric.burgey@orange-ftgroup.com" , Christian Huitema , "xing@cernet.edu.cn" , "behave@ietf.org" Thread-Topic: [BEHAVE] address-format: null suffix, consensus check Thread-Index: AQHKdqFWUvF8lhJYD0id0Bh1Dus4fZFdc0KwgACZ5nCAAL/hgA== Date: Thu, 10 Dec 2009 21:11:17 +0000 Message-ID: References: <4B1B8065.3040203@cernet.edu.cn><6B55F0F93C3E9D45AF283313B8D342BA211F2E21@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <08BA2C59E081884DB2AAE4A0BE9D6DC1A7928E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1A7928E@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] address-format: null suffix, consensus check X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 21:11:53 -0000 > -----Original Message----- > From: eric.burgey@orange-ftgroup.com [mailto:eric.burgey@orange- > ftgroup.com] > Sent: Thursday, December 10, 2009 2:03 AM > To: Dave Thaler; Christian Huitema; xing@cernet.edu.cn; behave@ietf.org > Subject: RE: [BEHAVE] address-format: null suffix, consensus check >=20 > Hello, > I have a question about this IPv4 translatable IPv6 address: > Is possible to use this address on a real node interface or is just the > IPv6 address of a virtual interface ? IPv4-translatable addresses should be usable on regular interfaces. However, I don't believe the text about null suffix should apply to IPv4 translatable addresses, only IPv4 converted addresses, for exactly the reason you mention. -Dave >=20 > If it is just for virtual interfaces, it is not really one node in the > subnet but just one virtual interface in a virtual subnet inside a node > connected to the real network through a different global unicast IPv6 > address and acting as router toward this virtual subnet and i fully > support the proposed format. >=20 > If it can assign to a real interface, the proposed sentence means that > this interface must be the only one interface on the link, so it means > that it is a point to point link. I have the feeling that it is a > little bit too much restrictive. > An alternative solution may be to write that this format is reserved > for virtual interface and that, if there is a need to allocate an IPv4 > translatable IPv6 to a real interface, another suffix value may be > considered. >=20 > Best regards >=20 > Eric BURGEY >=20 >=20 > -----Message d'origine----- > De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la > part de Dave Thaler > Envoy=E9=A0: jeudi 10 d=E9cembre 2009 01:36 > =C0=A0: Christian Huitema; Xing Li; 'Behave WG'; Behave Chairs > Objet=A0: Re: [BEHAVE] address-format: null suffix, consensus check >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Christian Huitema > > Sent: Sunday, December 06, 2009 10:24 AM > > To: Xing Li; 'Behave WG'; Behave Chairs > > Subject: Re: [BEHAVE] address-format: null suffix, consensus check > > > > I actually changed that text in the rev2 draft. The last text says: > > > > When a /32 prefix is used, an all-zero suffix results in an all- > zero > > interface identifier. We understand the conflict with Section > 2.6.1 > > of RFC4291, which specifies that all zeroes are used for the > subnet- > > router anycast address. However, in our specification, there > would > > be only one IPv4 translatable host in the /64 subnet, and the >=20 > s/host/node/ >=20 > It's not relevant whether there's only one "host" in the /64 subnet. > What's relevant is whether there's only one *node* in the /64 subnet > (a router is a node but not a host). >=20 >=20 > > anycast > > semantic would not create confusion. We thus decided to keep the > > null suffix for now. (This issue does not exist for prefixes > larger > > than 32 bits, such as the /40, /56 and /64 prefixes that we > > recommend > > in section 3.3.) > > > > > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Xing Li > > Sent: Sunday, December 06, 2009 1:59 AM > > To: 'Behave WG'; Behave Chairs > > Subject: [BEHAVE] address-format: null suffix, consensus check > > > > Hi, All, > > > > In the draft-ietf-behave-address-format-01.txt, the document reads: > > > > When a /32 prefix is used, the null suffix results in a null > > identifier. We understand the conflict with Section 2.6.1 of > > RFC4291, which specifies that all zeroes are used for the subnet- > > router anycast address. However, in our specification, there would > > be only one IPv4 translatable host in the /64 subnet, and the anycast > > semantic would not create confusion. We thus decided to keep the > > null suffix for now. (Different authors of this document have > > different opinions.) > > > > An example which support the above argument is presented in page 18 > of > > http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt > > > > Please confirm if we should keep the current conclusion. > > > > Regards, > > > > xing > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Thu Dec 10 14:16:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB263A6B5D for ; Thu, 10 Dec 2009 14:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lqLWkUCtMHB for ; Thu, 10 Dec 2009 14:16:39 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id EBDE03A67F6 for ; Thu, 10 Dec 2009 14:16:38 -0800 (PST) Received: by pwi20 with SMTP id 20so225161pwi.29 for ; Thu, 10 Dec 2009 14:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=d5NQYJpeeEjfiNzqkzVTewUeH3zyjtKTUPygkmm84ts=; b=U83TkhtTvfZwoj26gIGq3//Kk6tH5YvRErQ/amYhZ2G6xH32WoyvTm5cRh2AF8q73P DchAFOG+YHXoLPg5KyZ+NUToVonx8bwIMsEyr2VKD9mIyFSn/CezmtRraXdeJh9hxzEG 2XuUqQj18nIG2JJ4kBUW++09Sdvf6BXdCSxpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=J/TLBN/KocWRRrFJpw5IEfZHNe2ARSa0wuZILvfOaSzT/M2DST5KoZXJMTE0b4/QeD YFd0cWC3HdoX8/U3nZSsKlaD/pNyKeyRkjk2h5He7aTtfjkJaaVMyZhnhSamihZVErwe 6ajgGt6bmto8l1oCGJK1wZggV4cJ3PDDN9dCU= Received: by 10.142.6.20 with SMTP id 20mr305354wff.262.1260483384774; Thu, 10 Dec 2009 14:16:24 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm1229198pzk.10.2009.12.10.14.16.22 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 14:16:24 -0800 (PST) Message-ID: <4B217337.2040400@gmail.com> Date: Fri, 11 Dec 2009 11:16:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: bo zhou References: <1d38a3350912090750h799d8ee6pd55c06441ff8c5b@mail.gmail.com> <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> In-Reply-To: <36a593230912091943nf7569aet4ee264f75b45fef8@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , Sheng Jiang , behave@ietf.org, Sri Gundavelli Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 22:16:40 -0000 On 2009-12-10 16:43, bo zhou wrote: > Hi Sri, >=20 > Reply inline. >=20 > On Thu, Dec 10, 2009 at 12:17 AM, Sri Gundavelli w= rote: >=20 >> You are deploying IPv6 on the network and have IPv6-only hosts: >> >> - but your applications still use IPv4. >> - they won't use IPv6 natively which is available >> > [bo] Can you ask application developer do something. Maybe not, what yo= u can > do is recommend them do something. We cannot predict their behaviour, m= aybe > 5=EF=BC=90% follow your recommendation, 50% not. It rises to 100% when an application fails to work any more. That incenti= ve is pretty strong. But it drops to 0% if you promise to support a legacy solution indefinitely, which guarantees long-term costs for the carriers and avoids costs for the application developers. I don't understand the business case for your requirement. Long term messy solution for vendors and carriers versus simple short term work for application developers? Brian >> So, turning of IPv4, not sure, how its helping and what is migrated. A= nd >> this solution comes at a cost of making significant host stack changes= and >> having to maintain that code base for years to come. >> >> And we are deploying IPv6, removing IPv4 routing from the network, but= >> still >> enabling support for IPv4 services and we are not modifying hosts. >> > [bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solut= ion > for IPv4 exhaustion. But I cannot see any motivation for existed IPv4 > application developer upgrade their application to support IPv6, becaus= e > base on your solution, IPv4 working very well. So maybe in many ages, w= e > cannot see any application relies on IPv6. >=20 >> Sri >> >> >> >> >> On 12/9/09 7:50 AM, "Hui Deng" wrote: >> >>> fundamental difference here: >>> 1) u r doing IPv4 and solving ipv4 problem >>> 2) we are doing IPv6 and solving IPv6 problem >>> >>> -Hui >>> >>> 2009/12/9 Sri Gundavelli : >>>> Hi Sheng, >>>> >>>> If you decide to support such legacy IPv4 applications on future >> platforms, >>>> its rather logical to go with a dual-stack network till you migrate >> those >>>> applications to IPv6, or till you retire them. If your expectation i= s >> that >>>> you will have millions of such applications that you need to carry >> forward >>>> and without code recompilation on future platforms, may be the choi= ce >> of >>>> IPv6-only network as the first step in IPv6 migration is not the rig= ht >> step. >>>> A much more logical step would be to retain the IPv4 network and >> possibly >>>> use Dual-stack lite to solve the IPv4 exhaust issue, then you don't = have >> to >>>> deal with these weird cases and introduce significant changes to all= >> host >>>> stacks. >>>> >>>> If I may ask, which out of the two is a cost affective approach ? (1= ) >>>> Dealing with the development and maintenance of ALG's, modified host= >> stacks >>>> and translation functions on a zillion operating systems, Windows >> Mobile, >>>> Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensu= re >> all >>>> the roaming scenarios are not impacted, OR (2) just simply keep your= >>>> existing IPv4 network, don't turn it off on one fine morning in 2011= ? >> Are >>>> the efforts even in the same order of magnitude ? May be the migrati= on >>>> strategy of that operator requires some re-thinking ? >>>> >>>> Regards >>>> Sri >>>> >>>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ebisawa@sablenetworks.net Thu Dec 10 21:12:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15EE3A67EF for ; Thu, 10 Dec 2009 21:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwxeAmJk8jpx for ; Thu, 10 Dec 2009 21:12:47 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id F141F3A6359 for ; Thu, 10 Dec 2009 21:12:46 -0800 (PST) Received: (qmail 19376 invoked by SAV 20091210.052 by uid 0); 11 Dec 2009 14:12:34 +0900 Received: from unknown (HELO ?192.168.14.50?) (ebisawa@122.220.29.26) by dc12.etius.jp (202.229.133.90) with ESMTPA; 11 Dec 2009 14:12:34 +0900 Date: Fri, 11 Dec 2009 14:12:17 +0900 From: Kentaro Ebisawa To: behave@ietf.org Message-Id: <20091211140848.8337.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Subject: [BEHAVE] Translating ICMPv4 Type 3 Code 13-15 (draft-ietf-behave-v6v4-xlate-04) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 05:12:53 -0000 Hi, While reviewing draft-ietf-behave-v6v4-xlate-04, I noticed how to translate ICMPv4 Type 3 Code 13-15 are not mentioned in the doc. * Type, Code (defined in RFC1812) 3, 13 : Communication Administratively Prohibited 3, 14 : Host Precedence Violation 3, 15 : Precedence cutoff in effect Is this already discussed somewhere ? If not, I think we should add text explaining how to translate these codes as well. For example, here are my idea how it should be translated. Code 13: Set Type field to 1, Code 1 (communication with destination administratively prohibited) Code 14: Single hop message. Silently drop. # RFC1812: # 14 = Host Precedence Violation. Sent by the first hop router to a # host to indicate that a requested precedence is not permitted # for the particular combination of source/destination host or Code 15: Set Type field to 1, Code 1 (communication with destination administratively prohibited) Regards, -- Kentaro Ebisawa , Skype: ebiken-skype From xuxh@huawei.com Fri Dec 11 01:45:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749683A6AF0; Fri, 11 Dec 2009 01:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNVdw94jMWPK; Fri, 11 Dec 2009 01:45:32 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 332713A6A11; Fri, 11 Dec 2009 01:45:32 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUH002XPF03I1@szxga04-in.huawei.com>; Fri, 11 Dec 2009 17:43:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUH00C5WF03SB@szxga04-in.huawei.com>; Fri, 11 Dec 2009 17:43:15 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUH008K7F02HW@szxml04-in.huawei.com>; Fri, 11 Dec 2009 17:43:15 +0800 (CST) Date: Fri, 11 Dec 2009 17:43:14 +0800 From: Xu Xiaohu In-reply-to: <4B211690.6020403@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <005f01ca7a46$5c6c20d0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp5v5gK3LcPfGtjTnmhYyP8FfZpegAgEfcQ Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 09:45:33 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C210=C8=D5 23:41 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > Xu Xiaohu escribi=A8=AE: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C210=C8=D5 9:26 > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> Xu Xiaohu escribi=A8=AE: > >> > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >>>> =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > >>>> marcelo bagnulo braun > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C29=C8=D5 21:24 > >>>> =CA=D5=BC=FE=C8=CB: Christian Huitema > >>>> =B3=AD=CB=CD: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org > >>>> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL > >>>> non-0::/3 IPv6 addresses ? > >>>> > >>>> Christian Huitema escribi=A8=AE: > >>>> > >>>> > >>>>>> At least the former usage has some certain applications. For example, > >>>>>> > >>>>>> > >>> in > >>> > >>> > >>>>>> case of NAT64, if a dual-stack host could distinguish = synthesized > >>>>>> > > IPv6 > > > >>>>>> addresses from native IPv6 addresses, it will not prefer a > >>>>>> > > synthesized > > > >>> IPv6 > >>> > >>> > >>>>>> address to an IPv4 address for initiating a communication with = an > >>>>>> > > IPv4 > > > >>> host. > >>> > >>> > >>>>> The well known prefix is easy to recognize, so there is no = problem > >>>>> > >>>>> > >>> there. > >>> > >>> > >>>> For stateless, the design makes sure that the IPv4 translatable > >>>> > > addresses > > > >>> can > >>> > >>> > >>>> be routed natively, which means there is no reason to not prefer them. > >>>> > >>>> > >>> That > >>> > >>> > >>>> leaves a pretty small domain of applicability for any scheme that would > >>>> > >>>> > >>> reserve > >>> > >>> > >>>> identifier patterns... > >>>> > >>>> > >>>> In addition, in the NSP case, the host can configure the RFC3484 policy > >>>> table to preffer native connectivity. > >>>> > >>>> > >>> However, when one configures such a policy that native IPv6 connectivity > >>> should be preferred to IPv4 connectivity. How could the dual-stack host > >>> distinguish synthesized IPv6 addresses from native IPv6 addresses? = If > >>> > > there > > > >>> are some bits to tell whether it is an IPv4-embeded IPv6 address = or not > >>> (even which type of IPv4-embeded IPv6 address), the above issue = can be > >>> solved easily. > >>> > >>> > >> for the NSP, what the host needs to know is the NSP itself, that is what > >> needs to be included in the policy table > >> > > > > Even so, if a dual-stack host obtains a synthesized IPv6 address as = a > > response to its DNS query for AAAA record at first, will it send a = DNS query > > for A record later due to the above policy table? > > >=20 > mmm two comments about this. > First in general, except some rare excpetions, the dual stack hosts > should not have a dns64 capable server as their dns server, so in > general this should not happen Consider a scenario where dual-stack hosts coexist with IPv6 only hosts (IPv6 only stack or dual-stack with only IPv6 address), should they be configured with different DNS servers? That is to say, should dual-stack hosts be configured with a normal DNS server, while IPv6 only hosts configured with a DNS64 capable server? Or do you believe the above scenario itself is rare? > Second, you don't solve this problem by adding some bits in the middle > for recognizing the synthetic addresses. The point is that i am making > is that having them in the rpefix or in the iid achieve the same > capability (and have the same limitations) There seems no bit in a NSP to tell whether an IPv6 address is a = synthetic address or not in the current address-format draft. On the contrary, we could use some bits in the IID to achieve that goal.=20 Another possible way is as follows: the NSP used for synthesizing IPv6 address should be a specific prefix, e.g. starting with the binary value 00010101. In this way, the constraint on IID format mentioned before is removed due to starting with the binary value 000. In addition, this = address is also provider aggregatable because the remaining part between the = above binary value and the last four octets (i.e., IPv4 address to be = embedded) is network specific. Comments? Best wishes, Xiaohu > > > > > >>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> > >>>> > >>>>> -- Christian Huitema > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Behave mailing list > >>>>> Behave@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Behave mailing list > >>>> Behave@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/behave > >>>> > >>>> > >>> > >>> > > > > > > From remi.despres@free.fr Fri Dec 11 06:02:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463BF3A6860 for ; Fri, 11 Dec 2009 06:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp1NJzKLLL6q for ; Fri, 11 Dec 2009 06:02:03 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id C2C9E3A635F for ; Fri, 11 Dec 2009 06:02:01 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id BC62CE08198; Fri, 11 Dec 2009 15:01:44 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 28BDCE080A9; Fri, 11 Dec 2009 15:01:41 +0100 (CET) Message-ID: <4B2250C4.7070801@free.fr> Date: Fri, 11 Dec 2009 15:01:40 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090319) MIME-Version: 1.0 To: Christian Huitema References: <200912092359.AAA06299@TR-Sys.de> <6B55F0F93C3E9D45AF283313B8D342BA211F73B3@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211F73B3@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-behave-address-format@cabernet.tools.IETF.ORG" , "ah@TR-Sys.de" , "behave@ietf.org" Subject: Re: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 14:02:04 -0000 Christian, Just a minor suggestion at the top of page 5: after "host identifier format defined in the IPv6 addressing architecture", add "of [RFC 4291]". Thus, if the 'u' octet constraint is eventually relaxed, no update of your text will be needed. Regards, RD Christian Huitema a écrit : > Yes, this was an editing error in the 01 draft. It will be fixed in the 02 draft. > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ah@TR-Sys.de > Sent: Wednesday, December 09, 2009 4:00 PM > To: draft-ietf-behave-address-format@cabernet.tools.IETF.ORG > Cc: behave@ietf.org > Subject: [BEHAVE] draft-ietf-behave-address-format-01 -- section 2 flawed! > > Folks, > I got stuck in section 2 of draft-ietf-behave-address-format. > > How did you manage to get >>>> 17-octet prefixes <<<< (sic!) > (as shown in the table/diagram)? > > Perhaps, in the 'ruler headline' "127-" needs to be deleted > since bit #127 is the last bit of the 16yh octet and not the > starting bit of the 17th octet.. > > In the first 5 main table rows, perhaps the 'u' octet can and > should be removed, the corresponding octet in the last table row, > and the subsequent text needs to be adjusted accordingly (removing > 'u' and adjusting bit numbers). > > Note: > This way, the table also will better fit into the margins. > > > Kind regards, > Alfred HÎnes. > From marcelo@it.uc3m.es Fri Dec 11 12:57:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED00A3A68E0; Fri, 11 Dec 2009 12:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrmyCC82Nwne; Fri, 11 Dec 2009 12:57:17 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 81FEB3A68C9; Fri, 11 Dec 2009 12:57:17 -0800 (PST) Received: from r190-132-213-66.dialup.adsl.anteldata.net.uy (unknown [190.132.213.66]) by smtp01.uc3m.es (Postfix) with ESMTP id 9229BBA0163; Fri, 11 Dec 2009 21:56:56 +0100 (CET) Message-ID: <4B22B213.7080604@it.uc3m.es> Date: Fri, 11 Dec 2009 21:56:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Xu Xiaohu References: <005f01ca7a46$5c6c20d0$d40c6f0a@china.huawei.com> In-Reply-To: <005f01ca7a46$5c6c20d0$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 20:57:19 -0000 Xu Xiaohu escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ10ÈÕ 23:41 >> ÊÕ¼þÈË: Xu Xiaohu >> ³­ËÍ: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org >> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> Xu Xiaohu escribi¨®: >> >>>> -----ÓʼþÔ­¼þ----- >>>> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ10ÈÕ 9:26 >>>> ÊÕ¼þÈË: Xu Xiaohu >>>> ³­ËÍ: 'Christian Huitema'; behave@ietf.org; ipv6@ietf.org >>>> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >>>> non-0::/3 IPv6 addresses ? >>>> >>>> Xu Xiaohu escribi¨®: >>>> >>>> >>>>>> -----ÓʼþÔ­¼þ----- >>>>>> ·¢¼þÈË: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] ´ú±í >>>>>> marcelo bagnulo braun >>>>>> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ9ÈÕ 21:24 >>>>>> ÊÕ¼þÈË: Christian Huitema >>>>>> ³­ËÍ: behave@ietf.org; Xu Xiaohu; ipv6@ietf.org >>>>>> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to >>>>>> > ALL > >>>>>> non-0::/3 IPv6 addresses ? >>>>>> >>>>>> Christian Huitema escribi¨®: >>>>>> >>>>>> >>>>>> >>>>>>>> At least the former usage has some certain applications. For >>>>>>>> > example, > >>>>>>>> >>>>> in >>>>> >>>>> >>>>> >>>>>>>> case of NAT64, if a dual-stack host could distinguish synthesized >>>>>>>> >>>>>>>> >>> IPv6 >>> >>> >>>>>>>> addresses from native IPv6 addresses, it will not prefer a >>>>>>>> >>>>>>>> >>> synthesized >>> >>> >>>>> IPv6 >>>>> >>>>> >>>>> >>>>>>>> address to an IPv4 address for initiating a communication with an >>>>>>>> >>>>>>>> >>> IPv4 >>> >>> >>>>> host. >>>>> >>>>> >>>>> >>>>>>> The well known prefix is easy to recognize, so there is no problem >>>>>>> >>>>>>> >>>>>>> >>>>> there. >>>>> >>>>> >>>>> >>>>>> For stateless, the design makes sure that the IPv4 translatable >>>>>> >>>>>> >>> addresses >>> >>> >>>>> can >>>>> >>>>> >>>>> >>>>>> be routed natively, which means there is no reason to not prefer >>>>>> > them. > >>>>>> >>>>> That >>>>> >>>>> >>>>> >>>>>> leaves a pretty small domain of applicability for any scheme that >>>>>> > would > >>>>>> >>>>> reserve >>>>> >>>>> >>>>> >>>>>> identifier patterns... >>>>>> >>>>>> >>>>>> In addition, in the NSP case, the host can configure the RFC3484 >>>>>> > policy > >>>>>> table to preffer native connectivity. >>>>>> >>>>>> >>>>>> >>>>> However, when one configures such a policy that native IPv6 >>>>> > connectivity > >>>>> should be preferred to IPv4 connectivity. How could the dual-stack >>>>> > host > >>>>> distinguish synthesized IPv6 addresses from native IPv6 addresses? If >>>>> >>>>> >>> there >>> >>> >>>>> are some bits to tell whether it is an IPv4-embeded IPv6 address or >>>>> > not > >>>>> (even which type of IPv4-embeded IPv6 address), the above issue can be >>>>> solved easily. >>>>> >>>>> >>>>> >>>> for the NSP, what the host needs to know is the NSP itself, that is >>>> > what > >>>> needs to be included in the policy table >>>> >>>> >>> Even so, if a dual-stack host obtains a synthesized IPv6 address as a >>> response to its DNS query for AAAA record at first, will it send a DNS >>> > query > >>> for A record later due to the above policy table? >>> >>> >> mmm two comments about this. >> First in general, except some rare excpetions, the dual stack hosts >> should not have a dns64 capable server as their dns server, so in >> general this should not happen >> > > Consider a scenario where dual-stack hosts coexist with IPv6 only hosts > (IPv6 only stack or dual-stack with only IPv6 address), should they be > configured with different DNS servers? yes, that's how they should be configured. Please note that this does not require two dns servers, you can run them in the same box as two separate process, and use two different ip addresses. That would be the best configuration (especially cause it would work with legacy nodes, either dual stack or v6 only). (please note that other mechanisms recognizing some bits, either the prefix or some bits in the iid would require updating the node, and that is why this method is superior) > That is to say, should dual-stack > hosts be configured with a normal DNS server, while IPv6 only hosts > configured with a DNS64 capable server? > > Or do you believe the above scenario itself is rare? > > >> Second, you don't solve this problem by adding some bits in the middle >> for recognizing the synthetic addresses. The point is that i am making >> is that having them in the rpefix or in the iid achieve the same >> capability (and have the same limitations) >> > > There seems no bit in a NSP to tell whether an IPv6 address is a synthetic > address or not in the current address-format draft. the NSP itself is what needs to be learned by the hosts that want to recognize a synthetic address! I mean, in particular with the rfc3484 poilicy table, you need to configure the NSP in the policy table, so that native connectivity is preferred. the main difference between this iand having a fix set of bits is that these need to be learnt by the hosts in order to recognize the NSP. Note that there is ongoing work to dynamically configure the rfc3484 policy table, which would deal with this issue. Another option is to use the WKP which can be hardcoded. > On the contrary, we > could use some bits in the IID to achieve that goal. > > Another possible way is as follows: the NSP used for synthesizing IPv6 > address should be a specific prefix, e.g. starting with the binary value > 00010101. we have that, and that is the WKP Regards, marcelo > In this way, the constraint on IID format mentioned before is > removed due to starting with the binary value 000. In addition, this address > is also provider aggregatable because the remaining part between the above > binary value and the last four octets (i.e., IPv4 address to be embedded) is > network specific. > > Comments? > > Best wishes, > Xiaohu > > >>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -- Christian Huitema >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Behave mailing list >>>>>>> Behave@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/behave >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Behave mailing list >>>>>> Behave@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/behave >>>>>> >>>>>> >>>>>> >>>>> >>> >>> > > > > From dthaler@microsoft.com Fri Dec 11 18:49:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716FB3A6803 for ; Fri, 11 Dec 2009 18:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFzhWPCIVKjV for ; Fri, 11 Dec 2009 18:49:12 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B67993A67BD for ; Fri, 11 Dec 2009 18:49:12 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Dec 2009 18:49:28 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 11 Dec 2009 18:49:00 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 11 Dec 2009 18:49:01 -0800 From: Dave Thaler To: "Charles E. Perkins" , "behave@ietf.org" Thread-Topic: [BEHAVE] SIPNAT documents posted Thread-Index: AQHKUQI+MU/anN5Q8EmqbdPVA+7Aw5FhB69w Date: Sat, 12 Dec 2009 02:48:59 +0000 Message-ID: References: <4ADCD710.5070302@wichorus.com> In-Reply-To: <4ADCD710.5070302@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] SIPNAT documents posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 02:49:13 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Monday, October 19, 2009 2:16 PM > To: behave@ietf.org > Subject: [BEHAVE] SIPNAT documents posted >=20 >=20 > Hello folks, >=20 > At 1:59:30pm Pacific Time today, I posted the following draft: > "Payload-assisted Delivery for SIPNAT" > http://www.ietf.org/internet-drafts/draft-perkins-behave-dpinat- > 00.txt >=20 > There is also a revision to the base SIPNAT document: > "Translating IPv4 to IPv6 based on source IPv4 address" > http://www.ietf.org/internet-drafts/draft-perkins-sourceipnat- > 01.txt >=20 > Comments are appreciated. Thanks to those who have helped > me to improve these documents before submission. >=20 > Regards, > Charlie P. Two comments: 1) The documents do not address the problem whereby some recursive resolvers (aka DNS servers) used by clients cache answers for some time (like 30 seconds) even if the record TTL is less. Multiple clients can get the same answer and only the first one will work and the rest will break. 2) In the dpinat document, it discusses using the HTTP GET in the NAT for demultiplexing. However, it can't get an HTTP GET until after a TCP connection is established, which means it would need to terminate the TCP connections itself and act more like an HTTP proxy rather than a NAT. (Which is what is discussed in http://tools.ietf.org/html/draft-wing-behave-http-46-relay) -Dave =20 From marcelo@it.uc3m.es Sat Dec 12 14:22:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6E03A67FE for ; Sat, 12 Dec 2009 14:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.302 X-Spam-Level: X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTvh3zV-fgDu for ; Sat, 12 Dec 2009 14:22:11 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 00DDB3A65A6 for ; Sat, 12 Dec 2009 14:22:06 -0800 (PST) Received: from r190-132-220-161.dialup.adsl.anteldata.net.uy (r190-132-220-161.dialup.adsl.anteldata.net.uy [190.132.220.161]) by smtp02.uc3m.es (Postfix) with ESMTP id 89A056C2A19; Sat, 12 Dec 2009 23:21:46 +0100 (CET) Message-ID: <4B241777.3050608@it.uc3m.es> Date: Sat, 12 Dec 2009 23:21:43 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17066.002 Cc: behave@ietf.org Subject: Re: [BEHAVE] Review Part 2(final) of draft-ietf-behave-v6v4-xlate-stateful-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 22:22:15 -0000 second part see replies below... George Tsirtsis escribió: > Hi all, > > This continues and concludes my review of > draft-ietf-behave-v6v4-xlate-stateful-03 > > So on with the review from section 3.2.2 where I left it in Part 1.. > > Regards > George > ... > > 3.2.2. TCP Session Handling > > The state information stored for a TCP session: > > Binding:(X',x),(Y',y) <--> (T,t),(Z,z) > > Lifetime: is a timer that tracks the remaining lifetime of the UDP > session. The NAT64 decrements this timer at regular intervals. > When the timer expires, the TCP session is deleted. If all the > TCP sessions corresponding to a TCP BIB entry are deleted, then > the TCP BIB entry is also deleted (only applies to the case of > dynamically created entries). > > TCP sessions are expensive, because their inactivity lifetime is set > to 2 hours and 4 min (as per [RFC5382]), so it is important that each > > GT> according to RFC5382: // to 2 hours... / to at least 2 hours.../ > > fixed > TCP session table entry corresponds to an existent TCP session. > > In > order to do that, the NAT64 tracks the TCP connection procedure. In > this section we describe how the NAT64 does that tracking by > describing the state machine. > > GT> Maybe rephrase: "In order to do that, for each TCP session > established through it, it tracks the corresponding state machine as > follows": > > done > The states are the following ones: > > CLOSED > V4 SYN RCV > V6 SYN RCV > ESTABLISHED > V4 FIN RCV > V6 FIN RCV > V6 FIN + V4 FIN RCV > RST RCV > > The state machine for the TCP session processing is depicted next. > > > GT> What state machine is this exactly? It is clearly not the TCP > state machine according to RFC793. > - Is it a state machine you expect the NAT64 to implement? > Yes, i will clarify this by rephrasing the previous sentence as: The state machine used by the NAT64 for the TCP session processing is depicted next. > - on which interface? on the one where the TCP client is or the TCP > server? or is this state machine driven by either side (seems this is > the case)? > the state machine is driven by either side: I have added a clarification on this issue as: The described state machine handles all TCP segments received through the IPv6 and IPv4 interface. > - are all states valid for all TCP session? It seems not. A given flow > will either be initiated from the IPv6 or from the IPv4 side and thus, > only some of these states will be valid for a given session. i think > it is not immediately obvious which ones these are which leads to some > confusion when reading through this. > > each potential connection has an associated state machine. as such, any connection can be initiated by any side. Of course, not all connections will go through all states, but this is the same for TCP, or any state machine. So i am not sure how to clarify this further. > Bagnulo, et al. Expires May 25, 2010 [Page 18] > > Internet-Draft NAT64 November 2009 > > > +----------------------------+ +-----------------------------+ > | | | | > | V V | > | V6 +------+ V4 | > | +----SYN------|CLOSED|-----SYN------+ | > | | +------+ | | > | | ^ | | > | | |4min T.O. | | > | V | V | > | +-------+ +-------+ +-------+ | > | |V6 SYN | |RST RCV| |V4 SYN | | > | | RCV | +-------+ | RCV | | > | +-------+ | ^ +-------+ | > | | data pkt | | | > | | | V4 or V6 RST | | > 2Hrs V4 SYN V | V6 SYN | > T.O. | +--------------+ | | > | +--------->| ESTABLISHED |<---------+ | > +--------------------->| | | > +--------------+ | > | | | > V4 FIN V6 FIN | > | | | > V V | > +---------+ +----------+ | > | V4 FIN | | V6 FIN | | > +---------+ +----------+ | > | | | > V6 FIN V4 FIN 4 min > | | T.O. > V V | > +-------------------+ | > | V4 FIN + V6 FIN |----------------------+ > +-------------------+ > > > > After bootstrapping of the NAT64 device, all TCP session are in > CLOSED state. We next describe the state information and the > transitions. > > GT> RFC793 (which BTW should be referenced) describes the CLOSED state > as imaginary...since in practice it only exists on paper to describe > the absence of any state. I would also suggest that a brief > description of each of the states similar to the ones listed in > RFC793, section 3.2 would be useful. > i have included the following text: CLOSED: Analogous to , CLOSED is a fictional because it represents the state when there is no state for this particular 5-tuple, and therefore, no connection. V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. the NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction. V6 SYN RCV: An IPv6 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv6 side. The NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction. ESTABLISHED: Represent an open connection, with data flowing in both directions. V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, the NAT64 is waiting for a matching TCP FIN in the opposite direction. V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, the NAT64 is waiting for a matching TCP FIN in the opposite direction. V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and an IPv6 packet containing an TCP FIN for this connection were received by the NAT64. The NAT64 keeps the connection state alive and forwards packet in both directions for a short period of time to allow remaining packets (in particular the ACKs) to be delivered. RST RCV: A packet containing a TCP RST was received by the NAT64 for this connection. The NAT64 will keep the state for the connection for a short time and if no other data packets for that connection are received, the assumption is that the node has accepted the RST packet and the state for this connection is then terminated. > A TCP segment with the SYN flag set that is received through the IPv6 > interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 > FIN + V4 FIN, V6 RST and V4 RST. > > *** CLOSED *** > > If a V6 SYN is received, the processing is as follows: > > GT> It would be useful to note that this constitutes a TCP session > initiation from the IPv6 side to the IPv4 side. I have added that in the state description above > It should also be > noted that IPv6 packets are only processed if the destination IPv6 > address is from Pref64::/n. > I have already addressed this in the filtering section in common for TCP and UDP as a response to a previous comment from you > > Bagnulo, et al. Expires May 25, 2010 [Page 19] > > Internet-Draft NAT64 November 2009 > > > The state of the session is moved to V6 SYN RCV. > > GT> I think that it is more accurate to first successfully process the > packet and then change the state, otherwise if something goes wrong > you have to move the state back or move to a different state. > right, done > The NAT64 searches for a TCP BIB entry that matches the IPv6 > source transport address. > > GT> Use the (X',x) <--> (T,t) notation to describe what this search involves. > > > I have updated the description to use the terminology > If such entry does not exists, a new entry is created. > > GT> What should the NAT64 do if an entry already exists? is this an > error or could it be a retransmission? In general I think you should > check all the "if" statements to make sure that the "if not" case is > also covered. > > Done, rephrased the text as follows If such entry does not exists, a new BIB entry is created. The BIB IPv6 transport address is set to (X',x) (i.e. the source IPv6 transport address of the packet) The BIB IPv4 transport address is the to an IPv4 transport address allocated using the rules defined in The processing of the packet continues as described in the next paragraph. If the entry already exists, then the processing continues as described in the next paragraph. > As IPv6 > address, the source IPv6 transport address of the packet is > included and an IPv4 transport address allocated using the > rules defined in Section 3.2.3 is included as the IPv4 > transport address. > > GT> Use the (X',x) <--> (T,t) notation to describe how the new entry is created. > > done > Then a new TCP session entry is created in the TCP session table. > The information included in the session table is as follows: > > GT> Again use the (X',x),(Y',y) <--> (T,t),(Z,z) notation. I know this > sounds painful but it will make things much clearer. > > done > The IPv6 transport source and destination addresses contained > in the received V6 SYN packet, > > The IPv4 transport source address is extracted from the > corresponding TCP BIB entry and, > > the IPv4 transport destination address contains the same port > as the IPv6 destination transport address and the IPv4 address > that is algorithmically generated from the IPv6 destination > address using the reverse algorithm as specified in > Section 3.2.5. > > The lifetime of the TCP session table entry is set to 4 min > (the transitory connection idle timeout as defined in > [RFC5382]). > > GT>according to the RFC: //is set to 4 min/is set to at least 4 min/ > > done > The packet is translated and forwarded. > > GT> point to translator draft > > well, this is described int he next sections actually, so i have rephrased as: The NAT64 translates and forwards the packet as described in the following sections > If a V4 SYN packet is received, the processing is as follows: > > GT> It would be useful to note that this constitutes a TCP session > initiation from the IPv4 side to the IPv6 side. done > It should also be > noted that IPv4 packets are only processed if the destination IPv4 > address is from the pool of IPv4 addresses explicitly used by NAT64 > for translation. This again ensures that NAT64 does not interfere with > packets that do not need translation. > > I have added the following text int he filtering section Likewise, the NAT64 function will only process incoming IPv4 packets that contain a destination address that belong to the IPv4 pool assigned to the NAT64. > If the security policy requires silently dropping externally > initiated TCP connections, then the packet is silently discarded, > else, > > GT> What is this "security policy"? this is the first time it is > mentioned in the draft. I thought all filtering is either done by BIB > or by session entries. > > but it is possible that irrespectively what is in the BIB or session tables, the NAT64 is configured to not accept new connections initiated from the IPv4 side. that is what this sentence is trying to capture... not sure if can be phrased better... > If the destination transport address contained in the incoming V4 > SYN is not in use in the TCP BIB, then the packet is discarded and > an ICMP Port Unreachable error (Type 3, Code 3) is sent back to > the source of the v4 SYN. The state remains unchanged in CLOSED > If the destination transport address contained in the incoming V4 > SYN is in use in the TCP BIB, then > > GT> Use the (X',x) <--> (T,t) notation to describe what these > unsuccessful and then successful searches involve. > > done > The state is moved to V4 SYN RCV. > > GT> Again, I think it might be better if the state is changed after > the following processing completes successfully. > > done > Bagnulo, et al. Expires May 25, 2010 [Page 20] > > Internet-Draft NAT64 November 2009 > > > A new session table entry is created in the TCP session table, > containing the following information: > > GT> Use the (X',x) <--> (T,t) notation > > done > The transport source and destination address contained in > the V4 SYN and, > > The source IPv6 transport address (in the IPv6 --> IPv4 > direction) contained in the existing TCP BIB entry. > > The destination IPv6 transport address contains the same > port than the destination IPv4 transport address and the > IPv6 representation of the IPv4 address of the destination > IPv4 transport address, generated using the algorithm > described in Section 3.2.5. > > The lifetime of the entry is set to 6 seconds as per > [RFC5382]. > > The packet is discarded. > > GT> Without reading RFC5382, which describes how this helps > simultaneous-open, this sounds very weired and completly unorthodox. > Initialy I thought the statement "The packet is discarded" was simple > an error and only understood what was going on after talking to > Marcelo. It would be beneficial to briefly outline why this is done to > provide context to the reader and then encourage them to read RFC5382 > for the details. > > mmm, after our exchange, i realized that i needed to keep the packet in order to send a proper ICMP error back. So i ahve rephrased the thing as: If the NAT64 is performing Address-Dependent filtering, the packet is stored (The motivation for creating the session table entry and storing the packet (instead of simply dropping the packet based on the filtering) is to support simultaneous open of TCP connections) If the NAT64 is not performing Address-Dependent filtering, it translates and forwards the packet as described in the following sections. > For any other IPv6 packet, depending on the security policy other > packets MAY be forwarded or MAY be silently discarded. In any case, > the state remains unchanged. > > GT> this statement sounds hand-waving and wrong. What "other IPv6 > packets" it refers to? and "MAY be forwarded or MAY silently > discarded" based on what? for example other IPv6 SYN packets to > different source/dest? other IPv6 UDP packets? ICMPv6? > > mmm, since we are in the state machine and the state machine is per connection, then this only refers to IPv6 packets of that particular TCP connection. The situation that is considered here is what do we do with other packets from that connection that show up while we are in this particular state i.e. in CLOSED state. I mean suppose that we receive a TCP data packet for a connection that is closed. Suppose that we do have the information to process it (i.e. a corresponding BIB entry) So what do we do? do we drop the packet or do we froward the packet. The only thing i am convinced is that we shouldn't create a session entry for that packet, since it is too expensive (we only do that if we had the full 3 way handshake), but do we need to drop the packet? I am not sure. I think this is a policy decision and that i why i left it open. But we can discuss it. This applies to all non expected packets in all the rest of the states. So the same discussion applies. In any case, i have clarified that this only refers to packets from this connection. and i have made a common text both for v4 and v6 as follows: For any other packet belonging to this connection, If there is a corresponding entry in the TCP BIB depending on the security policy other packets MAY be forwarded or MAY be silently discarded. In any case, the state remains unchanged. If there is no corresponding entry in the TCP BIB the packet is silently discarded. > For any other IPv4 packet, > > GT> Again what other IPv4 packets? same questions as for IPv6 above. > > see previous comments > GT> Use the proper notation for the searches > > done > If the destination transport address contained in the incoming > IPv4 packet is in use in the TCP BIB depending on the security > policy other packets MAY be forwarded or MAY be silently > discarded. In any case, the state remains unchanged. > > If the destination transport address contained in the incoming > IPv4 packet is not in use in the TCP BIB the packet is silently > discarded. > > *** V4 SYN RCV *** > > GT> Unlike the CLOSED state where any TCP SYN packets would be > processed as defined since these are the only packets that > instantiate the state machine, from here one a packet will only affect > an instance of the state machine if it matches the BIB and session > entries. but that is true also for the closed state. I mean, we do have a instance of the state machine per connection. So, when a packet arrives, it is associated to a single state machine. The only difference between the closed state and the others is that in closed state there is actual state being stored in the nat64, while in the other it is. But the abstract binding to the state machine is the same for all of them > so this should be examined first again using our favorite > notation. > > If a V6 SYN is received, then the state is moved to ESTABLISHED. > > G> change state after processing > done > The > lifetime of the corresponding TCP session table entry is updated to 2 > hours 4 min (the established connection idle timeout as defined in > > GT> to at least 2 hours and 4 min > > done > [RFC5382]). The packet is translated and forwarded. > > If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code > > GT> //if the lifetime expires/If no relevant V6 SYN is received and > the lifetime of the session entry expires/ > > mm, if the relevant IPv6 SYN was received before, the state is no longer V4 SYN RCV, buty moved to ESTABLISHED > 3) is sent back to the source of the v4 SYN, the session table entry > is deleted and, the state is moved to CLOSED. > > > > For any other packet, depending on the security policy other packets > MAY be forwarded or MAY be silently discarded. In any case, the > > > > Bagnulo, et al. Expires May 25, 2010 [Page 21] > > Internet-Draft NAT64 November 2009 > > > state remains unchanged. > > GT> again hand waving regarding "other" packets. we should state what > happens to other packets that match the same BIB/session entries and > specifically what happens to other V4SYN packets (e.g. retransmitted) > > but packets that are processed by this particular state machine belong only to this connection in particular. I have added the following text to clarify this. There is one state machine per TCP connection that is potentially established through the NAT64. After bootstrapping of the NAT64 device, all TCP session are in CLOSED state. As we mention above, the CLOSED state is a fictional state that there is not state for that particular connection in the NAT64. About other V4 SYN packets for the same connection, from the NAT64 persepctive, i don't think they change much (potentially they could set the timer again to its initial value). whether forwarding them or not, i am uncertain. > *** V6 SYN RCV *** > > If a V4 SYN is received (with or without the ACK flag set), then the > state is moved to ESTABLISHED. The timer is updated to 2 hours 4 min > > GT> to at least 2 hours... > > done > (the established connection idle timeout as defined in [RFC5382]). > The packet is translated and forwarded. > > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > GT> //if the lifetime expires/If no relevant V4 SYN is received and > the lifetime of the session entry expires/ > > same than above > For any other packet, depending on the security policy other packets > MAY be forwarded or MAY be silently discarded. In any case, the > state remains unchanged. > > GT> same hand waving as earlier > > same than above > *** ESTABLISHED *** > > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > GT> This could be deleted since it is repeated below. > > done > If a V4 FIN packet is received, the packet is translated and > forwarded. The state is moved to V4 FIN RCV. > > If a V6 FIN packet is received, the packet is translated and > forwarded. The state is moved to V6 FIN RCV. > > GT> Be specific about FIN packet matching BIB/session entries. all packets processed in the state machine belong to this particular connection. I have added text in the begining describing the state machine that makes that clearer (i hope) > Also > what happens to lifetime when you move to FIN RCV? > > no change in the timer, since it may be a half closed connection > If a packet is received, the packet is translated and forwarded. The > lifetime is set to 2 hours and 4 min. The state remains unchanged as > ESTABLISHED. > > > GT> Again be more specific i.e., any TCP packet that matches the > BIB/Session entries not the bib entry, but the session table entry i.e. a packet for this connection. I hope this is clearer with the new text > for this TCP state machine resets the timer to at > least 2 hours and 4min i.e., the lifetime at the ESTABLISH state is > an "idle-timeout" affected by any packet on this session, including > regular data TCP packets and TCP keep-alives. right, i have moved this to the end of the processing and stated that if any other packet is received, then... > This is not the case in > some of the other states where only specific control packets affect > them. Make similar clarifications for V6/V4 FIN packets > > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > If a V4 RST or a V6 RST packet is received, the packet is translated > and forwarded. The lifetime is set to 4 min and state is moved to > RST RCV. > > GT> Some justification for this would be useful. > I have added: (Since the NAT64 is uncertain whether the peer will accept the RST packet, instead of moving the state to CLOSED, it moves to the RST RCV, which has a shorter lifetime. If no other packets are received for this connection during the short timer, the NAT64 assumes that the peer has accepted the RST packet and moves to CLOSED. If packet keep flowing, the NAT64 assumes that the peer has not accepted the RST packet and moves back to ESTABLISHED state.) > *** V4 FIN RCV *** > > If a packet is received, the packet is translated and forwarded. The > > GT> be specific on what packet > > right, i have changed the order, put this bullet last and stated any other packet > lifetime is set to 2 hours and 4 min. The state remains unchanged as > V4 FIN RCV. > > GT> to at least 2 hours... > > done > If a V6 FIN packet is received, the packet is translated and > > GT> one that matches BIB/session > > This is hopefully clarified by the text above > forwarded. The lifetime is set to 4 min. The state is moved to V6 > FIN + V4 FIN RCV. > > GT> to at least 4 min... > > done > Bagnulo, et al. Expires May 25, 2010 [Page 22] > > Internet-Draft NAT64 November 2009 > > > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > *** V6 FIN RCV *** > > If a packet is received, the packet is translated and forwarded. The > > GT> be specific on the packet. > > hopefully this is clear now > lifetime is set to 2 hours and 4 min. The state remains unchanged as > V6 FIN RCV. > > GT> to at least 2 hours... > > done > If a V4 FIN packet is received, the packet is translated and > forwarded. The lifetime is set to 4 min. The state is moved to V6 > FIN + V4 FIN RCV. > > GT> to at least 4 min... > > done > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > *** V6 FIN + V4 FIN RCV *** > > All packets are translated and forwarded. > > GT> be specific on which packets? > > hopefully this is clear > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > *** RST RCV *** > > If a packet is received, the lifetime is set to 2 hours and 4 min and > the state is moved to ESTABLISHED. > > GT> be specific on which packet. > > hopefully this is clear. > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > > 3.2.3. Rules for allocation of IPv4 transport addresses > > GT> Shouldn't this section be after section 3.2.4 on ICMP? > done > If the rules specify that a new BIB entry is created for a source > transport address of (S',s), then the NAT64 allocates an IPv4 > transport address for this BIB entry as follows: > > If there exists some other BIB entry containing S' as the IPv6 > address and mapping it to some IPv4 address T, then use T as the > IPv4 address. Otherwise, use any IPv4 address assigned to the > IPv4 interface. > > GT> from the pool specifically used for translation > > done > If the port s is in the Well-Known port range 0..1023, then > allocate a port t from this same range. Otherwise, if the port s > is in the range 1024..65535, then allocate a port t from this > range. Furthermore, if port s is even, then t must be even, and > if port s is odd, then t must be odd. > > GT> It is not immediately obvious why the above is so...some > justification would be useful. Section 7.1 of RFC5382 provides some > justification > > added a reference > Bagnulo, et al. Expires May 25, 2010 [Page 23] > > Internet-Draft NAT64 November 2009 > > > In all cases, the allocated IPv4 transport address (T,t) MUST NOT > be in use in another entry in the same BIB, but MAY be in use in > the other BIB. > > GT> I have no clue what this means. > > it refers to the TCP vs UDP bib added a clarification > If it is not possible to allocate an appropriate IPv4 transport > address or create a BIB entry for some reason, then the packet is > discarded. > > GT> are we sure this is appropriate in all cases? should appropriate > ICMP error be sent? > > added the possibility of sending an ICMP packet back I have added: The NAT64 MAY send an ICMPv6 Destination Unreachable/Address unreachable (Code 3) message. > 3.2.4. ICMP Query Session Handling > > The state information stored for an ICMP Query session in the ICMP > Query session table includes a timer that tracks the remaining > lifetime of the session. > > GT> As with TCP and UDP we should repeat the notation here for the > sessions and use it throughout the section > > The NAT64 decrements this timer at regular > intervals. > > GT> I do not understand what this means.a timer is a timer and it is > decremented as time passes. What is missing though it some indication > on when the timer is reset to its initial value. > deleted the sentence > When the timer expires, the session is deleted. If all > the sessions corresponding to a ICMP Query BIB entry are deleted, > then the ICMP Query BIB entry is also deleted in the case of > dynamically created entries. > > > GT> for the rest of this sub-section the usual comment sapply i.e., be > specific on what packet it is being processed and use our favorit > notation to explain how entries are searched or created. > right, tried to do that > An incoming ICMPv6 Informational packet is processed as follows: > > If the local security policy determines that ICMPv6 Informative > packets are to be filtered, the packet is silently discarded. > Else, the NAT64 searches for a ICMP Query BIB entry that matches > the (IPv6 source address, ICMPv6 Query Id) pair. If such entry > does not exist, a new entry is created. As (IPv6 address, ICMPv6 > Query Id) pair, the source IPv6 address of the packet and the > ICMPv6 Query Identifier are included. The IPv4 address and ICMPv4 > Query Identifier values are allocated as follows: > > If there exists some other BIB entry containing the same IPv6 > address and mapping it to some IPv4 address T, then use T as > the IPv4 address. Otherwise, use any IPv4 address assigned to > the IPv4 interface. > > As ICMPv4 Identifier use any available value i.e. any > identifier value for which no other entry exists with the same > (IPv4 address, ICMPv4 Query Id) pair. > > The NAT64 searches for the session table entry corresponding to > the incoming 3-tuple. If no such entry is found, a new entry is > created. The information included in the session table is as > follows: the IPv6 source and destination addresses contained in > the received IPv6 packet, the IPv4 source address, the ICMPv4 > Query Id and the ICMPv6 Query Id are extracted from the > corresponding ICMP Query BIB entry and the IPv4 destination > address is algorithmically generated from the IPv6 destination > address using the reverse algorithm as specified in Section 3.2.5. > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 24] > > Internet-Draft NAT64 November 2009 > > > The NAT64 sets or resets the timer in the session table entry to > maximum session lifetime. By default, the maximum session > lifetime is 60 seconds. The maximum lifetime value SHOULD be > configurable. The packet is translated and forwarded as described > in the following sections. > > An incoming ICMPv4 Query packet is processed as follows: > > The NAT64 searches for a ICMP Query BIB entry that matches the > IPv4 destination address and ICMPv4 query Id pair. If such entry > does not exists, the packet is dropped. An ICMP message MAY be > sent to the original sender of the packet, unless the discarded > packet is itself an ICMP message. The ICMP message, if sent, has > a type of 3 (Destination Unreachable). > > If the NAT64 filters on its IPv4 interface, then the NAT64 checks > to see if the incoming packet is allowed according to the address- > dependent filtering rule. To do this, it searches for a session > table entry with a source IPv4 address and ICMP Query Id pair > equal to the destination IPv4 address and ICMP Query Id in the > incoming 3-tuple and destination IPv4 address (in the session > table entry) equal to the source IPv4 address in the incoming > 3-tuple. If such an entry is found (there may be more than one), > packet processing continues. Otherwise, the packet is discarded. > If the packet is discarded, then an ICMP message MAY be sent to > the original sender of the packet, unless the discarded packet is > itself an ICMP message. The ICMP message, if sent, has a type of > 3 (Destination Unreachable) and a code of 13 (Communication > Administratively Prohibited). > > The NAT64 searches for the session table entry corresponding to > the incoming 3-tuple. If no such entry is found, a new entry is > created. The ICMP Query session table entry contains the ICMPv4 > Query Identifier, source and destination address contained in the > IPv4 packet and the source IPv6 address and the ICMPv6 Query Id > (in the IPv6 --> IPv4 direction) contained in the existing ICMP > Query BIB entry. The destination IPv6 address contains is the > IPv6 representation of the IPv4 address of the destination IPv4 > address, generated using the algorithm described in Section 3.2.5. > > The NAT64 sets or resets the timer in the session table entry to > maximum session lifetime. By default, the maximum session > lifetime is 60 seconds. The maximum lifetime value SHOULD be > configurable. The packet is translated and forwarded as described > in the following sections. > > > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 25] > > Internet-Draft NAT64 November 2009 > > > 3.2.5. Generation of the IPv6 representations of IPv4 addresses > > NAT64 support multiple algorithms for the generation of the IPv6 > representation of an IPv4 address. The constraints imposed to the > generation algorithms are the following: > > The same algorithm to create an IPv6 address from an IPv4 address > MUST be used by: > > The DNS64 to create the IPv6 address to be returned in the > synthetic AAAA RR from the IPv4 address contained in original A > RR, and, > > The NAT64 to create the IPv6 address to be included in the > destination address field of the outgoing IPv6 packets from the > IPv4 address included in the destination address field of the > incoming IPv4 packet. > > The algorithm MUST be reversible, i.e. it MUST be possible to > extract the original IPv4 address from the IPv6 representation. > > The input for the algorithm MUST be limited to the IPv4 address, > the IPv6 prefix (denoted Pref64::/n) used in the IPv6 > representations and optionally a set of stable parameters that are > configured in the NAT64 (such as fixed string to be used as a > suffix). > > GT> In this case the same "set of stable parameters" has to also be > configured in DNS64? > > yes, not sure if i should mention that here though > If we note n the length of the prefix Pref64::/n, then n MUST > the less or equal than 96. If a Pref64::/n is configured > through any means in the DNS64 (such as manually configured, or > other automatic mean not specified in this document), the > default algorithm MUST use this prefix. If no prefix is > available, the algorithm MUST use the Well-Known prefix > (include here the prefix to be assigned by IANA) defined in > [I-D.ietf-behave-address-format] > > GT> In either case, for a site using a given NAT64, the Prefix64::/ > MUST be uniquely routable to the NAT64 function defined here, correct? > This prefix I assume should be globally routable? this seems necessary > if the IPv6 side is the whole IPv6 Internet....but is this required > even in if the IPv6 site is a stab connected to the IPv4 Internet? Or > maybe all this is defined in draft-ietf-behave-address-format; if that > is the case then point to it not just for the format but for other > requirements on the Prefix64. > I am not sure i understand this comment, so i don't know what change to make here. > NAT64 MUST support the following algorithms for generating IPv6 > representations of IPv4 addresses defined in > [I-D.ietf-behave-address-format]: > > Zero-Pad And Embed, defined in section 3.2.3 of > [I-D.ietf-behave-address-format] > > Compensation-Pad And Embed, defined in section of 3.2.4 of > [I-D.ietf-behave-address-format] > > Embed And Zero-Pad, defined in section of 3.2.5 of > [I-D.ietf-behave-address-format] > > > > Bagnulo, et al. Expires May 25, 2010 [Page 26] > > Internet-Draft NAT64 November 2009 > > > Preconfigured Mapping Table, defined in section of 3.2.6 of > [I-D.ietf-behave-address-format] > > GT> The pointers need updating > > The default algorithm used by NAT64 must be Embed and Zero-Pad. > While the normative description of the algorithms is provided in > [I-D.ietf-behave-address-format]. > > GT> is the "must" above normative? should it be "MUST"? > > i have updated the pointer and now there is only one algorithm, so no longer needed. > 3.3. Computing the Outgoing Tuple > > This step computes the outgoing tuple by translating the addresses > and ports or ICMP Query Id in the incoming tuple. > > In the text below, a reference to the the "BIB" means either the TCP > BIB the UDP BIB or the ICMP Query BIB as appropriate. > > NOTE: Not all addresses are translated using the BIB. BIB entries > are used to translate IPv6 source transport addresses to IPv4 > source transport addresses, and IPv4 destination transport > addresses to IPv6 destination transport addresses. They are NOT > used to translate IPv6 destination transport addresses to IPv4 > destination transport addresses, nor to translate IPv4 source > transport addresses to IPv6 source transport addresses. The > latter cases are handled applying the algorithmic transformation > described in Section 3.2.5. This distinction is important; > without it, hairpinning doesn't work correctly. > > 3.3.1. Computing the outgoing 5-tuple for TCP, UDP and ICMP error > messages > > The transport protocol in the outgoing 5-tuple is always the same as > that in the incoming 5-tuple. > > When translating in the IPv6 --> IPv4 direction, let the incoming > source and destination transport addresses in the 5-tuple be (S',s) > and (D',d) respectively. The outgoing source transport address is > computed as follows: the BIB contains a entry (S',s) <--> (T,t), then > the outgoing source transport address is (T,t). > > The outgoing destination address is computed algorithmically from D' > using the address transformation described in Section 3.2.5. > > When translating in the IPv4 --> IPv6 direction, let the incoming > source and destination transport addresses in the 5-tuple be (S,s) > and (D,d) respectively. The outgoing source transport address is > computed as follows: > > The outgoing source transport address is generated from S using > the address transformation algorithm described in Section 3.2.5. > > > > Bagnulo, et al. Expires May 25, 2010 [Page 27] > > Internet-Draft NAT64 November 2009 > > > The outgoing destination transport address is computed as follows: > > If the BIB contains an entry (X',x) <--> (D,d), then the outgoing > destination transport address is (X',x). > > Otherwise, discard the packet. > > GT> This section is about calculating a tuple. the decision to discard > a packet seems completly out of place. > > right, removed > If the rules specify that the packet is discarded, then the NAT64 MAY > send an ICMP reply to the original sender, unless the packet being > translated contains an ICMP message. The type should be 3 > (Destination Unreachable) and the code should be 0 (Network > Unreachable in IPv4, and No Route to Destination in IPv6). > > GT> same here, looks out of place. > > removed > 3.3.2. Computing the outgoing 3-tuple for ICMP Query messages > > When translating in the IPv6 --> IPv4 direction, let the incoming > source and destination addresses in the 3-tuple be S' and D' > respectively and the ICMPv6 Query Identifier be I1. The outgoing > source address is computed as follows: the BIB contains a entry > (S',I1) <--> (T,I2), then the outgoing source address is T and the > ICMPv4 Query Id is I2. > > The outgoing IPv4 destination address is computed algorithmically > from D' using the address transformation described in Section 3.2.5. > > When translating in the IPv4 --> IPv6 direction, let the incoming > source and destination addresses in the 3-tuple be S and D > respectively and the ICMPv4 query Id is I2. The outgoing source > address is generated from S using the address transformation > algorithm described in Section 3.2.5. The outgoing destination > address and ICMPv6 Query Id are computed as follows: > > If the BIB contains an entry (X',I1) <--> (D,I2), then the > outgoing destination address is X' and the outgoing ICMPv6 Query > Id is I1. > > Otherwise, discard the packet. > > GT> same here > > removed > NOTE: Not sure if this applies to ICMP query messages....If the rules > specify that the packet is discarded, then the NAT64 MAY send an ICMP > reply to the original sender, unless the packet being translated > contains an ICMP message. The type should be 3 (Destination > Unreachable) and the code should be 0 (Network Unreachable in IPv4, > and No Route to Destination in IPv6). > > GT> same here > > > > removed > > > > Bagnulo, et al. Expires May 25, 2010 [Page 28] > > Internet-Draft NAT64 November 2009 > > > 3.4. Translating the Packet > > This step translates the packet from IPv6 to IPv4 or vice-versa. > > The translation of the packet is as specified in section 3 and > section 4 of IP/ICMP Translation Algorithm > [I-D.ietf-behave-v6v4-xlate], with the following modifications: > > o When translating an IP header (sections 3.1 and 4.1), the source > and destination IP address fields are set to the source and > destination IP addresses from the outgoing 5-tuple. > > > GT> clarify that the outgoing 5-tuple is defined in an earlier > section of this document. > done > o When the protocol following the IP header is TCP or UDP, then the > source and destination ports are modified to the source and > destination ports from the outgoing 5-tuple. In addition, the TCP > or UDP checksum must also be updated to reflect the translated > addresses and ports; note that the TCP and UDP checksum covers the > pseudo-header which contains the source and destination IP > addresses. An algorithm for efficiently updating these checksums > is described in [RFC3022]. > > o When the protocol following the IP header is ICMP and it is an > ICMP Query message, the ICMP query Identifier is set to the one of > the outgoing 3-tuple. > > GT> clarify that the outgoing 3-tuple is defined in an earlier > section of this document. > done > o When the protocol following the IP header is ICMP (sections 3.4 > and 4.4) and it is an ICMP error message, the source and > destination transport addresses in the embedded packet are set to > the destination and source transport addresses from the outgoing > 5-tuple (note the swap of source and destination). > > The size of outgoing packets as well and the potential need for > fragmentation is done according to the behavior defined in IP/ICMP > Translation Algorithm [I-D.ietf-behave-v6v4-xlate] > > 3.5. Handling Hairpinning > > This step handles hairpinning if necessary. > > If the destination IP address is an address assigned to the NAT64 > itself (i.e., is one of the IPv4 addresses assigned to the IPv4 > interface, or is covered by the Pref64::/n prefix assigned to the > IPv6 interface), then the packet is a hairpin packet. > > GT> This is not a sufficient definition of "hairpinning"....since it > describes ALL packets that go through the NAT64. Hairpinning is > defined in detail in Section 6 of RFC4787, and more compactly Section > 7.2 of RFC5382. to paraphrase the latter: > " A NAT64 that forwards packets originating from an IPv6 address, > destined for an IPv4 address that matches the active mapping for > another IPv6 address, back to that IPv6 address are defined as as > supporting "hairpinning". " > > I have added this text to the document > The outgoing > 5-tuple becomes the incoming 5-tuple, and the packet is treated as if > it was received on the outgoing interface. Processing of the packet > continues at step 2 Section 3.2 > > > > > > Bagnulo, et al. Expires May 25, 2010 [Page 29] > > Internet-Draft NAT64 November 2009 > > > 4. Application scenarios > > GT> this is clearly no longer normative. I wonder if it should be > either moved to the front or placed in an appendix. > mmm, i will move it to an appendix > In this section, we describe how to apply NAT64/DNS64 to the suitable > scenarios described in [I-D.ietf-behave-v6v4-framework] . > > GT> That's it....the security section looks ok so far, but I will try > to check it again in more detail during WGLC or closer to it. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From ssenthil@cisco.com Sat Dec 12 23:47:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8849C3A6834 for ; Sat, 12 Dec 2009 23:47:00 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm7EyfgGHyfB for ; Sat, 12 Dec 2009 23:46:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 79C7D3A6819 for ; Sat, 12 Dec 2009 23:46:59 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEoqJEurR7H+/2dsb2JhbAC8J5YJhCsEgWI X-IronPort-AV: E=Sophos;i="4.47,390,1257120000"; d="scan'208";a="118866075" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2009 07:46:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBD7klKa013955 for ; Sun, 13 Dec 2009 07:46:47 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Dec 2009 23:46:47 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 12 Dec 2009 23:46:46 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt Thread-Index: Acp7w2CDYhOI1yLbQ06F4BnGASF8nQ== From: "Senthil Sivakumar (ssenthil)" To: X-OriginalArrivalTime: 13 Dec 2009 07:46:47.0203 (UTC) FILETIME=[6C2CC730:01CA7BC8] Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 07:47:00 -0000 General comments: ------------------ - What is the requirement for the different tables that the document presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64 to have all these tables? If so why? - Requirement on state tracking. MUST, SHOULD RECOMMEND? Specific comments on state tracking below. - Confusing 3-tuple and 5-tuple usage and definition. Specific comments below. - There is no recommendation for BIB entry timeouts, is there one required? RFC4966 lists this as one of the drawbacks for NAT-PT.=20 - RFC4966 is mentioned in Section 1 and it is mentioned that a number of features have been added to overcome the reasons of deprecation of NAT-PT. I wonder if there should be a section discussing what has been overcome and how. Because I still see a number of issues discussed in RFC 4966 applies to this document as well - like ALGs, Binding state decay, Dos attacks, Loss of information through incompatible semantics (actually applies to stateless) etc.=20 Specific comments. ------------------- Section 1.1 2nd bullet - TCP [RFC4787] should be TCP[RFC5382] Section 1.2 NAT64 mechanism is implemented in an NAT64 box which has two interfaces should be NAT64 mechanism is implemented in an NAT64 box which has atleast two interfaces Section 1.2.1 Paragraph starting "NAT64 creates the required mappings..." It is a little confusing as it implies a IPv6 address pool is to be provisioned, but rather a global prefix can used to algorithmically/statically map the IPv4 addresses into IPv6 addresses. I would suggest that you use the terminology of algorithmically extracting the IPv4 address and algorithimically adding the prefix to form the v6 address. Section 1.2.1 Paragraph starting "Because of the dynamic nature.." last line. "For this reason NAT64 supports only communications initiated from the IPv6 side." Not entirely true, it should be "supports only dynamically initated communications from the ipv6 side". Section 1.2.2 Change the title of this section to be more meaningful than "Walkthrough". Section 1.2.3 I don't understand this "Filtering on the IPv6 interface is not supported, as mappings are only created by packets traveling in the IPv6 --> IPv4 direction." Can you explain why one cannot filter on ipv6 interface? Section 2 3-Tuple & 5-tuple. Kind of confused here, in case of ICMP protocol is not a tuple and in case of TCP/UDP protocol is a tuple, why is that? There are two things that the tuple(s) are used for in this document. 1. To extract the required information from the packet. 2. To do a search in the database. For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address & port, Dst address & Port) 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. For doing a search and add/update/delete, since you have separate databases for TCP/UDP/ICMP, the search is based on 4 tuple for TCP/UDP and 3-tuple for ICMP. So I don't see why the 5-tuple searches mentioned in the later sections are required.=20 Section 3.2 Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64 and not stateless? Section 3.2.1 Incoming IPv6 packet processing. Why should the search be based on the 5-tuple, since it is UDP session table the search is based on the 4-tuple of (SrcIP, DstIP, SrcPort, DstPort). Same comment on IPv4 packet processing. Section 3.2.2 TCP handling. Lifetime: is a timer that tracks the remaining lifetime of the UDP Should be TCP above. Section 3.2.2 TCP states. What is the purpose of this section, does this document requires all NAT64 devices to track the sessions with the described state machine? Is it a MUST, SHOULD, MAY, recommend? Section 3.2.2 Paragraph starting "After bootstrapping...." What does it mean all TCP sessions are in closed state? Where is this tracked? The state of the TCP session is tracked within the TCP session table entry and state tracking starts when the entry is created and stops when the entry is destroyed. So what is this CLOSED state and where is it tracked? This is very unclear and confusing. Section 3.2.2=20 "The state of the session is moved to V6 SYN RCV". Again where ? The text for the actual session creation is below this text and until the session is created where does this state hang off of?=20 Section 3.2.2 s/If such entry does not exists/If such an entry does not exist Section 3.2.2=20 "If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED." Same comment as above, where is the state stored for this session?=20 I will not repeat these comments in the subsequent text in the same section but this needs some serious explanation and clarifying.=20 Section 3.2.3 For port allocation, the text says if the port is even an even port must be allocated and same for odd. What if there are no even ports to allocate but there are odd ports, should the packet be dropped or allocated a odd port. I understand some application require that the port parity to be maintained but majority of the apps don't care. So making this a recommendation on the best effort basis is ok but making it a mandatory requirement sounds unreasonable. Note RFC 4787 recommends this behavior but this text mandates it. From marcelo@it.uc3m.es Sun Dec 13 15:28:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E583A67FE for ; Sun, 13 Dec 2009 15:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlDIwNX0z-h9 for ; Sun, 13 Dec 2009 15:28:15 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 10CE93A677D for ; Sun, 13 Dec 2009 15:28:14 -0800 (PST) Received: from r190-132-193-32.dialup.adsl.anteldata.net.uy (unknown [190.132.193.32]) by smtp03.uc3m.es (Postfix) with ESMTP id CB89772E600; Mon, 14 Dec 2009 00:27:53 +0100 (CET) Message-ID: <4B257875.4020503@it.uc3m.es> Date: Mon, 14 Dec 2009 00:27:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:28:17 -0000 Hi, thanks for the review see replies below... Senthil Sivakumar (ssenthil) escribió: > General comments: > ------------------ > > I will try to address some of these here and other i will leave for the details comments below > - What is the requirement for the different tables that the document > presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64 to > have all these tables? If so why? > The tables contain the information needed for the NAT64 to work. I don't think you can make a NAT64 work with less information. Do you think some of the information stored in the tables is not needed? which one? I would be glad to reduce the state needed by the NAT64, but i fail to see what can de dropped. > - Requirement on state tracking. MUST, SHOULD RECOMMEND? Specific > comments on state tracking below. > > Not clear to me at this point what you mean, will see specific comment below > - Confusing 3-tuple and 5-tuple usage and definition. Specific comments > below. > > Not clear to me at this point what you mean, will see specific comment below > - There is no recommendation for BIB entry timeouts, is there one > required? RFC4966 lists this as one of the drawbacks for NAT-PT. > > the behave requirements require to use of timeouts, but since we also have endpoint independets mappings, we need to track each session that is being used by each endpoint. In order to do that the proposed approach is to have timers in the session table entries. SO as long as there is at least one session table associated to a BIB entry, the BIB entry is preserved, When all session table entries associated to a BIB entry are deleted, the BIB entry is deleted. So, While the BIN entries do have an explicit timer, they are bound to the timers of the corresponding session table entries, so they do have a timer expiration. > - RFC4966 is mentioned in Section 1 and it is mentioned that a number of > features have been added to overcome the reasons of deprecation of > NAT-PT. I wonder if there should be a section discussing what has been > overcome and how. Right, we could try to do this, if people find it important. Another thing that would be also interesting would be to explain how the NAT64 complies with the behave requirements for UDP, TCP and ICMP. Both of these excersises would be good to have in the document as appendixes. We should discuss this in the interim > Because I still see a number of issues discussed in > RFC 4966 applies to this document as well - like ALGs, Binding state > decay, Dos attacks, Loss of information through incompatible semantics > (actually applies to stateless) etc. > > Specific comments. > ------------------- > > Section 1.1 2nd bullet - TCP [RFC4787] should be TCP[RFC5382] > > fixed > Section 1.2 > > NAT64 mechanism is implemented in an NAT64 box which has two interfaces > should be > > NAT64 mechanism is implemented in an NAT64 box which has atleast two > interfaces > > ok > Section 1.2.1 > > Paragraph starting "NAT64 creates the required mappings..." > > It is a little confusing as it implies a IPv6 address pool is to be > provisioned, but rather a global prefix can used to > algorithmically/statically map the IPv4 addresses into IPv6 addresses. I > would suggest that you use the terminology of algorithmically extracting > the IPv4 address and algorithimically adding the prefix to form the v6 > address. > > Right, i have rephrased the paragraph as: The IPv6 address pool is an IPv6 prefix assigned to the translator itself (hereafter called Pref64::/n). Due to the abundance of IPv6 address space, it is possible to assign an Pref64::/n that is equal or even bigger than the whole IPv4 address space. This allows each IPv4 address to be mapped into a different IPv6 address by simply concatenating the Pref64::/n with the IPv4 address being mapped and a suffix (i.e. an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX). The provisioning of the Pref64::/n is discussed at length in > Section 1.2.1 > > Paragraph starting "Because of the dynamic nature.." last line. > > "For this reason NAT64 supports only communications initiated from the > IPv6 side." > > Not entirely true, it should be "supports only dynamically initated > communications from the ipv6 side". > > right, i have removed that sentence > Section 1.2.2 > > Change the title of this section to be more meaningful than > "Walkthrough". > > I have changed the title to NAT64 behaviour walkthrough > Section 1.2.3 > > I don't understand this > > "Filtering on the IPv6 interface is not supported, as mappings are only > created by packets traveling in the IPv6 --> IPv4 direction." > > Can you explain why one cannot filter on ipv6 interface? > > good question NAT64 supports dynamically initiated connections only from the IPv6 side. So filtering on the IPv6 side seems some how orthogonal to the NAT behaviour. I mean you could do that, but you wouldn't be using NAT state in order to do so, i think. OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot support communications iniitated in the IPv4 side, when there is a hole in the NAT opened by an IPv6 connection and because we are doing endpoint independent mappings, we end up with the question on whehter we do accept this new communication that has been initiated from the IPv4 side or not (keep in mind that this is possible only because there is a hole open and would not be possible in other case) So, while the NAT could filter in the IPv6 interface, this seems to be orthogonal to the NAT behaviour, but filtering in the IPv4 interface i tightly couple to the nat64 state, hence need to be specified. In any case, i have rephrased the previous sentence to Filtering of incoming IPv6 packets is not described in this specification. in order to make it clearer that is not that is not supported, but that is not specified here. > Section 2 > > 3-Tuple & 5-tuple. > > Kind of confused here, in case of ICMP protocol is not a tuple and in > case of TCP/UDP protocol is a tuple, why is that? > mmm, not sure what do you mean here. In the terminology section it reads: 3-Tuple: The tuple (source IP address, destination IP address, Query Identifier). A 3-tuple uniquely identifies an ICMP Query session. When an ICMP Query session flows through a NAT64, each session has two different 3-tuples: one with IPv4 addresses and one with IPv6 addresses. 5-Tuple: The tuple (source IP address, source port, destination IP address, destination port, transport protocol). A 5-tuple uniquely identifies a UDP/TCP session. When a UDP/TCP session flows through a NAT64, each session has two different 5-tuples: one with IPv4 addresses and one with IPv6 addresses. So, the 3-tuple refers to the ICMP case. Not sure how to reword the document to make this more clear. > There are two things that the tuple(s) are used for in this document. > > 1. To extract the required information from the packet. > > 2. To do a search in the database. > > For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address & > port, Dst address & Port) > > 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. > > For doing a search and add/update/delete, since you have separate > databases for TCP/UDP/ICMP, the search is based on 4 tuple for TCP/UDP > and 3-tuple for ICMP. So I don't see why the 5-tuple searches mentioned > in the later sections are required. > > mmm, i see what you mean. OTOH, you could think that you actually search using the 5-tuple, since the protocol value in the 5-tupel determines which table (UDP or TCP) you need to search. We could use a 4-tuple for the 2 case, and we would need to define what the 4-tuple is and how it relates to the 5-tuple. IMHO, this would render the document less clear, but we can discuss further it you want. > Section 3.2 > > Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64 > and not stateless? > > not sure if it applies to the stateless, it certainly applies to the statefull translator, agree? > Section 3.2.1 > > Incoming IPv6 packet processing. > > Why should the search be based on the 5-tuple, since it is UDP session > table the search is based on the 4-tuple of (SrcIP, DstIP, SrcPort, > DstPort). > > Same comment on IPv4 packet processing. > > right, see comment above > Section 3.2.2 TCP handling. > > Lifetime: is a timer that tracks the remaining lifetime of the UDP > > Should be TCP above. > > fixed > Section 3.2.2 TCP states. > > What is the purpose of this section, does this document requires all > NAT64 devices to track the sessions with the described state machine? Is > it a MUST, SHOULD, MAY, recommend? > This is similar to the the TCP spec. It does have a state machine, you can implement it in this way, you could do it in a different way as long as the external behaviour is the same. This is captured in the draft in the following text: This breakdown of the NAT64 behavior into processing steps is done for ease of presentation. A NAT64 MAY perform the steps in a different order, or MAY perform different steps, as long as the externally visible outcome is the same. > Section 3.2.2 > Paragraph starting "After bootstrapping...." > > What does it mean all TCP sessions are in closed state? Where is this > tracked? > Again, this is similar to the TCP CLOSED state The closed state is somehow special, cause it means that there is no state for the particular connection. I have tried to make this clearer in the document by adding the following description: CLOSED: Analogous to , CLOSED is a fictional because it represents the state when there is no state for this particular 5-tuple, and therefore, no connection. > The state of the TCP session is tracked within the TCP session table > entry and state tracking starts when the entry is created and stops when > the entry is destroyed. mmm, i don't think you can keep track of all the state information using only the information stored in the session table. In order to keep track of the state informtation, you will likely have to keep track to the state information in addition to that information in the tables. > So what is this CLOSED state and where is it > tracked? This is very unclear and confusing. > > i hope this clarified with the text above. > Section 3.2.2 > > "The state of the session is moved to V6 SYN RCV". Again where ? The > text for the actual session creation is below this text and until the > session is created where does this state hang off of? > > I have moved the order to the sentence, so that first the session entry is created and then the state is moved to V6 SYN RCV, would that help? > Section 3.2.2 > > s/If such entry does not exists/If such an entry does not exist > > fixed > Section 3.2.2 > "If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED." > > Same comment as above, where is the state stored for this session? > > I will not repeat these comments in the subsequent text in the same > section but this needs some serious explanation and clarifying. > > I have made many changes aiming to clarify this in the 04 version. Could you check it and see if it clearer now? > Section 3.2.3 > > For port allocation, the text says if the port is even an even port must > be allocated and same for odd. What if there are no even ports to > allocate but there are odd ports, should the packet be dropped or > allocated a odd port. I understand some application require that the > port parity to be maintained but majority of the apps don't care. So > making this a recommendation on the best effort basis is ok but making > it a mandatory requirement sounds unreasonable. Note RFC 4787 recommends > this behavior but this text mandates it. > Right, i have changed this to a should. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From root@core3.amsl.com Sun Dec 13 15:45:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5FC403A6969; Sun, 13 Dec 2009 15:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091213234502.5FC403A6969@core3.amsl.com> Date: Sun, 13 Dec 2009 15:45:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-04.txt Pages : 41 Date : 2009-12-13 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how they should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-13153214.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Sun Dec 13 15:55:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AAA3A6971 for ; Sun, 13 Dec 2009 15:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-6SsqzwcNuv for ; Sun, 13 Dec 2009 15:55:30 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3AD9F3A685B for ; Sun, 13 Dec 2009 15:55:29 -0800 (PST) Received: from r190-132-193-32.dialup.adsl.anteldata.net.uy (unknown [190.132.193.32]) by smtp01.uc3m.es (Postfix) with ESMTP id 88BEBBA81E0 for ; Mon, 14 Dec 2009 00:55:11 +0100 (CET) Message-ID: <4B257EDB.2010909@it.uc3m.es> Date: Mon, 14 Dec 2009 00:55:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------090805040203000108040706" Subject: [BEHAVE] [Fwd: I-D Action:draft-ietf-behave-v6v4-xlate-stateful-04.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:55:31 -0000 This is a multi-part message in MIME format. --------------090805040203000108040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have submitted a new version of the stateful NAT64 and these are some points that could deserve more discussion (maybe in the interim or in the ml) Find the pointer attached below. -- Address-dependent filtering of ICMP queries. I have tried to reflect the concept of address dependent mapping for the ICMP queries. I am not sure if this makes to much sense or if it is worth the trouble. Could you check it and comment? See section 3.2.3. ICMP Query Session Handling -- What to do with non expected TCP msgs in states other than ESTABLISHED. The question is what to do with TCP segments of a given connection that is not what is expected by the state machine. In particular, what do we do with TCP data segments that the NAT64 has information to process i.e. a valid BIN entry) but do not correspond to any active connection. similar question applies to a duplicated SYN packet and so on. The current draft states that the NAT64 may forward of discard the packet, but certianly it must not create a session if the 3 way handshake is not performed properly. Would that make sense? See the text in section 3.2.2. TCP Session Handling in the CLOSEd state, and others. -- Address-Dependent filtering for TCP and simultaneous open How to implement Address Dependent filtering and support simultaneous opens is tricky. I would appreciate if someone could take a look. In particular, there is the question of whether we drop the incoming V4 SYN or we store it. And if we store it, whether we use it only for the ICMP error, or we do forward it when the V6 SYN arrives. Please take a look at page 23, how a V4 SYN is handled in CLOSED state of section 3.2.2. TCP Session Handling --Port allocation for TCP follows the same rules than for UDP? We are using the rules for port allocation following the recommendation of RFC4787. TCP does not have the same rules (they are much more relaxed). the current draft uses the same rules for both. Shoudl we drop these rules for TCP? See:3.2.4. Rules for allocation of IPv4 transport addresses -------- Mensaje original -------- Asunto: I-D Action:draft-ietf-behave-v6v4-xlate-stateful-04.txt Fecha: Sun, 13 Dec 2009 15:45:02 -0800 (PST) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org CC: behave@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-04.txt Pages : 41 Date : 2009-12-13 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how they should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090805040203000108040706 Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-behave-v6v4-xlate-stateful-04.txt" Content-Type: text/plain Content-ID: <2009-12-13153214.I-D@ietf.org> --------------090805040203000108040706 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090805040203000108040706-- From root@core3.amsl.com Sun Dec 13 16:15:18 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C50223A680B; Sun, 13 Dec 2009 16:15:18 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091214001518.C50223A680B@core3.amsl.com> Date: Sun, 13 Dec 2009 16:15:18 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 00:15:19 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-address-format-02.txt Pages : 16 Date : 2009-12-13 This document discusses the algorithmic translated to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a Well-Known Prefix for use in algorithmic translations, while allowing organizations to also use Network Specific Prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-address-format-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-13160606.I-D@ietf.org> --NextPart-- From xuxh@huawei.com Sun Dec 13 17:41:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAD13A697B; Sun, 13 Dec 2009 17:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBB8dswGBYJH; Sun, 13 Dec 2009 17:41:53 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 459A53A68D2; Sun, 13 Dec 2009 17:41:53 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00D06CPFLI@szxga01-in.huawei.com>; Mon, 14 Dec 2009 09:41:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00KPWCPFAC@szxga01-in.huawei.com>; Mon, 14 Dec 2009 09:41:39 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM0018YCPFP7@szxml06-in.huawei.com>; Mon, 14 Dec 2009 09:41:39 +0800 (CST) Date: Mon, 14 Dec 2009 09:41:38 +0800 From: Xu Xiaohu In-reply-to: <4B22B213.7080604@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <003101ca7c5e$948f26a0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp6pIUdDgxVnBo7QneCySX1UdU8PwBtjeAQ Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 01:41:54 -0000 > > Consider a scenario where dual-stack hosts coexist with IPv6 only hosts > > (IPv6 only stack or dual-stack with only IPv6 address), should they be > > configured with different DNS servers? > yes, that's how they should be configured. Please note that this does > not require two dns servers, you can run them in the same box as two > separate process, and use two different ip addresses. That would be the > best configuration (especially cause it would work with legacy nodes, > either dual stack or v6 only). (please note that other mechanisms > recognizing some bits, either the prefix or some bits in the iid would > require updating the node, and that is why this method is superior) Can the DNS server be automatically configured according to whether the client is dual-stack or not? If not, I don't think this is the best choice. > > That is to say, should dual-stack > > hosts be configured with a normal DNS server, while IPv6 only hosts > > configured with a DNS64 capable server? > > > > Or do you believe the above scenario itself is rare? > > > > > >> Second, you don't solve this problem by adding some bits in the middle > >> for recognizing the synthetic addresses. The point is that i am making > >> is that having them in the rpefix or in the iid achieve the same > >> capability (and have the same limitations) > >> > > > > There seems no bit in a NSP to tell whether an IPv6 address is a synthetic > > address or not in the current address-format draft. > > the NSP itself is what needs to be learned by the hosts that want to > recognize a synthetic address! > > I mean, in particular with the rfc3484 poilicy table, you need to > configure the NSP in the policy table, so that native connectivity is > preferred. If I understood it correctly, the basic precondition of this approach is the NSP is known to the hosts in IPv6 realm. Hence, I wonder whether this approach is still suitable for the IPv6 Internet to an IPv4 network scenario where NSPs used by different IPv4 sites are much various. > the main difference between this iand having a fix set of bits is that > these need to be learnt by the hosts in order to recognize the NSP. Note > that there is ongoing work to dynamically configure the rfc3484 policy > table, which would deal with this issue. Another option is to use the > WKP which can be hardcoded. > > On the contrary, we > > could use some bits in the IID to achieve that goal. > > > > Another possible way is as follows: the NSP used for synthesizing IPv6 > > address should be a specific prefix, e.g. starting with the binary value > > 00010101. > we have that, and that is the WKP There are three choice for the WKP in the address-format draft: o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 2765 Section 2.1; o request IANA to allocate a /32 prefix, o or request allocation of a new /96 prefix. Could you tell me which one is equivalent to the specific NSP I mentioned, which starts with a special binary value? Best wishes, Xiaohu > > In this way, the constraint on IID format mentioned before is > > removed due to starting with the binary value 000. In addition, this address > > is also provider aggregatable because the remaining part between the above > > binary value and the last four octets (i.e., IPv4 address to be embedded) > is > > network specific. > > > > Comments? > > > > Best wishes, > > Xiaohu > > > > > >>> > >>>>>> Regards, marcelo > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -- Christian Huitema > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Behave mailing list > >>>>>>> Behave@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Behave mailing list > >>>>>> Behave@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > > > > > > > > From ssenthil@cisco.com Sun Dec 13 19:36:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BCE28C0F8 for ; Sun, 13 Dec 2009 19:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LObUS2nYKNQ for ; Sun, 13 Dec 2009 19:36:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7C4E93A687F for ; Sun, 13 Dec 2009 19:36:50 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAARBJUurR7H+/2dsb2JhbAC+ZZVohCsEgWI X-IronPort-AV: E=Sophos;i="4.47,392,1257120000"; d="scan'208";a="448907659" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2009 03:36:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBE3abh9029899; Mon, 14 Dec 2009 03:36:37 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 19:36:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Dec 2009 19:36:32 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4B257875.4020503@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt Thread-Index: Acp8S+qh3R4xUZ+iTXGu7WraZ+A/EwAE4FvQ References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> From: "Senthil Sivakumar (ssenthil)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 14 Dec 2009 03:36:37.0846 (UTC) FILETIME=[A4506760:01CA7C6E] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 03:36:52 -0000 Hi Marcelo, Thanks for the response, please see inline for [Senthil]=20 -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Sunday, December 13, 2009 6:28 PM To: Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on = draft-ietf-behave-v6v4-xlate-stateful-03.txt Hi, thanks for the review see replies below... Senthil Sivakumar (ssenthil) escribi=F3: > General comments: > ------------------ > > =20 I will try to address some of these here and other i will leave for the = details comments below > - What is the requirement for the different tables that the document=20 > presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64=20 > to have all these tables? If so why? > =20 The tables contain the information needed for the NAT64 to work. I don't think you can make a NAT64 work with less information. Do you think some of the information stored in the tables is not needed? = which one? I would be glad to reduce the state needed by the NAT64, but i fail to = see what can de dropped. [Senthil] My question was more in the lines of must every NAT64 device = implement these 3 BIB tables and 3 Session tables. For example, you = could achieve the same with 1 BIB table and 1 session table for = TCP/UDP/ICMP. One could do it with 2 or 3 too. It depends on the = implementation needs and constraints. I am wondering why do we specify 3 = tables in the document. Instead we could refer to these as logical = tables and leave it up to the implementation as to however one choose to = implement as long as the behavior is the same. > - Requirement on state tracking. MUST, SHOULD RECOMMEND? Specific=20 > comments on state tracking below. > > =20 Not clear to me at this point what you mean, will see specific comment = below > - Confusing 3-tuple and 5-tuple usage and definition. Specific=20 > comments below. > > =20 Not clear to me at this point what you mean, will see specific comment = below > - There is no recommendation for BIB entry timeouts, is there one=20 > required? RFC4966 lists this as one of the drawbacks for NAT-PT. > > =20 the behave requirements require to use of timeouts, but since we also = have endpoint independets mappings, we need to track each session that = is being used by each endpoint. In order to do that the proposed = approach is to have timers in the session table entries. SO as long as = there is at least one session table associated to a BIB entry, the BIB = entry is preserved, When all session table entries associated to a BIB = entry are deleted, the BIB entry is deleted. So, While the BIN entries do have an explicit timer, they are bound to = the timers of the corresponding session table entries, so they do have a = timer expiration. [Senthil] I guess in the above paragraph you mean the BIB entries don't = have an explicit timer but tied to the session timer. I am fine with = that, my concern was wrt RFC4966 raising that as an issue. > - RFC4966 is mentioned in Section 1 and it is mentioned that a number=20 > of features have been added to overcome the reasons of deprecation of=20 > NAT-PT. I wonder if there should be a section discussing what has been = > overcome and how. Right, we could try to do this, if people find it important. Another = thing that would be also interesting would be to explain how the NAT64 = complies with the behave requirements for UDP, TCP and ICMP. Both of these excersises would be good to have in the document as = appendixes. We should discuss this in the interim [Senthil] Ok, I would like to address the issues arised by RFC4966 in = this document, even though I know a lot of issues mentioned in RFC4966 = is generic to any NAT, I think it will useful to document that we have = considered these issues and either addressed them or decided not to = address them. > Because I still see a number of issues discussed in RFC 4966 applies=20 > to this document as well - like ALGs, Binding state decay, Dos=20 > attacks, Loss of information through incompatible semantics (actually=20 > applies to stateless) etc. > > Specific comments. > ------------------- > > Section 1.1 2nd bullet - TCP [RFC4787] should be TCP[RFC5382] > > =20 fixed > Section 1.2 > > NAT64 mechanism is implemented in an NAT64 box which has two=20 > interfaces should be > > NAT64 mechanism is implemented in an NAT64 box which has atleast two=20 > interfaces > > =20 ok > Section 1.2.1 > > Paragraph starting "NAT64 creates the required mappings..." > > It is a little confusing as it implies a IPv6 address pool is to be=20 > provisioned, but rather a global prefix can used to=20 > algorithmically/statically map the IPv4 addresses into IPv6 addresses. = > I would suggest that you use the terminology of algorithmically=20 > extracting the IPv4 address and algorithimically adding the prefix to=20 > form the v6 address. > > =20 Right, i have rephrased the paragraph as: The IPv6 address pool is an IPv6 prefix assigned to the = translator itself (hereafter called Pref64::/n). Due to the abundance of IPv6 address space, it is possible to assign an Pref64::/n that is equal or even = bigger than the whole IPv4 address space. This allows each IPv4 address to be mapped into a different IPv6 address by = simply concatenating the Pref64::/n with the IPv4 address being mapped = and a suffix (i.e. an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX). The provisioning = of the Pref64::/n is discussed at length in [Senthil] Reads good. > Section 1.2.1 > > Paragraph starting "Because of the dynamic nature.." last line. > > "For this reason NAT64 supports only communications initiated from the > IPv6 side." > > Not entirely true, it should be "supports only dynamically initated=20 > communications from the ipv6 side". > > =20 right, i have removed that sentence > Section 1.2.2 > > Change the title of this section to be more meaningful than=20 > "Walkthrough". > > =20 I have changed the title to NAT64 behaviour walkthrough > Section 1.2.3 > > I don't understand this > > "Filtering on the IPv6 interface is not supported, as mappings are=20 > only created by packets traveling in the IPv6 --> IPv4 direction." > > Can you explain why one cannot filter on ipv6 interface? > > =20 good question NAT64 supports dynamically initiated connections only from the IPv6 = side. So filtering on the IPv6 side seems some how orthogonal to the NAT = behaviour. I mean you could do that, but you wouldn't be using NAT state = in order to do so, i think. OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot = support communications iniitated in the IPv4 side, when there is a hole = in the NAT opened by an IPv6 connection and because we are doing = endpoint independent mappings, we end up with the question on whehter we = do accept this new communication that has been initiated from the IPv4 = side or not (keep in mind that this is possible only because there is a = hole open and would not be possible in other case) So, while the NAT could filter in the IPv6 interface, this seems to be = orthogonal to the NAT behaviour, but filtering in the IPv4 interface i = tightly couple to the nat64 state, hence need to be specified. In any case, i have rephrased the previous sentence to Filtering of incoming IPv6 packets is not described in this = specification. [Senthil] I guess I was thinking filtering even before the session can = be created.=20 For example, one would want all the IPv6 hosts to have access to = internet but except for a handful of specific hosts. Another filtering = technique is all hosts are allowed except the ones that talk to a = specific port or set of ports. These types of filtering is common and = they protect the NAT64 resources (addresses & ports).=20 in order to make it clearer that is not that is not supported, but that = is not specified here. > Section 2 > > 3-Tuple & 5-tuple. > > Kind of confused here, in case of ICMP protocol is not a tuple and in=20 > case of TCP/UDP protocol is a tuple, why is that? > =20 mmm, not sure what do you mean here. In the terminology section it reads: 3-Tuple: The tuple (source IP address, destination IP address, Query Identifier). A 3-tuple uniquely identifies an ICMP Query session. When an ICMP Query session flows through a NAT64, each session has two different 3-tuples: one with IPv4 addresses and one with IPv6 addresses. 5-Tuple: The tuple (source IP address, source port, destination IP address, destination port, transport protocol). A 5-tuple uniquely identifies a UDP/TCP session. When a UDP/TCP session flows through a NAT64, each session has two different 5-tuples: one with IPv4 addresses and one with IPv6 addresses. So, the 3-tuple refers to the ICMP case. Not sure how to reword the = document to make this more clear. > There are two things that the tuple(s) are used for in this document. > > 1. To extract the required information from the packet. > > 2. To do a search in the database. > > For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address &=20 > port, Dst address & Port) > > 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. > > For doing a search and add/update/delete, since you have separate=20 > databases for TCP/UDP/ICMP, the search is based on 4 tuple for TCP/UDP = > and 3-tuple for ICMP. So I don't see why the 5-tuple searches=20 > mentioned in the later sections are required. > > =20 mmm, i see what you mean. OTOH, you could think that you actually search using the 5-tuple, since = the protocol value in the 5-tupel determines which table (UDP or TCP) = you need to search. We could use a 4-tuple for the 2 case, and we would need to define what = the 4-tuple is and how it relates to the 5-tuple. IMHO, this would = render the document less clear, but we can discuss further it you want. [Senthil] My confusion is this, if you have the tables as one big = monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if = not it is a 4-tuple search. The document calls for protocol specific = tables but mentions 5-tuple search, which is inconsistent. The second = inconsistency is 5-tuple search for tcp/udp but 3 tuple search for icmp. = I mean, if it is a 5-tuple search for tcp/udp it should be a 4-tuple = search for icmp. I feel it is more confusing if we leave it the way it = is. We may want to ask WG if anyone else find this confusing or if it is = just me. > Section 3.2 > > Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64=20 > and not stateless? > > =20 not sure if it applies to the stateless, it certainly applies to the = statefull translator, agree? [Senthil] Yes, it definitely applies to stateful, I thought it will also = apply to stateless and hence if it should belong in the stateless, = maybe?=20 > Section 3.2.1 > > Incoming IPv6 packet processing. > > Why should the search be based on the 5-tuple, since it is UDP session = > table the search is based on the 4-tuple of (SrcIP, DstIP, SrcPort,=20 > DstPort). > > Same comment on IPv4 packet processing. > > =20 right, see comment above > Section 3.2.2 TCP handling. > > Lifetime: is a timer that tracks the remaining lifetime of the UDP > > Should be TCP above. > > =20 fixed > Section 3.2.2 TCP states. > > What is the purpose of this section, does this document requires all > NAT64 devices to track the sessions with the described state machine?=20 > Is it a MUST, SHOULD, MAY, recommend? > =20 This is similar to the the TCP spec. It does have a state machine, you = can implement it in this way, you could do it in a different way as long = as the external behaviour is the same. This is captured in the draft in the following text: This breakdown of the NAT64 behavior into processing steps is = done for ease of presentation. A NAT64 MAY perform the steps in a = different order, or MAY perform different steps, as long as the externally visible outcome is the same. > Section 3.2.2 > Paragraph starting "After bootstrapping...." > > What does it mean all TCP sessions are in closed state? Where is this=20 > tracked? > =20 Again, this is similar to the TCP CLOSED state The closed state is somehow special, cause it means that there is no = state for the particular connection. I have tried to make this clearer = in the document by adding the following description: CLOSED: Analogous to , CLOSED is a fictional because it represents the state when there is no = state for this particular 5-tuple, and therefore, no connection. [Senthil] The state of a session is tracked via the session table, but = the text indicates that all the TCP sessions are in closed state. My = question is what is this "all TCP sessions" and how do you track a = session state without a session.=20 > The state of the TCP session is tracked within the TCP session table=20 > entry and state tracking starts when the entry is created and stops=20 > when the entry is destroyed. mmm, i don't think you can keep track of all the state information using = only the information stored in the session table. In order to keep track = of the state informtation, you will likely have to keep track to the = state information in addition to that information in the tables. [Senthil] Agreed, but the state information is keyed off of session = table. That is, if you don't have a session entry you cannot(and don't = have to) keep track state information for that session entry,=20 > So what is this CLOSED state and where is it tracked? This is very=20 > unclear and confusing. > > =20 i hope this clarified with the text above. > Section 3.2.2 > > "The state of the session is moved to V6 SYN RCV". Again where ? The=20 > text for the actual session creation is below this text and until the=20 > session is created where does this state hang off of? > > =20 I have moved the order to the sentence, so that first the session entry = is created and then the sta te is moved to V6 SYN RCV, would that help? [Senthil] Yes.=20 > Section 3.2.2 > > s/If such entry does not exists/If such an entry does not exist > > =20 fixed > Section 3.2.2 > "If the lifetime expires, the session table entry is deleted and the=20 > state is moved to CLOSED." > > Same comment as above, where is the state stored for this session?=20 > > I will not repeat these comments in the subsequent text in the same=20 > section but this needs some serious explanation and clarifying. > > =20 I have made many changes aiming to clarify this in the 04 version. Could = you check it and see if it clearer now? [Senthil] Ok, I will be travelling tomorrow, this would be a good read. > Section 3.2.3 > > For port allocation, the text says if the port is even an even port=20 > must be allocated and same for odd. What if there are no even ports to = > allocate but there are odd ports, should the packet be dropped or=20 > allocated a odd port. I understand some application require that the=20 > port parity to be maintained but majority of the apps don't care. So=20 > making this a recommendation on the best effort basis is ok but making = > it a mandatory requirement sounds unreasonable. Note RFC 4787=20 > recommends this behavior but this text mandates it. > =20 Right, i have changed this to a should. [Senthil] I am thinking that this should be a configurable parameter, = that is the admin can decide if the device should strictly allocate = even-for-even and odd-for-odd or it should do the first available port.=20 Senthil > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > =20 From huitema@microsoft.com Sun Dec 13 21:02:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57C03A67FC for ; Sun, 13 Dec 2009 21:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YVq1vIudyPs for ; Sun, 13 Dec 2009 21:02:45 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DE87A3A657C for ; Sun, 13 Dec 2009 21:02:45 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 13 Dec 2009 21:03:01 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Sun, 13 Dec 2009 21:02:32 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 13 Dec 2009 21:02:32 -0800 From: Christian Huitema To: Xu Xiaohu , 'marcelo bagnulo braun' Thread-Topic: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? Thread-Index: AQHKekaX3P7H6mepREaQ1c78nEEJHpFg2nuAgAN0OwD//7E8kA== Date: Mon, 14 Dec 2009 05:02:26 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211F8FDC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B22B213.7080604@it.uc3m.es> <003101ca7c5e$948f26a0$d40c6f0a@china.huawei.com> In-Reply-To: <003101ca7c5e$948f26a0$d40c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 05:02:46 -0000 > There are three choice for the WKP in the address-format draft: > o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC > 2765 Section 2.1; > o request IANA to allocate a /32 prefix, > o or request allocation of a new /96 prefix. > > Could you tell me which one is equivalent to the specific NSP I mentioned= , > which starts with a special binary value? I just submitted an update to the address format draft:=20 http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.txt In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96. -- Christian Huitema From xuxh@huawei.com Mon Dec 14 00:46:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C1E3A6811 for ; Mon, 14 Dec 2009 00:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.517 X-Spam-Level: X-Spam-Status: No, score=0.517 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMgELLDirKnO for ; Mon, 14 Dec 2009 00:46:34 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 828363A680C for ; Mon, 14 Dec 2009 00:46:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00DN3WB92F@szxga04-in.huawei.com> for behave@ietf.org; Mon, 14 Dec 2009 16:45:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM0040TWB8OJ@szxga04-in.huawei.com> for behave@ietf.org; Mon, 14 Dec 2009 16:45:08 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM005ARWB8FH@szxml06-in.huawei.com> for behave@ietf.org; Mon, 14 Dec 2009 16:45:08 +0800 (CST) Date: Mon, 14 Dec 2009 16:45:08 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA211F8FDC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , 'marcelo bagnulo braun' Message-id: <004301ca7c99$bdc27a00$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AQHKekaX3P7H6mepREaQ1c78nEEJHpFg2nuAgAN0OwD//7E8kIAANrPA Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:46:35 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > > There are three choice for the WKP in the address-format draft: > > o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in = RFC > > 2765 Section 2.1; > > o request IANA to allocate a /32 prefix, > > o or request allocation of a new /96 prefix. > > > > Could you tell me which one is equivalent to the specific NSP I mentioned, > > which starts with a special binary value? >=20 > I just submitted an update to the address format draft: > = http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.t= x > t > In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96. "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 = Internet to an IPv4 network), as this would lead to using the Well-Known Prefix with = non global IPv4 addresses". However, the specific NSP starting with a = special binary value (depicted as follows) could be used in the above scenario = since the Network Specific Parts is topologically aggregatable. That is to = say, the specific NSP is a hybrid type of 96/ prefix which starts with a well-known binary (e.g., 00010101) while the remaining part is network specific. +--------+--------------------------------+-----------------+ |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| +--------+--------------------------------+-----------------+ Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the = specific NSP I mentioned.=20 Xiaohu > -- Christian Huitema >=20 >=20 From marcelo@it.uc3m.es Mon Dec 14 04:29:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B127C3A687D for ; Mon, 14 Dec 2009 04:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.806 X-Spam-Level: X-Spam-Status: No, score=-4.806 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoIIE-fZPivU for ; Mon, 14 Dec 2009 04:29:14 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 741843A6836 for ; Mon, 14 Dec 2009 04:29:13 -0800 (PST) Received: from r190-132-213-7.dialup.adsl.anteldata.net.uy (unknown [190.132.213.7]) by smtp01.uc3m.es (Postfix) with ESMTP id 187EFBA7E48; Mon, 14 Dec 2009 13:28:54 +0100 (CET) Message-ID: <4B262F83.6050505@it.uc3m.es> Date: Mon, 14 Dec 2009 13:28:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Xu Xiaohu References: <004301ca7c99$bdc27a00$d40c6f0a@china.huawei.com> In-Reply-To: <004301ca7c99$bdc27a00$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 12:29:15 -0000 Xu Xiaohu escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: Christian Huitema [mailto:huitema@microsoft.com] >> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ14ÈÕ 13:02 >> ÊÕ¼þÈË: Xu Xiaohu; 'marcelo bagnulo braun' >> ³­ËÍ: behave@ietf.org >> Ö÷Ìâ: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> >>> There are three choice for the WKP in the address-format draft: >>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC >>> 2765 Section 2.1; >>> o request IANA to allocate a /32 prefix, >>> o or request allocation of a new /96 prefix. >>> >>> Could you tell me which one is equivalent to the specific NSP I >>> > mentioned, > >>> which starts with a special binary value? >>> >> I just submitted an update to the address format draft: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.tx >> t >> In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96. >> > > "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to > an IPv4 network), as this would lead to using the Well-Known Prefix with non > global IPv4 addresses". However, the specific NSP starting with a special > binary value (depicted as follows) could be used in the above scenario since > the Network Specific Parts is topologically aggregatable. That is to say, > the specific NSP is a hybrid type of 96/ prefix which starts with a > well-known binary (e.g., 00010101) while the remaining part is network > specific. > > +--------+--------------------------------+-----------------+ > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > +--------+--------------------------------+-----------------+ > > Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the specific > NSP I mentioned. > Maybe i am not understanding what you have in mind. Could you put an concrete example of a scenario involving the IPv6 internet that requires the host to distinguish that the address of its peer is synthetic? Regards, marcelo > Xiaohu > > >> -- Christian Huitema >> >> >> > > > > From xing@cernet.edu.cn Mon Dec 14 06:37:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986413A6886 for ; Mon, 14 Dec 2009 06:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDJbKNqv0dWT for ; Mon, 14 Dec 2009 06:37:57 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 91C8E3A6806 for ; Mon, 14 Dec 2009 06:37:55 -0800 (PST) Received: from [10.24.120.91]([117.136.1.156]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b26a0d8; Mon, 14 Dec 2009 22:37:39 +0800 Message-ID: <4B264B72.2000009@cernet.edu.cn> Date: Mon, 14 Dec 2009 22:28:02 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: U2ZDMUXB Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:37:58 -0000 Thanks. We will make modifications in the next version. xing Senthil Sivakumar (ssenthil) 写é“: > General Comments > Overall, the document is in a good shape and is ready for last call. > Some general comments/behavior. > 1. An example flow either in sections 2 & 3 or in the appendix would > help understand the translation > process easily. I believe something like this was in the initial ivi > document. > > Abstract: > Paragraph starting "Significant issues exist..." > > I don't know what issues are being referred to here but there is no > description of the issues nor there is a pointer to a document that > describes/addresses the issues. I think we should either drop this > paragraph or describe the issues or point it to another relevant > document. > It is like saying "There are significant issues with stateful & > stateless modes, we wont tell you what they are but we don't plan to > address them in this document". That doesn't give me a good feeling when > I start to read this document. > > Editorial comments. > 1. Section 1.2 Para "The translating function specified in ..." > > There is a reference to RFC2765 that is hanging here. I don't know what > is the intention of bringing in the reference without properly relating > it to the context. > > 2. Section 1.2 Para "Fragmented IPv4 UDP packet...." > > "use over wide-areas in the Internet" - did you mean over wide-area > networks? If not, what does wide-areas mean here? > > 3. Section 1.4 Para 1. > s/must send packet to big/must send packet too big > > 4. Section 2 > Para "However, when the IPv4 sender does..." > > s/needed should the packet pass through an IP/ICMP translator/needed > should the packet pass through another IP/ICMP translator > > 5.Section 2.1 > > Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." > > Why is this a MUST? Isnt this upto the implementation? How can you > verify the conformance? > How can you detect if the nat64 device fragments it and translates it or > translates it and fragments it? > > 6. Section 2.1 > Hop Limit: I think the recommendation should be to decrement the TTL and > send ICMP TTL exceeded before translation. Translating the packet and > decrementing TTL to find out the TTL expired and restoring the packet to > its original form seems to be unnecessarily complicating things. We > shouldn't even suggest that. > > 7. Section 2.2 > Para 2 "When a stateless translator...." > The text says "translator SHOULD drop the packet and generate a system > management > event specifying at least" > > Is the SHOULD for dropping the packet and generating the event? I think > generating the event should be optional/MAY. > > 8. Section 3.1 > Time to Live - Same comment as hoplimit for IPv6. > > 9. Section 5 - Security considerations. > This document does not address any potential issues that might arise by > extracting a IPv4 address from the IPv6 address - particularly addresses > like broadcast or loopback addresses etc. I think adding some text > around that might be of help. > > Senthil > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From xing@cernet.edu.cn Mon Dec 14 06:38:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C464C3A68D4 for ; Mon, 14 Dec 2009 06:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcXXJ3dynGQN for ; Mon, 14 Dec 2009 06:38:05 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id C2F283A680B for ; Mon, 14 Dec 2009 06:38:02 -0800 (PST) Received: from [10.24.120.91]([117.136.1.156]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4b26a0e0; Mon, 14 Dec 2009 22:37:46 +0800 Message-ID: <4B264BE4.1090807@cernet.edu.cn> Date: Mon, 14 Dec 2009 22:29:56 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4B1592E7.2030104@viagenie.ca> <4B1BB437.4010009@cernet.edu.cn> <4B1BCBF2.1090407@viagenie.ca> <4B1CD899.8010402@cernet.edu.cn> <4B1CFC4E.1080808@viagenie.ca> <4B1FA5BD.20900@cernet.edu.cn> <4B1FAD22.5040907@viagenie.ca> In-Reply-To: <4B1FAD22.5040907@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: U36DMUXB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:38:05 -0000 Simon Perreault 写é“: > Xing Li wrote, on 2009-12-09 08:27: > >> For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if >> there is a one-to-one relationship (defined in the xlate document) >> > > Do you mean that it is already defined, or that it will eventually be defined? > > Because I don't see it in the draft right now. > We mean: For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if there is a one-to-one relationship (defined in the sections 2.1 and 3.1 in the xlate document) between IPv4 and IPv6 headers of the invoking packet where the error was detected, the translator should translate the packets from one address family to the other address family. > >> between IPv4 and IPv6 headers of the invoking packet where the error was >> detected, the translator should translate the packets from one address >> family to the other address family. Otherwise, >> >> Option 1: >> The translator passes the invoking packet where the error was detected >> as opaque bit strings; this is likely to cause problems with processing >> of those ICMPv6/ICMP Error messages. >> >> Option 2: >> The translator silently drops the ICMP/ICMPv6 Error messages. >> >> Which option should we choose? Please comment. >> > > My opinion: Option 2. Doing otherwise would be useless. > Got the idea. xing > Simon > From xing@cernet.edu.cn Mon Dec 14 06:38:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724773A68DF for ; Mon, 14 Dec 2009 06:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.178 X-Spam-Level: X-Spam-Status: No, score=0.178 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KVz7loSjGlN for ; Mon, 14 Dec 2009 06:38:18 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 870B33A680B for ; Mon, 14 Dec 2009 06:38:17 -0800 (PST) Received: from [10.24.120.91]([117.136.1.156]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm24b26a0ef; Mon, 14 Dec 2009 22:38:01 +0800 Message-ID: <4B264C27.8000408@cernet.edu.cn> Date: Mon, 14 Dec 2009 22:31:03 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091210174724.8323.B01659E3@sablenetworks.net> In-Reply-To: <20091210174724.8323.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: U4lDMUXB Cc: Behave WG Subject: Re: [BEHAVE] Translating code of ICMPv4 Parameter Problem (Type 12) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:38:19 -0000 Kentaro Ebisawa 写é“: Thanks. We will present your comments in the interim meeting and try to get consensus. xing > Hi, > > draft-ietf-behave-xlate-04 [Page 14] says to translate ICMPv4 Type 12 > (Parameter Problem) to ICMPv6 Type 4, but there are nothing mentioned > about the Code to use. > > | Parameter Problem (Type 12) Set the Type field to 4. The > | Pointer needs to be updated to point to the corresponding > | field in the translated include IP header. > > It would be helpfull if we can clearly mention what code to use. > > Looking below, maybe we can translate all v4 codes to 0 ? > > Codes for ICMPv4 Type 12 : > 0 - Pointer indicates the error > 1 - Missing a Required Option > 2 - Bad Length > > > Codes for ICMPv6 Type 4 : > 0 - Erroneous header field encountered > 1 - Unrecognized Next Header type encountered > 2 - Unrecognized IPv6 option encountered > > Regards, > From xing@cernet.edu.cn Mon Dec 14 06:39:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D80A3A680B for ; Mon, 14 Dec 2009 06:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.916 X-Spam-Level: X-Spam-Status: No, score=0.916 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_05=-1.11, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnmTtLR+N16g for ; Mon, 14 Dec 2009 06:39:24 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 4CDBB3A6806 for ; Mon, 14 Dec 2009 06:39:22 -0800 (PST) Received: from [10.24.120.91]([117.136.1.156]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm584b26a0f1; Mon, 14 Dec 2009 22:38:04 +0800 Message-ID: <4B264D61.6060706@cernet.edu.cn> Date: Mon, 14 Dec 2009 22:36:17 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091211140848.8337.B01659E3@sablenetworks.net> In-Reply-To: <20091211140848.8337.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: U7oDMUXB Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv4 Type 3 Code 13-15 (draft-ietf-behave-v6v4-xlate-04) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:39:25 -0000 Kentaro Ebisawa 写é“: > Hi, > > While reviewing draft-ietf-behave-v6v4-xlate-04, I noticed how to > translate ICMPv4 Type 3 Code 13-15 are not mentioned in the doc. > > * Type, Code (defined in RFC1812) > 3, 13 : Communication Administratively Prohibited > 3, 14 : Host Precedence Violation > 3, 15 : Precedence cutoff in effect > > Is this already discussed somewhere ? > No. The current document only discusses the ICMP Codes defined in RFC792. > If not, I think we should add text explaining how to translate these > codes as well. For example, here are my idea how it should be translated. > > Code 13: Set Type field to 1, Code 1 (communication with destination > administratively prohibited) > > Code 14: Single hop message. Silently drop. > > # RFC1812: > # 14 = Host Precedence Violation. Sent by the first hop router to a > # host to indicate that a requested precedence is not permitted > # for the particular combination of source/destination host or > > Code 15: Set Type field to 1, Code 1 (communication with destination > administratively prohibited) > Thanks. We will present your comments in the interim meeting and try to get consensus. xing > Regards, > From iljitsch@muada.com Mon Dec 14 07:14:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9F53A68E7 for ; Mon, 14 Dec 2009 07:14:38 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew9udb5puRT5 for ; Mon, 14 Dec 2009 07:14:37 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8A20A3A68CD for ; Mon, 14 Dec 2009 07:14:37 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBEFDj9e039318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 16:13:46 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 14 Dec 2009 16:14:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <804B3431-69D7-4F3A-951F-6369745CBC35@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEAA15C.4060900@it.uc3m.es> <200910301320.n9UDKTOs099079@drugs.dv.isc.org> <4AEB99B5.8080106@gmail.com> <073AB33C-10FF-47F5-B4CA-9AF8F5A1AF93@muada.com> <4AEC9777.6070607@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:14:38 -0000 On 1 nov 2009, at 13:07, Iljitsch van Beijnum wrote: > I'll let it run for a week or so and after that also see in how many = cases the actual path MTU is smaller than the MTU advertised in the MSS = option. Ok, more than a month worth of SYNs: Total: 9863 1440: 5996 1220: 667 8940: 2971 Other: 329 However, ALL the sessions with MSS=3D8940 come from a single address... = I need to look at this data some more.= From ebisawa@sablenetworks.net Mon Dec 14 08:07:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2863A6A15 for ; Mon, 14 Dec 2009 08:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RpdizJU15cc for ; Mon, 14 Dec 2009 08:07:19 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 4F4B73A686E for ; Mon, 14 Dec 2009 08:07:18 -0800 (PST) Received: (qmail 16326 invoked by SAV 20091214.018 by uid 0); 15 Dec 2009 01:07:04 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 15 Dec 2009 01:07:04 +0900 Date: Tue, 15 Dec 2009 01:06:59 +0900 From: Kentaro Ebisawa To: Xing Li In-Reply-To: <4B264D61.6060706@cernet.edu.cn> References: <20091211140848.8337.B01659E3@sablenetworks.net> <4B264D61.6060706@cernet.edu.cn> Message-Id: <20091215002417.836C.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4B2658A000000000A547_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv4 Type 3 Code 13-15 (draft-ietf-behave-v6v4-xlate-04) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:07:20 -0000 --------_4B2658A000000000A547_MULTIPART_MIXED_ Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Hi Xing, Based on the draft, I've compiled matrix of ICMPv4(v6) to ICMPv6(v4) translation rules for all Type/Code registered to IANA. # I can send you MS Excel version personally if you want one. Looking into the matrix, the only Type/Code not defined how to translate are below ICMPv4 error messages. * Type 3, code 13,14,15 * Type 6 * Type 12, code 0,1,2 So it would be great if you can get consensus about how to handle above Type/Codes. BTW, I've noted in the Matrix to drop all ICMP Types not mentioned in the draft for ICMPv4 query, ICMPv6 informational and error messages since it's mentioned in the draft. But it doesn't say anything about how to handle unkown Type/Codes for ICMPv4 error messages. So I think it will be good idea to add text to the draft to drop all unkown ICMPv4 error messages as well, in case there were new ICMPv4 Type/Code defined in the future. Regards, -- Kentaro Ebisawa On Mon, 14 Dec 2009 22:36:17 +0800 Xing Li wrote: > Kentaro Ebisawa $B > Hi, > > > > While reviewing draft-ietf-behave-v6v4-xlate-04, I noticed how to > > translate ICMPv4 Type 3 Code 13-15 are not mentioned in the doc. > > > > * Type, Code (defined in RFC1812) > > 3, 13 : Communication Administratively Prohibited > > 3, 14 : Host Precedence Violation > > 3, 15 : Precedence cutoff in effect > > > > Is this already discussed somewhere ? > > > > No. The current document only discusses the ICMP Codes defined in RFC792. > > If not, I think we should add text explaining how to translate these > > codes as well. For example, here are my idea how it should be translated. > > > > Code 13: Set Type field to 1, Code 1 (communication with destination > > administratively prohibited) > > > > Code 14: Single hop message. Silently drop. > > > > # RFC1812: > > # 14 = Host Precedence Violation. Sent by the first hop router to a > > # host to indicate that a requested precedence is not permitted > > # for the particular combination of source/destination host or > > > > Code 15: Set Type field to 1, Code 1 (communication with destination > > administratively prohibited) > > > > Thanks. We will present your comments in the interim meeting and try to > get consensus. > > xing > > Regards, > > > --------_4B2658A000000000A547_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="ICMP-ALG-TypeCode-Matrix-20091214.pdf" Content-Disposition: attachment; filename="ICMP-ALG-TypeCode-Matrix-20091214.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjUNJeLjz9MNCjE4IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDUxOTkwL08gMjAvRSAz NTE2Mi9OIDMvVCA1MTY2Ni9IIFsgNDg2IDIwNV0+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAg DQozNCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3IgMTI+Pi9GaWx0 ZXIvRmxhdGVEZWNvZGUvSURbPDNCNDgwQjczREIyRjc3NDEwQUQxRjgwMEU0MTY1QzQzPjwxQkYz RUM3ODBGODkxQjRBQUEyMTQ2QzdDRjVCQTIyND5dL0luZGV4WzE4IDI0XS9JbmZvIDE3IDAgUi9M ZW5ndGggODMvUHJldiA1MTY2Ny9Sb290IDE5IDAgUi9TaXplIDQyL1R5cGUvWFJlZi9XWzEgMiAx XT4+c3RyZWFtDQpo3mJiZBBgYGJgWgwkGAOABMNuIMHMCRLLAhIsJ4AEmz6IuwXEVQQRVSBCBCRW BFJsDiS4WkAGlAKJC+4MTIwMC0FGMTBiJf4zXvwNEGAASccLGQ0KZW5kc3RyZWFtDWVuZG9iag1z dGFydHhyZWYNCjANCiUlRU9GDQogICAgICAgIA0KNDEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0kgMTM1L0wgMTE5L0xlbmd0aCAxMTgvUyA2Nj4+c3RyZWFtDQpo3mJgYGBmYGAyY2BhYBC7 x8DPgAD8QBkWIOTYwHDvEwODoMU2oCCj9lmhswwdDRwdDB0QUSQdfFDMwFAK1N3DFcC+wtVgukP/ wWvMrOx27F/4BBZ8YBDTgyhmZ2B0XAAyEYg7gZiLgTFQBcJnFAIIMABicxXdDQplbmRzdHJlYW0N ZW5kb2JqDTE5IDAgb2JqDTw8L01ldGFkYXRhIDggMCBSL1BhZ2VMYWJlbHMgMTQgMCBSL1BhZ2Vz IDE2IDAgUi9UeXBlL0NhdGFsb2c+Pg1lbmRvYmoNMjAgMCBvYmoNPDwvQ29udGVudHNbMjMgMCBS IDI0IDAgUiAyNSAwIFIgMjYgMCBSIDI3IDAgUiAyOCAwIFIgMjkgMCBSIDMwIDAgUl0vQ3JvcEJv eFswIDAgNTk1LjIyIDg0Ml0vTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCAxNiAwIFIv UmVzb3VyY2VzIDM1IDAgUi9Sb3RhdGUgOTAvVHlwZS9QYWdlPj4NZW5kb2JqDTIxIDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA0MC9MZW5ndGggNjgyL04gNi9UeXBlL09ialN0bT4+ c3RyZWFtDQpo3oRTbWvbMBBe92EM9ifuY8LIJFmybEMxpEmThi1dqLN1YPLBTdTUw7GMrULz73cn pymDwQKO7v3luTsZAgepIVEgIxAiABmDiPBJQGn8OAgeKLi8ZBNb2TZriq0hptPkxuEuTdn1i5tn rnCkmGeCIvWKma0dytZrQYF62aq128y4nK2mM7Y2L26TpjlbTCZXRWd2IAXZbdDr+woei6ozSCxB sGx8YrMl8C88YOtjY95SM9v0+jRF33G3NbWDOEzYZDHFdCADissmRXNjyv2Tg0hGbGp6u5FQnM2q Yt+B8kVfXdmXfCQCgSrsJkk0xdp43aw4lNVxsMxgNbfuqdwOe3FZGYRN+jQkuC0OBvuazb9OPy+z 0cnYqzLXGrd9Yre2PRSVF933VSnO2cIVVbkd1/vKAGffinrPfhcsc+Zwg1V44ieOSiF1rAjzVVHb zgw+Xrz/9OHinf8NEWkPEMWmNtuycbZlv07dh6H0QBHoZPKPQgm4Y4fJFvWjpXm0O9OW9X6w2CFm pTsO2Z3Zl51rj4Pxzj6YIcuem6YyB4KUYwEYYW3ni+myaNirE5ve40Zhl38XRmtHwGXPD47KRlcy oBaCt0bYfS5UoqNc8nBDVJKHnBMVhUD/uJS8p6KzJskDLgE5OL0kjSVZJYGXEyXJijSJ90+isybO VShB6xg0TlfjOmitQKsYQq0RSAE65sgLCBTyCnMkqMMDilTg5RFHHxH1bxCC5pg36X0oJtptRIhn lqPUUzqXUnsqfqVkkKsoAmzaV/b6Ur9Ki74/gTWIxPNER1J5echjsqcoCrtBT4nVk5UMewQosj7J fJYw2ggsN/Yobv63Kv0d7Qq8AjTocuydjphd11u7w5U5T390c54wDZWztf1Rl2hkIOgP9DzrNP0j wACKlkH/DQplbmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMjkyPj5zdHJlYW0NCmjeVJHLboMwEEX3fMUsW3VhY2gCEmJRokos+lCTdm/sgSIVYxmy yN/X9pBUXYB07jyufIc17aE14wrs3c3qiCv0o9EOl/nsFEKHw2ggFaBHtW4U/2qSFpgfPl6WFafW 9DNUVcI+fHFZ3QXuTqf0gd8De3Ma3WgGr+Ti88srx7O1PzihWYFDXYPGPmHNi7SvckJgcfBPPF0s goicbt6zxsVKhU6aAaHK5H5fQ5WLblcDGv2/nuxoquvVt3TJtZtzwetIJZGI1PFIjyWRIHoiyokO nsisyvizr3nPbXt+9SLrsL4PbbJIyaWIm4osiuUmNlEsSZQYxYzEroiips5dupnR+vDWcIdbdurs nI81HiuGF2IbDd7uaWcbEgpf8ivAALcslqENCmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTUzPj5zdHJlYW0NCkiJ1Fe7rts4EO31FawXEMP3 AzBc7AMBAmy16i5SkJIdIMBukVvk93dmOLRkX1u7N8VNUtCUyKE4c87wDP3u/V9afHoefp2Gd9Ok hRbTeVAiyBzESL9KaC+NEzZGGazyYvobDD5Bm2b8+TocbCnKllygd9CiLRFaTvBsoT+191JtWcBu huc625JCWzNDX2sbIzv4RoW1M4zNGRquOR+nz8Mf4ORvz0HMz0LmlMApmaw3WciofErief5n0DFI HUTwUlkIR8sILy5Kb8SX03AeZHIJvDcQlHIwn6T3YKekSsKYIC3bGeP3Zq1DbHYMgoOd9gwiGOzN J4eu7xhkMDA7BlY5GdYtnHTuah4oVyJJwG2kXyV8kkZ4I0NsNBsxfQGb99A+wPRnIXVM4iskyZ/i 6SOMLJQJD/i/5Zty4g7f80O+b/IwRAwB/HOchlLbDO6QA5Y/UtqH6MMzb17XDXDTyvNZtz7Bpim2 llVLzJR4vD/DmmQ5MNO+M3v+ZmLHA38X9+iBFJ4/tZ7mLftxx2bAhxzXQTLiBQk2rIwgPs8aA0Sk TIQjEAGj6XdEI/sGH6Q9wEe/QDXAl7bwKaT3sJKCRCBefbt5S5Jdfb3gi0QuryR7u+Ymaeal4bzl pp45MWr7No4TJ6Hh1RvCMaCDBKRvPWEUGjn11BZdkgSbYuxMAnno4KElUeuuacYVtK1iFhiuxH1P A+rdNYSUHgV3G/t2o5ZWR98Z+5E4WH46Drrbr+PiRv6MslgmtFFS640Csurd07ltys6pSU7fA6m4 6Nu8Rkyn+tTH7uic0YaqFki1fyl0d5S2k4ukUoJ47iv3iBhJglMg7lA3Ceenw23OHEdtoHLqw23i 0ISlif+9IiYlLS7oGcDjxljNM4BSXtrKLq61rsxRPIwuPXMeEaobO4q38KFJL+L+OH1oWjf28OHs ObgddAy2bpy4BuTj6KzLMh1Y0AsfBBZ5XFTn9bAuCiLLkDYyHLCUwFuKmcKkF9tfuLBktR1EC59y oMX3IKDEVptE5mSv7Aa6RqEvXCrceih6ktLY+Rqmbkv1rxJU0y/fgspxBDWDq0bGcM7/FT1Z/DTR d6fReoFAEyNQuOjPN+rSb78UyrJRnZ6Xhceu1A1AcD5bQhCy45EzvVVyeePMRmgvVyo+VPOOo/X1 jqJrDo5QMqkpiZHAtsU/BAdOFK6LyaHqgJ4Z43Szpf8NGFVTf64UJ3speZeSE9rp2tdQEKBgfP4R Umf0Fm5hIe/JyyP2cmXx5CAp6I1wPmKRwNreHVyXvZcyiaH3ElELpJvKLMQkRsHGdnrTUR1appsA tTAeiMfNiYYX7VOQ5g1YJGRh4+DMej14Q2Lxyta33+H1WySi9NPV/w8Ue1O6ml08N1sas3a9/HCJ f1nywAlF/Ea4+3fZjVs+4w2fb0tuIxWuXUGvV763P7TEbfNipfZx6QPzKEPKUUjt4aLIxh35bfyd FbqO4kILV0uvoxgvS586L+X1vJTQsJi3WbHJsP4Pt3P3+KaPH/XaUpZ8T/kU/wowAB9tDRYNCmVu ZHN0cmVhbQ1lbmRvYmoNMjQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjU2 Pj5zdHJlYW0NCkiJ1FfJjuNGDL3rK+oHXKl9AYw+pDOXOQQIxkAOjRwk2Q4SIANk+pDfD8kiVZJt dSeDuUwDkqWiSL7i8op9+jgcgtUu2KAOVgdv1emn4eXox7H6sZ7hGv1YLvBr4Lc+HYIPVRf8YPLj DItz8OM0wy98OMPaVNranP2YczNEcnievR/P5ungki+erBT4uky44ozOuJDhpeSqPb6EmxcbS9IO vSewWtlrapbnmRHA7zQ174QwMhLTtjMCuhFlsL1yRqPReh2PTWuubQ/TuVkroVmZxPq5rU28r+nK ez63d4D52+njUKIu1jhlMKBHcca/YvbagJP6JOoYAwrK6c/hIGb+b3J427SJ1DZFiWJPFJa0Co0k qbQw9oRCAqJ1UVdJ1vx9J6slB4ovZrskZ5u/r03Wh9Pw92DVH2rwJmmfVIJ7tMrpnJTz2hX15TL8 qj4PP54Go5KuSR3obpS3btEwUZ3+GvbT3Fz9cuPMWkh9Zm/R4P09b02ludNwn1txYfwo0oAmHKkI ojH4AK1bQDUSNii3mrTFdU9RfQDKR699ZVDk/D1MTWMJAZXceWfLPhcdxbrX4f34No1uPe9YDsFo K6lLVnv3rumm0ky/LEX/dKipUEtCkA4cxkmeJnjyJlAvUXD5eVv8EOicdDpSJHYCnUzttVaBNP5D rZHKbfYJkgvUt1AFgpibUyoB+4p66gp1Ul1tbHB+girHikFGD8kQacC+ebXvG+LOD1PfEAHNOgJQ uhtlA5UxlmnlpDl1+jJQav5RlEHbLiGxpV2wa698Mb1gNIl2fN9RYXqhrq5t/RH9iP5CjCMTz6Wv 4TdVsEQmnDW9TY3+MvsjArMN0yDHJwpzZaqZmcUvTDnXJiMD1BSuaAMs208Z4T7f3eZrY4/FQm4w Jjmw5+55fV7ssjCG1jd5OX9Du3iZJh/eU6C1CaeJNllMM4Uja2Nt7uHgrBCU6wpWbOG5P3zo0I1R m2w8HroW/sQY7xOV7sot9ljvxayGW8gcw7HFk6iurJ5rj/NevHZtih20bXBTNxzgjNMhANumfgJY X7GrXu4ISPYAzBCF/h8fz9jMRhWknwPdoYlhhDFBWRgZrBVPuXD/jqtDHLNCbbA6ZWUkwBZ4qyAp y5wc6S3KdO1VILbWfbgX2LfttYBuuSq5DVGtOAq5gGqZbSwccZO4khoWaqKpJxOTjJdQA3KW0IBM 3+v4LXuVyr7wu2+X8BOeUKPErnZ/805OhvXoI20jHy1tNHZnS1O6tG5KSYFv2ycr7JLClHtIptUW JB0yIS6D96NmfiPFFFLQG8F/vWDvIsofnl+Tev6kcCg06tPzz21lfuWV1/nzcJCtBA2nm+f9yPHz bf558F8xfG6PHjo9OE6z45heety2Ger5GN5KyFJvFwZBdSacG8NNetOq+sLWzfpfj00h3TA+enyz 26Ub61Zv8//oo1O6Sso/4MDx+2Br0NEpH0Ib+YD0oZU1TXzXwZkIjx6GOAfDddUuKJAbyD6JLcxa GeTV6gyTqC34hgZWysFG7W1X3mgGDzzp7zVBJwUCleOulFEt0gWWfLADq0kF1450B5iPSHgCDAaQ VO6lDGyRdmD8AQN7rC7AdqQM7FaaIp1oDKzg5HgnZFwi7LBYzrAeKguqx0IGdSPMIFwg+Ypj962Q XW6E6l8BBgDIqIgQDQplbmRzdHJlYW0NZW5kb2JqDTI1IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggNjIyPj5zdHJlYW0NCkiJpJfLjtQwEEX3+QqvkSjVy68vQEJiwS+AGAk0s4AN v0+VE3q6GQLquepNyxVfOSeVY+dh017Ji9ugYVJskrVCouXHl+1hk1mpa2ncya2ITGIvQkd1n2pt kParqcx2XXepZPIiWsXJI0w6zSpFmMn0OVumU9ViHpOzHOPajHQcs7kSj0s5U7VpDt2GT5Jjto9J /rus9VLLqT7Gc7J5rvN0qjtNvZ7NLLcB1WmM8/zmpP9YWo/yeXU49XaeHdC6npaNndq4XbvdXhHc mp8GcHm3SXlfpHxbtZ/x2MqHEmNfy/Y9hjl+UtRqMsrGyJTPT2v8acv7zlt53N6uVoil5t/4F4XH 7dOb7eNNSlvdNUntz5B2yRj+v4x4FtY5+vf1IT2vsi7UoJC4wrqu9+y1ISNfEoseYSgkkVSI68ym sN4grjOb2XpHuDrnuPWBcI2QaEYbjHD1fFttCMI1MuINtaEIV1eS4DoM4qppAgvhIFwtNWGjQVzj PiKjQ1x9bRfhMoRrbEm5kglxrbmH2mTIA7tgZ3RLRwU7lfoLS98r2GlrF8cEG4eNl/vFvYKdbZ0I MMHOThUKSSQD4roLdk6I6xKssyBcd8E6K8J1F6yzIVyXYD0OMQDXXbAex0eA6y5Yj1MxwnUJ1nlA XJdgnSfENQXrwhDXJVgXgbguwboYxHUJ1uMki3hgCTY/XWSCgnVp6/sIEqzHZ5IDIUuwLuMv+8Wd gvX4NhhAyBKsqxBDIYFEFeK6BOtqENddsOoI10OwWhGuh2C1I1x3wepAuB6C1YlwPQRrDHHdBWsC cd0FawZxXYI1v4dr+SXAAPK3ZPQNCmVuZHN0cmVhbQ1lbmRvYmoNMjYgMCBvYmoNPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCA5ODc+PnN0cmVhbQ0KSInUVz2P2zgQ7fUrWB/gAckhhySw2OJw 16QLYCDFIYUkrwME2QDJ/y/ukRRlrb22Za+vOCy0lCnO4xvOJ4c/us/dL2WUxp9R1jnSUTn25IJR 42uZf+3IOkWifnQbYlEUXXnFm81vwymIF4AIyQdAPGkHkEDxRpA/t51WQknUpvzXykdHAjCd1dJe bV+xYvu7e+I+Ru5DwCjT2NdxxDPg2/CCZ3zefu/+3nbYLqpvHetAySpjInlvlLGevFXWCrFVv1+6 fcc8HUGkyEYlDFEZSfMCx5zfZwidj32J4ByTjTNCXfAGwXPW+cICwYJL3wOTkUsLIhZcREhcveXc Am8jTHNeyV/tKAVzWAHzKFv0xucv6uc7pmRjs+GLQLPkt2zIPnGfdnhgwAijJY0xTYb7fNjKmFQ8 Ku/lNQW5uleVeLuZnoHPi1lDPjIvxEY/iX2EDbxNC7sMC8hht4ZJIBObxAhPH3FYo6sePg4PIJXz huG2w5rTQXy7CPdakPI59B5AxiPajTToPq1g4yN+zyLDmBPAA5iIp5hS05FXEJGAAZtUkZ0+JsEI e06VRBG9xqEKVO+d8l3cnYYFBwTphMuwzHXcInDADdeVc9qSMVXE4igTHGYswi4/x6o6p8lMWUHM lDQucqoSc4Iv2D08a1jhAs5BH+t4KTv22TMfwMt7siLxBkdwXiiwm30ne+SwKEUfYYPkaZxpbIZh BRskdZ+cTCKnUXoHi2AoGG9vyBmlYk0Z9elcvriHSaQwp8de1xrSwyf7NU6dUOrDIch3DyCU0PSk 2V3eC1fRaa6Yyefu4mrFLBJzvK6xumCI+nDeKReMY/XuYJL7AZ5PbE0FE6tJZCafI+E0X9zBBL2I j8Hd4IOClkZ775eV4qSA3sEE/WCK9paqLuivjW7GechxcModS+OwImkKulTNfk4lJ9npDhIONjEH yP0aFolSOojkpmZXbZMry2lI3sEKOTNpcacheV4kaOIo/mxiuIMFEmA4BGRcE8MhLHNmOY/9A5jg boBeyN9Q0SR6Yk6ytNLQrPQARrhkLfriGK6dj7U5Fy8uEv8c3SLKDWIsrc3GoRRTxIKU74RDfUpC HKc2Ybo39q2rznN2mmvrYi3ks8zwvLGcYFRpndkLZnKyC7Wl2lh0ScQ1vt/+QIgI2bnBac1KtsWy XahMy41Wt5J5XORquMCnAeoNk39a6Jf13bWUW1GGhr6rc0PR7/nr9lMHt2CP9hUd1F81fN+Lx7zZ NDbYfSX+1iuWZtw06I0hh9sm8P97g4XKCm34xnoND5sNtf//GqpZ5fmr+leAAQCuVvt+DQplbmRz dHJlYW0NZW5kb2JqDTI3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODIwPj5z dHJlYW0NCkiJ3Fe7rtswDN3zFZkLWNDDtiggyNTpztmKDpKcDP3/DygpkZacpmnRpPemHQw9TPFx jkhJp7cdjMo5N+/1/vR5d3AxLy6m7CKMtQ8Lt4nnLvg5lAFsU5MFTzLH07fdICoHq3xwhhR/Qc0x uBhQU4goiasB26CpPQ4OxqCAhFBlDlV9ilU9jfOMXxaTx8FCcFrNh6oGPM7MVit/4AH4oBwNxu3g 6+ltNznl9Rz2RhmrvcRNyif8LLdk8Fz7HmOLunoeMdboGyblH7YL/s+eHY6Eg94PGwv+UjWsoRCK rGG1yONEqOs6LzIpifYKTYGFrdK60p+bx5s+RpIujTXPa2iurIs81/fFVu58QL92RTEah4nCPH2i 4AJU4fLRwrEL4HzH4Jmd4nFE3SmwnrmC1HjvANNbalZKFv7P6wW4dQ/RNsV1oMl3izvVaLfdCanf gks1DRxOEleWOkeuFrcE28ezx4PSxlvKHiDffpY9pBHBg9xlT0idaqjISyjECKGxbsGpuZsF8ast FOSfoBcwm6zxc0204spxmLXWN1JtMBPMyj6QWzfyajDjbECFX/JUMh2Msnr0rbj9XerEHOb92Ope sh0xnNeyjaOpaJS0mLptT2mDEAJMh4pLlsTQ7EZmii68IrbMjhKaVAUZFxlkafRgCzOFwvBCFBba 0IEQHKy0vWf2sekbFHbg01eilpwZa4TX9Bk8/uqxdqNERanJuTFE3pRS2o2TJGUuzLnQmIsvxNwL J9/TmdMdUyP3N0zSdQT01C4o6UWZuqalModHz+TNytyzmWL1z2bqTpVcK+LZrdeP3AFz6/4kazJU auTuVSqoATcXeAu7+d3YLfzMVgXnx8oPYfcI40+ll7wbxL1/hV9fdS2aLjdhNo3X5QOztp6EoCbj XKuhH3ovLa78yCpFlvjQKihcMegma8qFkaiOVmoq/jAjtNMs6P4RB3ceca9VMv8U6VpqgxqNge0h eaNkstgW/M2bgB5kmVvo3gQUdpJLYmLIJIUwbKf1xAcVueiLW/io+20DQZBKLaFjwZ6U41OmSLHy jmH/XzNc2UVruPvbQXrnUGTRxvD+uwADAK2q71MNCmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5NzQ+PnN0cmVhbQ0KSInUVrtuWzEM3f0V+gEL kqgHBRiZ2iVAN29Bh/uwhwJdsvT3S0rUfTi+hpO6gxPIti5F6vAcirpvB+i6DF0eaXTQIf3GQb7x ZQ/os0ZalBG6gQxDD11/psG/Q50Phubk3OM8H2K1p1SDFxs/h+rb9y9755Ph2Eg+mGgendHpUHd2 mLIGnviLiQ0YtTsIHsbg5Jv3PM37dqYm1XkaNB/GuldHY2QsSfLoKKiPFnU+MDJ6kivifqwZoZcs GwNjgfLz+LpDpyFaZdTx2469s+R3lpzHOi8R2GuccZRnZ+FEuGtrMfGal+Ov3V522FvtwfI2b3eL JgFZnEKOr0kPuSUu427BvItVoQ+S5aeQjAVqsmFIC90erlkJ/6+i5TntT52sSP8bQnVPI9RSlSqa 1wAQJ9EeIZSE/IJQXRCAQ02sCPKlNkkiBGOjjlcF659KsCoUaFidrgeeLAn9nwQrtOWa4Gi3xKK/ DbGGpxKLc26CrdvhQ8QyCjWi2pdPo4JN2qCyxJW1Jqjj751Tx3da9krWX0rbhOqPsuqHYgxbJKSW fJYhkvFzvuGWN1uh4jSRVTBFnem8l0/CRBca2JwVUJF4qKi0hUxAamWtKCe6XQzaHio03rrvJwMU w90eCU0pja5VgDx3DqxYlmUNkvoHlYuChpnce6Njcv7W6SA2sqkXtoeLO6fQ1qo9bL/Rda1+WxWh tDY551xd9T6ibCA6W6qerx5rCV5hA20dJd4SIJfXWUY7pbJuuHKCC744y98YLlU/VinYliZMEudU eItIF0DA+U6RRpCkogrF7QBBDY2htKLm+kmyWxJDS+B+Mhmwp93QCWB6zSCg6jjsCr9y+LB0JYII UQfwoa41suzrl/AjekI58XsC5lLIim5f73Gi7uqJpw4erNNha8FYaPl+3IHxGukge52CpTaTdHbU VJx6P+3OzUqiubS0GgOrBdnqlLfcvQ3ULjatQJ0OPlo9AM8bMoIQrlhl4+vWFvrCyvtGVNEkKkFl M3JXo9O2jiw5T75Tyi24ZHU9OB1ZnZnQi+jBILdzzsqSmQ45Oc5WupRSnPbOmrrScutg6NGCblq9 2Fq8G7DmvXKd2L5wdTNkummiX2By5DgXCDX8ZdRqbPXRjDPgam94rzlP1XHV2OBeGGsyoiDQy8KC 4kmBXCgWOB6RXeoK60uK84q1mZpt3LaC1yHeDE932g3/BBf+azO9VVA9bZozUCfbNHsDTNQNcN7S ipsLHBQ6t3YAx5XTzMy6x8yYqtmDdjfwBeCq3DQTc9u5e2LObiFTfwUYAMrTfPMNCmVuZHN0cmVh bQ1lbmRvYmoNMjkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1NTY+PnN0cmVh bQ0KSImkl02OFDEMRvd1iqyRsOKfJPYVRmLBFUDMAs0sYMP1cZJSI810IZpPvSnFnU+pp/il8nyY K7EU5iBuXOazuZN4+fnteD4slKpfllsVMruVmWY5yG5ln7PVGulZlq5/ZrNTt1t5hkuXOWOXxa+T 1an163VZlq/fistT4fJ9jf8qXMuncvzIkZo/LqY2/6nd1+Svr2v89SCxMhfwcnwk7YWGrMd8ysLL 8eXD8flNyuiZEiT6NqXfQtz+HtLmuI5KBoXkWnUwdSCk08wQciijJ9hhVIGQQZxcR4O4jrXzRoe4 +txAOgbENXsgMxziGqvNvEJcY3aUOiNcLZeQXF0QrhmSzatpJoCrcSYYQtV4drt6R6hmSEyqA6K6 LKtpMISqUEyqAVFVyoVEhXbr1mukjgas1xAa7yT9qF7zkAsoZOo12p3j4kG9Rl8nIabXGNSAkK3X cIjr1msExHXp1SpDXKdeLT9TEK5Lr1YV4rr0atUQrluvVhvCdevV6kC4pl4tv+4AqluvVgOhuvVq XCGqS6/GDFFdejVWiOrUq7FBu3Xp1Th1FKhejVNL7yT9oF6NBxkUMiZYv3NcPKZXy+uAQxmpVxOm CoQsvZoIxHXp1UQhrluvYhDXpVdpENetVxkQ161XcYTrqVcJhOupV60I16lXZYTqqVdVhOqp16kU IGTrNfsYobr1OnsQCFl6ze75f65N9jWp+x3P/7Nem+57Uo+La0H5LcAAUOVjVA0KZW5kc3RyZWFt DWVuZG9iag0zMCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ5Nz4+c3RyZWFt DQpIiaSXwarbMBBF9/4KrQsZZjQjaQSli0I/4IF/IAlvU5pF+/+Lzkjtpi305V2CY+PIB+vYPiYX 0l7IrXw7LhRbNbduH46X43uRwvGR0pSp1aKDyVTK/bH2P44cHMfkkW+BSBCEOkIg84BUcggye0CM GIBUMgtIowpBZlrtkFWlPJEBeVXy9OqQV8tR6gx5tRyhLpDXRhpevUJeG4USV8hrp5oQg7x2Gum1 Q15H7lcfkNdBI7065NUpGRPy6tTD62TEa53UwuuMIo0/IVGZ35SY8X/KyCF2Vhrt/fPZeZ1KE4BE XmcjQQgrr7OTQpDM6xzUAMjO63TI6s7rnJDVzKuxQF5XXo0r5HXl1VghryuvxgZ5XXk1bpDXzKvx gLyuvBo75HXl1XhCXldeTRjyuvJqIpDXzKuJQl5XXk0M8brzahJFmmheTeJK/xXpJ/NqMsgAiATB //GueDKvJpMcgkRerQoxAFl5tVohqyuvVhWyuvJaDfK681ob5HXntQ7I685rdcjrzms8P4jXlde4 8RGvO69xxyFed17jGiFed15DL+J15zXMIF5XXmNSiNed1zifZ71+Pg8uPQNwWd9cWvy36LZexja4 lfMRI84fx0e9uut1jFj3X+vrXt9jucVvt9dY7p/Or8eX8yg/BRgAy6gYNA0KZW5kc3RyZWFtDWVu ZG9iag0zMSAwIG9iag08PC9BbHRlcm5hdGUvRGV2aWNlUkdCL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMjU5Ny9OIDM+PnN0cmVhbQ0KaN6clndUVNcWh8+9d3qhzTDSGXqTLjCA9C4gHQRRGGYG GMoAwwxNbIioQEQREQFFkKCAAaOhSKyIYiEoqGAPSBBQYjCKqKhkRtZKfHl57+Xl98e939pn73P3 2XuftS4AJE8fLi8FlgIgmSfgB3o401eFR9Cx/QAGeIABpgAwWempvkHuwUAkLzcXerrICfyL3gwB SPy+ZejpT6eD/0/SrFS+AADIX8TmbE46S8T5Ik7KFKSK7TMipsYkihlGiZkvSlDEcmKOW+Sln30W 2VHM7GQeW8TinFPZyWwx94h4e4aQI2LER8QFGVxOpohvi1gzSZjMFfFbcWwyh5kOAIoktgs4rHgR m4iYxA8OdBHxcgBwpLgvOOYLFnCyBOJDuaSkZvO5cfECui5Lj25qbc2ge3IykzgCgaE/k5XI5LPp LinJqUxeNgCLZ/4sGXFt6aIiW5paW1oamhmZflGo/7r4NyXu7SK9CvjcM4jW94ftr/xS6gBgzIpq s+sPW8x+ADq2AiB3/w+b5iEAJEV9a7/xxXlo4nmJFwhSbYyNMzMzjbgclpG4oL/rfzr8DX3xPSPx dr+Xh+7KiWUKkwR0cd1YKUkpQj49PZXJ4tAN/zzE/zjwr/NYGsiJ5fA5PFFEqGjKuLw4Ubt5bK6A m8Kjc3n/qYn/MOxPWpxrkSj1nwA1yghI3aAC5Oc+gKIQARJ5UNz13/vmgw8F4psXpjqxOPefBf37 rnCJ+JHOjfsc5xIYTGcJ+RmLa+JrCdCAACQBFcgDFaABdIEhMANWwBY4AjewAviBYBAO1gIWiAfJ gA8yQS7YDApAEdgF9oJKUAPqQSNoASdABzgNLoDL4Dq4Ce6AB2AEjIPnYAa8AfMQBGEhMkSB5CFV SAsygMwgBmQPuUE+UCAUDkVDcRAPEkK50BaoCCqFKqFaqBH6FjoFXYCuQgPQPWgUmoJ+hd7DCEyC qbAyrA0bwwzYCfaGg+E1cBycBufA+fBOuAKug4/B7fAF+Dp8Bx6Bn8OzCECICA1RQwwRBuKC+CER SCzCRzYghUg5Uoe0IF1IL3ILGUGmkXcoDIqCoqMMUbYoT1QIioVKQ21AFaMqUUdR7age1C3UKGoG 9QlNRiuhDdA2aC/0KnQcOhNdgC5HN6Db0JfQd9Dj6DcYDIaG0cFYYTwx4ZgEzDpMMeYAphVzHjOA GcPMYrFYeawB1g7rh2ViBdgC7H7sMew57CB2HPsWR8Sp4sxw7rgIHA+XhyvHNeHO4gZxE7h5vBRe C2+D98Oz8dn4Enw9vgt/Az+OnydIE3QIdoRgQgJhM6GC0EK4RHhIeEUkEtWJ1sQAIpe4iVhBPE68 QhwlviPJkPRJLqRIkpC0k3SEdJ50j/SKTCZrkx3JEWQBeSe5kXyR/Jj8VoIiYSThJcGW2ChRJdEu MSjxQhIvqSXpJLlWMkeyXPKk5A3JaSm8lLaUixRTaoNUldQpqWGpWWmKtKm0n3SydLF0k/RV6UkZ rIy2jJsMWyZf5rDMRZkxCkLRoLhQWJQtlHrKJco4FUPVoXpRE6hF1G+o/dQZWRnZZbKhslmyVbJn ZEdoCE2b5kVLopXQTtCGaO+XKC9xWsJZsmNJy5LBJXNyinKOchy5QrlWuTty7+Xp8m7yifK75Tvk HymgFPQVAhQyFQ4qXFKYVqQq2iqyFAsVTyjeV4KV9JUCldYpHVbqU5pVVlH2UE5V3q98UXlahabi qJKgUqZyVmVKlaJqr8pVLVM9p/qMLkt3oifRK+g99Bk1JTVPNaFarVq/2ry6jnqIep56q/ojDYIG QyNWo0yjW2NGU1XTVzNXs1nzvhZei6EVr7VPq1drTltHO0x7m3aH9qSOnI6XTo5Os85DXbKug26a bp3ubT2MHkMvUe+A3k19WN9CP16/Sv+GAWxgacA1OGAwsBS91Hopb2nd0mFDkqGTYYZhs+GoEc3I xyjPqMPohbGmcYTxbuNe408mFiZJJvUmD0xlTFeY5pl2mf5qpm/GMqsyu21ONnc332jeaf5ymcEy zrKDy+5aUCx8LbZZdFt8tLSy5Fu2WE5ZaVpFW1VbDTOoDH9GMeOKNdra2Xqj9WnrdzaWNgKbEza/ 2BraJto22U4u11nOWV6/fMxO3Y5pV2s3Yk+3j7Y/ZD/ioObAdKhzeOKo4ch2bHCccNJzSnA65vTC 2cSZ79zmPOdi47Le5bwr4urhWuja7ybjFuJW6fbYXd09zr3ZfcbDwmOdx3lPtKe3527PYS9lL5ZX o9fMCqsV61f0eJO8g7wrvZ/46Pvwfbp8Yd8Vvnt8H67UWslb2eEH/Lz89vg98tfxT/P/PgAT4B9Q FfA00DQwN7A3iBIUFdQU9CbYObgk+EGIbogwpDtUMjQytDF0Lsw1rDRsZJXxqvWrrocrhHPDOyOw EaERDRGzq91W7109HmkRWRA5tEZnTdaaq2sV1iatPRMlGcWMOhmNjg6Lbor+wPRj1jFnY7xiqmNm WC6sfaznbEd2GXuKY8cp5UzE2sWWxk7G2cXtiZuKd4gvj5/munAruS8TPBNqEuYS/RKPJC4khSW1 JuOSo5NP8WR4ibyeFJWUrJSBVIPUgtSRNJu0vWkzfG9+QzqUvia9U0AV/Uz1CXWFW4WjGfYZVRlv M0MzT2ZJZ/Gy+rL1s3dkT+S453y9DrWOta47Vy13c+7oeqf1tRugDTEbujdqbMzfOL7JY9PRzYTN iZt/yDPJK817vSVsS1e+cv6m/LGtHlubCyQK+AXD22y31WxHbedu799hvmP/jk+F7MJrRSZF5UUf ilnF174y/ariq4WdsTv7SyxLDu7C7OLtGtrtsPtoqXRpTunYHt897WX0ssKy13uj9l4tX1Zes4+w T7hvpMKnonO/5v5d+z9UxlfeqXKuaq1Wqt5RPXeAfWDwoOPBlhrlmqKa94e4h+7WetS212nXlR/G HM44/LQ+tL73a8bXjQ0KDUUNH4/wjowcDTza02jV2Nik1FTSDDcLm6eORR67+Y3rN50thi21rbTW ouPguPD4s2+jvx064X2i+yTjZMt3Wt9Vt1HaCtuh9uz2mY74jpHO8M6BUytOdXfZdrV9b/T9kdNq p6vOyJ4pOUs4m3924VzOudnzqeenL8RdGOuO6n5wcdXF2z0BPf2XvC9duex++WKvU++5K3ZXTl+1 uXrqGuNax3XL6+19Fn1tP1j80NZv2d9+w+pG503rm10DywfODjoMXrjleuvyba/b1++svDMwFDJ0 dzhyeOQu++7kvaR7L+9n3J9/sOkh+mHhI6lH5Y+VHtf9qPdj64jlyJlR19G+J0FPHoyxxp7/lP7T h/H8p+Sn5ROqE42TZpOnp9ynbj5b/Wz8eerz+emCn6V/rn6h++K7Xxx/6ZtZNTP+kv9y4dfiV/Kv jrxe9rp71n/28ZvkN/NzhW/l3x59x3jX+z7s/cR85gfsh4qPeh+7Pnl/eriQvLDwmwADAPeE8/sN CmVuZHN0cmVhbQ1lbmRvYmoNMzIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0 OD4+c3RyZWFtDQpo3mpgGAWjYBSMglEwCkYBhcDx/v/7////W/H///8DIzgYmEZTwpAAAAEGAKb9 CuINCmVuZHN0cmVhbQ1lbmRvYmoNMzMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAyMjc0Mi9MZW5ndGgxIDE3MzQwOD4+c3RyZWFtDQpo3sx7a6xlyXXWWffec/b7vc999eve7p6e nn7M9HTPtGfaM+7xPHpe8Yyx44knDsRD/MKxk8FMHJM/GCwFgWXJFigJBmIrOBbKhKiDhGSkKCD+ JOIPP/ljFBD/IgT8RAJpqDq9au63v7326R6YELpVt/apXbtq1apV61VrzWQ2m2Wzr882Z1de/fhD Vz/+P779CdfyB6689nNffetg9p9nfzKbSe9+/+Bzb37+y//8xX/3uvv9o9ls4+c//6W//rmrZ679 y5k899HZ7Ng/+sJn3/jMv/nlzTOzjd8+7/pf/4JrkP/w0T+ezbbOut9nv/Dlt772x+du/TP3+4WZ 3PynX/rFn3tj49Wv3Z7Jp/+L+/27X37ja2/+5Oube+772PU/+IU3vvzZC7/9gf822/j+b7hv3nzz K599899+5ZE/nckz/93B8OmZzH5evj2bu75fd/9ns5/R+sezYvZ0LBvZYhZtzOONre/PNv7VF/7o f/1P9652ZfaxF595dfbU7OCd/zr78Ts/Xn1x9qmN2ff+5N/7tzOZ/Z/962YeT/1s6f5uz3bc353Z 7mrOxv1tZq37mzvYZrNyVrm/0cyvM5ml7/6FEd55ZzVm5r7QZ/x7e3bp8OC52wef/tzB7dlPfvLw 9s1jt+WN1z/77OXbculHs43nztz69AuXb2+4583nHrt8e9M9xNq45Z4T3zh3D3NtXLjnhW+M3EOm jbF7zn1j4h52tDF1z7u+MXMPvTbm7nnpGwv3sK+NpXs+5hsr91BqY+2eK9/YuIdGG1v33PrG7tJt 2W4evXy7vyT1v758e3lp5qvtS3LQnDlob5259YlPPn7s8PXLt3cuzbhp99LBLY+S2wdvuDH37vz6 /J1f+5cObu9evH3g5jjmHvcu/uid/+iej186mD0uj1++feLS4eXbJy/9vhx/7tnf3zjh/myedH+2 Trk/8wP3Z3Ho/kSn3Z/4jPuTnHV/0vvcn+yc+5Pf7/4U592f8gH3p7rg/tQX3Z/mkvvTXnZ/ugfd n/4h92d5xf3Zftj92bnq/uxec3/2HnF/9h91f45df87t4ikHygc8KI95UB73oNzwoHzQg/KEB+VJ D8qHPCg3PShPeVA+7EF52oPyjAflWQ/Kcx6UWx6U5z0oL3hQXvSgvORBedmD8hMelI94UF7xoLzq QfmoB+UvOFDunIfVOZE7p+MdPiGv/qlr+Mzq8eurctWVwpWF1pGWbVc+qM9zfb+t9VLbYlf2XMld yfS3r0tXan32Y17Tkuj3Mcy5pd+nWlf6Lvx+RMfLoT3MVWqN3+cK24bWc313TdsKncOv/RDGzbRf Aevx4z+q6/brua7wVtDXr+kYtJVab2idaL8b+n0N8z8M+A4w925/XnHlY9q+D31C8ZtauHLaPZ9x 5YJ7/mk/rqtv+TG0PODKRf0mAXhTXYdVNvV9RcWP96ArnSsnoF/MxcHwJOxLTvtSGu3cJ9ANlmO6 njB/ATgfFDf/GV1zSQVxEOiO6xRowapzHRvxVNxDfS/jljpuoJ1O939f6abT8/Ao1KniptT3ufat dd4Htb5u1H6eUzp/ZdQR7H8M+411oN1c4cC6BRxN1Xh2sU6BVu6l3oAzn8C5L4za9xdHJ+dcedqf NVd+ypX7XfmQK4+48sya+lGtnwS62QSeGAF+KuCFW3CGc6C7BsYooD0FnrlF5/HAlcu6j63yqCu6 tsD3/DwC+xjOfYCx0eLnOA0lAT5VKVyBLjeBx21q34rOxFznKWEvE11XAnTTwJmvoN8+8KyAiznx qE2l9xbOhz8P96vc8mPtKv0/qG3X9PmEjvOo8uFZ4KtatpQPX9F9/glXLrnykv6+4cpDrnzVlaf0 2dPS454m9PeD2vcZbfe0c15r/+6KwhFka6MweD4bufeP6ThP6Zg3Xbmu9PphVz6pfa7reE+4ck37 +fqy8mL//iM6lp/7AVcu+jrMBTzNz/t8kEPaliqvOaH7GfjqTGFe7bOOH9b7kuLD13N9d0OLh/0+ fX8D3j2j+Pa4+gDgKnyzVJl3wpUL2t+vc0fX+KIrz6rs/Lie41teFmj9kpZXFacfgm/Cu2e17TlX TsG7jyo85/XsP65zPK+/n1O5O1NabJSeH1W8bSveau0TZFAJ5zTQdDibW9onBnm1BXxlTu0o1yM4 MwstOXwXQR3kz0Lhy1W/a0HGRHDOd/XbTeUtqLOVWm/qOgNPrnW8Susg3+fAMzLQxeakw20Czwh4 bHS+gOtS17wB9TnATwO6RAtjsPzfBH5U0PnIYbyw9hhkVQv1lLyMaV9j4LcN6CobEyXs+x3FHur3 Utw3P+vqk7rvx2i8P/LnTel22z3/mv72etVSz9MtlTcPqd7pz+6+yqR1865oUM/tjq7pENZcK55a 935XYayBL2+CPDyp+PC8bEfhO6X1OW2/T59Rvp3XtgPt+4D+Pvsev1/AuZvBudsiGo7gbAccRLCn eMYLkLNMe3PQDTeVv2fwPoNzJ3CmfFnIbABfQWfqXXnr9SCQ95Hyg7A/idYNyIig5yakf2EdcBWe V7LezfWXlBcfutKrXPD0lHk8udIpz29cSZTnXlPZd+DKW6q7XVdefFNl9b6Od1Xlp5d5x1Rm31IZ cFzneExrv/ZP6PyfUBz0oJckgPvAVwN/2tPfe/A+tEda97Cvm/DtXHWZRHlHonw2An4e5MLCqB+C sxypXXkSbG2EFcdcAD28KzP0rG+5ugU63iI9LIK17Cm8C1pvDDAh/B7X/qwdqm7yQaXVFT7c75Ne xge69vupz5me0VJ5zn1w7iKwHRM9xw/7PQXdxtPEtu7vKcDHE56GXdvrOt99Wq6rrPd6wJ7C9jSc jW0do1c944zyxIL2Z2XLKV5D+1Xd8/dSFlwUjwvAweJeip6zC0RLkZ7DM2Fv9YydAvoOOv+6GnX0 IOM2iWbC+GddeRjm9zrWRcPngfAXDDfQ+t0Kj1vC3BdU33kUfFihFqU10YLrzIgnLMiPNjizbh48 R3M4N8G/xOviZzy/c+oTcB7RPpj4p28j2sfIWN91A39e//c4elz5xuJ9LtH7XJ5Qm+mS2hKXtVxT e8Q/1/dY4j8D+KbKveBq630oi/+HZablV1x5E3xXT7nyGJzb1W/fT9v985uo+4Zx7vae+3B//oa+ f19/W89rdGf8HfAzU371BPAu7Pde2++lPEnPG+BnCrCFMlM4EV6u/2/KU8DntrTtayq/D8Gemhvy xNeXtAQ94kBLkAm7XgcFugz69K6WPdUZQj/0l7IPPA5+DJQJqhfMVffq1e6JJkqpa2bdIAKcR2vK 2bu8D3zG69+l6sSF+kYL1Z1eUB7p2/ZUP39F/TSVltO6ltP6vtDxvA7/sj6/rHjbUT1jR/X9Z9Wn cg3qTufaV/3wnOoK21p2Jp55fQn4eF5RGfCi6iHn1Od0XG2Fh3W+pf4+1DkbbT+h9Y4+L/XbPYV5 X+nwBf1+R22UfZ3nefBVbAANv9vmx1ObO/jlvA7qb8+PqwyrFJeF7tlp1UXPgf8wzN0rvsMePaDw nlM4H1e4z2vbOR3rIwFeHe+qtp/V+UI5q/uI5STU2zr2gY4dvrtC853TtT2odPaQ4v5A4Tyj7VcU litB/1Y77wzAdz8VP/Yvu/I59eH9lNp8V3WN13S/HleaewhoY/HnVDrdqwOFcVvbtgPfUZo60Hpf 20L5uNIn780jWs4qzZ4Hulgqro9p2zEdY0/HbLWeadue+qYz7feg0tbfU7r7lo7zff39a0qzv6m/ z6uv9x/r77+v439P5/oerPNbykcCb9pS3vNhpc+n9DnTd48QbdzUtsvq572idaMl0OKHdJz79bsr Wi5pCf7uoAuWWgI+drSc0nJR92sX+gQ6D3xtqXAvFY8ngM+EUkIpoGD/k9oW+OF5XUfwp4S7gTNa f1jPYqp9T8H3pdJIo3gLsD+ruD6vcF3S9od13IeA7iqguyXwyuPAq88DDVZwjnstgZ4D/gNe9/T7 h5VPHAKMb3hfp9LQMS3bCgfi7gaUi1CWE2VP+7aKt109L63STgd3hmcVTzXcz4Q7jlL3+wG1RQ6V xs7rc3jv9/OLOsZjyp+i/8/KvfKzbE15r7xx/j7z2qXylUzPSNCDan0uwOaL/xxlwvtRcvC1ZsDH dnSdnZ75HM5e4PvIewK+Gv1dK38OuMr1u1LHrrQth7ECjjul/8va97iOlepYsX6f6Jk41L0I/uJt rVuFJ+xZq9/VsKfIQzuFJ3yb6NyH2h70wFrHCes61PMd67engc/E74Ge7qVYtnoBuMlgv3JYf6N9 W513Tj6MAr7Jgf/OFbdhn1DmLnTOOeC+1H7h2wLaA60cgqwsFF818LkGaHKhfRItYb/mAGsNc3Uw j2/fBHgLeI4AtkTnSWBv9rQ+r9/sAC0+oDR2RcdYAk2GNbRaFjrHzp8xDawrQW7ugn7TaftS6wbo v9Lfu/p7V+FraB9bOO8tFD/OX9O1XVQ5e0z79vr7UHH4AdjvXusnQBcKbcF22QN4wx43xF9qpakb +twC3S+BbvZgPY1hR+WK70+pDrKE/cqBF7ZyFJvQkZ5SET02wGcb+B73pIb+PexZA/Z4DvsV+E4G a4lhLTk9h/XhWc6BPiuYB+VyOHu7cN5TwAfLcZwrMt7lME4GZwf74PiJ8T7U4fxGIFuyif4pnHse uzD6c0nhm8Toh20lrCsl3OM3W/S7oHkQTwxLTHNb7RWNHdH+FfDdHNoKg74K0uEiwmXQixKtizW6 Xmo8RwY+E4K/NvomtOaCcJlRnQB+U8BJQviJ4ZuIfmN7BnDx/kYwzxbRIeo1KXxf0h7FMG4McOD5 RXk2hXOEhfGGcjC6C61FBJNFozGNxbhLjD3GfcnX0MumYTfwOaiIjzBsjIPEsEMSPRPJxFqsPalh zJjexRMwLGCNC2NdqbEHc4PW5hOwZaA3IZ62DLzxGhfAFxbG2lKoF9QH++I7fE7g3C0M+yroFTXI 9G2QtSnI+Ax09Ap0/lL7xCojt4EvBhkcAd+oVQep5MgHwj6XDuYqSM/05YTqPuH5JMjFYzDWvv4+ pbrLKZDbwbeBc6KttA12Gr73338E5kCcoKyvQf/BsoDnMHcJv1F3qCYK2oaB51SgG+UwTtA7EsMW yQHWk6qD7CtujqlejrjyfV4DHQtlV8BTD+sJOkQJsFSgU6bQFn43YH800FZQv8LQ2YJtVsNeLWGf WC8rgPYqoIcK9AyUJzWtF3XdCMbqSQ/MyBZDHSQGHKSwthLk5ZzkUOh3DHCYKfw5yeoScB4DDHuA rxzGQfm+RzZ+DmtPYR3Blx2BXZqCnpKCnYB3XygvW9Lj0O8b6Dqm/UD+2JLNjr6EFuyMFmikgLqS oa8G6SIiPtVDv7DXx5UXhbuD4M/clqP7tdAefMlLOfJ/nIBvwjgn9JttGd6NHVe4llrvanune9HD 3uO5DOvvlRcibSAvQrr9tL6/oPVJsCGfAR6SAj9G2wjxVht8qITzznpEacCFuj/7LSJqz+E8oY5Z grzqAV8BP7sEZwdnoAO8ZvA90kTYkxRkXZDFO3A+fN8H4GwFf0i4S2jl6L4D5VG4rwnn8IT2Cf7s 0PcAbP3A5+/TtpO0lj3Y145g2oO+S7LFS3iu6Xz0cPZ25MhX0oNMPQffop0e9hrv4gqYO+A8+DBy +t0Dvmr6JuzjEmgf/TY9tLe0x0uYC31SPdFTBc856FH4voFxeoK7B/7RA15D2ae+pZ59POPoL8Fv w7zb2n+bdL8e4G3omwbe4z4i/paAUy6MVz6DHcBRG3vJeKqNs9fQfIgv3I+O8I8+s9qAbwkykt81 oGPgtwXR1RROatBjEPedsd4czj7vQUe4R/rNjLk7ohPcyyXZCKG9I7qrgb/0IOv5HLQETwfr3Jah vxR5Ct6PYFtl7APTPq+xM9ZeEB7bCfyE9lTGfn4eG32MiIcW2mtaF+KwA5newvvS2O9Khn7TGORT AjYa6t6o7+Sky3SkoydAkwXYB3tgY+0Z7XtyFLcTyi79Pg59t+F5j8bZpm+X8Iz02sH7baNv4C34 e2nsTUe6YUK2KPYvAW+oc7T0DfrFO7JDCjj7BcjVAmCIQF4nxO8asqUaGd6F5NAv6CINyNka1pnL 8F6iAn29keE9ZE22ekZ2LNq2Eaw5AZrMyDaqCE603yrSHUug8QzgnPKZ56QHlqSP5mSDhvF7wE9G NngJ36AfNJy/iuBifzjiG3N0EGa8X+0JVxm0BTygTo53GBaO2J+QAA/OaN0ZvUNawrtq9vUHWzwj uw/9jz3sN+9NCnUqQ59RTvY22qCVDP2RuE6cv4S1oJ2Nc6LtjbKjJD2qAllRA14y4NcV8SzUKQIf CPZUAft6inCbkHzKZOinyMH27YindMSfwjkL9nRKdFgSLDmsE222lvhUuLMt6czgXVNFe4p3IxXx h0bGd8+FwXdb2A8rrovv8PAOEX02CFNF+C0mcJiRrLbkAPqSErH9YhXZ6CwvEDfZBF7Q94b0inZ1 A7w1gd/M9wuyldH3h7ya7XbkDbj+hORkJcP7pZLoMiedpYZ9xzE7gK2mdyjTcgNXCeExJRopZBhr URH/2JHxvXdF/InlR0H6VkLyr5DxvQ7yyDB/RO9zA+cl8bfEkKnIY4Jv9ALonQ3ZIo1M3/tj/ENG PDHk+gT9YAl6DvpV0YcQbNcdGd5dNMB3Ar8roS/GSe0Az96Gb4P+yHpNiN/akaHff8ewzTHea5vw 3pN8RPpAPb0Gvb6G9QSYkaZ60AcbY8/xfgL9mngHERNPrGQYD1KBfMP4j6XBz0qg1xL2BP1QNeyl H+eQaL0BXCSkgwT7Jga48U6sA1orie+VdBaZf+Zk1xWEu8w4w4izUsZ3Wv79AyTT98CWaiZs2xCf jrYuwo843ad9C/wv6BdLwgWPifYH3yUVpLcE//GS7Fi8s+qgrYQ9OUb2bw5jZmQbIR0UchQzlRFN 4x1FBXwE4zNQluJ5Q/nKeniwH9Hm4LGWQCPob8Rv+PzhGWC9ZAnnqjLg5N8lnSvW+3kvKoPWM6Jz 1MlSWMeuDH08lQx9VuH5PjnykVRylGMS4v/DvcwOycBDwkdj6BIlnWP0Q/mxTgO9B194gBnhLAy6 RZ8g29Yl6XY96AYx2dEYh1iTXh5oPQb8F6TX5DL0P1UE8w7xfqYptvlRBhcyjGG1dMVCxveXuYxj zJg/5jQe2g6WnhzR7xTs85joNJFxPE4k4/ioAsYIsRCVDOOW0dZHedYTPllv3pGhH3MJNH9GaZzv zHHsRsdoSGfpgM81IMcLkOcV8cKOeEhD35YkxzIZ+olK0K8DTzht8Ba0wYPOeBbOTQww1DK8F8Zz FOa7QHReU40+ycI4IxXZ/OjjrGnsjGwDtOVrsutYv+f58a4Z/VEh5iaSoZ/Bv3+Z7KsQ04b+fYzL jmCfeuNc9jKMpeH4y6mYUI7dQ99LJEPfXWhrgD6WAHtBMhh1shTkbwt6G9puDZzfmPhUROtDOySl NSIPy4jnZaQDoj6TwTwJwFOQXoW+H6QBnCvc/6WEU8wfQJsa40ixP9ptKHen9rQmuNGPhXTWEHzb MoydyAx4Ap1jzH0GdlgkR/5fvG+PCFbMHWkBDvSXL2DNKZ1b1LcbGcf1xWRT5qT34NlPZRiLijSQ 0pnvAFa0odEH2MJ3jRzlI+Q0Dxfk4RjLUtI+1XQ+ErLR0K+ZEK7DeV4YMpXjtBMZ+tpaGfpcGhn6 ZtGOirV/RLiIxI4LbWm9Kb1DHSyVcSxvRfuAvBbbwvcd4AP9uryXpQxz7ZAP1fA95+ShDhMDz8ex OZYvAt7Ykn3K96ioh5YkR3oZxjyVBp/fIj6S0HkIZ7yX4X1RQXOyvo38+qaMY0JRX2pIj0plnC9R GDKFfVUsj3OxY4sqQ8dsZBjHh+vEuyO210ux/bwYV1bJMFckBT2d8z4yOjusL5cyjiUt6dwXMr7H QtnK8VsV2atBLpY0N9pqLcnMgmiUY+qRz3bEowrAeUW6nIVP9Oc0MsxzaMh+jmXo64pJFsSGrRsT bnMYC2VOSbTHOSqNweNw7kKGcdEIYww4R7zy3RX7SitDhy1kfFeVkdxMST4i/nA85KUxncOY7C+O P8e1lTKM/2SbzMJHarRj/5hkGMNUkH7Oc9ZA45wbEtNYVm6gZZOmdB5Qv45lGDcQG3OyjIhp7ZgL EpP9FZNOwDnDsQzvWBnHGeEokaHPtpJxrhTmeFr5RiijWffCO2fr/jUB+RCRnW/dUWeGjlAY31i5 drGhN7BfL+RpBp4WztI+8IiU5FpFZ6QiPskxAQW1897mxO8Rx5WM8wl7oEnk6R3oCWxHhzX4+Nkd wkXwz2V0dhqw7TAHYMeQQSgTG5LjnYzvYAsZ3+WxvpAafDCWoR/Cr+2q/vb+xvtk6IPoYO967YM+ +ODnQf863qGH2CL/2/vBQ5xS0M3CvX4uR/FFnQzj3LHfkvTrcM+FsbZLginw9iXImiCblrBehHdH jvxWoRQwBradhG+XBEMm43hcvG/vZBgDivMF2mhh7hzwF3Dd0vxLouUG1ox3HdswZybDeEWMbexo jkbG91lLGcZ65NC3kGFuSUv4bGE96KNeyjCvCv27HY1ZwVlD2/Qs0EeAG+/6MAfrgHRV9L3syfC+ dwHyoyS+G3yjsQx9h7Ec3T8iH8e74Zr4JN/HJWtsPLQX0efGfLGUcWwR3kF2ZCNmYucS4b1jZsjA lHRFtkeZn3OOrGXDFmB7ot8DfU+JYeMmQJ8J2SIVyCTLH5GR/GN/bAs0nBp2ZE46Aud/Y84u++2b u+AnIR0LfY21QRcxjTe1Zm7LDfuN408C/AsZ+jlyknNIT9kafLOeV8rYhxFyvhCG0oA9vOsNnS8x YMlk2m+COuCU36USO26PcdgQ7oIeG+LAkgk6DDov0tUW7V8rw3xZjpHJZNrfM5ejODTWw1PaY4xL zSd0xmJCv7P2CWFg/6tFl2G+BdF4QrxoHb3HMvaBVQZPY5i3DNpA+tqeWCvmbrHNksL8Ea01gnXy WUkMWxdpLfjoNgG/S4IvNvZnk2yQkvqWMvTBFjRGJUc54Xx3ktC5zmToI85l6AeKZXivgecxJrmR 0dkK+7opYx835rUjnSO9JDLMjeN9R1shAZpkHjMHeYtnaw68Y5POcix2vFtJv7dg3AWdixx4TiTj +F0+L4HesKCdjPQ15de3eGtLeLbWVxmwpTL2C0Ww1gzwFhM+E1pzTWNa+EBegLwyoudWhv6A5QR/ 6WR494R+4ors3VzG96gY85PRmec7M5TXeAfeyDBmNZVhbAzHFO+QDEffAuf65jK+R8pJ/2W/Wyb2 ndOUbyKRYYwWy5ua+FEs47v2VsZ5tfgd5rJUoPuz3tIZsIb4mTnRaUp7k8owL3Mb6KIBe4bjlazi x3uF9F+MLcN4+5r2G+0ujqFuCRaMt8T4Cv6O7zIQfvSpoA8C18uw8drR5sO9agzcYN5uZdA66so1 4aKjudAPjrFiDBvCiHflmFvO8WgN9S+pHeOrUhnGdxQGLjD+iuEqaOyS1ol7lsJ+Y+xDSfYGxphh 3gF+m8s4dh39oOyvawhWtM1rWndOe4j3ZR19h744jE9Afsh3SAXhCfkwx4xjzldKuj/y+lqGfjw8 U7WMcxDwHgrzOpAvd7RmvANHeDsZxjgi7jjWOpVxLktB60vIBi1pD3PimdmETMFv2Z+J996WzzMn Wu9knKOJMSa1DO+xOuOMlGTbMC6su8bM4HkF6b418Z5Cxv5ulFWljHM+kDaXgN+c4J7Kc8H94/el sU7rzhjXZNEm5uJgfBzOh3yllfHdNsMVdAkLHmuNpYzvzTEOmnOB8N6TcwuteTBOx8qxKg2a5XjJ Avaa6aqdWEtEvMu6g53CS07nBf056C9K1+ybFb+aTpxLtAs5j2id3ovvWtI9c9C7U8KrFTuRT/AV zi8tyBbqQd9siFfUsL9BtnckE3cM3aSTYd4IytKG+F1n6FlLmptpmuNSWZ9EHaiXYfxfbcAa4O9p zILmzo0xMK+hMOjMuqerDF7Cd2EV2QGdDOO7M+L3KE8rGcZatXJ0L1dO6N6ZUTdky3EcCd5vsr8Z ccH5D+jDT2V4Z4h2K/o6KjqrS5mOu8gM26UweBjmeJbE7wK+l0RPrQzj+6/JOFYplB1aO+cOo/2c AM17OrxBthTGUuM9LOc3W75G5iP4bluGMZmpDP2oqQxjvNEv7/s/D7hKZByzhDwyN+Qqx2zyXT3S USnjvAOOCWAb3/LDZzKO8Q54tmKpeR3WfQnrGpkMY4XRP16ALpDQOBy/UMo43yKRca4a4y+m79IJ fSaSoe8i+LsikhU9yaBwB8x45LVM5Vuz/OJcabRfGzqbVt52YdijxRrdrpzoi3mQOZ2xkmRxItM5 wxnpVukavS037NxiQo/kXMNywqa4W8kN3Z7z/6byogvgg3wPm5B9kct0PnoKtm+guwW8X0zQTELf lHdZ58IouD8LmC+luRcwZ23wpkKG/nq+D61kHPMSyzCXvVzDQwL/bYBnIO8IZ2IhY59H8CXmgIec dJLTQFuntb+vfR7T/XInxuC0yokSZG+wqT0POCFH8R8etnMyzIWuAbYMdE7fdw90gQ7GRH0RecqB HMXINKCbcg5jDfY4+oN6mAfz/ELZhjFL0g8LsvtTgyeVho1dTNjSuWHvso8in7BvSmPMlHhQYfBj pDeLX2RreDXyoWSibzZhG1n5ftl75Fl495aIHT+eGGtJJ3h1SrwmN+y/7C7fpYadiHGZCdl9Gb3D WNGc9DTk8+eV1i7KUWxPyBvH3O0e5MgOyO2e5EsH3+ZwLvC8hjPRUlsNvAtz4PD+qpqQT3w2SkPu c64fn6+caDjgD99dBfgLONMZnfdCjuKkeioN9NkjfCC/QF63C7ynhu876N9PlAKel/BNDvoP86h1 pZtoY5hxzuIexmb50xO9cNk1+rRAnxas1ngYx5oT7db0uwd66cnWq0EPwPi/ms5yRHSFd7QN2apo y0Vgj2GsN8asL2SYq7UAPcKPOyfbOtytL6At3FtnsB68Mw5z4Ph4b479IxnnhcWgX2GcQ0bjxATb HN7HMr5rD7nYCzi7izUllmGe4ELGMfQ8RphzC9aG68bnuaEnzgE+1J0WoHfGRh2DPhZD/02FYwl4 iGltuEcxfIN3x5grGYNtdkPGeSAcH50a9irf39ZkK1Yy9pkmZCNgrEQtdhykZYejjYgyEPd0S8Z3 4BybsiSbP5exLwTvejDOw+uuJ1XP3ZFhvhrq5+gPqGV4V8555hizkpEegnuEOkpCNJjROeF4l/A7 Il6VEM1g3iLH/WGfXIbxXRxnhjGL2MZrRbvHyjO14nIWE+8tOKbm5hiYBPSKEB+9VDneyDDOIsRs BzkR4sfDd43+3oa19TLMLQ8+1Y70nV3SeYKciXW8ToY+zVKG98E12Cq1DH1LeK+J9+412YElyPVG hvfcFdmpqK+hrYB+vYx0U7S5atDd0G7lPMqK7DReD8YEoB+pEvser6YxS8M24xgRvncL9NoTjKWh l1YwXkv6bGPYWJgvi/f1uC7M7c2JBoJ93NF86PeuDZutlvEdW0410gDfuXNcQgU6Ft8NlHD+MReF 4z4wVq+AsRuxfXZ8R8p3MzntO9vRuN94j5HJ+H6O70AKQx7i+U5lHANeGzZzRXwyl3E+ZkZ7ksj4 fjkjuwfzHTIZ393j/Xug724N767pHd+PYvwy+8rnOvacvsXzk5Csmss41i3IoznMk0L/DJ5T6DfX b+fwfQ66a4hNnZP+XJH9ncgwZnUuw5hPjOPoQT4gjSZi+2wzsWM8mKcmMvbJck4I3sGjny/oZpin vCfjuwKGwfJfWvEfVq4G50ZbdyQL4AmJ2PfoWFe0zmxC32L85QYM/N7Cu5VHyjmo+cQ8yQSMlsxE uDgHopgYfynjex68a8V8UeQR3V3Wjfo8379hbjb7qay7nqCLT927pcb3qUFbtYxzSRBf1t1hRXjm 2JbgG8a75ljG/nfUgzmviWPucU/Rt5fIMFeQc0QwT53zE0riQRGtu5dhzHZKcHJONtJkLNOxSnxH Zd17Yo7voZZ90NPQFxT0reDXCd+0tGc16MxBr6hATpUT/CXoyrEh5zB2BO+vO9KjWxnmweRk/2Ke cCvjO3X2aWJcRmPwM4x3asEma2Tspy5lHB/Vkf1fgW4dk/6FcemYV9nQOWdawHjlpQxzvYsJG86K DbByC2LSVVoD75h7WMNzbvAoPNchDrwmndXia7xejGvEc14SXynonBwHugt0e9GwK3LSS9HeR501 hjMe5HZCPNjfA5yS8X1RRrI/m5CpKemgrYGXxHguxc7HKEgHbYAOI6CxhubNDf2TYxw4R6KYkAGc axu+PybDe2mmz4zWWBhtU/knVu5iQWcqIV0GY4R7Q5dLZehXzg3ZmBpnC/PUMpLXhSErEXeRsSeM W85pi8SOuwn3s3vK78P96UNydH8S+EonR7mg6+yxQxi/k6EPoQd5Xsn4jq8hezO8i2R8f8n2fGno swnhlN+xzrtOX0zX8LSc9LlcxrmfeE7QD3wM9iKGdSyBRy3lyIfFOTnhrIY9akD+NTK89w9nfRv6 5jRmB/Ohb6sAemjJpm9lmNeFukQDZ6c2xs3BLmtl6PPBOPmK9JYG1hd0t/BND+PjOtlnltHYHekd eL+GPqqWaLalmnOFchn6zVqaF/0pHK+Kd2gtyE/MaUc/UEdyuKB9zmlejB9u4Ds8iw3ZL40M7+3R D4Z725Ne0JCMboiWUM9jOsA970gvRh8X4qSXoX+vkXHuB+e3YGw0yvvO0LMrQ+/jvCTUWTpjPZZv NKd9wrOEORiNDGOyOE4Z+yCvKEjnZl8G731LfLqTYTx+R2eJ5yrABsDY6ILmSAFHvYGDhmi3k2Ee ZSPjmLiaeBjmr/UyjBFG+xzzWtHHXpMOlxl7iGczN74J+mQJMPL5QDjYV8xxhqVxtjsZ+9NrwhPG e3cyjMdivzPnpPG+ZIYsR56AeiXam7EM41ly+C4z7An0QeP5wlho9OujbcDxKphTwHYi55A1xPsb 4hcF2aDs545lmB/TG2tDfzvHCzeEA87LYDpFHGH8eyPj2Bv2kRRkk1aGDoR2G8ZWlQRXbYyL8oH5 HdMB50FbOlgpR34XtG1TGfqn/fMuvNuTcVzfJumLiaHXcZ0SLNiGPAHvsS29Enkq+9BiGft4Wzny Y7Nt09P+4nlHGk2BPmIZ+0IKse/nS2PvrRwnC08cw5wZsobxXMrQ58a5AYmBx4TssIzOBMcFJjRv YdhgKfFw9IHyvQ3no3I7nxuOecB4vYLkLcZX5Ibtzf5AzjupZRgrgrmgGdngGfFB6x4sm7Bbebya 7EeMwUS9ie/d0FbmdbLdzPNa+VeIj9yAm+UF6orsU+N7qEzGOa2pjOPD0BfHfdF+DGf/qgxzpNlX 2UzsQwp6Xkn0Hu7W8O6OcYo0w7FibNPyfWNCcq+gs8oxXAXVIZ4GfXoxtXNc11yOYrHw7iCSYex/ GCOnvduSYfxbTvuUEcxbcnSHinFfGEOMsWOcW4rxgei7wRi9sA6MW8M4okiGvsfYmJvnwnjCLXqX w3NMe473sDXJcL7TqQx+hm1o96bEozDuupNh7pN1x9TD75p4ZwK6TyrjuMyljGMTYzgbeEZxL7eU 1jZpLahHc0xLabxvZJxLlcs4h8HKHZqK08G+mJuH9kVp2KtW3Hwh4/ihimxg9pkzvCXRPsaDYKyG lTNs5UBZdzqMl9RYczEB3xQ+WFdA2Zcb9jvviRUjsyvj2A8rRsaKua/WfIP4t3yfnGte0h5a+Sup jPMD+BxP5XRwjh/6nisDzwWNz+vnfB1e+zqayA3brDToqSRdFelpKjeH2wo6E6VM5+wUhnyzcn5Y NrPtWBo6REnPBfGSTIb+q2CbBR6Pd0WYR5CAPoM20gJ4LeoG+9DvAtEw3yVZPviS7KxUpmMWwh12 gGEJNmsLcwYfSUL2cUFy7ZgM45jRB4G+SvQtYN9O7Hzm1Ogf5C7eMe8CzHugg2LcXirjvKWFDPPE GXcd2Rvs+0D9OKbvUJdBP0q2xh7JAFcc54B3i8hH7hZXjPpxIePY5J74WGbYX6z7s61rxfzwfvGZ tugygb0oJsa04mHYJuXflp2byDgGkO9f2RZN76FkZPOlE+OlE2tNSAdOZJzDkk3Mmxn7y3EYuWHj 5RN7yXZ5KfY9avi9LetjG/hONFvTlso4bjsl3c+iqXKNTpGTnLRitlivK8XO58wNPbUwaHVKnnE8 rSVnp/JIp3JdCwNunnvKT1gYOl5MPI7lT0Pwp6QjLIgmLJkc2nrSn1rSvVBfx5h8zsnMjf4VvWO9 EX3LNelVuYz9/aWhe/MdSC52rqjVhvZ/auhqPE9u6PwV6axcUJfNxPaD85kpDf2Jcw0sXzzGjlYT OiOfP24P38UTZywVOx6bfaAYj58QHVp5IdkEPZ2TOzlVAT87tCfhPhxzZjAGH/0sqCeGWFj0B3Fc QUY0HL7bkeGdE+dblYZMKon3o181FjuObCnDeAb0C20CfInYdzQJ0SfbSqkha1sZ3ttsAk5iGefX FISjwuDz5Zpzmq85v5hPUhFvKY3vp8bODfrOjXFyGce1lhPyh3/zXVJp2A+4D+wPxf4LGeY7sS84 MvTBjGDDnGNL1+ISyzieK554n9/le45xa4hXxRNjrIPPKtYYkYzj0ZI1+g/exyTGmjjPM14Dc0Fj LCbgrmScRzwVb405HPEaXCQyvhPMaS2pIS/Wjcd7adV3gwf3CfOj1+1jSnzaGtPqW1C/fILup9aW 0V6nZLfiOYwnYOQY0UjGeSe8PvTfz9fo6Rl9Z9F1LOM7Mit2Or3LGeIY2OQe9js2zklM616SvY9z oR89WUNPnHuMtWXPxHSW0on3mWH7871fIsPcCtxrK249N+bh/GOOJY1kHDeMOE7FjuHFvgtj33Jq j2Xsq0hBxljx9olBf2gjx0TvoX9DOn6I7d1RvS3kSe+qTbIrR7nS4Z0vx/V3iMcINY7Ta70Lc+xr HcYJ/Xr4LpQQ19jBHOGbFsYO37fwbLV1NM8S3m0TLD28D995XH7CmKMn2BoYsycYcb49mGMH8L4E PAZYA/4sOLehfw/jNfAOcYbwthMwWPjpYW29scZdwiXGHW/DnKGtgnaMI0ecb9NedrSvu2B/tDK8 D0N9sJnQV3PDNggyrDF0EI49mIpZ4TxvjM1dgr4ebKWAa4yjQFueY3LxDqSVse8+9A10gf5VjFXt ZBjTWRE+MHcnJx0IcYt46ibsm4p4JurVgdY5zoZ9OJnYuRCZYcOyHof2PccjVqQvljIdO4LzoT1e rNEfp/ysd/OlJjL2QVl3ZVM+Ji5WDGkhdpwZ+vBCHNlSxvdvVo5RSfrgknQ29Mvi2emghL0IMFqx PTnZ+ahPhbOBMWIJrTcGGkaf61zGcXXIMzBmEHUlzFuJQJe09N+7/Y5If0vIpgp3bnM48xh/EdHv ENeQyjA+JIU+Celx3Ceh9YU4EZ43pd8J9F0Y7bEBa0RlMbGm6C7F+o5jZzCXKKL9Dd82Ms5nCj4g 9g9vQz/khehLQVm0L7a/kumO6bSVsa8nIR2bc/MSgqEw9F2OWytk6ONCWk/EjnPD+JzwHdNZWMu+ DP1WEdnc6MdjGVzDNxjDhLI9IpmFNmEsw1jgUo7igDnPK5dxrATfoxVG+7q7iqm7DIw951wWXDfH ZtSGnlDKOP6W4zFqGcc98P2IFfux7l6mpHOAMmJJumRn/D4lw1yOVMb32ZjLjDpdY9iIhYzzMdlH gjmbC+CZyLsSopmKbLeIbOmFwfsK6JfCO9SBYoMPxzLO/41oLQHGhYzjnRGOjGRDTDZwSrw/1n2L ZHznzrAvCO7UWMvCeLeQYawdw888ZC52fOMCYGR5Mwe5zHvFsnOL8IK+KZRDc4Al0B/OGeJAY7Fj MjkPO56QxRHMw/MHfC3XyENLZvIZwfwq9B1g/EUH9sZigs8F/t2TnpbB2a3kyCeJvtkWvu3hPcdY ZyQbrXwIpKUC9qid0Jk7GfvmOKYikWHuTER6ZiLDe00rtiKc0SBPF4Z8wdgVtkE3AUcpnUP02VVg m6UyzGELezUnu8PPc1xtyBbgwxjbpaEfIG+swDZvZehrq4EPhj3DfJ6UzkBBZ75U+dCSPMTYyoj0 m4zoPzN4Ugr2YER6C+ccBD8Ex/PHEzZdQbZnRfpcQTwXZWsC9N+QjVnJMD+kNGyK0jiDbH/EYsfN BZ/lLuxlT2eiMgrmO1ek/6K+kMl0/NZU4bi4dbZ0buhHxT0Wjt/CONqKeBnm+1VwBjDmlmOXef/5 fn8hY//Jap9mX59Fvuh5qMnODL4ePLMY01IbegHz1hrmL0n/2ZGjfIiV7AN43nTlk64cunJd+cRl V77iyu8p7Twtd2IK9qD263/clY+5ctOVJ/T3k1R8+1915cuuHOj3fq5HdJzzrjzqyjVXHtNvXnDl ksLzeR3Dv3tex3hUv3tSa//uivb35X5d50OuPOzKB1z5XZCXL7kyc+U1XZuf75YrT2n9s64848pz rvySK59y5UVXvqp89llXPgTf/GV9/qR+84zC+bQ+v6C4DN/vOdxXrjzqSuZK6cqDWteudFB8W6r9 j7vSuBJrKbQkrmxqv7mOGWnfLe3rfy90vFLbEm2/oO8SHSPWPhuu7Onzlhbfp9d5Ku27od8vtW1P 4dlVGCqF089VKv5OK13OFC9+/TcU9l7n9HW7gukV1/Gxd2GPFE/R7DccPI+48V9x9Sur9ju0/chq zlCHtR0jnBU6nocxXz37/ne+CWc2nr3lnt925bfcmv6J6/s7rt8PXf0dV77lYPw9B8sPHJw33Zjf dP3+gXv+u679D13t2/+FG+83XR9ff9/h6Luu/nU3tn/3Ww6nf+jw910H46+7+jtujNfct3/TzfWa +/1Ftx6/9i+6b37FvfsbK5jzd2v/7qurPahm1x08j73zn9zvYvX8B6t1VLO/5XDq+/vyuoP9q+67 n3bffX015qZby5ZrW7jnjdkvOfifcL+fcDA84d590bUd4T5yeMhm33AweVhvrM7SK6s9etu9+9QK T35dkYM/Wj2/vdpff+5Oz550cD65wum+e1+t9uqRFc5L156v3vlvvuHWGcpbinervO2K34vv6F6E 8pob4yVXftEV//xDxfXbbk4qnoesnn/gxsHi1/dNt2ffdM8e71Z5e4X3fFRedvO97OD28/+Mq7+x wt2dfaDi5j/j6ljPyFHxe+H3y9d+rX6+UPt1/21X/85q3Hyy9jT6D90YP3Rj/B1Xf0fp/G61x4en qan6B6sz6XG2uTr7b7l9/JJb619c0cAdvP8VV551NPSUG/Omqz09vu3qz7nv/Bn5kqMpf048rfri z8szjgZ9fdOdEV9/3H3j69dW9Wz2qpvrB6tzXwEMreIsmn1bcfe24hrrX13Vnr62VmfQn4M7dbKq f8G9++5qfflk7c+sPze+/ozW/5t9c4Gyqyrz/D73cd6P+zj3nnurUlU3dZOqpCqpVFKpqgQIBFJ5 JyQQECIMEEIgUUhCVYVHYysotA8EHQXkIQq2jzZIAQ4Z1FFpFFtdSxwzLtdqx9FebT9oXazp1rFx pu1Zmf/e5zu3Tl0qoj2202vNR/jdvc8++/ntvb/97X12vVHVqTRvndLuH7WepXwzas7JMSb7N5n3 cu61u3LsPE7jPen7J6gv5Li5taWzA/hjnXCbytsUj6pnR3Ecz0dRX8lxcCvSHID7ENy3qDwspJP6 TZ8zDidUGxdgpSqi77LwG+Iq0QN9FiCfWf4Y8niE0tyhyjPEvfC/W8WPuU25PrAwPnwgyywojqHe f6zKz6IfZZ9kVf2uQL7vUjrBRrwAeZrIWxd3Iuw98D+A8JuAbM+dynWUTKR7G57fjng3o6ybVVst Vb9J5P2HSHsd/I+m0hxXssmp/I+TnOSz7AfJ1eSOob4blC7zMUdt5GeIrcSZtIZsU2NE6pKMepau 7PfDyhVKj8pn6HiyXaSdsIPsnm30fAbZMDeRnSH9fSk7Sz4PUdwNFL6abKLV9G5Y6SA5xu5Auw6i Xm9V8zQDmRpkO62g/NeRLTdGtsu5ZNOsobAhssVGKJ50l8v+ofc7KS9Z9lIwKF3MsZwsC7IzlPu4 slE3w59R6+eHUL+HMVbPwfyQ+vputY7Ice5Dz2XxriTuQ/ijymZfkWrvNpLHtpS9dwYh676Y3p+R ereB5L2W7MJEVkma5Jtvlxb/fdMGamdEbdxK9sv5YE/KDmySu43YRTI9O5UmeTdBYRtpX5y82031 SWzitVTGZnqW8Tcp2+oAZHMDZHKTGo+BktslGFf3Q6b3Kx2ZwRiP14+7EFfO/0eUbZLFnJHrppxv rtItt6lx7kLGHtwsdJV8dqCDfNhXJt7LuZFBfEPN9Xh+59Tcit083LxKO/s+Lm/Wjdeku/H8h/BP Ic/DqOdh6JUbMAYOwv0A6YiHYDfeBuK5mEd9pQ1mio9iHLwVdXwI6d5COubdqg7SfspDJ0m7q4Rn OV5Kqi6PKf1kiPep+HEdpN6+RdmOco3Pt1yp++6jef8+8BjKuVPlEa85j5EtK9v5HqRJ3HOVfHIq nazDW5QcS8ij2Eor5Sx1TOLGsjKh6+I19x6yNRM3ye8BMI16vVvJxlb257uQZ+IeVzrXmceN9wKx q7XcpD7H4X5YrcnxWtTuJmvT7cp+Ey33YrAeDIDHwG7QAIXYkH8Nt2Ot2EV7jzta9qBQOvB26AC5 Z5i1uavqeS/8N6h65slGtBHTxxoU0NztwHNx3vIItec+rvbA6j6OGs87aP8g/dMqbykT9Te8Yr8a k/E+I9b7pqqzdJP6X4FxegWetyksch3gA5v8RosxZYc7WDN9ilumONZvlf7jZOtJ7lGyc2m+xfby cdVWOR6t1LoVnzvcr+ou+1/D2JTjx6L265RGV2Phj5CnnPfvxbh8UI1NgThZGqfq3JTmRVbNg9m1 Mic+ocZThVDn5YiXQ1k55GcoOX8Udf8I2vMu1OMy1OFBdebRr+rwMXAv4u2D+3aaV+9VcyADe0XD fNEwD7OwF+RzsgfNn8bVU/sHXdkNt6szkCtIFy+kM4C+tjOhMun85Ox8c+pMokFrWSetxcm+fwGl XZM6u7qY8r1YrWEHlJwsknM8nmKZ5ik8fr5MxcuTm6W4SXhsVx9ovWt389BnBdpzuy33OMZbokeO K31otNk28fNm9N/mVv0M+EsgfvdAK1xvjbnZPBI3T+0woD/lnKtIPSrPtUifOhQn3zZGs622XUZl pNt7XLXBUPbfvcq1lXuvWusXoY0LyeY4k+zcvJQ5nrvl2k37d9kny8gv4ywSH4z3Y9I+ID1kpM5H HBpHPdA76gwxdVYmv31XqX97WmcNt2OnHOuRvVTeYmKM1vAJOvORdTuP+idD+k7mEZL90IR/mM4l 9FSd5BguK7nOhq9qOyeayyEVpz1cb4fkqLfJ4HWh+TPQSnNHvOen+dWkNho0d3roTEincOt13By5 SZiZ5Nfu0nniylQfSdtpMNWe+drlpcLS783fgPZ8/VTZA3SmN5o6y0tcTa6h5Gpt7XTITdcxyb/a NhbU90kaN4mrk3zHKKy9Xe3+XOo53xYnmzoXTPfDvPJvS2u09aMxT/vG5sR/ND5vkefXmIsXAL3t G/zvAuN3zFm0F1pGe4TlxAjtM5Zrc//u69dh/ivU79fdr3o9cr8D9N8jicn3B/JbBq0ZkgvANrKN 7ORZxkv5jypb9HhMks/rvac425I4aX9Sn3SatvS/0+f5/KejLU4sn/gsYhvNvW2ESPHbhr8+cdnp erTX9YIUguSb9KeY4z7Rlva3f75YnQkmxOEfo/V7Yep7SX6e9cQQG/FOMmtHNIhkTZDfYcu0BhRS 58Q1xY3xnjQVL0h9V5k9X74x3hcm5xOt8uMznEqyVyLbtjbPOpVer9bTmZifsg0MFR5jnJbNv+bd bJvTf9ebfL/tT31r3UI6sp++AXbRecq5qW+uvdSWXnqfvk+xnfzbtdm/WWlos3foJ+isZCTllqms DrIP+8hWSP4GIjqNP7Y930fEe4nk7OZ8WgO2kh3SR2dJC2ivsJLKq9DzQiqzSOFd2uzf2XRps3+v U6c6d9A43ELpIzoH6qByNtP+z8TeylDnwg+T+0RrD7hAntmm4kr/5XK/S2tY+93SXrJF+1LngknZ yd9xJH20lOrbR/VcS/VeQmF9lNfOpL6U3yoKX0TlJSyifkzTnXKrlHeD8k7SDbeV10dtG6JxtoJk 36B6Nil8mOoynNjftM9rpurX34bM+2ZwLZ3NXUJ7vlXUxhHqr7U05lakxob+/4gy9VWD6pj8zVby d1llGlMNcju0uff799D4bO+b1cSi1Lf8ZFxUSNadFNZJedS11N+Lkb6tS+jMuYv6bQHppZDs9YD0 akg2sQzrpr2TLFd+O+6i53vUvu158DPE/zbi/lx9d/XECYT9KXgZuvjbePdzVU9190X8Od6/DD4E /0nsXX+O/H6FMr6FtH8DXoS+/DF4UXQqXoVd+6vZ+zriFdTxVfAK8pD8EDr6ZSDL/wXe/6PKP1C8 iPx+DF5GHj9r/X1Z8jdHXQnIr5Cgzb13nr73Mhv/r+P7K6hXEZRQdoB2+UrWfw67/FfQDV+A/4dK LjXIqBt+dbcF7wP4kztZVdWmH6B+r0Je31W6r674ItbF/4C0X0Gav8W7T2Hd/C7SvoB80RbxZYT9 DdL+Z7h/j/Z/F+4r4FXU65dwpTx+Bv67CnMh3wD1Tu4aBSrPv1V9ZCO+I34K/6+Q37db8neQnyN+ gjxk+i/C/0MV5om/Qj1lH3wSY+UE2ibL+Ymqv6vKOzH3PhHyipA2Rtbrx8TPkV+CLOsXkJ3kZfV9 0RP/BD6n6ukhnayfJ76j6iO/17mQsava/7zql4L4rxjPP8Q++EXI52dKl6l7X0hbQLiUQ4Q0nvg6 2vwT8CrK+iX66hW19x9Q7XweaZ9Xc/P1bHondccp/TcHw6T30vezF6buWi2keeqm7q0lf59WTt15 8ylucuYViCPqHoJIXLKF59wpojsurftENOcT1xNPIZ+n8PwU5sVTGLvxc7kN+Q11tWS++0TiOewz vw5Zfhn98BW4/xF8DPn9GfL6GvybIFf5PUKO1ccxhv8eYV9TfR8gbocaA19BfHl34yPIS757TmTQ vxmMc019S/+kmgvLyA4L6exHKL0kz5YeRt7yW/TD6F/p7lDnYvIMtALrKhTrT/0vef4Jf0X8A+J+ FDyCuI/AfRj9vA/uB5DPG1C+fPcO1aasuAu8DXV4uypf6sib5J0g1e4bkf5GsRi45F8q3gtXfvee xBy8De4t6rupjjBdfQs8SuelH8e7j6jvPY54DOU9BFd+C3k/+BT87wEfpbzkWd6H1HtHfALcC94J Hk5xE+Qo38l87gOfRNvfSnneiTbLej1K5T6izqId8Wm6E/FhKkO+uwu8T903qYg/QXx5P+F98H9I ydeB/HRxphrv7feJhvi+EN8X4vtCfF+I7wvxfSG+L8T3hfi+EN8X4vtCfF+I7wvxfSG+L8T3hfi+ EN8X4vtCfF+I7wvxfSG+L8T3hfi+EN8X4vtCfF+I7wv9f3xfSH7TPon4n4Z+PAmdKM/dHlJnnrb4 JtJ/GnmeVHeDPPE98ALivQTugP9xINN+DzyDfezXQOJ+HvtGyfeRPsZTPI98v6XyjvkqyvqmKs+C K+vikuuosC+BH0AHfxN5fh/uX+FZvvsB6pRwEvl/jziJeT0fP8C6kvCCysdFuK/a9VWEPYPn71N7 f0D3AV6A/xnI/XHIUtZTlv1VhD8D9/uqXjYwEa+AfKx57ws9gPAX1HfFPORh4dkXX0a+D6lwH+UZ 4kWsqc8h/5dUnQpoh6yPAzk6qg9kHZ9RdzmCVj+cFB1wO5DWVTKb7R8f+fiIb6M8KWNfIe9iyG/d L6l7WIGS2QnsyT+PtewlvHse7fg8yeTT1FdS3t9DPT+F/j2BPv8S3CcR9gKVk8gvlnGB5F9QcpPf LU+qerh4ttVdh5NKvrZy74D7uGqXC5mESn4vqDETivtR1guQ3Ulq+wnk+Tzy+ybyvU/dm/DmvS90 UsXj+0J8X4jvC/0G94XAMeIocRHZLxfRWG7tGX/NZ4Tk/evF+5emfwp8huaQS/PNITs4bT8n4Tvn ieumbGzJ1eBucJDskG30DXcTcR6dg59B78ZJfulvkuNkq51JcS+lsjfR8zGyk6pUB5PcQsqurZJ+ 8ekbZ0KV4pXp3LyH/N1U/5D0RWKTlsgtUv86pPfclD5aksrTJ5u0SjZXSHkkdm5I9e2h5xq1JUzV uU46JYnvU95Rqt19lE+yTzCpLun9Qz+lL9KzRzrYTD2HJO+0nu5L+f8LsTfVx4K+dyeu7POfgQvB G6mfkvH/dZLnA+Qm4+Df8rz4v50bW8h+30bupbQ+bKJ+T9wikewdzqb8+yndMLGMSO4dJGd3Po2V evKdMTXOz6OxVUvFSfYkyR503jviKRu8Q/sN7oin5k4y9pZQW8o0z82ULMaojb0Ub5zW0GKqnhO0 T5ugOkxQ+FbKYyOVO07zKtkPVFJ72AWpubEktTcIUvurkEj2GYmcExnWKf1mmo8LU3XcB66k+dpJ VKkeaTmdkWIwReU01CluiWRUIz1YSsn00tS+Zz2NheQ+zE5qq0P7oAGqd6I730Tzcg3tERNdlNwh T/RZosdKKT2a6JOkbfPpibWkB86hc+rkrlAaGX4juIH0SnLfJPneuY7m0DIaL9dRmjXUFw2Kv4Ti LqF3wxR/jOqa3MlZmdJxHo1FOcffQPNkizb7TXUT9esGGmdSVpfR2LuJZDKhzd67WU/6bxP1y0ZK 26C8N1D+rC9Pry8vojlxEfXXQRo/F1HfJu4iItn37yCSObW2jS1Eck6T6IkBIvlOuoK4kMZ0f0on ryEW095lIY2B3pReSZ839bXZG2nS5zjLKWwxtWmExmWDxuUAzY0hGmMbqY4LKGwT+RdSPisobbsO fSPNoytT7ioKl3XYTekTGSb1W0Uk7UvmVdIHK4kkfhKefItK3i8lLk+tP4n89xOL6XkF+ZM7D8mZ 2QZqT3LHMNFdiex6Un3WT2VspPcjVP5uiruH3EPa7F3CRKdMUN77UuvSIvKPkzyuoP5hPfpvRI+K 7Z8T6y+4FL/FCy79nHbqrqfFPZ3K1e7Z2/m0uGvv9s9pYs+lT2tPa/fu/ezoajH42VUr8bNiCD/L BvGzdAl++hbjp9mLn0YPfroWiMEviG7RJRZsbG68auILYqFoiB7yLxJN0Uv+ftEnFpN/APveJeRf LpaJQfIPixViiPwjYpVYSf4xMSpWK/9nd+9CqTt34GfbVvxs3oSfiQ34OXc9fs5eh58zz8DPmnFZ sbVijRinTM7CNvQM8p8jzhbryH+eOFesJ/9GMSE2kH+L2Cw2kX+72Ca2kv98sVPsIP8FYrfYpfwQ 9jX49wj+ZdH9oyOVa8avGR8XIiN8hE2JlxBuiPzT3VAf52gjxrjRHPfrC5p7mqX6I6vkf7LDrFOv iE3iz7Dnj2NGfaOrxyO9EkZnrlrlDA2FK84+e4UzOD4+KFQHG4g/kYo/1j9erYRG/9jo6JAjU7x/ 0KEkKn4eu/7bsOcvtmoSGZHRHzXHjf7x/vGof2TLUntw0F6aCTOJ51BHqVotdYyMxO6wzCc49Xfo zzr29hWZz4lsPpfPGAPiRCaXzWWyA8iwCRnUbduOap3Vqqqr2CNuFfshB0+VfSIDbyYYGB+pNI3J yf0FmS+CZL5ZyldoWS3OV8bNqrhBFNWriKuf+p/iD8R/wguS1Xhk6G+y35T5kv4lKXcL3CyeQVub FGN89fjYyKqo2qWFht7s7e8bHTN0PETVkVXjY+u01f19TSv0KxU/jH+Xm55vWrbpeaa9f1no++Gy cFA6g7tMb1HU9E3pLPJM2b5OkcNwkOeecd1zmXxG1T1v6EbGGRiTlR+FWFaNb9DcqNvyzU86T97l mkjroRVT4mnRm8imVCgXMtpAUmP0qa7+ySzGxvFvVFa219ArxYJXqnpe4AemaeS3X5sJ6oWiqVum 7kz3FDzPK9dKxYJlmWa5aJc6S6XQNXXdqanx4AFZ7pgIVZ1rHfUOWedno2pNq84tvhq7Um7rtJEK SU3WY1AbTbyySkYx8MpVz7UN0zZc369XfD+yDNsz8Z8tq2aaum0ZpvaHUeB5bhjahpY13LDq47+y aXh4ZxYh3KJpBp6pG2ZJ9WdW3IK62qh1j6zteiQzNUfztByqvN6WAjczVianyXECSSlxjxsjO6JK JdqwYfnypw+Xly0Lt2xNtX1GDM4ZjyptswJZV1pNl03uH6nONli1sjk2Ol5/wwYto3lB6PklvxJ6 XjbKoIGu4Vi66Vp6JtTyM+VsuZTNup7f2VvyPa+jjBY5HXVLt/RsLrsz1hGamETbGtCBNJNJ8s2k n8fG59RHDt10HzT9mlsqu16k65alF3K65ZXcoOBWSkFp0HBcw0R5lmG8t+a6Xujrul5YYqCmQXdP wQ1KI77hlGsuQjrQVUo+RYjjKOSjJ/LJwxvLB7qrWbxyuDq8daZ6v7yJ6iL+NOq/UKyEOp3bAjl2 KqnBA402Nj7aN08T9Lbnou9WKhggecMyXd+r1z3fRTMMZzHGh2G5On7lqMJbhFuG94Dvel616GLi ZUyMK0gbU9k18Wg4hW7DDHzT0M0gMI0dGFoBRqKFX9neX9cHScVHdKqcfro+KDnlklep+uWy40Wa lTMto5DLO4XALizRbdMwXN1xDOuDJcerrB6t+nA8K2cUBvW8Yxc6l+p2PUQNnULdMWSdYn14TK0d NOalSsxpBo15OWb1nJHLxbqxEuvHKDpW3SR1pH3qf0MHnoDeT+t7e7+9d6+993L7wgttodpuYIW9 VbxdlVNSMVNZB62soaYnJ99eWF6Q48NE3sfa8u4fh6JE7k/YlyP3OG9b/YXi07ARFrbp4VirYYjP UWgRCrKL0Aau5xquVTLystMwoWyvWr21oyjHb1G9qTqmbzq+oet2eEUtLksTj6OsM7Fgz9uH/a0h iNDxEUOfO6mpN6PXdO85Wl/T7qj0NMJK0fHsfD7jBq7pVLyCa2TLvpbNZKy8Xyx1dpYjLJILynq4 sCes7zADrIxmPq85unVHRyWsLGwWnXxeL5hOsVHxHGernc3k/e6eYqkcDTSrpYJeCuv9y8ygx0XK fHbUku3Kqq8MT6N37NZsxHzGbIQtETX7m7AnRrIT4UStcl5lrGN19sknV69+70bIP6vm8Qcxj0vo gSViWbyulktlqefX+8WeUk8Zb7rDJaGuDazHWC0u6Ozq71uSjdDvbcp/UBuvtORlzHqLu0PPdaTi g1hqu6Ix6H7owTUjASanFcxAyRccaDvDLVUD98FRw/QcU9+yzrTkAhvbMnL+Pap0yJyei5p9c/pm DNOQpp9fL3d3F0taLeO4xZJfKnnl0PFrWrnY6C7X76yXi6UFFcf1S4sXlzzH7+gtF8v1QSnPovoL mxm5VotFsUQc21ESsS3Xdh2EYxl5DlomLFcyKUnMkUDxrG5otnLPWdGisltGDWYq1WUDUfnBu9xy 76KS39Kjd6IsR3THJWWdbCz7ZIbZJoShtWaZpHj4kgsuuHxqpjxaXleO5ROqvyidwTrYQflYcT6z MzWVRzOcunzLlmimvKa8M04v7Ss5hhaLBfFav6C+QNkn9c6OTowkWvNPJ/ZxabpUmjSBClGlu7tc 0Gqa45TLXqnsRUXHyXStLurFjkZYvzOqlAsyyCv1LSpjnLuF8qXFYlgfUHUpocYfmJXJevS9NCEN TBVH02Wl5EIeLzYjo8puqjRL0YUR/p/ZsuWJ3bvjNkmbYCwlWytrt8sW7/RZ5Tg6Mtq0ljsO/p+p vq1afVucj63+gmFGlMkOElpZ2Z3PloplaQeNzK4BySi8OvK9zk6vGNlmUDCsmdvw7BX7uqDlLT9p 4/2qbh7l6ag8kRkUDyatIZt0ftfExs4zomjm/PMnrrskWj+3r/MtOzgf28HKqEzsmzDCCHmwTGV9 BvHdWHtjlbBl4107pwqMlOlpNPtRYs/QUE80VBiKZu6664l34L90f1it9Ia05C2D0queR+L67gj/ z7zznU+8853x+pQRn8CYCkTPadbM9iUyqGHgVGrx75qgWAzKZfX7jlqlUhsYUL8TQXHRomIQ/8py ClQ/V0TJfLVdm+arb/sewmm+VivR3PlaaaZmbGE3jEzPq62NotW+1E3+DAzUuudtePA8KKqiUkZo 16lfol3yO/biVruwPZq7TvS1moqFL27tIasaVN1Wm7bHzaxAp5bL8IRGp9dR6Gk17bBqbV9H2Q9t eOL1EpoHelB+V+8QC+O2eoEXt9UtesUCwtHWZ+u1Di2touUyMKetlYtgkHqG119ftDqKzrQN6GTn Kc+LIs/I7Ny27cEzDQMGkan2XZq4F/04fjrrE+2N/712IiBK8m+07PtdPQU/Mq1yxTRyeS/qMg3H D3oXlrzIdKIKzH9p6ZSg8Kz7fL/gl2G5odcsrHW2lzWcIPSDklcvmY4N40zP5/OGmc/qVhDvd9Vf Hs/AjXUg3qR1IMITHQiNYbx7bbR2pvzgg4J0jqbGUCXWf9KSgqJ3K8qSes4ybanp47mebAhnp30p spxKxbEiv9DbW/BnbvEtx7H8W26t+oWCr/a3OfTdR9BvemLlyGlnNHO10dHaROmpu+9+Mq5HBnxR jeVUPBW132hmqp0Lqws7q31hsxnOvA3/PXn33Um6rLgP6UzSJ1JZZpLpDV0ymqmtXFlbJzXJlTt2 kB459RPsur/RkpfIGtlMcWB+6y48Z2jonG8Uni9QeUh7biptXtM1SgvVoGQdp5U6NXMOEn/jLwrP x2PYQvobYR0ugl0ZqdSLjVEjk4eg+xb3rx4ZzbQWGrn/bvaNzm4N5L/WHiuKt72zq1DRdip1jI1a LojKtmXZJdfy8tjQ+nouU92s54uWKe0mu+gY2lW249jeOY6eswKs676F1SGbzWL/i6ZXM1ouk8nl dSOfdYysqren9gAz0DcLW1q7oMl6o6FpxVZppo8O1HTzQpgfXqEA+98K+21LGhIGamrPbCl4he4u /Pj7bAu7Lex9nSrWjVjOLn6PYff0m9s9biGo1lwnU9UMHTsf18HuyDSrmudhq126uBC4TkHuc9xK 6GCvjT0Gtqcdc9vXmJ0Fcj9R0HKyc/I5PfAL8SxojqZt5fa92RVh6JQrbkmePrhLTdsxbNjD+H/m Cb/glhZ0F7yiZtpR1TFgJldcU8k33iceE3XRK5qy/M92G8agOGF0mV2ZYGC919Pd0Kq63PDZ0OID LT30GhmMycMQWRG36FcrgX8B1gEfdmrO8qJaUFhiGpm1puG9oegHflfFxq7RKllegD0W9oxYowV9 lMmKS6D3ItEXS0PucS2YA1IaKaUSDDzr2G5sCcTHCiMkl0rcR8t6e8NazbKLng/NkM9NFa66qrAA Ay4fGhCqLMc89SO0/JgYERvExXP6euxMrdJnJENrPmUr50WfcufZNfe/Zt/sOMWCa/vY3WMAlm0n n8mXCiU7D/2/uMdBhcxsLh84jTy2TqYlZ4CV9YxsLqeHnQYmt30l5o1dzucst+TYeewuM3lNwzxQ PYyuRhY5TB3TtpygmodAdT2vOwj+d5kMskaLoVmQkaAzvRuV3q239C4M3ooacc+6jheLlZRBs3W+ gp1sWAwrtg0JWo7l6OHMrqpt+7u3OzIgPIPs+MXiydl9a2p/HE/a2JoO8d+THY2jGIOn/hL90KfS lGdrJNOU4xq1TD6ZNO6A0Vi2JeSCZSDwIGA9h/ymPVSrbOjo4OQMr83ey8+197xwZb1vqNIXhTPX r+zbti7qE609wmKkzbbSZpO0svIzT5Acn8T46RON2GaWS4I8J+zq7O7U5ezFAob5I2evNNVjLdIu 1pQXsyr0imU7n/WigmWHOd30LTPU87ZjWtmj8o1esWx3zy40EIv05vPRy1itW316bLZPZV1c27OV BH0v0NKVaCuzJI9kQqhs2w6yR7HPN509Oy1s4oOi1BEO8r8Zef/mNqVTDKpVaXDJ3wHoQ8t1LYxU 92JpaHV0qN8l8kDIsTBwQqmMoAsxDiZRzqyul42QUo9aNaciX6PrFyKTckUp+4pdtmwMz1jX994P W63QBe1X2GPZvu870PVRNdb1c8vsj3tRng5bmFELjC5D9uJ6P5eFieR2dizo7urJJevk6KxCTjU/ PrP2lBJGZ1aLHjSf1MVYEmzTu7SA2tw/gtBuBFcj6GI38ALbjPfbWXGpknPcejkpZevHRirJBJRi GF/XmTMCz8mFYV4/hkXGcdceXWDqtHZp4k3IY7Tdbuw7vd1YbbcbRwPLrdYcO9SyesHW89lcxcMi btpuve4iNGf4RT0HZVSCZrWuslxIx8hKjQMNk8d6noNasl3XDqycnIuICgslm7fs1of3S8TDszpe bu5CLdJiHS93VGGmkpE6vjX15eSPRVyhA2/Iohb29qIWPja1oWXXag/3F87V8zmjrGOSbCgIsqNv hBagUwW5r5U2pu8GsDNV7zpY2bAdwFTNttuaSf8GmIKWZwdhiF22ZU1tdzElg8JaTBXLis8UsmqO TLXbmtnqokXV4XBq797JWK/kwMcQb15bM1eJatVaVOktd3SUpy7Cf5OXXRan09XZ7xTmYjp/qcOa 41bU2Rn1LY26u6OlU0uWjK8dGFgb24t/IW7C6l6ak0ZPKdDxjKzfKqw5rp/DuoM1ZHrv3lsC3cyV sVwYyV48K96Msq3WSaS08k08x/am+gYy3vQvndi6b2L9VHFXobhLphsQm7GuTra+B40j2sWDk4Pq U5mQf2/FMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzD MAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzD MAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzDMAzD MAzDMAzDMAzzWiZOwzT4OHglRmsAhGtHwfuFyCA4cxZ4VojsVeBpIXJ4zn0H/LMQ+T8VQr8I3Ed8 EfyDEAbKNO4UwrwcPCiEtR58Rggb4TbysR8TwlkGUL6DNG4B7ABvAfL5F0J4SOt9Swh/C0BYcA1A OkQVhSXgKuI+4jsxRbeNF4UorQFoZ3kRQFtCtLOCulRQfuVPhKgizyraVUV+VcghQpkR2lpD/Jp0 UZ862tGRA9cDlNeBunUiXSfidt7OMAzDMAzDMAzDMAzDMAzDMAzDMAzDMMy/Ch9mGIZhGIZhGIZh GIZhGIZhGIZhGIZhGIZhGIZhGIZhGIZhGIZhGIb5/SB8MSM0Ef93BMT+rCjiKfbn4L+d/Dr8/578 hjhPfAwxRc5CSEn8NfkzyPNV8mdFr5Yjfw7+PvLr8G+BX4NfiB9pbyK/Ie7MxOFFhN+U+Rb5DXF7 9rwlG5Y2Vq5dO97YcOTorZOHrjs43bjw0P4jB/F8w9F9h29dtuOiiaHGuddf34hf7ps80Jg8MHVg 8qYD1zSOHb7mwGRj+uCBxvWH9h84PHWgse+6yQMHbth3eLpx86Hpg40Lbz1y9aHG1hv2XXfoFuQ4 NLR1w6bN2ycGd+5ZvnvzkemDh/a/fsCsr3FoqrEPpV93aGr6wCTKn57cdw1Km3xz48i1qho7D+2f PDJ15NppFDZ59MjkvulDRw4Pia1ig9gkNovtYkIMip1ij7hQHBDXiWPierFPTM7zfrnYjecjYloc FIfE/t9JjCWIsVQ0xEqxFv/G4duAt0fFrajBIdTmIGI2UDMZ9wie4vc3IMY+cRixlokd4iLkPoQ3 56Lm18NNp5QtOaDCDogpMCluwu81CDmG9NeokIaqjYx1vSrnAN5Mqed9yEemPIASZXkyx5sRZ1rV 5EKUf0RcjecGWnqDin1I3EJ1HMK/+VrcwO+Uyjuu1XXqeVrVJK7ZNHz7VN1uUPV/M8KOiGtT9dyp cppE6JR6M01lTkIuR1TqacQ4ghoPkYRn5Xuh6pVdYotKswt57Ybkzhd7Z2V53bLh7w1/evh/DH9j +MjwT4dfHv7n4e8Of3z4R8OfG35q+POnzIMDp6zhw5dd8uaXht98yT8NHxieGL521+VXF4YvGX4r uHI4c2r5qRHRODU8/Ozwc8NfHX7q995qaI5dP9X+DmlES9c0pIrRVuBJUyEZkV2cv2fyyuCsfxSd cZRnRq5elrin/vLUD8Up8d/wWEdcFeH/CDAAtX+H6Q0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2Jq DTw8L0NvbnRlbnRzIDIgMCBSL0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL01lZGlhQm94WzAgMCA1 OTUuMjIgODQyXS9QYXJlbnQgMTYgMCBSL1Jlc291cmNlcyAxMiAwIFIvUm90YXRlIDkwL1R5cGUv UGFnZT4+DWVuZG9iag0yIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTQ2NT4+ c3RyZWFtDQpo3uxbTY/kuJG956/QeYCUxW8SKNTBuw0DBnxYbAF7GPggKauMHXgMjOfgv78RZFCk JCozq6Kmu3ech+ysTopUMCL4GHyM+MOf/lt0f/v19MeX0x9eXkQnupe309DZPtjuHP8dOmF6qTvl XG/VYLqXn+GBv8HnZcZ//nV6UuM4qDGM8K3h49To4BM8/K3g+zX9f5zUeIHnZvh7mtXobeozw/c0 pd/iczDGBH1n+G0O8ME+b88vP52+gJD/8avt5l+7PvhBha53Rgbd9cZqJ7pf53+cpFG9kp0KondB dFr0Rnba9cJ2/3w9vZ16rz1ID716JzshfG8MTFv3upPSYtf4GOhjowUYA0ay8IgpSvgR5w4yhkua i4e5BpDXh+ezVjr0Hh6Y3tIk5zFNCic5w2RnkyaIE8cJT2N6Nv6NE1fY9vzXlz+fYBraSw9ivPzn SfbeBYXqh8E9vtXTx6GWlO2N0iY9O9BjEykzjn1JcnidlIvvx//j7/jblGUiWeYLGUynv/2FvvMY byQrGS0/6x0+gyKdne8HAfo+y94OSqNkd6kOfSX6gCV/sElN8f/qt1BloHl5lFvIXkoN7tELObha n2Olz/jyca+DKBwJ3VoAztG7aCKtxYBmxW/3tl9k2RZxbEfvzjLpyq74HXA+Q3cuU3miUUi9RU2p N6yvOHKe4ZQ9Ny9PuZ5lVPdcpIkmGkg7ixR7rcyNZ3fPbMcf1ho4xR8NvQTdMbrdyw84yfBW+cVG kLgU8hLAycd+UvdKDKpb6eo7WkEk1P0ryJKZfxPwyQA0fffgA7uAAQy/V3VR1Cz2a7WmskfnTWog FRtSLzli/Ezlu7WawpSEiP3GrI571D4RWLkaqEw/GLEGqjtAIyKqLLbIYBUnRUsw0E48vVYwMBPw jUVJUf+mCTbbRazTb+N8tBbb6sS3bQEie01WcXxOkKePxTMWM1zKqmgBzERmxeemS8EM/D5FgaKt CshkAaJQr0XgxSeuIdiBb2xRLj5zBcziRKHPRRTTeHo/gmPeRHeo7YvZT3nWa6HLRFuCLzv0vIf6 RZOVNbMga6c/UNS9XjKkySb/a49Vy3lqCmqz5sqEdwIPyfkjsFb7ZY0McTyZFFVPICtt0mXXr4U8 8pb5RrSxcmW9dvsM+Kd547K7l7g9ksa/c/uF/q/Sb9nFFtejsGYay9rJlqqtlCd5S0G7NT5tQ5o0 2VMetABANUlFL5XFZS5DmfAy2bcDd9tGP/ldY6WIG2vqnvfUijladkcwPh/AeF4GMXacy1JrAt7r OhxYlDyu5/FeB9nq5LRaRuPaUPV+slPmlTW9AG/2CrP2umUvm4qA8XdVll1UQGWgFs6gQv1AMp/7 YcCD4AzBhJZTdNJnOCxK3A3ks+tDDLAhnnja+jg+5p6yp9OjpXfQz+ferH5yYffTGJ5VDFNSDPN8 9vF/+SwYoxm/6pCWBr0bggyS9W0/tH7u1VPtoIto0zNEUfhXsl8+jcEcsEOZGvhuGhXtcRnyzzAP DG1ygA3hCgaL32eo6OQ7zqljtQOGHB4c747Zw6IoQ/H+6a7Qb66P+zn0KxH3j9WudU2AJriOVUxr WjHu81loZ0yy8rezFqrpbFTvBhsw0Iz6apkrcyMhmUx5Mlm4e8YlgqojvOVQJak97/+yihleo8bu MOnlYdKvb9LQIOZ4Znx9mJFvxvEKmDZNNlQAvI1P7gLUt4fZdmaLG/S7Vl82ga4OIYZkH6/QJa/0 WxV9fTY452gl30tEPeuKdBzKu07LSSu/6LJQYUr2Qgnyjaf1cWJFpr7RvEM1tznzi6FXyNK0nTEH bmsGeu2M0yeqenqnqqcb6mtrL6sKY6Yge8329WQO0YOXqsUczOjP696LQda81Tfx/nebpAGKHzXT aXtCTi6d1W2MDEndPz5ddfOzE1bHk4KHs4m0Kp1ywKuHp4i08Jsc0jEIDiUSVkE8QuB/hPF0Nvn9 +XnajuCYAR5UYOQrn3JCb7WMfi6DEt9H2HzzLqLN3LYu1SICZ457rNiiS3GdE55QhdDWJ79sOak/ dFIXzZh3y2U9PGK7rxqif2WXiR4jgzVH/hKu+EsBteIkyYlMP4igKyf6/ToOTRUcx2mhDx0nh+Of sb8GFoy/K7JDEwff2yP3GK/seaifeGEWrq2opmJaK6QiRvPpaXEZsz5RjZdKaartQlJaI/tDv5/q iel6Yrr2+7Hy09fNEs2TcLdvF5f7Bls2+2WcMWrSml56H0pcWBHIeRGsXjcVwy7HBBv3yjzUR0zz HjPEUGeuslwu1T1cfWsyr28lYz80gJTOHZtovsf3IqrfS3leO6WPvroiMgWd821EvU9Om6wXP9w6 sU+EKjo62PeZdPDl5fTLSXT/253UYHtlU+KY6GTvbCcV+BTmmf1P949GppmCQ1/ukVLNju2RXvVf m5cJATZy9DYjeq9vvi11Sa/rTT5o4lsB2cwwRMr/GY5ILl8fiGDSLYGOBmuIoRDwsxgK7HlTitRj mbSflwnuu0g74Lh2CIuecnYgnpeHmA74lHaAma7GavypnS/vKttL3GtJSNtotozdyn7IF2zLknHl gi7MVVrVUN1PTWWPyWgZRLk9xZwM7ItbQMy2vKT/T7q6OLx1dbzRSPOicbqSwDa2ktfK+yMojrQ8 fLq8yDDw2y3R6l7x6lLN93lfXmI6pwroWkrr3uFaNRrTRsGKKSeUWuHEIF3dOgxq9QClnra7awGr Rhy2Kt97tW+VuNbkIplHx981kmC5cRErt5Nczc5ZrHYjSbVuBIkBV4SAjQaV5XQfZAcnSmodcONc JA64+ktXaiSJc2NRJLWTxM3OWeJ2I0m8aYwS28H1Wu0FpumEXoC82Ed7Tzj9dsJN77DRQYBz2AjR j7CHrcKZKwML7Hw8tAi21yuZh0GsnpAAxM5efQLsNxxLIKXuvb86gJK9vTIAqPpa75Sufdjbuo0C 0EcU7lX0gB+iFav+dWvQdXe0tfaBNiJ0Fl3PfdcsdG+PXWLo/gSfP8NG81Ns+1cnhu4v3Y9/hV8u aR/8hXYi0aFfwljo8TjW/HP8HbZaqTt84d9PZ9z/MCcd/4S/oOHvp+kH3FSrUaI/KBt6qbaj2GUQ r28NAijlBlgFHx8jeo1yoresQQxKIuNa/eggvh+wOgFMyRrEgF5hMXL0GmAEy9JqdL5UacEZBHch 5zlaFQMii4LVNbAGgbWpvOBoVcBBAMaQHL3CGABiyiuOXilCxUsC1iAep2NZek0lLt6x9Kp6VIln 6VXHbRow07IGweNBGFgokOAVAgbr2PAaZIxZWPAaVAyLePAK4ZcwXHgN6eTJg9fgYp0UD16DZ+kV 4DUEllYjvOpBsLSaAvVBcrSa4FUPiqPVBK960BytRnjVsHyCYcKrHhxHrwleNbiKMkx41WAjjl5V OhENLL0ivGrQDEevOh10FEuvEV41fHFQIMIrHrlE4MKrFjae+jjwquHUoh0TXrXwjd3infCqiWpj wauWIhJlLHjVUrL0GmAExdJqglc4MVrHhVdpOFoleJWOo1WCV+k5Wk3wKgNHrwSvauDoleBVCZZe E7wqxdJrglelWXqN8KoMS68JXpVl6TXBq3Lv1uue0TY+Eg64G+uKBKdra2/XjOtS9vGaGdcvL7m8 HcEplPJ2iwLU5e3KaFyruR1cHfCwfiAz6X3wgwqA7EYGmJGxqG8k1pXV8YSYyU6JYChF5P3jCFkS OOr41Zv0WpQI5eUBOEq8TxAtbc2rggQ4FYWKTONrGddxbjdogrrdJAg+aocXezSmV5j61INdYDrx xRDiw6usiUc5WKR4GaEdQnGtAANLLtgrqjZa1LbaP/BLNifdIYF3vP8KCente66RFs9J2xq+6/0X SMvLrlzf5G6wXUg52Krb4swcaQD73bCsoVSFeIc0SGZKkbvVl7fpSugTJNMWvNe7fK+n75AKRnZK qzyZ5sX4VrJ8+YaSffrdm4L1ruTK5vm2cC41n3v10f2QL7VYS+GZp1u48b4K3Wt5ZXXh22oMumOf qhqxebkDgl3NYTZc48Z53t44H+SIf0qGw/NZWGlCzCP51hk74KupHkpEmogKub+imbfZLam0/Iap /MNU38BUH0+ra5fa1iv8tF/id/hBePjB78APagg43Y0B47+j7evM3JLXjakio0jpIrEIWD+fDcRc MUEs5ILtqbKKWb/mKBE351Yu014U9HyWKphUKewvOcMMYwYIkr+dWG0HXpdP3Mo+uxzFAhDVhToB LdQJcqr481JVOK0rzWufr/N74xrN2abuoOBhU/ywONV0nOC4+ju/a65kIDXFeqi05rZJTSMlLV2G 4s/7lMyP5V9OvlhtntcJvEuykqVgrqr+q9OmF5VXCZSY4LQkNhEknSjZs1o/7qgwopkLmU2iK8+c 05pdEj+r5E9MFpZOBEkpmFT2AkcDk1I4RfpEeeuXT5Rp+laSsnJCWA5oV/Ou09d0SdCKeHQpCc6u yphf0DDXzoS1m06LO8eV4kBVQrsl1TY5yjn/fK1GoKXJuaHJ1SzUOk07p8Qea3rvAXMrJW6gNNrB wgG8tkpJm3V12ux4lN6/bG/TO7bHaoZx58qJgZTOjMCZt6+4c1X5ss2lbNYVEdmmWSNgpLMHB4zS f+tNK88OXcUac7erRFlDFau08jerEpFl687ZlmGd5d9yvVuuhYoUPia5NV3GH7oMthgf7CfGDVGd 3qQaxqW07IOlkGYphVTB3m+UMSN3FThO83of35VU1OiD5QNGexFL53JG/feOjAkJh14GW5BwDZYF Gekx0KyvoqG7NBv3uKG4eK3ROoTYFsXkUKKFR0t0lfdkrGKSSG6KygIHKDgdF8XlcIi2xxUE3prK xmC16EvZQB1uUD716gRzZOzGu48zvZuZ3GN1FK3DyyoOmxqZ1fsNtL01rXLMb2Rvt7a4aSyBUL1J 5MAnh7ynpXauUj85aRUIWSf11RI/BI23uupFVxVWY0MPvizf+FoqFlmdS6cS4O1j3liQlMrw/NWy u4Z7xmOIOJpTa+GFUNQUZWrCQXwTpus2pQo3pfJ4S3KO/w6dkZicGUIHbtcLkQhW2b388wSie8w0 7f7SxZXVytbfVA3Vx52lymBzhph8qTq4VnsFJ7u4ItbXVhJOvw6kRY1pRTUkQgUQNKl4FfJgESWg uXjaFQ1gQ4Kdu3s4n6K1sTpU4e9SKorjVvZV6zNI2W/JCqDhsx6Sz68P0bvNJn/GuhZvLnFXBpOt m5eyTTwDaJDfPlXFsuhIqoori6e8bSLOzw4fPhzBvfzwSRpyOSDDmVrMOak0E4ZDzbjvVTNxyWqq dtU9xInlJNRcuaApI1KlZbsQp4kWQ7phrLCCYOLTCoAuhW1p7RorSsGsN9NrBUXH4zVgRutdvVdc sP9Pi76+t8KvbR3mjrZt+2N5HzvyL5d2zUKzjJCrgq11lZH2vT2sMsqNR1VGzc45LaDdSFVGm0a8 Ry0yKSwr2TWSTLmxyETtJFOzc5ap3UgybRp9TLJYKttgn9435sI2aiwyUXtO9Wh1Xsramo25qm3V iOl3lZ5SRsqulV7abs0Db1qxrsf6XOglbIhVPv1mZJru0neZbx6cptQePNe9bUc3mPGl46wwaVOK WIC0tEqZCnhy4ZvUg1i9HOHflrwaEMVVdqT+pfYt9191zmrZdgafiIkaVLE3xOqmRTQVU3iyOUTA aVR9UysJvrQWuemBLHez+5Jk027NYm9a06TImirEOfRyVcK1SA2/B700Xi/gUpipeNyqNAq1KT1b PQEvNce1awoOUf5KdVlKoLo2PjKKVwYI7krZIWZjXxEOk3CvCEdJVVeEo7Sqw/FTVtVBXZ52stbt 9u3LGjIx3wmb8WCQx4ZFsLThwHDMQh9Y+/jByDnXqpqXXQlujNgUPK6aq0K/R3Xfo7rvUd33qO57 VPc9qvse1X2P6r5Hdd+juu9R3feo7ntU9z2q+x7Vff/u1X3VIMbE0xaTHIBRApscMBaPWzxywETm iEkOGBePWzxyAAbxbHLA+Hjc4pEDMIjn0gMmxOMWjx6AQRybHrAD/s6kB2AQx6YHLBJ4THoAxrBs esDKXrDpAZuofR49gBkSbHoABrFcesAm5p1HD1idTrEseoAAlkkPEMDy6IEEsDx6gACWRw8QwPLo AQJYHj1AAMujBxLA8giCBLBMgiABLJMgSADLJAgSwDIJggiwTIIgASyTIEgAyyQIEsAyCYIEsEyC IAIskyBIAMskCBLAMgmCBLBcgiABLJMgiADLJAgSwDIJggSwTIIgASyTIEgAyyQIIsAyKQICWB5F QADLowgIYHkUAQEsjyJIAMujCAhgeRQBASyPIiCA5VEEBLA8iiABLI8iIIDlUQQEsDyKwKdAi0kR +BRp8SgCn46yLIrA01GWRRHAIJFnYFEEcLCIPAOLIsDTieZSBHA6iTwDiyOAQdgUARxwonFYFAGe kiyXIoBjUuQZthQBdk2D4HC3B/HsFIKg0507iyOAQTyXIggpJZVHEcAg0TgsigBOjtE4LI4ABokk EIsjgONnPECyOAJCWCZHQAjL4wgSwvI4AkJYHkdACMvjCAhheRwBISyPIyCE5ZEEEWGZHEFCWCZH kBCWyREkhN1zBB9AWCZJkBCWSRJEhGVyBAlhmRxBQlgmR5AQlkkSJIRlkgQJYZkkQUJYLkmQEJZJ EkSEZZIECWGZJEFCWCZJkBCWSRIkhGWSBAlhmSxBQlgeSUAIyyMJCGF5JAEh7I4k+AjC8lgCQlge S5AQlkcSEMLySAJCWB5JQAjLYwkIYXksASEsiyVALOInEuAo7EQCRLRWIoGQeQwsmbo9Rryr5rAE Wqa7ahZLgIPgMYXFEiA+c/MIcIxYM8EhCRDjY82EY+lVppoJz9KrYlIEcavxDYrgXY4mP4EiwA2L TRHgIFyKADc9NkWAg8RUBMfy1pRQz6IIcBDLZAjiFu6ZDEFGVx5DkNGVxRAQuu4Ygo+gK4shyOjK YggyurIYAkJXFkGQ0ZVFEBC68hgCQlceQ4DoyqMHCF339MAH0JVHDxC68uiBhK48eoDQlUcPELry 6AFCVx49kNCVxw4QuvLYAUJXJjtA6MpjBxK67tmBD6Arjx0gdOWxA4SuPHYgoSuPHCB05ZEDGV1Z 7EBGVxY7ENGVRQ1kdN1RAx9BVxY1kNGVRQ0QurKogYyuLGogoyuLGsjoyqIGCF1ZzEBG1w8wA398 OQ2dxYKac/x36AycLGzai7UbTPfy8+lJjT6o0Tn4tvQ9pu8ZPpOHzyt85ueXn05fXk7/J8AAy0fd YA0KZW5kc3RyZWFtDWVuZG9iag0zIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1 L0xlbmd0aCA5Mi9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNFIwULCx0XfOz8kvCi5ITE4F cYrNFIzNgBJBdnb6rhUl7sEliSUgCfdgQwVjc6iEW35eCVAsJMRQwcQAKhZQlJ8cnFoSrR/g4qYf klpREmtnBxBgAEf2G6oNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9Db250ZW50cyA1IDAg Ui9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50 IDE2IDAgUi9SZXNvdXJjZXMgMTMgMCBSL1JvdGF0ZSA5MC9UeXBlL1BhZ2U+Pg1lbmRvYmoNNSAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYwMzM+PnN0cmVhbQ0KaN7sW8tu7DiS 3edX5LoBqym+CVzcRWEKDTTQi8EYmEWhF/mwC1PoGqBrFvX7E0FGSJQylbbzXN9H1V3YTiepUCge h8Ejxl//9l/j/uf/2/3wuPvr4+O4H/ePzzuzj0OJ+4f62+zHMFi/dykN0Zmwf/yVJvxMP48n/vX7 7oM7HIw7lAP99fST3CHRT8n02dHfp/b/4egOZ5p3os/Hkzvk2K450d/jsX1X55GMI117ou9OhX74 muePj7/sfnzcDdlnurk3g92PYx5CGPe5DH5vbRyc3f/2tHvejZa+yXvv8pAdPZMZTN6PscwTHE3w tyZ4lnljPNDnOGnQJixUaJNvSEhlsLOOlib45YRCE24IsKYM4y0V7EgTbkogM5lbZrJkJtOZoQwh LieEzIZWHYIZ4tITMkEltAm9BIq7VbT5NAS7jyQjzMH2E8cYxUI5t5jJ9DlTXGWKk5w+PrhMDssf WvCcKJBOTgKIgud4kIA6tO9qkDkJLPmOg+8U5G+RObnJ0u/O5uMD2cxRHnyQWx/a7a0jb7oP8k/W f/zqnzHkONgPclcjd3xq2mr4H59bSpwkjU5eNDi0H34SvuZ4IoHRUiCyNkdJljp6bs+UvTz/6eM/ H/++y+NgjU9k4sf/4Jytj31u046l3YRvXk11lhz17XM+y18V+yxK59l8/H1OPIdz9UFv9zAOnlxP 9/wyTpQnY3NWszKiHNmRkUAk947MX7cjmxPNkHonVoHv7Ei55Rd2ZDmKOUMzmXVutMtMLF9/Jtbg k2wMIbrZke+aifVWNxzIwp6bcE6D2YFFTHDqHKOZJWv3yc2OraY8duu3UaeRA2iJCMuMO3wbDlt7 pznQ0QqVxtmBn9BhIvoTO4wLsvqw5/n7yUkH+c7P2Vdh0pvihtI77fjtOa05zA554bBPnGUi/h6n KdQZedTnFmm6Xt2VbT5SGKXecadvy3HqNBc7n5X38Bvf4Z3cdlfOORvHJVCevx3X6eqWO7e938KW 490wWZVRV+j/fVFywyi0rwlhWXw8fZtrWe+Q5jo/5NHYBUwiPhJxSycdrez9RdfTk+grqVP5ADKV s9a/XIiULn80n0qXb5OJGRYTRY3vHfdcH5s2dblcK3LxuwoSKIB7mZtlnDPeuOjWWr09nFQbK39j Myx/riGkGnWGPvlry4d8514ReuNIm3o7hV6z5TiMaexq27uiEQ49VeP9fDrNP/T7HPLPmG1uDrrq z/zN+JNH1afRp7LYr3x+f1YVVv7UVbRna4LsM5VS3PDn2oeyP2OWx5blCkz+Gycv8X73tK6ovno/ qtOaP6nsMX65RH8uP5ahFJdfWrfPYugFoXCFZz6EKxzyG0y6SfWZ5JsDNQiKub5UfGjkdjXRaWYr JhNkWdLPnYldU7h+f5iVmcp5eQD2a52TO2VNe3g1v45XAxznYkbjosaK1KcTA/PcxZ7OoWt3/UMc BNZqUTteVkjV6mf2qY1D8AL47EwVp7fUW1zamR4hcGpRGV6Wpv4m1z+o9CJJIaX4qUqvlIbRmsiB SiaynzFSq9XUin6+12uj8DVBuFtG4WtiTiI1jWZex6YodLM0XRqalGpLvYxsSTZNPfvqhVw+LgUp x9lH3rXn6/nQyU7dI6k9GeYOUX5STRtSzLnBFkKhIcSiyXc9h76tmuNzFBg15zy/hjNxsQ4u2YGQ HIG9HcYQ7JdG++OfAe3Ld7T/ZBvtL1tV9aGZurA/iDkLvyueOMpjVWurwiq6rmiYHuYaf/LVed6H 1bn9yz+nAdjG9EjCIgWuzH9rfqtB9NrFguI55/pBDVxN7NItDNPiUnOOFvMx2TnppvWGEiqM3q/t +Kcqn16TPS3pPK3f2S+oiRsvsH2o5ZNNoWxA/1aMH1fUwsQwaoh2oav4ydf2IV7lrULxonzIc05V 2Jd7vhTmu7fHuYShWxwi6CP/SYLAzc6XF2Z0ZRhKJsM/TOvoT5vx+r1UgUoVft07pq14zTN06Ems rSp6cc1qHb8oJ17yRh/fd+TQ7u24LfGaRxsmm70OyVvJL5cuS/7tIF+j9gKib5XqF/H/xy+A3iP+ CykWnauluvjrogI6iMlLs/KiAqo27F/TrQjEF1/19a/1tMg/X2bN297kvvwuanTGpLmcPt55kmmK prZOhmGMKXflxh88whbhxBZ4UBPcKKi/hnB6+xvmV4RUDYuxD6lyb0hp2ZVMLF04/QlA60pIiRle CKkn+Tl1IVWe59eHE+0wPeTSteUFeuDVSFWuvFp55Rvy0bp+k3+88+DQ1TWuhVQcstUXGIpQf4IQ ksf+1kJotdO4vaCF9YJ2+tTb2RZCaYg294vcHzt05HHvCJ16kDfKImWWJ1UO692taercdWqNKmS3 ZDLOXxuTUY0Z/UBBmrrQ+Zpd/+PjzhVur3DME4VxnzL/x+0htQtDBmMebOoGjXGL8TIOqWxc7Mcw uHFrUPo/VoN0B/6sStGk6C9HRatpdNJKJ4ha1y9XvTZGRbH1aFhYy9Po5aDopYOzWmFhrasXq1bX B0Wp5SD3+6SFTjRyMTor1UYnrXTCrNWVyzu1ro3OevWj5OLs9+NIkE162VT24zC1/9QOI9U5ZG4g msXKqOg8jc46ywTR+frlqvPGqHYeLUebzpGWGe+WKuvTlGEkjWuM5MydWnWU4XBzMFQrbY1GGrWb owRjcSHZmHExIZfaOrVxeaHRW1ePpvVubVzODVxlVo6N4XPtoev76W7Jbw11m/JrO92t68k/ne0u FGgdY5viWy/dLfm1mW7remtyb5313aWRbvPq1ka3Odya6DaHaVXOefvelBw3DGsJUVeGdcsJ9Nlt O96WfMuwzuSVYZfDlPNdUK51N/u/0c/faY38pV76+340+3/sf/onfXPejfv/2e/+vecC3tBvBmTf wIBlnX6t3/+649ZTHvjX7oEfhHOIP9InGvjX7viX3X+upFRsJne7tZQ4Ccn+tpCRbe6SqXXS/UIo pRwfWgOE2IEVsRXD7pdBAeaSHwwgxPEslwJkV8czXIqQXT1HbOtGRoSwSTJk18CJ4LKB7Brqqszv mgAhsTZo037bQ0Iot1x2kF3TwDI8ZFd++0tCImTXzM3RLifIrrUqdIR4iF3r4uF4/YaEcO1mILs2 gKViKiYYYIutFR0GsNxZFlCALeHKgvFGgC3cbY4CbEn83g0EWFqPU0ABloodxK4VYL0ZIbsywHpj IbtWgPXGQXatAOuNh+xaAdabANm1AqynPQdiVwZYT2WZCyDAet4SBBBg/Wggu1aA9eMI2bW0fb6D 7MoA60cP2bUCLO9Hx4ICrB9j3RRDAOupPvcJBFhPe8OYMID1tEPICQRYT/qYBAKsJ1k2gQDr6Q9i 1waw9CcmEGAJ3RC7NoAlPDAJBVibIbs2gGWeIaEA6wxk1wqwboTs2gDWOciuDWCdh+zaANYFyK4N YF2E7FoB1iXErtHUrR9IEZCUjDIEcax7P4whICG898MYgmjr3g+jCEgI7/0wiiA63vthDAHJ4L0f xhBEX/d+GENAQnjvh1EEMbS9H0QRkBCYIYixEukYQ0BCQkQZgpiYDQUpAhISLEoRVJIB4geYm80o PxDrOzGQH4ilbaghgkDgFSQIGrxi/IDAK8YPCLxi/IDAK0YQCLxiBEGDV4wfEHjF+IEGryA/0OAV JAgavIIEQYVXkB9o8AryAw1eQX6gwStIEDR4BQkCroAxdqDBK8gONHgF2YEGryA90OAVpQcqvILs QINXkB1o8AqyAw1eQXqgwStID1R4BdmBBq8gOyDwirEDAq8YPSDwitEDDV4xdkDgFWMHBF4xdkDg FaMHBF4xeqASDBA3IPCKcQMCrxg3IPAKkQN2nE6LAeQAS0GPD1hasAxKDrCQgJIDdrR1swWRAywk oOSAHR1IDZCEutmCqAEWUlBqwFIZ4FFqgIUUlBqwVEt4kBpgGRmlBizVIw6lBlhIRqkBS0WNQ6kB FoKSA3bM7XhIhuya2/GQAtm1tD2sgew6nbUFyAGBV4gcUHiFyAGFV4gcUHiFyAGFV4gcqPAKUQMK rxA1IPCKUQMCrxg1IPCKUQMNXjFqQOAVowYEXjFqQOAVowYEXjFqoMErRg4IvGLkgMArRg4IvGLk gMArSA40eMXIAYFXjBwQeMXIAYFXjBwQeMXIAYZXjBoQeMWoAYVXiBpQeIWoAYVXiBoQeIWoAYVX iBpQeIWoAYVXiBpQeIWoAYFXiBxQeIXIAYVXiBxQeL2DHPjhcWf2kVPmof42+5DltQM/lgn7x193 H1rXI7f35Sh/5X/uWe3a+R5/4T46ulPe/7xz3KHKjRO5LoQEvJRU1kZ2n7RO1Anaf9QmSB9Lm+AT E32dBILdXoI3cSWBu0w6CQz0Od+aYGNrZmq38IXlLW5RYmt82dLh0oSOMo4+RK55mwUNmePdG0m1 H7nvMT71Pcinrgu39jF/fCBwoHUo982kT19TM6k2kppFI+lX30ds9pnD7qH+poAgjOAmIG6oHFtE 2P3jb7thTJlbfvb/2HOSHUyLDA6A6mi5OZticmiZTXi7rZr/54RcB6f3lczgdjPXdBlGV0iNFqHH 1oBeE5tNapni/tAUq1F5nAZcHXj1FSmbGjoHjRD53lo3ykifHhIDl54UC5P9HjwvR4RmN9q1j93P ocuycuwMd+xi9EpM1szTGNdoya1VW6OmZmuXqel5bRpBTs4zQ2Yq2Zuadxy39BDVZnlsP/WO68d4 lp+j5LvMq1qf5EfG6hPEOUROUTPJpbElkmaJaXZlPave3XNUyU/iqec2Vn1y7jLJNTk5cLA9yB3u cIgCR0pdlJ/mFFs/1vHVDqyP7kmjbHN7dksLZXH7x9NOkU/WNPIGPQUVxNZ6sZPhaRV1nkWg3LAq 9OqoIC+nMaUhfHl0eghuSCaWe7x0lKSuQeU7Axh58I30qcuB6ULpTR6U+brA+XmuLm6nzqTTtec5 RDW8TxJdu4pMz6K4rrTNPlSfGuf8cr050mpZPFnOSdLOS+HiHzIWISMVNlNkVZm0NYrJhT3tommv Jen3JW15JZjvte+uGViqv3/v+C0G7+QInVvPK5VKtrYPU8H03/v/vVYy5bFdwqRJ8rwqTSk3Oejj Qw7jEGsCVaPS3a6VsPwehorqaMpUgH3ZpGNgTHkwBPN35Zxoc+7LJAWgQxdH3TJTw/s8z5nQtEhs nZY+n6wz1RKvQc3yHTVf58FNK7/ZIK/wyuG7V15XcaRuO3J8D08c1RvfPXHTE4e7EGouRqta3VZ5 QkfTFbGra5nKqHOfNnJSo8PNKzItcq/wutrGb3v9pR3z27d7FAneu/I17H6hSFBPjKJWnxaffVdw /u5J8aSj8q28zZNpBi42jqpbt7biMfVakQKcDXBz81zq5vkFz5VuP3fsPccnKUc/uW+LctH99Tsy BG23bDhDRmuSbAgOUtBPbJ9v3x1O2/vuawzABGF9YpRLSOUkO3VP2ENnz9WprF63njs4doxj2xAE xXB+zMe/7Loqtir1NCs87WrWD28uXVJN31W/iznneWczmf84KzZVwnTNeZxdO907SxJ3a0a/hjRj ds+j7u3XrtCh1dOsS/9sky69cTtK7JotTjdySfW7CTb6TAdZz06zbXbTQprnh+PsnnDnac0b3zZ0 i23u4B2N63LuK9qDEZrlaN8GZ5rxfnZLObXbarly7MyqIboJZYfGA1oXg631G9/uczCBr+X9GmOY B+dCnijDt1CBcuk95OzzvKOtirvZ+Mp8TPH+ggP6/FiwGGHGg/YqJPvUXoUcekInrQkdpnuiNUPS 0ZBLFFriPcK7+iGnIUXnJj+8MuL1snt88AoI6Je6qZDR10xlxbxdSaDb/qN0yMG3twxLn+SbPsmf 3ifNB2HIo7FzLtyHQirmnupY10CNYd89RLe2HLpquS87eP5NUDoKKI2F6qsKSvq6hbQtPru3hdB6 ORJ8mpbLw8tL9lbNM+HUleW3r0VaGOXiW2wcb6Z2WaY2P7lWwPz2d7NO0+XcXOpwT31Wn0U3M/my Nltg+pV7X8yZ9L1WdU4WLKuNcFrSjevCaLMaNdtF3VUAdhtPeaNo6Ys/jaDdy8WIbmK+Kjq4xBDe hgLrjYa+aH2aOXutcKdKOcxoqyFSblXKV9DhDSn3wg7t2DGVZXtvfWt3duoJAYn1STF3B49mDZ/n +5r23HbgavD9Q+PKJkqLr6uvjt6CvCl604qqBfKWNyHvlLTfgfebBd559fyyyFsP3jw4Pv8byt6Z wffwe/UEDuVXGNse7Toi6ctIW3Jte/LtODwfy9vzmeV6TkwHyziksjE4nVO7GHR2Hw3hE22oDZ/W HYeV2NjOiOqVhoy+kDwG8sSGZNp11iPiK9HORj62xI/D73EtB2836lobkdy4HkHsb+xsqr1K+ryZ T2ZPd5arVS29enHpZI3VpT7Vjh+xcqo9mhejotY0OuslE0Sv65erXhujothqlM/6du6nSdFfjopi 0+ikmE4Qxa5froptjIpi69GYaqOVKGYz92BfjIpi0+ismEwQxa5froptjIpiq1Hn5XClxl+u5zOH 6exlPf+peofIombRMip6T6Oz3jJB9L5+ueq9MSp6r0YlQDUj+QzpMiNrUpWaNrVpIdezwnLqtX7e HCZb8FlBGWapPheOs2VOhtpKwcN8EG+6mtLKTqMsm1ZVtunS3BuyQ6oZvqUZd3bfUDzVxu/N4Zz6 MXbSYrjUwxtbV8tB383hdsz3hnw+52u3zepj7J/tYjjF3ikXt880vD1aQv9oa9mBHi1sP1qwbtg2 enCOAWlzmGoov/3UPP33/Wj4/Ol8nNz5/AnaxFkK2ibOh1ThNnEWAreJu2DwNnEWAreJc15jbeIk AW8TZyFwm7gLFm8TZyFwm7jjRAHbxFkG3CbugsfbxFkI3CbuQsDbxFkI2ibu2uKLtYmzELhNnBdI uE1c4RVrExd4hdrEFV6hNnGFV6hNXOEVahNXeIXaxCu8Qm3iCq9Qm7jAK9YmLvCKtYkLvGJt4g1e sTZxgVesTVzgFWsTF3jF2sQFXrE28QavWJu4wCvWJi7wirWJC7xibeICr2CbeINXrE1c4BVrExd4 xdrEBV6xNnGBV6xNnP2KtYkLvGJt4gqvUJu4wivUJq7wCrWJC7xCbeIKr1CbuMIr1Cau8Aq1iSu8 Qm3iAq9Qm7jCK9QmrvAKtYkrvN7RJj4LYT4vepQc8FEoBoQdYCERJAd8FIYBIQdYSGUYEHLAJ2EY EHKAhVSGAeEHOEwxcoAkNIYBIQdYSGUYMmTVxjBA5AALqQzDCFm1MQwWsqswDA6yqzAMHrKrMAwR sqswDAmya2MYMmRXYRgKZNfGMEDkgMIrRg4ovELsgMArRA4ovELkgMIrRA4ovELkgMIrxA9UeIXI AYFXjBwQeMXIAYFXjBwQeMXYgQavGDkg8IqRAwKvGDkg8IqRAwKvGDvQ4BUjBwReMXJA4BUjBwRe QXJA4BVjBxq8YuSAwCtGDgi8YuSAwCtGDgi8YvwAWxMjBxReIXJA4RUiBxReIXJA4RViBwReIXJA 4RUiBxReIXJA4RUiBxReIXZA4BUiBxReIXJA4RUjB7i6gk8O+JJRZqDktv+EqAESUtBzA54KPY+e G2AhBT03EIzh/SfEDLCMjJ4cCFS2OvTkAAvJ6MmBwLUvenKAhWSQGwjGtf2nhezq2htuB9nV1zfc EDnAQhJ6ciBQKY9yAywjouQAn88a0ZMDLCSiJwcUXkFygOEVYwYEXjFqQOAVowYEXjFqQOAVogYE XiFmQOEVIgcEXjFyQOAVIwcEXjFyoMErxg0IvGLkgMArRg4IvGLkgMArRg40eMW4AYFXjBwQeMXI AYFXkBxo8IqSAyWjzECDV5AaaPAKUgMNXkFqoMErRg00eMWYAYFXjBxQeIXIAYVXiBxQeIXIAYFX iBtQeIXIAYVXiBxQeIXIAYVXiBwQeIW4AYVXiBxQeIXIAYXXO8iBHx53Zl9bOx7qb7MPtLeIjar3 yYT946/c8Ptb7QuW9sws7ZP6f23JzK0BsrVS/vi4+38BBgAGEuIaDQplbmRzdHJlYW0NZW5kb2Jq DTYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDUvTGVuZ3RoIDc1L04gMS9UeXBl L09ialN0bT4+c3RyZWFtDQpo3jI0VjBQsLHRd60ocQ8uSSxJBbLdgw0VjM2B4kF2dvpu+XklQLGQ EEMFEwOoWEBRfnJwakm0foCLm35IakVJrJ0dQIABAMotFDcNCmVuZHN0cmVhbQ1lbmRvYmoNNyAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgMTEvTGVuZ3RoIDQ0L04gMi9UeXBlL09i alN0bT4+c3RyZWFtDQpo3jI0UTBQMDRVMLRUsLHR9yvNLY4G8w0UgmLt7IBCwfoudnYAAQYAovQI xQ0KZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqDTw8L0xlbmd0aCAzNjEwL1N1YnR5cGUvWE1ML1R5 cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhp SHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iQWRvYmUgWE1QIENvcmUgNC4yLjEtYzA0MyA1Mi4zNzI3MjgsIDIwMDkvMDEvMTgtMTU6 MDg6MDQgICAgICAgICI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMv MS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAg ICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAg PHJkZjpsaT5lYmlzYXdhPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAg PC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6dGl0bGU+CiAgICAgICAgICAgIDxyZGY6QWx0Pgog ICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPklQdjR2Ni1UcmFucy1T cGVjX0lDTVAtQUxHLTIwMDkxMjE0Lnhsc3g8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0 PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIwMDktMTIt MTVUMDA6NTE6MjYrMDk6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1wOkNyZWF0b3JU b29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAg IDx4bXA6TW9kaWZ5RGF0ZT4yMDA5LTEyLTE1VDAwOjUxOjI2KzA5OjAwPC94bXA6TW9kaWZ5RGF0 ZT4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z LyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0aWxsZXIgOS4yLjAgKFdpbmRv d3MpPC9wZGY6UHJvZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXBNTT0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6 OGM4YTk4Y2MtZGQxNS00ZWE1LWEwMDEtN2JmMTc0OTc3MTg0PC94bXBNTTpEb2N1bWVudElEPgog ICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOjI2YTVjNDNjLTI3ZTEtNGViNy1iYTBhLWU2 MzkyZjQyZjJhMjwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAg IDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9i ag05IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCA1Ni9OIDEvVHlw ZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNFMwULCx0XfOL80rUTDW985MKY42MgAKBikYgkkTEBmrH1JZ kKofkJieWmxnBxBgAGgUDgYNCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0ZpcnN0IDUvTGVuZ3RoIDE4MC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN58 jU0LgjAYgP/Kbm2E+jq0MEIQhRAShKQuQqxt0GC4eDfLn5+Hzt2fj3RPgByPSTWHp0OqH8aLj2BJ jVoE46ZGBE2bAwcoUp7mAHnKd1soNgCbH7Vq/UWieYU8VtaSq0a/miSPecxZ0jn1P9KjU7PUSCuJ 7iECaYwPxlqNpFgTQEZ6M5NyHz8ylgwmWE3b/p29d9GAYvLR5aXlva27PqrOp+h3yeLF+oWV5VeA AQBuPELbDQplbmRzdHJlYW0NZW5kb2JqDTExIDAgb2JqDTw8L0RlY29kZVBhcm1zPDwvQ29sdW1u cyA0L1ByZWRpY3RvciAxMj4+L0ZpbHRlci9GbGF0ZURlY29kZS9JRFs8M0I0ODBCNzNEQjJGNzc0 MTBBRDFGODAwRTQxNjVDNDM+PDFCRjNFQzc4MEY4OTFCNEFBQTIxNDZDN0NGNUJBMjI0Pl0vSW5m byAxNyAwIFIvTGVuZ3RoIDY4L1Jvb3QgMTkgMCBSL1NpemUgMTgvVHlwZS9YUmVmL1dbMSAyIDFd Pj5zdHJlYW0NCmjeYmIAAibGzigGJgaGdiAhNh9IMO6AcSWug7jLQdxOIMGfDmJNAYkJAbWZG4C4 zCCCEUQwMAIJpv9gLkCAAQCqwQgxDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJlZg0KMTE2DQol JUVPRg0K --------_4B2658A000000000A547_MULTIPART_MIXED_-- From dwing@cisco.com Mon Dec 14 10:18:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD53F28C142 for ; Mon, 14 Dec 2009 10:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yznaa5c9mpFd for ; Mon, 14 Dec 2009 10:18:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9CCA328C157 for ; Mon, 14 Dec 2009 10:18:22 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAJ8QJkurRN+K/2dsb2JhbACIXoEWuDGWMIQrBIFi X-IronPort-AV: E=Sophos;i="4.47,396,1257120000"; d="scan'208";a="119537049" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2009 18:18:06 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBEII6fJ013326; Mon, 14 Dec 2009 18:18:06 GMT From: "Dan Wing" To: "'Behave WG'" Date: Mon, 14 Dec 2009 10:18:06 -0800 Message-ID: <001d01ca7ce9$c8920f40$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acp86cgtnzKM+IOKRcWMt4+YmjyB0Q== Cc: 'Dave Thaler' Subject: [BEHAVE] reminder: Wednesday interim teleconference X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:18:36 -0000 A reminder: BEHAVE has a teleconference this upcoming Wednesday at 7am Pacific Time. The December 16 teleconference will resolve all open issues with the following documents so they may be immediately WGLC'd: * draft-ietf-behave-v6v4-framework * draft-ietf-behave-v6v4-xlate * draft-ietf-behave-v6v4-xlate-stateful * draft-ietf-behave-dns64 * draft-ietf-behave-address-format * draft-ietf-behave-ftp64 (currently published as draft-van-beijnum-behave-ftp64-06) WebEx information, dial-in information, and agenda are at: http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart -d From guoseu@huawei.com Mon Dec 14 19:49:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8E93A6870; Mon, 14 Dec 2009 19:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-1.908, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vfonf58ekcx; Mon, 14 Dec 2009 19:49:38 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 71B993A680B; Mon, 14 Dec 2009 19:49:38 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00J8HDA2ZC@szxga01-in.huawei.com>; Tue, 15 Dec 2009 11:49:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00E83DA2WG@szxga01-in.huawei.com>; Tue, 15 Dec 2009 11:49:14 +0800 (CST) Received: from g57775 ([10.111.12.203]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00851DA17D@szxml04-in.huawei.com>; Tue, 15 Dec 2009 11:49:14 +0800 (CST) Date: Tue, 15 Dec 2009 11:49:13 +0800 From: Dayong Guo In-reply-to: <20091214001518.C50223A680B@core3.amsl.com> To: Internet-Drafts@ietf.org Message-id: <000d01ca7d39$919c7c00$cb0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp8Uq3jDTM8AHZTSqG6TcAHyQ4FyAA4DIPA Cc: behave@ietf.org Subject: [BEHAVE] DAD and draft-ietf-behave-address-format-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 03:49:39 -0000 Hi, all. draft-ietf-behave-address-format-02 recommends a zero suffix: " In the other cases, the remaining bits of the addressconstitute the suffix. These bits are reserved for future extensions, and SHOULD be set to a zero. " But RFC 4862 requires "DAD MUST be performed on all unicast addresses". Because solicited-node multicast address is used in NS message of DAD, hosts are seldom affected by DAD. So if there are many 0-suffix addresses in a subnet, solicited-node multicast address will be useless and too many DADs disturb hosts. Could DAD NOT be performed on the IPv4 Embedded IPv6 Address? IPv4 can play the same role of IPv6 DAD. Guo Dayong From guoseu@huawei.com Mon Dec 14 19:55:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8C73A67D8 for ; Mon, 14 Dec 2009 19:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP13ZkSxI5yR for ; Mon, 14 Dec 2009 19:55:45 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F05A13A67E1 for ; Mon, 14 Dec 2009 19:55:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00C11DJYD6@szxga04-in.huawei.com> for behave@ietf.org; Tue, 15 Dec 2009 11:55:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00D8XDJYE6@szxga04-in.huawei.com> for behave@ietf.org; Tue, 15 Dec 2009 11:55:10 +0800 (CST) Received: from g57775 ([10.111.12.203]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00ISQDJXWF@szxml06-in.huawei.com> for behave@ietf.org; Tue, 15 Dec 2009 11:55:10 +0800 (CST) Date: Tue, 15 Dec 2009 11:55:09 +0800 From: Dayong Guo To: behave@ietf.org Message-id: <000e01ca7d3a$65988530$cb0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_diy3g+EJ78y1W3QYzFR9Bw)" Thread-index: Acp9OmVT5vDqFUGZSxW8d3ajlgqHgA== Subject: [BEHAVE] DAD and draft-ietf-behave-address-format-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 03:55:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_diy3g+EJ78y1W3QYzFR9Bw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all. draft-ietf-behave-address-format-02 recommends a zero suffix: " In the other cases, the remaining bits of the addressconstitute the suffix. These bits are reserved for future extensions, and SHOULD be set to a zero. " But RFC 4862 requires "DAD MUST be performed on all unicast addresses". Because solicited-node multicast address is used in NS message of DAD, hosts are seldom affected by DAD. So if there are many 0-suffix addresses in a subnet, solicited-node multicast address will be useless and too many DADs disturb hosts. Could DAD NOT be performed on the IPv4 Embedded IPv6 Address? IPv4 can play the same role of IPv6 DAD. Guo Dayong --Boundary_(ID_diy3g+EJ78y1W3QYzFR9Bw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi, all.
    draft-ietf-behave-address-format-02  recommends a zero suffix:   " In the other cases, the remaining bits of the addressconstitute the suffix.  These bits are reserved for future extensions, and SHOULD be set to a zero. "
    But RFC 4862 requires "DAD MUST be performed on all unicast addresses". Because solicited-node multicast address is used in NS message of DAD,  hosts are seldom affected by DAD.
    So if there are many 0-suffix addresses in a subnet, solicited-node multicast address will  be useless and too many DADs disturb hosts.
   
    Could DAD NOT be performed on the IPv4 Embedded IPv6 Address?  IPv4 can play the same role of IPv6 DAD.
 
 
Guo Dayong
--Boundary_(ID_diy3g+EJ78y1W3QYzFR9Bw)-- From huitema@microsoft.com Mon Dec 14 20:15:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CBE3A6856; Mon, 14 Dec 2009 20:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX4OM+E33lir; Mon, 14 Dec 2009 20:15:54 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 646043A67A5; Mon, 14 Dec 2009 20:15:54 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 20:16:10 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 14 Dec 2009 20:15:41 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 14 Dec 2009 20:15:41 -0800 From: Christian Huitema To: Dayong Guo , "Internet-Drafts@ietf.org" Thread-Topic: [BEHAVE] DAD and draft-ietf-behave-address-format-02 Thread-Index: AQHKfTmkLqkl5MmaJESkRT0n0U3g2pFlfx5w Date: Tue, 15 Dec 2009 04:15:37 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211FB7CB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <20091214001518.C50223A680B@core3.amsl.com> <000d01ca7d39$919c7c00$cb0c6f0a@china.huawei.com> In-Reply-To: <000d01ca7d39$919c7c00$cb0c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] DAD and draft-ietf-behave-address-format-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 04:15:55 -0000 > draft-ietf-behave-address-format-02 recommends a zero suffix: " In > the other cases, the remaining bits of the addressconstitute the suffix. > These bits are reserved for future extensions, and SHOULD be set to a zer= o. The subnet prefix used on the link is supposedly the top level 64 bits of t= he IPv4 translatable IPv6 address. The host identifier is composed of bits = 64-127. In most cases, the zero suffix does not translate in a zero identif= ier. This is only a problem if the NSP is /32, an option that we do not in = fact recommend. -- Christian Huitema From guoseu@huawei.com Mon Dec 14 23:29:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963DD3A693D; Mon, 14 Dec 2009 23:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iaev48ATDWq; Mon, 14 Dec 2009 23:29:57 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BD71A3A6885; Mon, 14 Dec 2009 23:29:57 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00A2YNGOM3@szxga04-in.huawei.com>; Tue, 15 Dec 2009 15:29:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO0028RNGOMW@szxga04-in.huawei.com>; Tue, 15 Dec 2009 15:29:12 +0800 (CST) Received: from g57775 ([10.111.12.203]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00MAGNGNRA@szxml04-in.huawei.com>; Tue, 15 Dec 2009 15:29:12 +0800 (CST) Date: Tue, 15 Dec 2009 15:29:11 +0800 From: Dayong Guo In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA211FB7CB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , Internet-Drafts@ietf.org Message-id: <001901ca7d58$4c1614b0$cb0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AQHKfTmkLqkl5MmaJESkRT0n0U3g2pFlfx5wgAAgUJA= Cc: behave@ietf.org Subject: Re: [BEHAVE] DAD and draft-ietf-behave-address-format-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 07:29:58 -0000 see inline. > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Christian Huitema > Sent: Tuesday, December 15, 2009 12:16 PM > To: Dayong Guo; Internet-Drafts@ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] DAD and draft-ietf-behave-address-format-02 > > > > draft-ietf-behave-address-format-02 recommends a zero > suffix: " In > > the other cases, the remaining bits of the > addressconstitute the suffix. > > These bits are reserved for future extensions, and SHOULD > be set to a zero. > > The subnet prefix used on the link is supposedly the top > level 64 bits of the IPv4 translatable IPv6 address. The host > identifier is composed of bits 64-127. In most cases, the > zero suffix does not translate in a zero identifier. This is > only a problem if the NSP is /32, an option that we do not in > fact recommend. > RFC 4291 defines Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX. The "XX:XXXX" is low-order 24 bits of an IPv6 address. For example, several IPv4 embedded IPv6 addresses with 0 suffix in a share-link: 2001:DB8:102:30D:1:4403:: [embed IPv4: 13.1.68.3, PL: 2001:DB8:102:300::/56] 2001:DB8:102:30D:1:4404:: [embed IPv4: 13.1.68.4] 2001:DB8:102:30D:1:4405:: [embed IPv4: 13.1.68.5] ....... All of them derive the same Solicited-Node Address:FF02::1:FF00:0000. So each DAD disturbs all hosts in a subnet. I think that IPv4 Embedded IPv6 Addresses, except /96 prefix, have the same problem. Dayong Guo From xing@cernet.edu.cn Tue Dec 15 05:06:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457CB3A6836 for ; Tue, 15 Dec 2009 05:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.427 X-Spam-Level: * X-Spam-Status: No, score=1.427 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_40=-0.185, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cufGM4PM6W3e for ; Tue, 15 Dec 2009 05:06:24 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 35EE43A6A0A for ; Tue, 15 Dec 2009 05:06:21 -0800 (PST) Received: from [10.24.187.193]([117.136.1.157]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04b27e005; Tue, 15 Dec 2009 21:06:02 +0800 Message-ID: <4B2789B7.4020501@cernet.edu.cn> Date: Tue, 15 Dec 2009 21:05:59 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091211140848.8337.B01659E3@sablenetworks.net> <4B264D61.6060706@cernet.edu.cn> <20091215002417.836C.B01659E3@sablenetworks.net> In-Reply-To: <20091215002417.836C.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: UTSG7UXB Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv4 Type 3 Code 13-15 (draft-ietf-behave-v6v4-xlate-04) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 13:06:25 -0000 Hi, Kentaro, Kentaro Ebisawa $B Hi Xing, > > Based on the draft, I've compiled matrix of ICMPv4(v6) to ICMPv6(v4) > translation rules for all Type/Code registered to IANA. > # I can send you MS Excel version personally if you want one. > Thank you very much for this very useful matrix. Yes, please kindly send me a excel file. > Looking into the matrix, the only Type/Code not defined how to translate > are below ICMPv4 error messages. > > * Type 3, code 13,14,15 > * Type 6 > * Type 12, code 0,1,2 > > So it would be great if you can get consensus about how to handle above Type/Codes. > I will add your notes in the ppt file and ask for the consensus. > BTW, I've noted in the Matrix to drop all ICMP Types not mentioned in the > draft for ICMPv4 query, ICMPv6 informational and error messages since it's > mentioned in the draft. > > But it doesn't say anything about how to handle unkown Type/Codes for > ICMPv4 error messages. So I think it will be good idea to add text to the > draft to drop all unkown ICMPv4 error messages as well, in case there were > new ICMPv4 Type/Code defined in the future. > agree. > Regards, > regards, xing From root@core3.amsl.com Tue Dec 15 06:00:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 63F993A68E8; Tue, 15 Dec 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091215140001.63F993A68E8@core3.amsl.com> Date: Tue, 15 Dec 2009 06:00:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 14:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-03.txt Pages : 30 Date : 2009-12-15 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-dns64-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-15055736.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Tue Dec 15 06:27:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60EA3A6A4A for ; Tue, 15 Dec 2009 06:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IikA5zidWMGr for ; Tue, 15 Dec 2009 06:27:25 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A63AD3A6A2C for ; Tue, 15 Dec 2009 06:27:24 -0800 (PST) Received: from r190-135-61-177.dialup.adsl.anteldata.net.uy (r190-135-61-177.dialup.adsl.anteldata.net.uy [190.135.61.177]) by smtp01.uc3m.es (Postfix) with ESMTP id A2A0F67AC for ; Tue, 15 Dec 2009 15:27:07 +0100 (CET) Message-ID: <4B279CB9.2050702@it.uc3m.es> Date: Tue, 15 Dec 2009 15:27:05 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary="------------040906080601040403080707" Subject: [BEHAVE] [Fwd: I-D Action:draft-ietf-behave-dns64-03.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 14:27:26 -0000 This is a multi-part message in MIME format. --------------040906080601040403080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, we have submitted a new version of the dns64 document. We think this one is ready for WGLC, since we have addressed the few remaining issues that were discussed in hiroshima. Regards, marcelo -------- Mensaje original -------- Asunto: [BEHAVE] I-D Action:draft-ietf-behave-dns64-03.txt Fecha: Tue, 15 Dec 2009 06:00:01 -0800 (PST) De: Internet-Drafts@ietf.org Para: i-d-announce@ietf.org CC: behave@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-03.txt Pages : 30 Date : 2009-12-15 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040906080601040403080707 Content-Type: Message/External-body; name="draft-ietf-behave-dns64-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-behave-dns64-03.txt" Content-Type: text/plain Content-ID: <2009-12-15055736.I-D@ietf.org> --------------040906080601040403080707 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --------------040906080601040403080707-- From caozhenpku@gmail.com Tue Dec 15 07:02:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CED3A6A67 for ; Tue, 15 Dec 2009 07:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WxAc0IgqSEx for ; Tue, 15 Dec 2009 07:02:08 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 5B15D3A6A2B for ; Tue, 15 Dec 2009 07:02:08 -0800 (PST) Received: by pxi1 with SMTP id 1so3501936pxi.29 for ; Tue, 15 Dec 2009 07:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=EjPX3Po4rfXLN5aV29QXCtSRRMgT0grss4fBfzUzU5k=; b=iC33nupw5Nfj9BjTuMIXJy3dng/I+962iayXWxjz+kXzgTbI1a/QZZ6RqIvYit995i +Hkt2Ck6srxqqloeQq3VJsYNobwhhxzyJUuYpeEXOFnK1k8y3fN/pEW/KZBs6oxnChLm 7J9jjrPS8jTfMtHwhTwkRya3+ui6z+hqUk2Kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=s7efezfd2JyOE6tuIJLMpLD1yOx5VFJ/gifUpfeG7zzx0e34xu0qyFcflBNUAjHupC Bfro8UhXAF7dRrNleud1dkJrRWpuBtTtztmsPUvSnSqJIWfFXUzif05QJn0PTXHiOnIk AF6qeW2ASTGy9eQQPOjsq6XrmALB4QinHlLf4= MIME-Version: 1.0 Received: by 10.142.249.6 with SMTP id w6mr4215991wfh.346.1260889312681; Tue, 15 Dec 2009 07:01:52 -0800 (PST) Date: Tue, 15 Dec 2009 23:01:52 +0800 Message-ID: From: Zhen Cao To: Xing Li , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] Comments on the xlate draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 15:02:09 -0000 Hi All, Some comments on the draft before the interim meeting. 1. section1.3, when discussing the stateful and stateless mode, a reference to the framework draft is important because there is a clear definition of stateless and stateful translation. 2. section2.3 [page 13], handling of ICMPv4 error message to ICMPv6 on Code 4: I believe that adjust of the MTU should be the minimum of the original advertised MTU + 20, the translator's MTU on the IPv6 side and the translator's MTU on the IPv4 side+20, i.e. min (advertised MTU+20, MTU_t6, MTU_t4+20). That's what the xlate-stateful draft's wording. 3. section3.2 [page 20], handling of ICMPv6 error message to ICMPv4 on Type 2: similar to the above, min (advertised MTU-20, MTU_t4, MTU_t6-20). 4. section 5, for IPsec ESP tunnel model, "the ipv6 node needs to be able to generate an inner IPv4 header...", that's not possible IMO. The IPv6 application has no way to fill in the IPv4 inner address. Often, the tunnel insider ipv4 address is used for further routing at the IPsec terminator. Only if the client is using the IPv4 application could this case happen. So i think ESP tunnel cannot work through the translator. Thanks for discussion, Zhen From caozhenpku@gmail.com Tue Dec 15 08:04:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7B43A67DB for ; Tue, 15 Dec 2009 08:04:00 -0800 (PST) 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.753, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvPs0kP-R4ec for ; Tue, 15 Dec 2009 08:04:00 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 211573A62C1 for ; Tue, 15 Dec 2009 08:04:00 -0800 (PST) Received: by pzk6 with SMTP id 6so243pzk.29 for ; Tue, 15 Dec 2009 08:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ftPK1THJHg7Oui2k/Rxr70NCa+vSEW+WQCNZRHh/q70=; b=srdt9M4s/8XDZOx7fghlVtXVDwMuN4WEXov68KZJJ7f3fzKUC8jldTBlayjtfL0Wj/ +RXINWCwEzGpja6Yq7Z/moRz6yIlmUUDP0twvIa5+Jt3NR/eCVB8hlOicKeuAam8mH51 G0qrWBAqW0CJzaaG/9/Er8WykvqOqJ64wVvKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZWIBPgMKZuvpaFzgfVUSwfrBY+h0sf98nJYGwPaLfBDKJy19dQSlbKP09lGdz6Whr3 LFE5jiHmy7R1XlTFXUpDwuTNVp2pVWJK0iRYtGNIJ93BcA5KqrgOwrjg1WNhAvvQVGZ7 9k45sUSOPY/fpS1yO4I6R8dTnmT11Wv4BqzUM= MIME-Version: 1.0 Received: by 10.142.248.2 with SMTP id v2mr4300895wfh.177.1260893023926; Tue, 15 Dec 2009 08:03:43 -0800 (PST) Date: Wed, 16 Dec 2009 00:03:43 +0800 Message-ID: From: Zhen Cao To: marcelo bagnulo braun , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] Comments on NAT64 draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:04:01 -0000 Hi All, I have a short comment for the latest NAT64 draft relating to IPsec. 1. In section.5, it states: "this implies that end to end IPSec verification will fail when AH is used (both transport and tunnel mode) and when ESP is used in transport mode". For AH, this is correct. But for ESP, transport mode can be supported because the outer sider IP header is not counted into the secure computation. The xlate draft also states: "Note that ESP transport mode is easier to handle than ESP tunnel mode;" 2. In section 1.1, it says "some forms of IPsec support", and it might be too vague? Thanks and regards, Zhen From ebisawa@sablenetworks.net Tue Dec 15 09:31:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0173A6AB3 for ; Tue, 15 Dec 2009 09:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV66s6AXg0q8 for ; Tue, 15 Dec 2009 09:31:13 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id D03EE3A6AD8 for ; Tue, 15 Dec 2009 09:31:11 -0800 (PST) Received: (qmail 17472 invoked by SAV 20091215.021 by uid 0); 16 Dec 2009 02:30:57 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 16 Dec 2009 02:30:57 +0900 Date: Wed, 16 Dec 2009 02:30:28 +0900 From: Kentaro Ebisawa To: Xing Li , Simon Perreault In-Reply-To: <4B264BE4.1090807@cernet.edu.cn> References: <4B1FAD22.5040907@viagenie.ca> <4B264BE4.1090807@cernet.edu.cn> Message-Id: <20091216011653.8391.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:31:15 -0000 Hi, > For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if > there is a one-to-one relationship (defined in the sections 2.1 and 3.1 > in the xlate document) between IPv4 and IPv6 headers of the invoking > packet where the error was detected, the translator should translate the > packets from one address family to the other address family. I basically agree on above, but I think there are some cases which translated pointer value is identical from the type/code of the original message. Also, there are some cases which we can drop the packet before trying to translate the pointer. I think above cases would be better to be clearly defined in the xlate document to minimize ambiguity. Here are the 6 cases which pointer field needs to be updated for both [ICMPv4 -> ICMPv6] and [ICMPv6 -> ICMPv4] cases. [ICMPv4 -> ICMPv6] 1. protocol unreachable (3,2) | Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and | make the Pointer to point to the IPv6 Next Header field This is clearly defined. Keep it as is. For ICMPv4 Parameter Problem, Code is not defined as I mentioned in another thread. | Parameter Problem (Type 12) Set the Type field to 4. The | Pointer needs to be updated to point to the corresponding | field in the translated include IP header. So I think we can translate each code like below. 2. Pointer indicates the error (12,0) We can translate to ICMPv6 Type 4 Code 0 (Erroneous header field encountered) and update the pointer as defined in sections 2.1 and 3.1 in the xlate document. 3. Missing a Required Option (12,1) Do we have ICMPv6 Type Code corresponding to this ? If not, and if the case mentioned in RFC1108 2.8.1. is the only case this message is used, then I think we can drop this since we can not translate the "Option" anyway and thus don't have pointer value to be translated. Or should we leave this open to implementers ?? 4. Bad Length (12,2) I'm assuming the "Length" is "Total Length" and not IHL since we will have either malformed Options or payload if IHL was incorrect. In that case, I think we can translate this to Type 4, Code 0 and set pointer to 4 (IPv6 Payload Length) which corresponds to text like below : > Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and > make the Pointer to point to the IPv6 Payload Length field [ICMPv6 -> ICMPv4] Parameter Problem (Type 4), code 0,2 is the only case we need to update pointer for ICMPv6 to ICMPv4 translation. | Parameter Problem (Type 4) If the Code is 1, translate this to an | ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set | the Type to 12 and the Code to zero. The Pointer needs to be | updated to point to the corresponding field in the translated | inner IP header. 5. Erroneous header field encountered (4,0) I think we can translate to ICMPv4 Type 12, Code 0 and update the pointer as defined in sections 2.1 and 3.1 in the xlate document, as in the original text. 6. Unrecognized IPv6 option encountered (4,2) Since it is "Unrecognized" IPv6 option, I don't think we can translate the option to IPv4 and thus we can not translate the pointer value. If we are going to drop packets whoes pointer value could not be translated, then we would be always dropping this packet. So if I'm not missing something, I think we should replace the text to drop the packet. Regards, -- Kentaro Ebisawa On Mon, 14 Dec 2009 22:29:56 +0800 Xing Li wrote: > Simon Perreault $B > Xing Li wrote, on 2009-12-09 08:27: > > > >> For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if > >> there is a one-to-one relationship (defined in the xlate document) > >> > > > > Do you mean that it is already defined, or that it will eventually be defined? > > > > Because I don't see it in the draft right now. > > > > We mean: > > For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if > there is a one-to-one relationship (defined in the sections 2.1 and 3.1 > in the xlate document) between IPv4 and IPv6 headers of the invoking > packet where the error was detected, the translator should translate the > packets from one address family to the other address family. > > > > > >> between IPv4 and IPv6 headers of the invoking packet where the error was > >> detected, the translator should translate the packets from one address > >> family to the other address family. Otherwise, > >> > >> Option 1: > >> The translator passes the invoking packet where the error was detected > >> as opaque bit strings; this is likely to cause problems with processing > >> of those ICMPv6/ICMP Error messages. > >> > >> Option 2: > >> The translator silently drops the ICMP/ICMPv6 Error messages. > >> > >> Which option should we choose? Please comment. > >> > > > > My opinion: Option 2. Doing otherwise would be useless. > > > > Got the idea. > > xing > > > Simon > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Tue Dec 15 13:08:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDED3A682F for ; Tue, 15 Dec 2009 13:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GROaAap8RDm9 for ; Tue, 15 Dec 2009 13:08:02 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8384C3A67AF for ; Tue, 15 Dec 2009 13:08:01 -0800 (PST) Received: from r190-135-23-251.dialup.adsl.anteldata.net.uy (r190-135-23-251.dialup.adsl.anteldata.net.uy [190.135.23.251]) by smtp01.uc3m.es (Postfix) with ESMTP id DF24E7035; Tue, 15 Dec 2009 22:07:43 +0100 (CET) Message-ID: <4B27FA9E.1040206@it.uc3m.es> Date: Tue, 15 Dec 2009 22:07:42 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:08:03 -0000 Senthil Sivakumar (ssenthil) escribió: > Hi Marcelo, > Thanks for the response, please see inline for [Senthil] > > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, December 13, 2009 6:28 PM > To: Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt > > Hi, > > thanks for the review > > see replies below... > > Senthil Sivakumar (ssenthil) escribió: > >> General comments: >> ------------------ >> >> >> > I will try to address some of these here and other i will leave for the details comments below > > >> - What is the requirement for the different tables that the document >> presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64 >> to have all these tables? If so why? >> >> > The tables contain the information needed for the NAT64 to work. > I don't think you can make a NAT64 work with less information. > Do you think some of the information stored in the tables is not needed? > which one? > I would be glad to reduce the state needed by the NAT64, but i fail to see what can de dropped. > > [Senthil] My question was more in the lines of must every NAT64 device implement these 3 BIB tables and 3 Session tables. For example, you could achieve the same with 1 BIB table and 1 session table for TCP/UDP/ICMP. One could do it with 2 or 3 too. It depends on the implementation needs and constraints. I am wondering why do we specify 3 tables in the document. Instead we could refer to these as logical tables and leave it up to the implementation as to however one choose to implement as long as the behavior is the same. > sure, that is the intended meaning. I have added the follwoing text: These tables contain information needed for the NAT64 processing. The actual division of the information into six tables is done in order to ease the description of the NAT64 behaviour. NAT64 implementations MAY use different data structures as long as they store all the required information and the externally visible outcome is the same as the one described in this document. > >> - RFC4966 is mentioned in Section 1 and it is mentioned that a number >> of features have been added to overcome the reasons of deprecation of >> NAT-PT. I wonder if there should be a section discussing what has been >> overcome and how. >> > > Right, we could try to do this, if people find it important. Another thing that would be also interesting would be to explain how the NAT64 complies with the behave requirements for UDP, TCP and ICMP. > > Both of these excersises would be good to have in the document as appendixes. > > We should discuss this in the interim > > [Senthil] Ok, I would like to address the issues arised by RFC4966 in this document, even though I know a lot of issues mentioned in RFC4966 is generic to any NAT, I think it will useful to document that we have considered these issues and either addressed them or decided not to address them. > > > i have no issues with that > >> Section 1.2.3 >> >> I don't understand this >> >> "Filtering on the IPv6 interface is not supported, as mappings are >> only created by packets traveling in the IPv6 --> IPv4 direction." >> >> Can you explain why one cannot filter on ipv6 interface? >> >> >> > good question > NAT64 supports dynamically initiated connections only from the IPv6 side. So filtering on the IPv6 side seems some how orthogonal to the NAT behaviour. I mean you could do that, but you wouldn't be using NAT state in order to do so, i think. > OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot support communications iniitated in the IPv4 side, when there is a hole in the NAT opened by an IPv6 connection and because we are doing endpoint independent mappings, we end up with the question on whehter we do accept this new communication that has been initiated from the IPv4 side or not (keep in mind that this is possible only because there is a hole open and would not be possible in other case) > > So, while the NAT could filter in the IPv6 interface, this seems to be orthogonal to the NAT behaviour, but filtering in the IPv4 interface i tightly couple to the nat64 state, hence need to be specified. > > In any case, i have rephrased the previous sentence to > > Filtering of incoming IPv6 packets is not described in this specification. > > [Senthil] I guess I was thinking filtering even before the session can be created. > For example, one would want all the IPv6 hosts to have access to internet but except for a handful of specific hosts. Another filtering technique is all hosts are allowed except the ones that talk to a specific port or set of ports. These types of filtering is common and they protect the NAT64 resources (addresses & ports). > > in order to make it clearer that is not that is not supported, but that is not specified here. > right, i agree with that, but i still think this is orthogonal to the nat64 (e.g. firewalls have the same issues) so i am not sure what to say about this in the draft... any suggestion? >> Section 2 >> >> 3-Tuple & 5-tuple. >> >> Kind of confused here, in case of ICMP protocol is not a tuple and in >> case of TCP/UDP protocol is a tuple, why is that? >> >> > mmm, not sure what do you mean here. > In the terminology section it reads: > > 3-Tuple: The tuple (source IP address, destination IP address, Query > Identifier). A 3-tuple uniquely identifies an ICMP Query session. > When an ICMP Query session flows through a NAT64, each session has > two different 3-tuples: one with IPv4 addresses and one with IPv6 > addresses. > > 5-Tuple: The tuple (source IP address, source port, destination IP > address, destination port, transport protocol). A 5-tuple > uniquely identifies a UDP/TCP session. When a UDP/TCP session > flows through a NAT64, each session has two different 5-tuples: > one with IPv4 addresses and one with IPv6 addresses. > > So, the 3-tuple refers to the ICMP case. Not sure how to reword the document to make this more clear. > > >> There are two things that the tuple(s) are used for in this document. >> >> 1. To extract the required information from the packet. >> >> 2. To do a search in the database. >> >> For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address & >> port, Dst address & Port) >> >> 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. >> >> For doing a search and add/update/delete, since you have separate >> databases for TCP/UDP/ICMP, the search is based on 4 tuple for TCP/UDP >> and 3-tuple for ICMP. So I don't see why the 5-tuple searches >> mentioned in the later sections are required. >> >> >> > mmm, i see what you mean. > OTOH, you could think that you actually search using the 5-tuple, since the protocol value in the 5-tupel determines which table (UDP or TCP) you need to search. > We could use a 4-tuple for the 2 case, and we would need to define what the 4-tuple is and how it relates to the 5-tuple. IMHO, this would render the document less clear, but we can discuss further it you want. > > [Senthil] My confusion is this, if you have the tables as one big monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if not it is a 4-tuple search. The document calls for protocol specific tables but mentions 5-tuple search, which is inconsistent. The second inconsistency is 5-tuple search for tcp/udp but 3 tuple search for icmp. I mean, if it is a 5-tuple search for tcp/udp it should be a 4-tuple search for icmp. I feel it is more confusing if we leave it the way it is. We may want to ask WG if anyone else find this confusing or if it is just me. > i see what you mean, but i am not yet convinced this is an issue I mean, the 5-tuple is widely used, so using 4-tuple doesn't seem very intuitive to me Making searches using the 5-tuple, as i mentioned can be read as using the protocol value to select whic table you search and then using the 4 reamining values to search within the table. In the ICMP case, you don't need that cause there is only one table to search using the 3-tuple Don't get me wrong, i perfectly see the comment you make and i can see you can see it as an inconsistency. My comment is that people are used to use the 5-tuple for identifying connections, so using 4-tuples is not very intuitive, so i rather keep it as it is (even if this can be interpreted as the inconsistency you mention) > >> Section 3.2 >> >> Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64 >> and not stateless? >> >> >> > not sure if it applies to the stateless, it certainly applies to the statefull translator, agree? > > [Senthil] Yes, it definitely applies to stateful, I thought it will also apply to stateless and hence if it should belong in the stateless, maybe? > > maybe you should bring this issue as a comment to the stateless draft, not sure what i can do in the statefull draft w.r.t. this >> Section 3.2.1 >> >> Incoming IPv6 packet processing. >> >> Why should the search be based on the 5-tuple, since it is UDP session >> table the search is based on the 4-tuple of (SrcIP, DstIP, SrcPort, >> DstPort). >> >> Same comment on IPv4 packet processing. >> >> >> > right, see comment above > > >> Section 3.2.2 TCP handling. >> >> Lifetime: is a timer that tracks the remaining lifetime of the UDP >> >> Should be TCP above. >> >> >> > fixed > > >> Section 3.2.2 TCP states. >> >> What is the purpose of this section, does this document requires all >> NAT64 devices to track the sessions with the described state machine? >> Is it a MUST, SHOULD, MAY, recommend? >> >> > This is similar to the the TCP spec. It does have a state machine, you can implement it in this way, you could do it in a different way as long as the external behaviour is the same. > > This is captured in the draft in the following text: > > This breakdown of the NAT64 behavior into processing steps is done > for ease of presentation. A NAT64 MAY perform the steps in a different > order, or MAY perform different steps, as long as the externally > visible outcome is the same. > > >> Section 3.2.2 >> Paragraph starting "After bootstrapping...." >> >> What does it mean all TCP sessions are in closed state? Where is this >> tracked? >> >> > Again, this is similar to the TCP CLOSED state > > The closed state is somehow special, cause it means that there is no state for the particular connection. I have tried to make this clearer in the document by adding the following description: > > CLOSED: Analogous to , CLOSED is a fictional > because it represents the state when there is no state for this particular 5-tuple, and therefore, > no connection. > > > [Senthil] The state of a session is tracked via the session table, no. the state is tracked by the state. I mean, current session table does not have a "STATE" column defined.Additional data is needed to track the state, sicne the state a given connection is is a piece of information that needs to be stored somewhere. We could define all the data strcutures needed for the implementation, but i fail to see the need for that > but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. > > as i mentioned earlier, the CLOSED state is a fictional state (similar to the the one for TCP) that represents that there is no state for a connection. In other words, in a normal TCP stack (in any regular host, no nat64 involved) all non existent connections are in CLOSED state... so where does a TCP stack store the state for those connections? Nowhere, cause the CLOSED stated in fact means that there is no state. So, if there is no state, then it is closed state. Similar to the NAT64 >> The state of the TCP session is tracked within the TCP session table >> entry and state tracking starts when the entry is created and stops >> when the entry is destroyed. >> > mmm, i don't think you can keep track of all the state information using only the information stored in the session table. In order to keep track of the state informtation, you will likely have to keep track to the state information in addition to that information in the tables. > > [Senthil] Agreed, but the state information is keyed off of session table. That is, if you don't have a session entry you cannot(and don't have to) keep track state information for that session entry, > > see above, you don't need to track state for the entries that do not have a session table entry. If there is no state, then it is in closed state >> So what is this CLOSED state and where is it tracked? This is very >> unclear and confusing. >> >> >> > i hope this clarified with the text above. > > >> Section 3.2.2 >> >> "The state of the session is moved to V6 SYN RCV". Again where ? The >> text for the actual session creation is below this text and until the >> session is created where does this state hang off of? >> >> >> > I have moved the order to the sentence, so that first the session entry is created and then the sta > te is moved to V6 SYN RCV, would that help? > > [Senthil] Yes. > > >> Section 3.2.2 >> >> s/If such entry does not exists/If such an entry does not exist >> >> >> > fixed > > >> Section 3.2.2 >> "If the lifetime expires, the session table entry is deleted and the >> state is moved to CLOSED." >> >> Same comment as above, where is the state stored for this session? >> >> I will not repeat these comments in the subsequent text in the same >> section but this needs some serious explanation and clarifying. >> >> >> > I have made many changes aiming to clarify this in the 04 version. Could you check it and see if it clearer now? > > [Senthil] Ok, I will be travelling tomorrow, this would be a good read. > > >> Section 3.2.3 >> >> For port allocation, the text says if the port is even an even port >> must be allocated and same for odd. What if there are no even ports to >> allocate but there are odd ports, should the packet be dropped or >> allocated a odd port. I understand some application require that the >> port parity to be maintained but majority of the apps don't care. So >> making this a recommendation on the best effort basis is ok but making >> it a mandatory requirement sounds unreasonable. Note RFC 4787 >> recommends this behavior but this text mandates it. >> >> > Right, i have changed this to a should. > > [Senthil] I am thinking that this should be a configurable parameter, that is the admin can decide if the device should strictly allocate even-for-even and odd-for-odd or it should do the first available port. > > but that is not what is reccomended by the behave requirements, right? I mean, what is required is what you mentioned earlier and that i have tried to relfect in the document with the text above. If we want to reccomend something else than what is described in the behave requirements, then we need to go against prior consensus. We can do that, but it would require strong WG consenus. Regards, marcelo > Senthil > > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> > > > From marcelo@it.uc3m.es Tue Dec 15 13:51:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01B33A6925 for ; Tue, 15 Dec 2009 13:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KpYHoSJ7xtO for ; Tue, 15 Dec 2009 13:51:33 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 94C643A6912 for ; Tue, 15 Dec 2009 13:51:33 -0800 (PST) Received: from r190-135-23-251.dialup.adsl.anteldata.net.uy (r190-135-23-251.dialup.adsl.anteldata.net.uy [190.135.23.251]) by smtp02.uc3m.es (Postfix) with ESMTP id 5D6A26C3539; Tue, 15 Dec 2009 22:51:15 +0100 (CET) Message-ID: <4B2804D1.9010509@it.uc3m.es> Date: Tue, 15 Dec 2009 22:51:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17072.000 Cc: Behave WG Subject: Re: [BEHAVE] Comments on NAT64 draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:51:34 -0000 Hi, thanks for the comments, see below... Zhen Cao escribió: > Hi All, > > I have a short comment for the latest NAT64 draft relating to IPsec. > > 1. In section.5, it states: "this implies that end to end IPSec > verification will fail when AH is used (both transport and tunnel > mode) and when ESP is used in transport mode". right, this was ESP in tunnel mode, since the inner header cannot be translated by the NAT64 in that case. I fixed that > For AH, this is > correct. But for ESP, transport mode can be supported because the > outer sider IP header is not counted into the secure computation. The > xlate draft also states: "Note that ESP transport mode is easier to > handle than ESP tunnel mode;" > > > 2. In section 1.1, it says "some forms of IPsec support", and it might > be too vague? > > right, it is vague, because is not defined in thsi document. I will add comment stating that the IPsec support is out of the scope of this specification (as agreed by the WG in the dublin meeting) Regards, marcelo > Thanks and regards, > Zhen > > From brian.e.carpenter@gmail.com Tue Dec 15 13:54:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899423A6B0B for ; Tue, 15 Dec 2009 13:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbJ6c-JHEahb for ; Tue, 15 Dec 2009 13:54:48 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 9A3B83A6AFA for ; Tue, 15 Dec 2009 13:54:48 -0800 (PST) Received: by pwi20 with SMTP id 20so222383pwi.29 for ; Tue, 15 Dec 2009 13:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G0xez1GZCBWqN/O+TijfzofdHMxWBLeVejd7RQ9BzQg=; b=uzihJhRZIFQ3jPKKeArE8fUHU1zVnkZQiWmPnPooe5aomt7miAIZ+OMW4tBd8+yvXx UoEhai4iFd11caIN98CsxABpCupma4p8DPHFDbz6F1rRHV/OJGwYmT10NGFXk6o7nHX/ dxrD+PCuqMt/o+v6D31bsEMjVK60Wv8hCPCdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=szhrpTIb5ShrNLlHEqL8hKb/Z9nqMA0kKgTjTCgST2JMJ4iYlsE7lt6oQ4IfEyRdGs //gsaafUYaZl6JcInXwR+PVVUltEacH6SAiFRWyr3eaaioenRGRYHrzXT5WmtIxqIKeH fUujcTHbZ+Mxf+Y0yK+XWSrYrUxvYpVbyZXtY= Received: by 10.142.4.24 with SMTP id 24mr78236wfd.109.1260914072344; Tue, 15 Dec 2009 13:54:32 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm162238pzk.5.2009.12.15.13.54.30 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 13:54:31 -0800 (PST) Message-ID: <4B280594.3070502@gmail.com> Date: Wed, 16 Dec 2009 10:54:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> <4B27FA9E.1040206@it.uc3m.es> In-Reply-To: <4B27FA9E.1040206@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: [BEHAVE] Tuples [Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:54:49 -0000 On 2009-12-16 10:07, marcelo bagnulo braun wrote: > Senthil Sivakumar (ssenthil) escribi=C3=B3: =2E.. >>> Section 2 >>> >>> 3-Tuple & 5-tuple. >>> >>> Kind of confused here, in case of ICMP protocol is not a tuple and in= >>> case of TCP/UDP protocol is a tuple, why is that? >>> =20 >> mmm, not sure what do you mean here. >> In the terminology section it reads: >> >> 3-Tuple: The tuple (source IP address, destination IP address, Que= ry >> Identifier). A 3-tuple uniquely identifies an ICMP Query sessio= n. >> When an ICMP Query session flows through a NAT64, each session h= as >> two different 3-tuples: one with IPv4 addresses and one with IPv= 6 >> addresses. >> >> 5-Tuple: The tuple (source IP address, source port, destination IP= >> address, destination port, transport protocol). A 5-tuple >> uniquely identifies a UDP/TCP session. When a UDP/TCP session >> flows through a NAT64, each session has two different 5-tuples: >> one with IPv4 addresses and one with IPv6 addresses. >> >> So, the 3-tuple refers to the ICMP case. Not sure how to reword the >> document to make this more clear. >> >> =20 >>> There are two things that the tuple(s) are used for in this document.= >>> >>> 1. To extract the required information from the packet. >>> >>> 2. To do a search in the database. >>> >>> For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address & >>> port, Dst address & Port) >>> >>> 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. >>> >>> For doing a search and add/update/delete, since you have separate >>> databases for TCP/UDP/ICMP, the search is based on 4 tuple for >>> TCP/UDP and 3-tuple for ICMP. So I don't see why the 5-tuple searches= >>> mentioned in the later sections are required. >>> >>> =20 >> mmm, i see what you mean. >> OTOH, you could think that you actually search using the 5-tuple, >> since the protocol value in the 5-tupel determines which table (UDP or= >> TCP) you need to search. >> We could use a 4-tuple for the 2 case, and we would need to define >> what the 4-tuple is and how it relates to the 5-tuple. IMHO, this >> would render the document less clear, but we can discuss further it >> you want. >> >> [Senthil] My confusion is this, if you have the tables as one big >> monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if= >> not it is a 4-tuple search. The document calls for protocol specific >> tables but mentions 5-tuple search, which is inconsistent. The second >> inconsistency is 5-tuple search for tcp/udp but 3 tuple search for >> icmp. I mean, if it is a 5-tuple search for tcp/udp it should be a >> 4-tuple search for icmp. I feel it is more confusing if we leave it >> the way it is. We may want to ask WG if anyone else find this >> confusing or if it is just me. >> =20 >=20 > i see what you mean, but i am not yet convinced this is an issue > I mean, the 5-tuple is widely used, so using 4-tuple doesn't seem very > intuitive to me > Making searches using the 5-tuple, as i mentioned can be read as using > the protocol value to select whic table you search and then using the 4= > reamining values to search within the table. > In the ICMP case, you don't need that cause there is only one table to > search using the 3-tuple >=20 > Don't get me wrong, i perfectly see the comment you make and i can see > you can see it as an inconsistency. > My comment is that people are used to use the 5-tuple for identifying > connections, so using 4-tuples is not very intuitive, so i rather keep > it as it is (even if this can be interpreted as the inconsistency you > mention) Just to add some more confusion, we could also imagine a situation in the future where non-zero flow labels are found in the incoming IPv6 packets. Theoretically, that allows a different 3-tuple {src, dest, flow_label}. I'm not sure we want to talk that, but an implementation note recommending flexibility in the n-tuple design might be useful. Brian From root@core3.amsl.com Tue Dec 15 14:00:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D26A53A6B12; Tue, 15 Dec 2009 14:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091215220001.D26A53A6B12@core3.amsl.com> Date: Tue, 15 Dec 2009 14:00:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-05.txt Pages : 41 Date : 2009-12-15 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how it should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-15135708.I-D@ietf.org> --NextPart-- From ssenthil@cisco.com Tue Dec 15 21:21:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CAA3A689E for ; Tue, 15 Dec 2009 21:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeLHY9V8gIwa for ; Tue, 15 Dec 2009 21:21:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2704A3A6AF8 for ; Tue, 15 Dec 2009 21:21:01 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAr9J0urR7H+/2dsb2JhbAC+L5chhCsEgWI X-IronPort-AV: E=Sophos;i="4.47,404,1257120000"; d="scan'208";a="450317554" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Dec 2009 05:20:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBG5KlSI018891; Wed, 16 Dec 2009 05:20:47 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 21:20:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 21:20:44 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB090569E1@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4B27FA9E.1040206@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt Thread-Index: Acp9yrUiwf2RdRQiRj61PQ9O9vCyjwAQhPmQ References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> <4B27FA9E.1040206@it.uc3m.es> From: "Senthil Sivakumar (ssenthil)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 16 Dec 2009 05:20:47.0532 (UTC) FILETIME=[863E4EC0:01CA7E0F] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 05:21:03 -0000 =20 -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Tuesday, December 15, 2009 4:08 PM To: Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on = draft-ietf-behave-v6v4-xlate-stateful-03.txt Senthil Sivakumar (ssenthil) escribi=F3: > Hi Marcelo, > Thanks for the response, please see inline for [Senthil] > > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, December 13, 2009 6:28 PM > To: Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on=20 > draft-ietf-behave-v6v4-xlate-stateful-03.txt > > Hi, > > thanks for the review > > see replies below... > > Senthil Sivakumar (ssenthil) escribi=F3: > =20 >> General comments: >> ------------------ >> >> =20 >> =20 > I will try to address some of these here and other i will leave for=20 > the details comments below > > =20 >> - What is the requirement for the different tables that the document=20 >> presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64=20 >> to have all these tables? If so why? >> =20 >> =20 > The tables contain the information needed for the NAT64 to work. > I don't think you can make a NAT64 work with less information. > Do you think some of the information stored in the tables is not = needed?=20 > which one? > I would be glad to reduce the state needed by the NAT64, but i fail to = see what can de dropped. > > [Senthil] My question was more in the lines of must every NAT64 device = implement these 3 BIB tables and 3 Session tables. For example, you = could achieve the same with 1 BIB table and 1 session table for = TCP/UDP/ICMP. One could do it with 2 or 3 too. It depends on the = implementation needs and constraints. I am wondering why do we specify 3 = tables in the document. Instead we could refer to these as logical = tables and leave it up to the implementation as to however one choose to = implement as long as the behavior is the same. > =20 sure, that is the intended meaning. I have added the follwoing text: These tables contain information needed for the NAT64 = processing. The actual division of the information into six tables is done in = order to ease the description of the NAT64 behaviour. NAT64 implementations = MAY use different data structures as long as they store all the required information and the = externally visible outcome is the same as the one described in this = document. > >> - RFC4966 is mentioned in Section 1 and it is mentioned that a number = >> of features have been added to overcome the reasons of deprecation of = >> NAT-PT. I wonder if there should be a section discussing what has=20 >> been overcome and how. >> =20 > > Right, we could try to do this, if people find it important. Another = thing that would be also interesting would be to explain how the NAT64 = complies with the behave requirements for UDP, TCP and ICMP. > > Both of these excersises would be good to have in the document as = appendixes. > > We should discuss this in the interim > > [Senthil] Ok, I would like to address the issues arised by RFC4966 in = this document, even though I know a lot of issues mentioned in RFC4966 = is generic to any NAT, I think it will useful to document that we have = considered these issues and either addressed them or decided not to = address them. > > > =20 i have no issues with that > >> Section 1.2.3 >> >> I don't understand this >> >> "Filtering on the IPv6 interface is not supported, as mappings are=20 >> only created by packets traveling in the IPv6 --> IPv4 direction." >> >> Can you explain why one cannot filter on ipv6 interface? >> >> =20 >> =20 > good question > NAT64 supports dynamically initiated connections only from the IPv6 = side. So filtering on the IPv6 side seems some how orthogonal to the NAT = behaviour. I mean you could do that, but you wouldn't be using NAT state = in order to do so, i think. > OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot = > support communications iniitated in the IPv4 side, when there is a=20 > hole in the NAT opened by an IPv6 connection and because we are doing=20 > endpoint independent mappings, we end up with the question on whehter=20 > we do accept this new communication that has been initiated from the=20 > IPv4 side or not (keep in mind that this is possible only because=20 > there is a hole open and would not be possible in other case) > > So, while the NAT could filter in the IPv6 interface, this seems to be = orthogonal to the NAT behaviour, but filtering in the IPv4 interface i = tightly couple to the nat64 state, hence need to be specified. > > In any case, i have rephrased the previous sentence to > > Filtering of incoming IPv6 packets is not described in this = specification. > > [Senthil] I guess I was thinking filtering even before the session can = be created.=20 > For example, one would want all the IPv6 hosts to have access to = internet but except for a handful of specific hosts. Another filtering = technique is all hosts are allowed except the ones that talk to a = specific port or set of ports. These types of filtering is common and = they protect the NAT64 resources (addresses & ports).=20 > > in order to make it clearer that is not that is not supported, but = that is not specified here. > =20 right, i agree with that, but i still think this is orthogonal to the nat64 (e.g. firewalls have the same issues) so i am not sure what to say = about this in the draft... any suggestion? [Senthil] True. I was thinking some text along these lines. "NAT64 device can do filtering of IPv6 packets based on the = administrative rules to create BIB and session entries. The filtering = can be flexible enough and broad enough but the idea of the filtering is = to provide the operators necessary control to avoid DoS attacks that = would result in exhaustion of NAT64 address, port, memory and CPU = resources". >> Section 2 >> >> 3-Tuple & 5-tuple. >> >> Kind of confused here, in case of ICMP protocol is not a tuple and in = >> case of TCP/UDP protocol is a tuple, why is that? >> =20 >> =20 > mmm, not sure what do you mean here. > In the terminology section it reads: > > 3-Tuple: The tuple (source IP address, destination IP address, = Query > Identifier). A 3-tuple uniquely identifies an ICMP Query = session. > When an ICMP Query session flows through a NAT64, each session = has > two different 3-tuples: one with IPv4 addresses and one with = IPv6 > addresses. > > 5-Tuple: The tuple (source IP address, source port, destination IP > address, destination port, transport protocol). A 5-tuple > uniquely identifies a UDP/TCP session. When a UDP/TCP session > flows through a NAT64, each session has two different 5-tuples: > one with IPv4 addresses and one with IPv6 addresses. > > So, the 3-tuple refers to the ICMP case. Not sure how to reword the = document to make this more clear. > > =20 >> There are two things that the tuple(s) are used for in this document. >> >> 1. To extract the required information from the packet. >> >> 2. To do a search in the database. >> >> For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address &=20 >> port, Dst address & Port) >> >> 4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID. >> >> For doing a search and add/update/delete, since you have separate=20 >> databases for TCP/UDP/ICMP, the search is based on 4 tuple for=20 >> TCP/UDP and 3-tuple for ICMP. So I don't see why the 5-tuple searches = >> mentioned in the later sections are required. >> >> =20 >> =20 > mmm, i see what you mean. > OTOH, you could think that you actually search using the 5-tuple, = since the protocol value in the 5-tupel determines which table (UDP or = TCP) you need to search. > We could use a 4-tuple for the 2 case, and we would need to define = what the 4-tuple is and how it relates to the 5-tuple. IMHO, this would = render the document less clear, but we can discuss further it you want. > > [Senthil] My confusion is this, if you have the tables as one big = monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if = not it is a 4-tuple search. The document calls for protocol specific = tables but mentions 5-tuple search, which is inconsistent. The second = inconsistency is 5-tuple search for tcp/udp but 3 tuple search for icmp. = I mean, if it is a 5-tuple search for tcp/udp it should be a 4-tuple = search for icmp. I feel it is more confusing if we leave it the way it = is. We may want to ask WG if anyone else find this confusing or if it is = just me. > =20 i see what you mean, but i am not yet convinced this is an issue I mean, = the 5-tuple is widely used, so using 4-tuple doesn't seem very intuitive = to me Making searches using the 5-tuple, as i mentioned can be read as = using the protocol value to select whic table you search and then using = the 4 reamining values to search within the table. In the ICMP case, you don't need that cause there is only one table to = search using the 3-tuple Don't get me wrong, i perfectly see the comment you make and i can see = you can see it as an inconsistency. My comment is that people are used to use the 5-tuple for identifying = connections, so using 4-tuples is not very intuitive, so i rather keep = it as it is (even if this can be interpreted as the inconsistency you mention) [Senthil] Actually most TCP stack implementors use 4-tuple a lot, but I = agree with you that in NAT world we do use 5-tuple. But as Brian = Carpenter has indicated in another email we have more tuples depending = on existing needs & future needs. In many Cisco NAT devices we currently = have 6-tuple searches. In any case, I would be fine if the consensus of = the working group is to leave it as is and it is not confusing.=20 > =20 >> Section 3.2 >> >> Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64 = >> and not stateless? >> >> =20 >> =20 > not sure if it applies to the stateless, it certainly applies to the = statefull translator, agree? > > [Senthil] Yes, it definitely applies to stateful, I thought it will = also apply to stateless and hence if it should belong in the stateless, = maybe?=20 > > =20 maybe you should bring this issue as a comment to the stateless draft, = not sure what i can do in the statefull draft w.r.t. this [Senthil] Ok, will do.=20 >> Section 3.2.1 >> >> Incoming IPv6 packet processing. >> >> Why should the search be based on the 5-tuple, since it is UDP=20 >> session table the search is based on the 4-tuple of (SrcIP, DstIP,=20 >> SrcPort, DstPort). >> >> Same comment on IPv4 packet processing. >> >> =20 >> =20 > right, see comment above > > =20 >> Section 3.2.2 TCP handling. >> >> Lifetime: is a timer that tracks the remaining lifetime of the UDP >> >> Should be TCP above. >> >> =20 >> =20 > fixed > > =20 >> Section 3.2.2 TCP states. >> >> What is the purpose of this section, does this document requires all >> NAT64 devices to track the sessions with the described state machine? = >> Is it a MUST, SHOULD, MAY, recommend? >> =20 >> =20 > This is similar to the the TCP spec. It does have a state machine, you = can implement it in this way, you could do it in a different way as long = as the external behaviour is the same. > > This is captured in the draft in the following text: > > This breakdown of the NAT64 behavior into processing steps = is done > for ease of presentation. A NAT64 MAY perform the steps in a = different > order, or MAY perform different steps, as long as the = externally > visible outcome is the same. > > =20 >> Section 3.2.2 >> Paragraph starting "After bootstrapping...." >> >> What does it mean all TCP sessions are in closed state? Where is this = >> tracked? >> =20 >> =20 > Again, this is similar to the TCP CLOSED state > > The closed state is somehow special, cause it means that there is no = state for the particular connection. I have tried to make this clearer = in the document by adding the following description: > > CLOSED: Analogous to , CLOSED is a fictional > because it represents the state when there is no = state for this particular 5-tuple, and therefore, > no connection. > > > [Senthil] The state of a session is tracked via the session table, no. the state is tracked by the state. I mean, current session table does = not have a "STATE" column defined.Additional data is needed to track the = state, sicne the state a given connection is is a piece of information = that needs to be stored somewhere. We could define all the data = strcutures needed for the implementation, but i fail to see the need for = that [Senthil] Let me ask you this, as an implementor when the doc says = "After bootstrapping all the devices should set its connection state for = all the sessions to CLOSED." How do I do that?=20 Again, I didn't mean to say the state should be tracked within a = session, but the state is per-session and hence keyed off of the = session. You cant get to the state of the session without knowing what = the session keys are.=20 > but the text indicates that all the TCP sessions are in closed state. = My question is what is this "all TCP sessions" and how do you track a = session state without a session.=20 > > =20 as i mentioned earlier, the CLOSED state is a fictional state (similar = to the the one for TCP) that represents that there is no state for a = connection. In other words, in a normal TCP stack (in any regular host, no nat64 involved) all non existent connections are in CLOSED state... so where = does a TCP stack store the state for those connections? Nowhere, cause = the CLOSED stated in fact means that there is no state. [Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and = there is a time period when the connections are in CLOSED state. (I = don't recall the whole state diagram now) but the CLOSED state is tied = to an existing TCP session at some point of time in the life cycle of = the connection. Is there a state progression for the TCP states in = NAT64 too, if so I must have missed that. So, if there is no state, then it is closed state. Similar to the NAT64 >> The state of the TCP session is tracked within the TCP session table=20 >> entry and state tracking starts when the entry is created and stops=20 >> when the entry is destroyed. >> =20 > mmm, i don't think you can keep track of all the state information = using only the information stored in the session table. In order to keep = track of the state informtation, you will likely have to keep track to = the state information in addition to that information in the tables. > > [Senthil] Agreed, but the state information is keyed off of session=20 > table. That is, if you don't have a session entry you cannot(and don't = > have to) keep track state information for that session entry, > > =20 see above, you don't need to track state for the entries that do not = have a session table entry. If there is no state, then it is in closed = state >> So what is this CLOSED state and where is it tracked? This is very=20 >> unclear and confusing. >> >> =20 >> =20 > i hope this clarified with the text above. > > =20 >> Section 3.2.2 >> >> "The state of the session is moved to V6 SYN RCV". Again where ? The=20 >> text for the actual session creation is below this text and until the = >> session is created where does this state hang off of? >> >> =20 >> =20 > I have moved the order to the sentence, so that first the session=20 > entry is created and then the sta te is moved to V6 SYN RCV, would = that help? > > [Senthil] Yes.=20 > > =20 >> Section 3.2.2 >> >> s/If such entry does not exists/If such an entry does not exist >> >> =20 >> =20 > fixed > > =20 >> Section 3.2.2 >> "If the lifetime expires, the session table entry is deleted and the=20 >> state is moved to CLOSED." >> >> Same comment as above, where is the state stored for this session?=20 >> >> I will not repeat these comments in the subsequent text in the same=20 >> section but this needs some serious explanation and clarifying. >> >> =20 >> =20 > I have made many changes aiming to clarify this in the 04 version. = Could you check it and see if it clearer now? > > [Senthil] Ok, I will be travelling tomorrow, this would be a good = read. > > =20 >> Section 3.2.3 >> >> For port allocation, the text says if the port is even an even port=20 >> must be allocated and same for odd. What if there are no even ports=20 >> to allocate but there are odd ports, should the packet be dropped or=20 >> allocated a odd port. I understand some application require that the=20 >> port parity to be maintained but majority of the apps don't care. So=20 >> making this a recommendation on the best effort basis is ok but=20 >> making it a mandatory requirement sounds unreasonable. Note RFC 4787=20 >> recommends this behavior but this text mandates it. >> =20 >> =20 > Right, i have changed this to a should. > > [Senthil] I am thinking that this should be a configurable parameter, = that is the admin can decide if the device should strictly allocate = even-for-even and odd-for-odd or it should do the first available port.=20 > > =20 but that is not what is reccomended by the behave requirements, right? I mean, what is required is what you mentioned earlier and that i have = tried to relfect in the document with the text above. If we want to reccomend something else than what is described in the = behave requirements, then we need to go against prior consensus. We can = do that, but it would require strong WG consenus. [Senthil] From RFC4787, REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes". It does not say SHOULD. So what you have in this draft is going above = what has been said in the RFC4787. Thanks Senthil Regards, marcelo > Senthil > > =20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> =20 >> =20 > > > =20 From rpenno@juniper.net Tue Dec 15 21:42:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0603F3A6A48 for ; Tue, 15 Dec 2009 21:42:54 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY0xcXx3kxTq for ; Tue, 15 Dec 2009 21:42:53 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id DA7BF3A6968 for ; Tue, 15 Dec 2009 21:42:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSyhzToSlrIbm5X7JZ2o8FslxZLmHmm/E@postini.com; Tue, 15 Dec 2009 21:42:39 PST 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.1.393.1; Tue, 15 Dec 2009 21:41:52 -0800 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, 16 Dec 2009 00:41:51 -0500 From: Reinaldo Penno To: "behave@ietf.org" Date: Wed, 16 Dec 2009 00:41:47 -0500 Thread-Topic: Analysis of 64 Translation Thread-Index: Acp9/2M/BcY/a8aMQZCGVtyTc2BQKQAExGwU Message-ID: In-Reply-To: <20091216032451.05E593A6935@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Analysis of 64 Translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 05:42:54 -0000 Hello, We submitted a new draft with the purpose to analyze the 64 stateful solution and foster a structured discussion around the benefits of the solution. Thanks, Reinaldo http://www.ietf.org/id/draft-penno-behave-64-analysis-00.txt From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D Action:draft-penno-behave-64-analysis-00.txt X-RSN: 1/0/935/27926/31280 X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D31280 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : Analysis of 64 Translation Author(s) : R. Penno, et al. Filename : draft-penno-behave-64-analysis-00.txt Pages : 10=20 Date : 2009-12-15=20 =20 Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6/IPv4 translation. Since then, new work has commenced which standardizes new mechanisms to perform IPv6/IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.=20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-behave-64-analysis-00.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.=20 From xing@cernet.edu.cn Wed Dec 16 01:07:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5493A693C for ; Wed, 16 Dec 2009 01:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H3WnR7Ij8Dw for ; Wed, 16 Dec 2009 01:07:19 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 68D163A67D8 for ; Wed, 16 Dec 2009 01:07:16 -0800 (PST) Received: from [59.67.46.216]([59.67.46.216]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b28c251; Wed, 16 Dec 2009 17:06:59 +0800 Message-ID: <4B288F03.8010109@cernet.edu.cn> Date: Wed, 16 Dec 2009 15:40:51 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <4B1FAD22.5040907@viagenie.ca> <4B264BE4.1090807@cernet.edu.cn> <20091216011653.8391.B01659E3@sablenetworks.net> In-Reply-To: <20091216011653.8391.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 4B5qpUXB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:07:20 -0000 Kentaro Ebisawa $B Hi, > > >> For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if >> there is a one-to-one relationship (defined in the sections 2.1 and 3.1 >> in the xlate document) between IPv4 and IPv6 headers of the invoking >> packet where the error was detected, the translator should translate the >> packets from one address family to the other address family. >> > > I basically agree on above, but I think there are some cases which > translated pointer value is identical from the type/code of the original > message. Also, there are some cases which we can drop the packet before > trying to translate the pointer. > > I think above cases would be better to be clearly defined in the xlate > document to minimize ambiguity. > > > Here are the 6 cases which pointer field needs to be updated for both > [ICMPv4 -> ICMPv6] and [ICMPv6 -> ICMPv4] cases. > > > [ICMPv4 -> ICMPv6] > > 1. protocol unreachable (3,2) > | Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and > | make the Pointer to point to the IPv6 Next Header field > This is clearly defined. Keep it as is. > > > For ICMPv4 Parameter Problem, Code is not defined as I mentioned in > another thread. > | Parameter Problem (Type 12) Set the Type field to 4. The > | Pointer needs to be updated to point to the corresponding > | field in the translated include IP header. > > So I think we can translate each code like below. > > > 2. Pointer indicates the error (12,0) > We can translate to ICMPv6 Type 4 Code 0 (Erroneous header field > encountered) and update the pointer as defined in sections 2.1 > and 3.1 in the xlate document. > > > 3. Missing a Required Option (12,1) > Do we have ICMPv6 Type Code corresponding to this ? > If not, and if the case mentioned in RFC1108 2.8.1. is the only case > this message is used, then I think we can drop this since we can not > translate the "Option" anyway and thus don't have pointer value to > be translated. > > Or should we leave this open to implementers ?? > > > 4. Bad Length (12,2) > I'm assuming the "Length" is "Total Length" and not IHL since we will > have either malformed Options or payload if IHL was incorrect. In that > case, I think we can translate this to Type 4, Code 0 and set pointer > to 4 (IPv6 Payload Length) which corresponds to text like below : > > > Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and > > make the Pointer to point to the IPv6 Payload Length field > > > [ICMPv6 -> ICMPv4] > Parameter Problem (Type 4), code 0,2 is the only case we need to > update pointer for ICMPv6 to ICMPv4 translation. > | Parameter Problem (Type 4) If the Code is 1, translate this to an > | ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set > | the Type to 12 and the Code to zero. The Pointer needs to be > | updated to point to the corresponding field in the translated > | inner IP header. > > 5. Erroneous header field encountered (4,0) > I think we can translate to ICMPv4 Type 12, Code 0 and update the > pointer as defined in sections 2.1 and 3.1 in the xlate document, > as in the original text. > > 6. Unrecognized IPv6 option encountered (4,2) > Since it is "Unrecognized" IPv6 option, I don't think we can translate > the option to IPv4 and thus we can not translate the pointer value. > If we are going to drop packets whoes pointer value could not be > translated, then we would be always dropping this packet. > > So if I'm not missing something, I think we should replace the text > to drop the packet. > > > Regards, > From rpenno@juniper.net Wed Dec 16 01:51:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA36C3A69D8 for ; Wed, 16 Dec 2009 01:51:59 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STeryxyMOX-t for ; Wed, 16 Dec 2009 01:51:59 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with SMTP id 3CC473A68B3 for ; Wed, 16 Dec 2009 01:51:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSyitnTL7Q7v+2mc37SIkcFKEeKu8jv+a@postini.com; Wed, 16 Dec 2009 01:51:26 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 16 Dec 2009 01:49:27 -0800 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, 16 Dec 2009 04:49:26 -0500 From: Reinaldo Penno To: "behave@ietf.org" Date: Wed, 16 Dec 2009 04:49:23 -0500 Thread-Topic: TCP RST RCV in v6v4-xlate-stateful-05 Thread-Index: Acp9/2M/BcY/a8aMQZCGVtyTc2BQKQAExGwUAAiluNw= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:52:00 -0000 Hello, The current draft states that: " If a packet other than a RST packet is received, the lifetime is set to at least 2 hours and 4 min and the state is moved to ESTABLISHED. If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED. " Let's suppose B in the IPv4 world sends a RST to A in IPv6 and we move into a RST RCV state.=20 If after that you only receive packets in the B->A direction, should the session be kept open? Wouldn't that be an indication that A accepted the RS= T and/or in general is not in the picture anymore? Finally it says ' If a packet other than a RST packet is received". If B sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the connection open?=20 This is my understanding of TCP RST processing: If host B sends a RST that is accepted by A, any other packets after that would not get processed by A. All of TCP control state is removed as soon a= s the TCP RST is accepted. And if the RST is not accepted by A, this was B's original intention so it will not be sending any more packets after that. NAT behavior: Therefore, for a NAT device without keep-alives that cannot make an assessment whether the TCP RST was accepted or not, keeping the connection open if any packet gets received does not seem to serve a purpose. I would suggest the following: " =20 If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED. " In other words, we remove the session entry after 4 minutes. Thanks, Reinaldo From marcelo@it.uc3m.es Wed Dec 16 05:01:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF7F3A68A2 for ; Wed, 16 Dec 2009 05:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gvkPuh74Obg for ; Wed, 16 Dec 2009 05:01:27 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id EA75E3A63C9 for ; Wed, 16 Dec 2009 05:01:26 -0800 (PST) Received: from r190-135-63-62.dialup.adsl.anteldata.net.uy (r190-135-63-62.dialup.adsl.anteldata.net.uy [190.135.63.62]) by smtp02.uc3m.es (Postfix) with ESMTP id A4BD56C2F08; Wed, 16 Dec 2009 14:01:08 +0100 (CET) Message-ID: <4B28DA13.8020903@it.uc3m.es> Date: Wed, 16 Dec 2009 14:01:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> <4B27FA9E.1040206@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB090569E1@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB090569E1@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17072.007 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:01:28 -0000 Senthil Sivakumar (ssenthil) escribió: > > > >>> Section 1.2.3 >>> >>> I don't understand this >>> >>> "Filtering on the IPv6 interface is not supported, as mappings are >>> only created by packets traveling in the IPv6 --> IPv4 direction." >>> >>> Can you explain why one cannot filter on ipv6 interface? >>> >>> >>> >>> >> good question >> NAT64 supports dynamically initiated connections only from the IPv6 side. So filtering on the IPv6 side seems some how orthogonal to the NAT behaviour. I mean you could do that, but you wouldn't be using NAT state in order to do so, i think. >> OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot >> support communications iniitated in the IPv4 side, when there is a >> hole in the NAT opened by an IPv6 connection and because we are doing >> endpoint independent mappings, we end up with the question on whehter >> we do accept this new communication that has been initiated from the >> IPv4 side or not (keep in mind that this is possible only because >> there is a hole open and would not be possible in other case) >> >> So, while the NAT could filter in the IPv6 interface, this seems to be orthogonal to the NAT behaviour, but filtering in the IPv4 interface i tightly couple to the nat64 state, hence need to be specified. >> >> In any case, i have rephrased the previous sentence to >> >> Filtering of incoming IPv6 packets is not described in this specification. >> >> [Senthil] I guess I was thinking filtering even before the session can be created. >> For example, one would want all the IPv6 hosts to have access to internet but except for a handful of specific hosts. Another filtering technique is all hosts are allowed except the ones that talk to a specific port or set of ports. These types of filtering is common and they protect the NAT64 resources (addresses & ports). >> >> in order to make it clearer that is not that is not supported, but that is not specified here. >> >> > > right, i agree with that, but i still think this is orthogonal to the > nat64 (e.g. firewalls have the same issues) so i am not sure what to say about this in the draft... any suggestion? > > [Senthil] True. I was thinking some text along these lines. > > "NAT64 device can do filtering of IPv6 packets based on the administrative rules to create BIB and session entries. The filtering can be flexible enough and broad enough but the idea of the filtering is to provide the operators necessary control to avoid DoS attacks that would result in exhaustion of NAT64 address, port, memory and CPU resources". > > Ok, i will add that text to the draft, thanks >> >> >>> Section 3.2.2 >>> Paragraph starting "After bootstrapping...." >>> >>> What does it mean all TCP sessions are in closed state? Where is this >>> tracked? >>> >>> >>> >> Again, this is similar to the TCP CLOSED state >> >> The closed state is somehow special, cause it means that there is no state for the particular connection. I have tried to make this clearer in the document by adding the following description: >> >> CLOSED: Analogous to , CLOSED is a fictional >> because it represents the state when there is no state for this particular 5-tuple, and therefore, >> no connection. >> >> >> [Senthil] The state of a session is tracked via the session table, >> > no. > the state is tracked by the state. I mean, current session table does not have a "STATE" column defined.Additional data is needed to track the state, sicne the state a given connection is is a piece of information that needs to be stored somewhere. We could define all the data strcutures needed for the implementation, but i fail to see the need for that > > [Senthil] Let me ask you this, as an implementor when the doc says "After bootstrapping all the devices should set its connection state for all the sessions to CLOSED." How do I do that? > you don't create any state for any connection, hence they are all in CLOSED state. > Again, I didn't mean to say the state should be tracked within a session, but the state is per-session and hence keyed off of the session. You cant get to the state of the session without knowing what the session keys are. > > the keys are the connection identifier. You search among the connections that have state, If you can't find state for the connection you are searching, it means it is in closed state. Again, CLOSED state is a _fictional_ state that represents that no state is available for that connection and hence there is no connection. Again, this is exactly the same as 793, >> but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. >> >> >> > as i mentioned earlier, the CLOSED state is a fictional state (similar to the the one for TCP) that represents that there is no state for a connection. > In other words, in a normal TCP stack (in any regular host, no nat64 > involved) all non existent connections are in CLOSED state... so where does a TCP stack store the state for those connections? Nowhere, cause the CLOSED stated in fact means that there is no state. > > [Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and there is a time period when the connections are in CLOSED state. from RFC793 page 21 CLOSED is fictional because it represents the state when there is no TCB, and therefore, no connection. and then in page 22 CLOSED - represents no connection state at all. >> >> >>> Section 3.2.3 >>> >>> For port allocation, the text says if the port is even an even port >>> must be allocated and same for odd. What if there are no even ports >>> to allocate but there are odd ports, should the packet be dropped or >>> allocated a odd port. I understand some application require that the >>> port parity to be maintained but majority of the apps don't care. So >>> making this a recommendation on the best effort basis is ok but >>> making it a mandatory requirement sounds unreasonable. Note RFC 4787 >>> recommends this behavior but this text mandates it. >>> >>> >>> >> Right, i have changed this to a should. >> >> [Senthil] I am thinking that this should be a configurable parameter, that is the admin can decide if the device should strictly allocate even-for-even and odd-for-odd or it should do the first available port. >> >> >> > but that is not what is reccomended by the behave requirements, right? > > I mean, what is required is what you mentioned earlier and that i have tried to relfect in the document with the text above. > If we want to reccomend something else than what is described in the behave requirements, then we need to go against prior consensus. We can do that, but it would require strong WG consenus. > > [Senthil] From RFC4787, > > REQ-4: It is RECOMMENDED that a NAT have a "Port parity > preservation" behavior of "Yes". > > It does not say SHOULD. From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. > So what you have in this draft is going above what has been said in the RFC4787. > > not sure i understand what you mean Regards, marcelo > Thanks > Senthil > > Regards, marcelo > > > >> Senthil >> >> >> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >>> >> >> > > > From marcelo@it.uc3m.es Wed Dec 16 05:21:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3B53A68B7 for ; Wed, 16 Dec 2009 05:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02kO+0k+ga8Q for ; Wed, 16 Dec 2009 05:21:20 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 037E63A68AB for ; Wed, 16 Dec 2009 05:21:19 -0800 (PST) Received: from r190-135-63-62.dialup.adsl.anteldata.net.uy (r190-135-63-62.dialup.adsl.anteldata.net.uy [190.135.63.62]) by smtp03.uc3m.es (Postfix) with ESMTP id EA22F730F58; Wed, 16 Dec 2009 14:21:02 +0100 (CET) Message-ID: <4B28DEBD.8000506@it.uc3m.es> Date: Wed, 16 Dec 2009 14:21:01 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:21:22 -0000 Reinaldo Penno escribió: > Hello, > > The current draft states that: > > " If a packet other than a RST packet is received, the lifetime is set > to at least 2 hours and 4 min and the state is moved to ESTABLISHED. > > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > " > > Let's suppose B in the IPv4 world sends a RST to A in IPv6 and we move into > a RST RCV state. > > If after that you only receive packets in the B->A direction, should the > session be kept open? Wouldn't that be an indication that A accepted the RST > and/or in general is not in the picture anymore? > > Yes, it would keep the session open. Similarly, if a delayed packet hits the nat64 after the RST, it will move back to established. We discuss this at large in stockholm. this is an optimization, to reduce the amount of state in the nat64, so we decided to keep it simple and be overly conservative about dropping useful state. > Finally it says ' If a packet other than a RST packet is received". If B > sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the > connection open? > > yes, but we can limit it to data segments and we could limit it packet flying from the end the received the RST. I don't have a problem with that neither. > This is my understanding of TCP RST processing: > > If host B sends a RST that is accepted by A, any other packets after that > would not get processed by A. All of TCP control state is removed as soon as > the TCP RST is accepted. > > And if the RST is not accepted by A, this was B's original intention so it > will not be sending any more packets after that. > > but the other scenario is that an attacker sent the RST to drop the connection Morevoer, that the receiving node have made some validation of the seq number and decided not to accept the RST But thsi is still not standarized (i.e. how the node should behave) so we wanted to not to try to guess what the node will do. So we keep the stare unless we have a very clear signal that the RST was accepted i.e. no more packets. I mean, if a node send a RST and the other accepts it, there shoudln't be no more packets in either direction, right? > NAT behavior: > > Therefore, for a NAT device without keep-alives that cannot make an > assessment whether the TCP RST was accepted or not, exactly > keeping the connection > open if any packet gets received does not seem to serve a purpose. > > but the consluion is exactly the opostive. Since the nat64 cannot guess, we need to keep the state in case the node still has the connection open, right? > I would suggest the following: > > " > If the lifetime expires, the session table entry is deleted and the > state is moved to CLOSED. > " > > This is the text that is already in the draft afaict, not sure what is your suggestion here. Regards,marcelo > In other words, we remove the session entry after 4 minutes. > > Thanks, > > Reinaldo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From xing@cernet.edu.cn Wed Dec 16 05:39:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C663A6405 for ; Wed, 16 Dec 2009 05:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srmqkNp6QWkd for ; Wed, 16 Dec 2009 05:39:52 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 325233A687D for ; Wed, 16 Dec 2009 05:39:50 -0800 (PST) Received: from [192.168.100.249]([218.67.241.11]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm94b290233; Wed, 16 Dec 2009 21:39:34 +0800 Message-ID: <4B28E30E.9000308@cernet.edu.cn> Date: Wed, 16 Dec 2009 21:39:26 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 4oSGuUXB Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:39:53 -0000 Hi, Senthil, Thanks for the review. Senthil Sivakumar (ssenthil) 写é“: > General Comments > Overall, the document is in a good shape and is ready for last call. > Some general comments/behavior. > 1. An example flow either in sections 2 & 3 or in the appendix would > help understand the translation > process easily. I believe something like this was in the initial ivi > document. > The IVI reference will be added. > Abstract: > Paragraph starting "Significant issues exist..." > > I don't know what issues are being referred to here but there is no > description of the issues nor there is a pointer to a document that > describes/addresses the issues. I think we should either drop this > paragraph or describe the issues or point it to another relevant > document. > It is like saying "There are significant issues with stateful & > stateless modes, we wont tell you what they are but we don't plan to > address them in this document". That doesn't give me a good feeling when > I start to read this document. > Deleted. > Editorial comments. > 1. Section 1.2 Para "The translating function specified in ..." > > There is a reference to RFC2765 that is hanging here. I don't know what > is the intention of bringing in the reference without properly relating > it to the context. > Modified. (same as in [RFC2765]). > 2. Section 1.2 Para "Fragmented IPv4 UDP packet...." > > "use over wide-areas in the Internet" - did you mean over wide-area > networks? If not, what does wide-areas mean here? > wide-area deleted. > 3. Section 1.4 Para 1. > s/must send packet to big/must send packet too big > Corrected. > 4. Section 2 > Para "However, when the IPv4 sender does..." > > s/needed should the packet pass through an IP/ICMP translator/needed > should the packet pass through another IP/ICMP translator > I think we still mean this IP/ICMP translator. > 5.Section 2.1 > > Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." > > Why is this a MUST? Isnt this upto the implementation? How can you > verify the conformance? > How can you detect if the nat64 device fragments it and translates it or > translates it and fragments it? > This is discussed in para However, when the IPv4 sender does not set the DF bit, the translator has to ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size. > 6. Section 2.1 > Hop Limit: I think the recommendation should be to decrement the TTL and > send ICMP TTL exceeded before translation. Translating the packet and > decrementing TTL to find out the TTL expired and restoring the packet to > its original form seems to be unnecessarily complicating things. We > shouldn't even suggest that. > We think this leaves the space for different implementation. The text is from the RFC2765. If the consensus is there, we are fine to make the modification. > 7. Section 2.2 > Para 2 "When a stateless translator...." > The text says "translator SHOULD drop the packet and generate a system > management > event specifying at least" > > Is the SHOULD for dropping the packet and generating the event? I think > generating the event should be optional/MAY. > Again, this is from RFC2765. Any comments from the WG? > 8. Section 3.1 > Time to Live - Same comment as hoplimit for IPv6. > The same question to the WG. > 9. Section 5 - Security considerations. > This document does not address any potential issues that might arise by > extracting a IPv4 address from the IPv6 address - particularly addresses > like broadcast or loopback addresses etc. I think adding some text > around that might be of help. > How about adding: There are potential issues that might arise by extracting a IPv4 address from the IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. Special action SHOULD be taken to avoid security problems. Thanks. xing > Senthil > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From marcelo@it.uc3m.es Wed Dec 16 05:51:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94893A68B7 for ; Wed, 16 Dec 2009 05:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-n4fv7v7DPj for ; Wed, 16 Dec 2009 05:51:26 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7679D3A68B5 for ; Wed, 16 Dec 2009 05:51:26 -0800 (PST) Received: from r190-135-63-62.dialup.adsl.anteldata.net.uy (r190-135-63-62.dialup.adsl.anteldata.net.uy [190.135.63.62]) by smtp03.uc3m.es (Postfix) with ESMTP id AC9A272DB15; Wed, 16 Dec 2009 14:51:08 +0100 (CET) Message-ID: <4B28E5CB.4010006@it.uc3m.es> Date: Wed, 16 Dec 2009 14:51:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Wing , Dave Thaler , Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Subject: [BEHAVE] Open issues with NAT64 v05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:51:27 -0000 This is a complies list of open issues that have been brought up during the last discussions. We can go through the list today in the interim. Open issues with statefull nat64 v05 -- Address-dependent filtering of ICMP queries. I have tried to reflect the concept of address dependent mapping for the ICMP queries. I am not sure if this makes to much sense or if it is worth the trouble. See section 3.2.3. ICMP Query Session Handling See http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.3 -- What to do with non expected TCP msgs in states other than ESTABLISHED. The question is what to do with TCP segments of a given connection that is not what is expected by the state machine. In particular, what do we do with TCP data segments that the NAT64 has information to process i.e. a valid BIN entry) but do not correspond to any active connection. similar question applies to a duplicated SYN packet and so on. The current draft states that the NAT64 may forward of discard the packet, but certianly it must not create a session if the 3 way handshake is not performed properly. Would that make sense? See the text in section 3.2.2. TCP Session Handling in the CLOSED state, and others. See http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.2 -- Address-Dependent filtering for TCP and simultaneous open How to implement Address Dependent filtering and support simultaneous opens is tricky. I would appreciate if someone could take a look. In particular, there is the question of whether we drop the incoming V4 SYN or we store it. And if we store it, whether we use it only for the ICMP error, or we do forward it when the V6 SYN arrives. Please take a look at page 23, how a V4 SYN is handled in CLOSED state of section 3.2.2. TCP Session Handling See http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.2 --Port allocation for TCP follows the same rules than for UDP? We are using the rules for port allocation following the recommendation of RFC4787. TCP does not have the same rules (they are much more relaxed). the current draft uses the same rules for both. Should we drop these rules for TCP? See:3.2.4. Rules for allocation of IPv4 transport addresses See http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.4 -- 10 secs timer for waiting for fragments In order to quantify this we need to understand how long may it take to receive a full packet over a slow link. So, if we have 64KB of data, with 10 secs, the bandwidth we are assuming as minimum is 51 kbps If we move to 2 secs as was suggested, the minimum bandwidth we are assuming is 256 kbps The other issue related to this is whether it is possible to send 64KB long UDP packets. In a link with a 1500B MTU, this would result in 42 packets and with a packet loss of 1%, half of the UDP segments will loose one segment, so maybe this is not feasible in any case. -- Handling of RST packets. Proposal to stsy in RST RCV unless we receive a data segment from the side that received the RST pkt. Currently we move away from the RST RCV state upon the reception of any packet from any side. From xing@cernet.edu.cn Wed Dec 16 05:53:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7113A68AB for ; Wed, 16 Dec 2009 05:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQgEs0Fs-w-P for ; Wed, 16 Dec 2009 05:53:43 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E587D3A688B for ; Wed, 16 Dec 2009 05:53:41 -0800 (PST) Received: from [192.168.100.249]([218.67.241.11]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm164b290572; Wed, 16 Dec 2009 21:53:25 +0800 Message-ID: <4B28E654.9080609@cernet.edu.cn> Date: Wed, 16 Dec 2009 21:53:24 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zhen Cao References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 4LhTuUXB Cc: Behave WG Subject: Re: [BEHAVE] Comments on the xlate draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:53:43 -0000 Hi, Zhen, Thanks. Zhen Cao 写é“: > Hi All, > > Some comments on the draft before the interim meeting. > > 1. section1.3, when discussing the stateful and stateless mode, a > reference to the framework draft is important because there is a clear > definition of stateless and stateful translation. > Added. > 2. section2.3 [page 13], handling of ICMPv4 error message to ICMPv6 on > Code 4: I believe that adjust of the MTU should be the minimum of the > original advertised MTU + 20, the translator's MTU on the IPv6 side > and the translator's MTU on the IPv4 side+20, i.e. min (advertised > MTU+20, MTU_t6, MTU_t4+20). That's what the xlate-stateful draft's > wording. > Modified. > 3. section3.2 [page 20], handling of ICMPv6 error message to ICMPv4 on > Type 2: similar to the above, min (advertised MTU-20, MTU_t4, > MTU_t6-20). > Modified. > 4. section 5, for IPsec ESP tunnel model, "the ipv6 node needs to be > able to generate an inner IPv4 header...", that's not possible IMO. > The IPv6 application has no way to fill in the IPv4 inner address. > Often, the tunnel insider ipv4 address is used for further routing at > the IPsec terminator. Only if the client is using the IPv4 application > could this case happen. So i think ESP tunnel cannot work through the > translator. > Yes, this is the meaning this document reads, in a softer wording. Thanks for the comments. xing > Thanks for discussion, > Zhen > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From iljitsch@muada.com Wed Dec 16 06:34:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA5C3A67B3 for ; Wed, 16 Dec 2009 06:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md84p4bYgWqB for ; Wed, 16 Dec 2009 06:34:42 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 93A013A691B for ; Wed, 16 Dec 2009 06:34:42 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBGEXfJM063841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 15:33:45 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B28E5CB.4010006@it.uc3m.es> Date: Wed, 16 Dec 2009 15:34:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B28E5CB.4010006@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: Behave WG , Dave Thaler , Dan Wing Subject: Re: [BEHAVE] Open issues with NAT64 v05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 14:34:43 -0000 On 16 dec 2009, at 14:51, marcelo bagnulo braun wrote: > similar question applies to a duplicated SYN packet and so on. Duplicate SYNs can easily happen when a packet is lost in the path = between the translator and the receiver. (Packets can also get = duplicated easily on wifi when the actual packet was received correctly = but the ACK was lost.) So duplicates must be allowed through. > How to implement Address Dependent filtering and support simultaneous = opens is tricky. I would appreciate if someone could take a look. In = particular, there is the question of whether we drop the incoming V4 SYN = or we store it. I would hesitate to store packets coming in from the v4 side because = that is where attackers will be as there is no relationship between the = v4 users and the translator, but there is a relationship between the v6 = users and the translator. > -- 10 secs timer for waiting for fragments > In order to quantify this we need to understand how long may it take = to receive a full packet over a slow link. > So, if we have 64KB of data, with 10 secs, the bandwidth we are = assuming as minimum is 51 kbps > If we move to 2 secs as was suggested, the minimum bandwidth we are = assuming is 256 kbps > The other issue related to this is whether it is possible to send 64KB = long UDP packets. In a link with a 1500B MTU, this would result in 42 = packets and with a packet loss of 1%, half of the UDP segments will = loose one segment, so maybe this is not feasible in any case. Indeed. In theory 64k UDP packets are valid, in practice they don't = happen. I think the largest real-world UDP packets are 4k EDNS0 DNS = packets and even those are rare. Worst case 4k in 2 seconds is about 16 = kbps, which seems fairly reasonable. > -- Handling of RST packets. > Proposal to stsy in RST RCV unless we receive a data segment from the = side that received the RST pkt. > Currently we move away from the RST RCV state upon the reception of = any packet from any side. Both should work, I would go with what's simplest here.= From simon.perreault@viagenie.ca Wed Dec 16 07:36:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3739D3A69AA for ; Wed, 16 Dec 2009 07:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLINxZDHT0br for ; Wed, 16 Dec 2009 07:36:14 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 321083A69C6 for ; Wed, 16 Dec 2009 07:36:14 -0800 (PST) Received: from momo.viagenie.ca (unknown [IPv6:2620:0:230:c000:20a:95ff:febc:7f66]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A1DF721BBC for ; Wed, 16 Dec 2009 10:35:59 -0500 (EST) Message-ID: <4B28FE5E.6020800@viagenie.ca> Date: Wed, 16 Dec 2009 10:35:58 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] What ICMP to send when not reassembling UDP with checksum 0 because out of resources X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:36:15 -0000 In the interim, the question of what ICMP type/code to send when the translator does not reassemble a UDP packet with zero checksum because it is out of resources. It was proposed to send an ICMP Parameter Problem pointing to the UDP checksum field. However, I think we should follow the guidance of RFC 5508: REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Wed Dec 16 08:27:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDE13A69E0 for ; Wed, 16 Dec 2009 08:27:25 -0800 (PST) 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.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QL48MMAxvxP for ; Wed, 16 Dec 2009 08:27:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 761283A69F3 for ; Wed, 16 Dec 2009 08:27:24 -0800 (PST) Received: from momo-2.local (unknown [IPv6:2620:0:230:c000:20a:95ff:febc:7f66]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 76D7B21BBC for ; Wed, 16 Dec 2009 11:27:10 -0500 (EST) Message-ID: <4B290A5D.1040700@viagenie.ca> Date: Wed, 16 Dec 2009 11:27:09 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:27:25 -0000 Hello, Today I attended the interim meeting on WebEx over NAT64. I had only one problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an A query is successful. Now, section 5.1.2 prevents the DNS64 from synthesizing a record in this situations. What to do? Try an A query even when the AAAA query fails? In my case, I just edited /etc/hosts... ;) Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From wwwrun@core3.amsl.com Wed Dec 16 08:28:23 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C07193A69FE; Wed, 16 Dec 2009 08:28:23 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091216162823.C07193A69FE@core3.amsl.com> Date: Wed, 16 Dec 2009 08:28:23 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Resolution Mechanism) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:28:24 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Traversal Using Relays around NAT (TURN) Resolution Mechanism ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-13. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18080&rfc_flag=0 From ajs@shinkuro.com Wed Dec 16 08:31:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C7F3A67FA for ; Wed, 16 Dec 2009 08:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHgLAELHi+LG for ; Wed, 16 Dec 2009 08:31:07 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9F7A93A6A39 for ; Wed, 16 Dec 2009 08:31:06 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6FC422FE8CDF; Wed, 16 Dec 2009 16:30:51 +0000 (UTC) Date: Wed, 16 Dec 2009 11:30:49 -0500 From: Andrew Sullivan To: Simon Perreault Message-ID: <20091216163049.GD37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B290A5D.1040700@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Behave WG Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:31:08 -0000 On Wed, Dec 16, 2009 at 11:27:09AM -0500, Simon Perreault wrote: > Hello, > > Today I attended the interim meeting on WebEx over NAT64. I had only one > problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an > A query is successful. Do we know why it returned SERVFAIL? Do all the servers return SERVFAIL? I'm trying to understand whether there is a good reason (well, a good operational reason) we'd want to address this, or whether it's actual breakage we need not to fix. (For it seems to me this is already so broken that we maybe ought not to try to fix it.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Wed Dec 16 09:00:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD7E3A69D9 for ; Wed, 16 Dec 2009 09:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hpe5K0z5sG2K for ; Wed, 16 Dec 2009 09:00:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6B46B3A69C2 for ; Wed, 16 Dec 2009 09:00:10 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 299732FE8CEE for ; Wed, 16 Dec 2009 16:59:56 +0000 (UTC) Date: Wed, 16 Dec 2009 11:59:53 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091216165953.GE37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216163049.GD37010@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:00:12 -0000 On Wed, Dec 16, 2009 at 11:30:49AM -0500, Andrew Sullivan wrote: > On Wed, Dec 16, 2009 at 11:27:09AM -0500, Simon Perreault wrote: > > Hello, > > > > Today I attended the interim meeting on WebEx over NAT64. I had only one > > problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an > > A query is successful. > > Do we know why it returned SERVFAIL? Do all the servers return > SERVFAIL? I'm trying to understand whether there is a good reason Hmm, curiouser. When I query those nameservers for AAAA for ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your DSN64 returning SERVFAIL when it gets REFUSED? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Wed Dec 16 09:04:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F753A69EE for ; Wed, 16 Dec 2009 09:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qabtzqdLYMLZ for ; Wed, 16 Dec 2009 09:04:50 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 2C6933A69CE for ; Wed, 16 Dec 2009 09:04:49 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBGH3v2N064865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 18:03:57 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20091216165953.GE37010@shinkuro.com> Date: Wed, 16 Dec 2009 18:04:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71D2A0BB-6474-44BE-9EA0-335AB8A0E82E@muada.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:04:51 -0000 On 16 dec 2009, at 17:59, Andrew Sullivan wrote: > Hmm, curiouser. When I query those nameservers for AAAA for > ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your > DSN64 returning SERVFAIL when it gets REFUSED? Not unreasonable. The server failed because it was refused the info it = needs. Note that google public dns does "refused" for RFC 1918 space which = really slows down my traceroutes. But that's for another list.= From ajs@shinkuro.com Wed Dec 16 09:17:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658F93A688B for ; Wed, 16 Dec 2009 09:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU9NqDP2UoDE for ; Wed, 16 Dec 2009 09:17:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9A6FC3A67AB for ; Wed, 16 Dec 2009 09:17:17 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0D2B32FE8CEE for ; Wed, 16 Dec 2009 17:17:02 +0000 (UTC) Date: Wed, 16 Dec 2009 12:17:01 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091216171701.GF37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <71D2A0BB-6474-44BE-9EA0-335AB8A0E82E@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71D2A0BB-6474-44BE-9EA0-335AB8A0E82E@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:17:18 -0000 On Wed, Dec 16, 2009 at 06:04:26PM +0100, Iljitsch van Beijnum wrote: > > Not unreasonable. The server failed because it was refused the info it needs. Hrm. I'd normally expect a recursive server (which is what step 1 of the DNS64 processing is) just to pass on the REFUSED. It strikes me that we might want to think about the chances that many servers out there are configured to REFUSE AAAA queries. I have no idea what the population of v4-only servers REFUSEing AAAA queries might be. If someone actually has numbers, it'd be good; otherwise I'll go see what I can scare up. > Note that google public dns does "refused" for RFC 1918 space which > really slows down my traceroutes. But that's for another list. In my not-a-little-bit-humble-on-this opinion, they're doing a totally reasonable thing, and if more people had done that ages ago we wouldn't have needed the AS112 project. (But yes, this is the wrong list.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From rpenno@juniper.net Wed Dec 16 09:28:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D0D3A680F for ; Wed, 16 Dec 2009 09:28:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cusOMTsVm+ZA for ; Wed, 16 Dec 2009 09:28:49 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with SMTP id 8D80C3A67A4 for ; Wed, 16 Dec 2009 09:28:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSykYwFCHSFAj+OULl7pFSa3CnfuV+Pou@postini.com; Wed, 16 Dec 2009 09:28:34 PST 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.1.393.1; Wed, 16 Dec 2009 09:21:47 -0800 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, 16 Dec 2009 12:21:46 -0500 From: Reinaldo Penno To: marcelo bagnulo braun Date: Wed, 16 Dec 2009 12:21:43 -0500 Thread-Topic: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 Thread-Index: Acp+UqEax/T2yFyvRyOAztfPSYCbbgAIZtpy Message-ID: In-Reply-To: <4B28DEBD.8000506@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:28:49 -0000 My suggestion is to be conservative but also optimize for the common case (RST are valid). In other words, we start the 4 minute timer and only move back to establish if we see packets on _both_ directions. Otherwise, if the premise is that the common case pertain to attacks and we keep the connection open, then we are wasting resources and leaving ourselves open to starvation since the attacker can send RST followed by ACKs. " If packets other than a RST packet are received from both directions, the lifetime is set to at least 2 hours and 4 min and the state is moved to ESTABLISHED." On 12/16/09 5:21 AM, "marcelo bagnulo braun" wrote: >> I would suggest the following: >>=20 >> " =20 >> If the lifetime expires, the session table entry is deleted and the >> state is moved to CLOSED. >> " >>=20 >> =20 > This is the text that is already in the draft afaict, not sure what is > your suggestion here. From simon.perreault@viagenie.ca Wed Dec 16 09:54:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70E53A6836 for ; Wed, 16 Dec 2009 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS8SqNXtZuUG for ; Wed, 16 Dec 2009 09:54:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id CD11E3A680F for ; Wed, 16 Dec 2009 09:54:24 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id A336421BBC for ; Wed, 16 Dec 2009 12:54:10 -0500 (EST) Message-ID: <4B291EC2.4060709@viagenie.ca> Date: Wed, 16 Dec 2009 12:54:10 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> In-Reply-To: <20091216165953.GE37010@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:54:26 -0000 Andrew Sullivan wrote, on 2009-12-16 11:59: > Hmm, curiouser. When I query those nameservers for AAAA for > ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your > DSN64 returning SERVFAIL when it gets REFUSED? This seems to be normal Bind behaviour. Both normal Bind and my DNS64-Bind return SERVFAIL when they get REFUSED. But this is largely irrelevant from a DNS64 protocol point of view. Why wouldn't we want to try an A query when the AAAA query fails? The failure could be due to a multitude of valid reasons, not just misconfiguration or misbehaving. For example, the AAAA record might be sitting on a failed disk partition while the A record is OK. Yes this is far-fetched, but it is just an example. The point is that you can't assume anything about the availability of the A records when the AAAA query fails (or is refused, or whatever else). Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Wed Dec 16 10:39:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFFB3A6A27 for ; Wed, 16 Dec 2009 10:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQgt0MakvtuC for ; Wed, 16 Dec 2009 10:39:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 0628A3A68E3 for ; Wed, 16 Dec 2009 10:39:08 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CADDD2FE8CEE for ; Wed, 16 Dec 2009 18:38:52 +0000 (UTC) Date: Wed, 16 Dec 2009 13:38:51 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091216183850.GJ37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B291EC2.4060709@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 18:39:09 -0000 On Wed, Dec 16, 2009 at 12:54:10PM -0500, Simon Perreault wrote: > Andrew Sullivan wrote, on 2009-12-16 11:59: > > Hmm, curiouser. When I query those nameservers for AAAA for > > ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your > > DSN64 returning SERVFAIL when it gets REFUSED? > > This seems to be normal Bind behaviour. Both normal Bind and my DNS64-Bind > return SERVFAIL when they get REFUSED. Interesting. Well, I can see the justification for either answer for an iterative mode resolver, so it's not wrong. It _feels_ wrong to me, but intuition is a lousy guide to correctness in these tricky cases, I'd say, and as someone already observed "SERVFAIL" is a coherent response for the server part of the recursive server. > Why wouldn't we want to try an A query when the AAAA query fails? > > The failure could be due to a multitude of valid reasons, not just > misconfiguration or misbehaving. For example, the AAAA record might be sitting > on a failed disk partition while the A record is OK. Yes this is far-fetched, > but it is just an example. The point is that you can't assume anything about the > availability of the A records when the AAAA query fails (or is refused, or > whatever else). But we're trying to solve _just one_ problem: that you can't get to a host that doesn't have AAAA, but that does have A at the same owner name. We're not trying to make IPv6 connectivity work whenever some bozo's DNS servers are broken, misconfigured, hiding behind a misconfigured and packet mangling firewall, or any of these other things. If we take on the scope, "Fix broken DNS when querying for AAAA," we will spend until the heat death of the universe nailing down all the ways this could be wrong. In this particular case, REFUSED means "go away". If the point of the REFUSED response code was to say, "We don't do AAAA," then I submit the server is broken. We have a perfectly good response code for that: RCODE 4, NOTIMP. I am, however, susceptible to the argument that we ought to try an A query in the event of RCODE 4 on the AAAA query. What do people think? By the way, despite my resistance to querying for A no matter what the non-positive answer is (since I think that will just drive up error-encumbered traffic), this is an incredibly valuable bit of feedback, and I really appreciate it. Thank you very much A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Wed Dec 16 10:52:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6FF3A6895 for ; Wed, 16 Dec 2009 10:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU-M4k5wNobK for ; Wed, 16 Dec 2009 10:52:11 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 568C73A67AB for ; Wed, 16 Dec 2009 10:52:11 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBGIpG6Z065582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 19:51:17 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20091216183850.GJ37010@shinkuro.com> Date: Wed, 16 Dec 2009 19:51:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 18:52:12 -0000 On 16 dec 2009, at 19:38, Andrew Sullivan wrote: > In this particular case, REFUSED means "go away". If the point of the > REFUSED response code was to say, "We don't do AAAA," then I submit > the server is broken. We have a perfectly good response code for > that: RCODE 4, NOTIMP. =20 > I am, however, susceptible to the argument that we ought to try an A > query in the event of RCODE 4 on the AAAA query. What do people > think? Ok, let me take a crack at this. Basically, the tradeoff is one between being pedantic and getting a = working result out of as many broken configurations as possible. Both = are admirable goals. :-) There is a reason to not be overly pedantic: we want people to adopt = IPv6, and we want people to adopt NAT64. So we don't want to break stuff = that works with IPv4, and we don't want to break stuff that works with = regular IPv6. With normal dual stack, the client has the option of asking for an A = record if it can't get an AAAA record. One good way to avoid issues like = this is ask for the A record first and then for the AAAA record. If the = server then chokes on the AAAA query we have the A answer so everything = works for dual stack hosts. We could do that with DNS64, too. I'm not sure we want to go that far. Just being persistant and request an A record whenever we don't get an = AAAA answer for any (?) reason (timeout, SERVFAIL, NOTIMP, REFUSED) = other than NXDOMAIN seems like a reasonable tradeoff. However, that = would be a slight departure from the current draft.= From ajs@shinkuro.com Wed Dec 16 11:29:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE773A69F6 for ; Wed, 16 Dec 2009 11:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaJwMGFyMNPY for ; Wed, 16 Dec 2009 11:29:29 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 839553A69EA for ; Wed, 16 Dec 2009 11:29:29 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ED9812FE8CEE for ; Wed, 16 Dec 2009 19:29:14 +0000 (UTC) Date: Wed, 16 Dec 2009 14:29:13 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091216192913.GP37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 19:29:30 -0000 On Wed, Dec 16, 2009 at 07:51:46PM +0100, Iljitsch van Beijnum wrote: > With normal dual stack, the client has the option of asking for an A > record if it can't get an AAAA record. One good way to avoid issues > like this is ask for the A record first and then for the AAAA > record. If the server then chokes on the AAAA query we have the A > answer so everything works for dual stack hosts. > > We could do that with DNS64, too. Except that it's backwards to what we want. The people behind a NAT64 should use the NAT64 as a last resort, preferring v6 connectivity as much as possible. So we want them to ask AAAA first, I think? > > Just being persistant and request an A record whenever we don't get > an AAAA answer for any (?) reason (timeout, SERVFAIL, NOTIMP, > REFUSED) other than NXDOMAIN seems like a reasonable > tradeoff. However, that would be a slight departure from the current > draft. The worry I have there is that this more or less mandates an increase in traffic which, for most of those cases, ought to produce exactly the same result. REFUSED is very commonly encountered when you query a recursor for which you're not authorized, for instance. SERVFAIL is a good indication that the server is encountering an error, and it's not plain to me we want to encourage implementations to pound away on a server that's already indicated it has a problem. &c. RCODE=4 I get, but the rest of them just seem to me like the server telling you that there's an error. Why shouldn't that get returned to the client? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Wed Dec 16 11:43:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B343A688F for ; Wed, 16 Dec 2009 11:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVG4LKnTksYB for ; Wed, 16 Dec 2009 11:43:50 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0E5E83A677C for ; Wed, 16 Dec 2009 11:43:50 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMbHKEurRN+K/2dsb2JhbACIX4EWtWCXDIQrBA X-IronPort-AV: E=Sophos;i="4.47,407,1257120000"; d="scan'208";a="120842574" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Dec 2009 19:42:42 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBGJgfGY008863; Wed, 16 Dec 2009 19:42:41 GMT From: "Dan Wing" To: "'Behave WG'" Date: Wed, 16 Dec 2009 11:42:42 -0800 Message-ID: <02cb01ca7e87$ef32d090$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+h+7oNhPt3a/ITvCQPc2ZVQhH0w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] proposed 3gpp-ietf workshop X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 19:43:51 -0000 I expect many people in BEHAVE will be interested in the proposed 3GPP/IETF workshop, March 1-2, in San Francisco. Please see discussion and details here: http://www.ietf.org/mail-archive/web/int-area/current/msg02078.html The mailing list 3gv6 will be used to discuss the workshop. Subscribe at: https://www.ietf.org/mailman/listinfo/3gv6. Please send comments about the proposed workshop to the 3gv6@ietf.org mailing list. -d From simon.perreault@viagenie.ca Wed Dec 16 11:45:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65FA3A69D9 for ; Wed, 16 Dec 2009 11:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI-0QV2+D91a for ; Wed, 16 Dec 2009 11:45:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C66853A69CD for ; Wed, 16 Dec 2009 11:45:13 -0800 (PST) Received: from momo-2.local (unknown [IPv6:2620:0:230:c000:20a:95ff:febc:7f66]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9E79A20E64; Wed, 16 Dec 2009 14:44:59 -0500 (EST) Message-ID: <4B2938BA.3020708@viagenie.ca> Date: Wed, 16 Dec 2009 14:44:58 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andrew Sullivan References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <20091216192913.GP37010@shinkuro.com> In-Reply-To: <20091216192913.GP37010@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 19:45:14 -0000 Andrew Sullivan wrote: > The worry I have there is that this more or less mandates an increase > in traffic which, for most of those cases, ought to produce exactly > the same result. You already get that with dual-stack. Why should NAT64 be any gentler? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Wed Dec 16 12:46:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958703A6A5F for ; Wed, 16 Dec 2009 12:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCWrzvr5GfI3 for ; Wed, 16 Dec 2009 12:46:36 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D47D93A67F3 for ; Wed, 16 Dec 2009 12:46:36 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 513F52FE8CEE for ; Wed, 16 Dec 2009 20:46:22 +0000 (UTC) Date: Wed, 16 Dec 2009 15:46:20 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091216204620.GU37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <20091216192913.GP37010@shinkuro.com> <4B2938BA.3020708@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2938BA.3020708@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:46:37 -0000 On Wed, Dec 16, 2009 at 02:44:58PM -0500, Simon Perreault wrote: > Andrew Sullivan wrote: > > The worry I have there is that this more or less mandates an increase > > in traffic which, for most of those cases, ought to produce exactly > > the same result. > > You already get that with dual-stack. Why should NAT64 be any gentler? Hrm. Well, ok, I get that point. OTOH, this has been the way we've been promoting it, so we'll have to call this change out to the DNS community too (it's their servers that will take the load.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marka@isc.org Wed Dec 16 13:28:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C1C3A68CD for ; Wed, 16 Dec 2009 13:28:47 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuzzhDQrQTL5 for ; Wed, 16 Dec 2009 13:28:45 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id A75CA3A67AF for ; Wed, 16 Dec 2009 13:28:44 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 03B22E60A3; Wed, 16 Dec 2009 21:28:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBGLSQrJ068300; Thu, 17 Dec 2009 08:28:26 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912162128.nBGLSQrJ068300@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <71D2A0BB-6474-44BE-9EA0-335AB8A0E82E@muada.com> <20091216171701.GF37010@shinkuro.com> In-reply-to: Your message of "Wed, 16 Dec 2009 12:17:01 CDT." <20091216171701.GF37010@shinkuro.com> Date: Thu, 17 Dec 2009 08:28:26 +1100 Sender: marka@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 21:28:47 -0000 In message <20091216171701.GF37010@shinkuro.com>, Andrew Sullivan writes: > On Wed, Dec 16, 2009 at 06:04:26PM +0100, Iljitsch van Beijnum wrote: > > > > Not unreasonable. The server failed because it was refused the info it need > s. > > Hrm. I'd normally expect a recursive server (which is what step 1 of > the DNS64 processing is) just to pass on the REFUSED. It's not worth the effort to track to see if you get REFUSED from all the server. > It strikes me > that we might want to think about the chances that many servers out > there are configured to REFUSE AAAA queries. > I have no idea what the > population of v4-only servers REFUSEing AAAA queries might be. If > someone actually has numbers, it'd be good; otherwise I'll go see what > I can scare up. Very small, about the same number that return NXDOMAIN or A records or other garbage. > > Note that google public dns does "refused" for RFC 1918 space which > > really slows down my traceroutes. But that's for another list. > > In my not-a-little-bit-humble-on-this opinion, they're doing a totally > reasonable thing, and if more people had done that ages ago we > wouldn't have needed the AS112 project. (But yes, this is the wrong > list.) > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From root@core3.amsl.com Wed Dec 16 19:00:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 009213A6868; Wed, 16 Dec 2009 19:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217030002.009213A6868@core3.amsl.com> Date: Wed, 16 Dec 2009 19:00:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-04.txt Pages : 30 Date : 2009-12-16 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-dns64-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-16184948.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Dec 16 19:00:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0688E3A689C; Wed, 16 Dec 2009 19:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217030002.0688E3A689C@core3.amsl.com> Date: Wed, 16 Dec 2009 19:00:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-06.txt Pages : 41 Date : 2009-12-16 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how it should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-16185435.I-D@ietf.org> --NextPart-- From ebisawa@sablenetworks.net Wed Dec 16 19:00:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201E53A684F for ; Wed, 16 Dec 2009 19:00:58 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stYFgCy7wTvt for ; Wed, 16 Dec 2009 19:00:57 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 8310E3A6B0E for ; Wed, 16 Dec 2009 19:00:56 -0800 (PST) Received: (qmail 2737 invoked by SAV 20091216.051 by uid 0); 17 Dec 2009 12:00:40 +0900 Received: from unknown (HELO ?192.168.1.128?) (ebisawa@66.166.233.116) by dc12.etius.jp (202.229.133.90) with ESMTPA; 17 Dec 2009 12:00:40 +0900 Date: Thu, 17 Dec 2009 12:00:23 +0900 From: Kentaro Ebisawa To: Xing Li , Behave WG Message-Id: <20091217115747.83B7.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Subject: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:00:58 -0000 Hi, In the yesterday's interim conf call, there was comment that we should add more guidance to how to translate the pointer. I've classified to 5 classes (A~E) when translating a pointer so it would be eaiser to think through. # Summarized list of pointer value and classes are at the tail of this e-mail. BTW, my assumption is we will drop if the pointer is pointing to Options (IPv4:20+) or Extention headers(IPv6:40+) since we are not going to translate them and thus no way to translate the pointer.0 (For Fragment Header, I explicitly classified this to case E since it has field in IPv4 header.) /// Classification and my comments to how to handle them /// A. There is one-to-one mapping and can be translated with no ambiguity. B. The translated field is spread among multiple octets. We can translate but need to define which octet to use. C. Multiple fiels are included in the octet original pointer is pointing to, and can not distinguish which field it's pointing to. We can NOT translate unless we are aware of which value normally used in current (and future) implementations. D. There is no corresponding filed in the translated protocol(IPv4/IPv6) E. Pointer is pointing to fragment related header (IPv4) or Fragment Extention Header(IPv6). For A and D, it's simple. We can translate(A) or drop(D) based on the chart below. For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to this. We can either drop it, or decide to use 0 or 1. Maybe we can use 0 since if we have any problem in version field, we wouldn't have sent the packet triggering this ICMP message anyway. For C, there are 3 cases. 1 for IPv4->IPv6 and 2 for IPv6->IPv4. C-1. v4->v6 : pointer=0, Version/IHL C-2. v6->v4 : pointer=0, Version/Traffic Class C-3. v6->v4 : pointer=1, Traffic Class/Flow Label For C-1, I think we can drop this. We wouldn't have sent the packet triggering this ICMP message if the version field had problem, and there is no corresponding field for IHL in v6. For C-2, we can either drop this or translate to 1 (Type of Service), assuming we won't send original packet with incorrect Version. But I would preffer dropping this to avoid sending fales alert. For C-3, I think we should drop it since there are no way to distinguish if the sender wanted to point to Traffic Class or Flow lable. For E, we can add Fragment Header and point to it (v4->v6). Also, we can parse the Extention header and if it was Fragment header, we can point to corresponding Fragment related field (v6->v4). But if we try to translate, we will need to think about the case don't fragment bit is set since we can not insert Fragment Header in such case. So perfer simply dropping this but would like to hear more comments. /// Summarized list of pointer value and classes /// * Translating from IPv4 to IPv6: | Original IPv4 Pointer | | Translated IPv6 Pointer Vaule | +-----------------------------+ +--------------------------------+ | 0 | Version/IHL | C | 0 | Version/Traffic Class | | 1 | Type Of Service | B | 0or1| Traffic Class/Flow Label | | 2,3 | Total Length | A | 4,5 | Payload Length | | 4,5 | Identification | E | - | | | 6 | Flags/Fragment Offset | E | - | | | 7 | Fragment Offset | E | - | | | 8 | Time to Live | A | 7 | Hop Limit | | 9 | Protocol | A | 6 | Next Header | |10,11| Header Checksum | D | - | | |12-15| Source Address | A | 8-23| Source Address | |16-19| Destination Address | A |24-39| Destination Address | +-----------------------------+ +--------------------------------+ * Translating from IPv6 to IPv4: | Original IPv6 Pointer | | Translated IPv4 Pointer Vaule | +--------------------------------+ +-------------------------------+ | 0 | Version/Traffic Class | C | 0or1| Version/IHL, Type Of Ser| | 1 | Traffic Class/Flow Label | C | 1 | Type Of Service | | 2,3 | Flow Label | D | - | | | 4,5 | Payload Length | A | 2,3 | Total Length | | 6 | Next Header | A | 9 | Protocol | | 7 | Hop Limit | A | 8 | Time to Live | | 8-23| Source Address | A |12-15| Source Address | |24-39| Destination Address | A |16-19| Destination Address | +--------------------------------+ +-------------------------------+ /// FYI: pointer value and header field included in the octet /// | IPv4 Pointer | | IPv6 Pointer | +-----------------------------+ +--------------------------------+ | 0 | Version/IHL | | 0 | Version/Traffic Class | | 1 | Type Of Service | | 1 | Traffic Class/Flow Label | | | | | 2,3 | Flow Label | | 2,3 | Total Length | | 4,5 | Payload Length | | 4,5 | Identification | | - | | | 6 | Flags/Fragment Offset | | - | | | 7 | Fragment Offset | | - | | | 8 | Time to Live | | 7 | Hop Limit | | 9 | Protocol | | 6 | Next Header | |10,11| Header Checksum | | - | | |12-15| Source Address | | 8-23| Source Address | |16-19| Destination Address | |24-39| Destination Address | | 20+ | Options | | 40+ | extension header | +-----------------------------+ +--------------------------------+ Thanks, -- Kentaro Ebisawa From dwing@cisco.com Wed Dec 16 21:31:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D733D3A69D2 for ; Wed, 16 Dec 2009 21:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=-2.367, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlfatfoS1o1y for ; Wed, 16 Dec 2009 21:31:22 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E2A803A68D4 for ; Wed, 16 Dec 2009 21:31:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQTAB9RKUurRN+K/2dsb2JhbACCX4YAgRaNH6dSlwKELQSBY4pS X-IronPort-AV: E=Sophos;i="4.47,410,1257120000"; d="scan'208";a="63940318" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Dec 2009 05:30:54 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBH5Usmn028649; Thu, 17 Dec 2009 05:30:54 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Andrew Sullivan'" References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> Date: Wed, 16 Dec 2009 21:30:52 -0800 Message-ID: <046901ca7eda$19473db0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+gNxG2NUkIqRwQra9OIUOajC24QAIGIng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 05:31:23 -0000 Iljitsch van Beijnum wrote: > Just being persistant and request an A record whenever we > don't get an AAAA answer for any (?) reason (timeout, > SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > reasonable tradeoff. However, that would be a slight > departure from the current draft. Optimizing for NXDOMAIN is tempting, but it means DNS64 would be ineffective for many websites, including popular ones. I checked the top 5000 websites (according to Alexa, see http://www.alexa.com/topsites) to see how they handle AAAA queries. Of those 5000, their nameservers returned: NOERROR, 4766 (95.3%) NXDOMAIN, 37 (0.74%) REFUSED, 18 (0.36%) SERVFAIL, 23 (0.46%) There is some inconsistency because my script is simplistic (the results don't add up to 5000), but I was mostly intending to get a feel for real numbers that would affect DNS64 if DNS64 did not provide effective service to an NXDOMAIN response. Below, I summarized the domains that returned errors when queried for AAAA. The command I used for the test was: dig +short DOMAINNAME ns | xargs -t -n 1 -I J dig @J aaaa www.DOMAINNAME | grep status and the log file is at ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt -d ----- NXDOMAIN: www.1e100.net www.uimserv.net www.yimg.com www.rmxads.com www.ggpht.com www.edgesuite.net www.webry.info www.images-amazon.com www.pgmediaserve.com www.livefilestore.com www.googlesyndication.com www.ytimg.com www.myfiles-express.com www.myspacecdn.com www.fbgdc.com www.say-move.org www.www.ne.jp www.ucom.ne.jp www.xtshare.com www.nocookie.net www.bingj.com www.k12.ca.us www.wateen.net www.2mdn.net www.kvors.com www.yahoofs.jp www.ecshop.com www.xii.jp www.ebayrtm.com www.atwola.com www.twimg.com www.www.gov.cn www.movie-japan.com www.mofile.com www.donetsk.ua www.gnspf.com www.bannch.jp REFUSED: www.ehow.com www.sanspo.com www.cracked.com www.nbc.com www.answerbag.com www.mozilla-europe.org www.hindustantimes.com www.treehugger.com www.blogsome.com www.gamershell.com www.rotoworld.com www.books.com.tw www.nbcsports.com www.livestrong.com www.longporntube.com www.airliners.net www.essortment.com www.greenpeace.org SERVFAIL: www.livejasmin.com www.ynet.com www.awempire.com www.ikea.com www.hc360.com www.vnet.cn www.bramjnet.com www.miibeian.gov.cn www.startpagina.nl www.sznews.com www.yingjiesheng.com www.rueducommerce.fr www.shortnews.de www.heavy.com www.penny-arcade.com www.nouvelobs.com www.eventim.de www.cdcovers.cc www.soccerway.com www.pathfinder.gr www.gazetaesportiva.net www.5giay.vn www.ratp.info From marka@isc.org Wed Dec 16 22:02:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04963A6936 for ; Wed, 16 Dec 2009 22:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjcchtibWA8y for ; Wed, 16 Dec 2009 22:02:08 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id A7AAC3A695A for ; Wed, 16 Dec 2009 22:02:07 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8491CE601C; Thu, 17 Dec 2009 06:01:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBH61mR3087916; Thu, 17 Dec 2009 17:01:48 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912170601.nBH61mR3087916@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> In-reply-to: Your message of "Wed, 16 Dec 2009 21:30:52 -0800." <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 17:01:48 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 06:02:10 -0000 In message <046901ca7eda$19473db0$c4f0200a@cisco.com>, "Dan Wing" writes: > Iljitsch van Beijnum wrote: > > > Just being persistant and request an A record whenever we > > don't get an AAAA answer for any (?) reason (timeout, > > SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > > reasonable tradeoff. However, that would be a slight > > departure from the current draft. > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > would be ineffective for many websites, including popular > ones. I checked the top 5000 websites (according to Alexa, > see http://www.alexa.com/topsites) to see how they handle > AAAA queries. > > Of those 5000, their nameservers returned: > > NOERROR, 4766 (95.3%) Which is correct according to RRF 1034. > NXDOMAIN, 37 (0.74%) > REFUSED, 18 (0.36%) > SERVFAIL, 23 (0.46%) Which are usually the result of crappy/misconfigured load balancers. If you look at things other than www.* you get much higher success rates because general purpose nameservers know how to answer AAAA queries. > There is some inconsistency because my script is simplistic > (the results don't add up to 5000), but I was mostly intending > to get a feel for real numbers that would affect DNS64 if > DNS64 did not provide effective service to an NXDOMAIN > response. http://www.alexa.com/topsites is a very biased sample. > Below, I summarized the domains that returned errors when > queried for AAAA. > > The command I used for the test was: > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > dig @J aaaa www.DOMAINNAME | grep status > and the log file is at > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > -d > > ----- > > NXDOMAIN: > www.1e100.net > www.uimserv.net > www.yimg.com > www.rmxads.com > www.ggpht.com > www.edgesuite.net > www.webry.info > www.images-amazon.com > www.pgmediaserve.com > www.livefilestore.com > www.googlesyndication.com > www.ytimg.com > www.myfiles-express.com > www.myspacecdn.com > www.fbgdc.com > www.say-move.org > www.www.ne.jp > www.ucom.ne.jp > www.xtshare.com > www.nocookie.net > www.bingj.com > www.k12.ca.us > www.wateen.net > www.2mdn.net > www.kvors.com > www.yahoofs.jp > www.ecshop.com > www.xii.jp > www.ebayrtm.com > www.atwola.com > www.twimg.com > www.www.gov.cn > www.movie-japan.com > www.mofile.com > www.donetsk.ua > www.gnspf.com > www.bannch.jp > > REFUSED: > www.ehow.com > www.sanspo.com > www.cracked.com > www.nbc.com > www.answerbag.com > www.mozilla-europe.org > www.hindustantimes.com > www.treehugger.com > www.blogsome.com > www.gamershell.com > www.rotoworld.com > www.books.com.tw > www.nbcsports.com > www.livestrong.com > www.longporntube.com > www.airliners.net > www.essortment.com > www.greenpeace.org > > SERVFAIL: > www.livejasmin.com > www.ynet.com > www.awempire.com > www.ikea.com > www.hc360.com > www.vnet.cn > www.bramjnet.com > www.miibeian.gov.cn > www.startpagina.nl > www.sznews.com > www.yingjiesheng.com > www.rueducommerce.fr > www.shortnews.de > www.heavy.com > www.penny-arcade.com > www.nouvelobs.com > www.eventim.de > www.cdcovers.cc > www.soccerway.com > www.pathfinder.gr > www.gazetaesportiva.net > www.5giay.vn > www.ratp.info > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Wed Dec 16 22:16:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47323A6B17 for ; Wed, 16 Dec 2009 22:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DNSWL_MED=-4, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwRpFJx+qMWg for ; Wed, 16 Dec 2009 22:16:06 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B6D6F3A6A62 for ; Wed, 16 Dec 2009 22:16:06 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQTAKtbKUurRN+K/2dsb2JhbACCX4YAgRaNH6dElwsChCsEgWOKUg X-IronPort-AV: E=Sophos;i="4.47,410,1257120000"; d="scan'208";a="63956005" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Dec 2009 06:15:52 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBH6FqEC018783; Thu, 17 Dec 2009 06:15:52 GMT From: "Dan Wing" To: References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <200912170601.nBH61mR3087916@drugs.dv.isc.org> Date: Wed, 16 Dec 2009 22:15:51 -0800 Message-ID: <048401ca7ee0$62373600$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+3nErKzknjqRDSqungNPy1WayLgAAQGQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <200912170601.nBH61mR3087916@drugs.dv.isc.org> Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 06:16:11 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Wednesday, December 16, 2009 10:02 PM > To: Dan Wing > Cc: 'Iljitsch van Beijnum'; 'Andrew Sullivan'; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > > In message <046901ca7eda$19473db0$c4f0200a@cisco.com>, "Dan > Wing" writes: > > Iljitsch van Beijnum wrote: > > > > > Just being persistant and request an A record whenever we > > > don't get an AAAA answer for any (?) reason (timeout, > > > SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > > > reasonable tradeoff. However, that would be a slight > > > departure from the current draft. > > > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > > would be ineffective for many websites, including popular > > ones. I checked the top 5000 websites (according to Alexa, > > see http://www.alexa.com/topsites) to see how they handle > > AAAA queries. > > > > Of those 5000, their nameservers returned: > > > > NOERROR, 4766 (95.3%) > > Which is correct according to RRF 1034. > > > NXDOMAIN, 37 (0.74%) > > REFUSED, 18 (0.36%) > > SERVFAIL, 23 (0.46%) > > Which are usually the result of crappy/misconfigured load balancers. > > If you look at things other than www.* you get much higher success > rates because general purpose nameservers know how to answer AAAA > queries. The world is long trained to type "www". > > There is some inconsistency because my script is simplistic > > (the results don't add up to 5000), but I was mostly intending > > to get a feel for real numbers that would affect DNS64 if > > DNS64 did not provide effective service to an NXDOMAIN > > response. > > http://www.alexa.com/topsites is a very biased sample. I expect a similar list of different top-NNN sites would yield similar results. Is my expectation unfounded? -d > > Below, I summarized the domains that returned errors when > > queried for AAAA. > > > > The command I used for the test was: > > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > > dig @J aaaa www.DOMAINNAME | grep status > > and the log file is at > > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > > > -d > > > > ----- > > > > NXDOMAIN: > > www.1e100.net > > www.uimserv.net > > www.yimg.com > > www.rmxads.com > > www.ggpht.com > > www.edgesuite.net > > www.webry.info > > www.images-amazon.com > > www.pgmediaserve.com > > www.livefilestore.com > > www.googlesyndication.com > > www.ytimg.com > > www.myfiles-express.com > > www.myspacecdn.com > > www.fbgdc.com > > www.say-move.org > > www.www.ne.jp > > www.ucom.ne.jp > > www.xtshare.com > > www.nocookie.net > > www.bingj.com > > www.k12.ca.us > > www.wateen.net > > www.2mdn.net > > www.kvors.com > > www.yahoofs.jp > > www.ecshop.com > > www.xii.jp > > www.ebayrtm.com > > www.atwola.com > > www.twimg.com > > www.www.gov.cn > > www.movie-japan.com > > www.mofile.com > > www.donetsk.ua > > www.gnspf.com > > www.bannch.jp > > > > REFUSED: > > www.ehow.com > > www.sanspo.com > > www.cracked.com > > www.nbc.com > > www.answerbag.com > > www.mozilla-europe.org > > www.hindustantimes.com > > www.treehugger.com > > www.blogsome.com > > www.gamershell.com > > www.rotoworld.com > > www.books.com.tw > > www.nbcsports.com > > www.livestrong.com > > www.longporntube.com > > www.airliners.net > > www.essortment.com > > www.greenpeace.org > > > > SERVFAIL: > > www.livejasmin.com > > www.ynet.com > > www.awempire.com > > www.ikea.com > > www.hc360.com > > www.vnet.cn > > www.bramjnet.com > > www.miibeian.gov.cn > > www.startpagina.nl > > www.sznews.com > > www.yingjiesheng.com > > www.rueducommerce.fr > > www.shortnews.de > > www.heavy.com > > www.penny-arcade.com > > www.nouvelobs.com > > www.eventim.de > > www.cdcovers.cc > > www.soccerway.com > > www.pathfinder.gr > > www.gazetaesportiva.net > > www.5giay.vn > > www.ratp.info > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Dec 16 23:11:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B493A684E for ; Wed, 16 Dec 2009 23:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY9C1q8qhn7N for ; Wed, 16 Dec 2009 23:11:38 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 61E9F3A6835 for ; Wed, 16 Dec 2009 23:11:38 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5BEB8E60A3; Thu, 17 Dec 2009 07:11:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBH7BJDk098768; Thu, 17 Dec 2009 18:11:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912170711.nBH7BJDk098768@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <200912170601.nBH61mR3087916@drugs.dv.isc.org> <048401ca7ee0$62373600$c4f0200a@cisco.com> In-reply-to: Your message of "Wed, 16 Dec 2009 22:15:51 -0800." <048401ca7ee0$62373600$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 18:11:19 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:11:40 -0000 In message <048401ca7ee0$62373600$c4f0200a@cisco.com>, "Dan Wing" writes: > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Sent: Wednesday, December 16, 2009 10:02 PM > > To: Dan Wing > > Cc: 'Iljitsch van Beijnum'; 'Andrew Sullivan'; behave@ietf.org > > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > > record available > > > > > > In message <046901ca7eda$19473db0$c4f0200a@cisco.com>, "Dan > > Wing" writes: > > > Iljitsch van Beijnum wrote: > > > > > > > Just being persistant and request an A record whenever we > > > > don't get an AAAA answer for any (?) reason (timeout, > > > > SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > > > > reasonable tradeoff. However, that would be a slight > > > > departure from the current draft. > > > > > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > > > would be ineffective for many websites, including popular > > > ones. I checked the top 5000 websites (according to Alexa, > > > see http://www.alexa.com/topsites) to see how they handle > > > AAAA queries. > > > > > > Of those 5000, their nameservers returned: > > > > > NOERROR, 4766 (95.3%) > > > > Which is correct according to RRF 1034. > > > > > NXDOMAIN, 37 (0.74%) > > > REFUSED, 18 (0.36%) > > > SERVFAIL, 23 (0.46%) > > > > Which are usually the result of crappy/misconfigured load balancers. > > > > If you look at things other than www.* you get much higher success > > rates because general purpose nameservers know how to answer AAAA > > queries. > > The world is long trained to type "www". > > > > There is some inconsistency because my script is simplistic > > > (the results don't add up to 5000), but I was mostly intending > > > to get a feel for real numbers that would affect DNS64 if > > > DNS64 did not provide effective service to an NXDOMAIN > > > response. > > > > http://www.alexa.com/topsites is a very biased sample. > > I expect a similar list of different top-NNN sites would > yield similar results. Is my expectation unfounded? http://www.alexa.com/topsites has a very high percentage of load balancers. Much higher that www.* sites in general and much higher than non www.* sites. There are a lot of load balancers vendors that paid no attention to how to answer non A queries correctly. There at lots of sites that don't bother to correct the problem even after it is reported to them. Note the numbers of bad load balancers are going down. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Wed Dec 16 23:15:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703A63A6835 for ; Wed, 16 Dec 2009 23:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jenzjFhsKjGx for ; Wed, 16 Dec 2009 23:15:02 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id DE05C3A67FC for ; Wed, 16 Dec 2009 23:15:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS006KVC4M0T@szxga04-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 15:14:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00963C4LDQ@szxga04-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 15:14:46 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS00M66C4LEF@szxml04-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 15:14:45 +0800 (CST) Date: Thu, 17 Dec 2009 15:14:45 +0800 From: Xu Xiaohu In-reply-to: <4B262F83.6050505@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp8uQ10NALxb5B0TBuaqpPNenKQAgCLPeFA Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:15:03 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > Xu Xiaohu escribi=A8=AE: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > >> =B3=AD=CB=CD: behave@ietf.org > >> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> > >>> There are three choice for the WKP in the address-format draft: > >>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in = RFC > >>> 2765 Section 2.1; > >>> o request IANA to allocate a /32 prefix, > >>> o or request allocation of a new /96 prefix. > >>> > >>> Could you tell me which one is equivalent to the specific NSP I > >>> > > mentioned, > > > >>> which starts with a special binary value? > >>> > >> I just submitted an update to the address format draft: > >> > = http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.t= x > >> t > >> In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96. > >> > > > > "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet > to > > an IPv4 network), as this would lead to using the Well-Known Prefix = with non > > global IPv4 addresses". However, the specific NSP starting with a special > > binary value (depicted as follows) could be used in the above = scenario since > > the Network Specific Parts is topologically aggregatable. That is to say, > > the specific NSP is a hybrid type of 96/ prefix which starts with a > > well-known binary (e.g., 00010101) while the remaining part is = network > > specific. > > > > +--------+--------------------------------+-----------------+ > > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > +--------+--------------------------------+-----------------+ > > > > Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the specific > > NSP I mentioned. > > > Maybe i am not understanding what you have in mind. > Could you put an concrete example of a scenario involving the IPv6 > internet that requires the host to distinguish that the address of its > peer is synthetic? +-------------------+ | | +-------------+ | IPv6 Internet | +--------------+ | +---+ +--++---++ IPv4 only |Dual-stack | +-------------------+ |NAT64| | | +-----+ | ++---++ +-----+| | | H1 | | +-------------------+ | | H2 || | +-----+ +---++ +---+ +-----+| +-------------+ | IPv4 Internet | +--------------+ | | +-------------------+ In the above scenario, after obtaining a synthesized IPv6 address of H2 (IPv4 host) through some way, H1 (dual-stack host) will initialize communication to H2 using IPv6 since it could not identify whether the resolved IPv6 address is synthetic or not. However, it's better to use = IPv4 for the communication between them. Does that make sense? Xiaohu =20 > >> > >> > >> > > > > > > > > From dwing@cisco.com Thu Dec 17 00:21:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745EF3A6862 for ; Thu, 17 Dec 2009 00:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOnQ971fxN4Q for ; Thu, 17 Dec 2009 00:21:35 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 85A773A6937 for ; Thu, 17 Dec 2009 00:21:34 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFAPh4KUurRN+K/2dsb2JhbACEC4RUgRa0a4Z6CJATgSuBAoEqVgSBYw X-IronPort-AV: E=Sophos;i="4.47,410,1257120000"; d="scan'208";a="64001981" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Dec 2009 08:21:15 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBH8LFSe008036; Thu, 17 Dec 2009 08:21:15 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'marcelo bagnulo braun'" References: <4B262F83.6050505@it.uc3m.es> <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> Date: Thu, 17 Dec 2009 00:21:14 -0800 Message-ID: <04e101ca7ef1$e660c480$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp8uQ10NALxb5B0TBuaqpPNenKQAgCLPeFAAAKl3uA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 08:21:39 -0000 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > Sent: Wednesday, December 16, 2009 11:15 PM > To: 'marcelo bagnulo braun' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALL non-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALL > > non-0::/3 IPv6 addresses ? > >=20 > > Xu Xiaohu escribi=A8=AE: > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > >> =B3=AD=CB=CD: behave@ietf.org > > >> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = to=20 > apply to ALL > > >> non-0::/3 IPv6 addresses ? > > >> > > >> > > >>> There are three choice for the WKP in the address-format draft: > > >>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as=20 > specified in RFC > > >>> 2765 Section 2.1; > > >>> o request IANA to allocate a /32 prefix, > > >>> o or request allocation of a new /96 prefix. > > >>> > > >>> Could you tell me which one is equivalent to the specific NSP I > > >>> > > > mentioned, > > > > > >>> which starts with a special binary value? > > >>> > > >> I just submitted an update to the address format draft: > > >> > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > format-02.tx > > >> t > > >> In draft-02, we propose to use the Well Known Prefix=20 > 64:FF9B::/96. > > >> > > > > > > "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 > Internet > > to > > > an IPv4 network), as this would lead to using the=20 > Well-Known Prefix with > non > > > global IPv4 addresses". However, the specific NSP starting with a > special > > > binary value (depicted as follows) could be used in the=20 > above scenario > since > > > the Network Specific Parts is topologically aggregatable.=20 > That is to > say, > > > the specific NSP is a hybrid type of 96/ prefix which=20 > starts with a > > > well-known binary (e.g., 00010101) while the remaining=20 > part is network > > > specific. > > > > > > +--------+--------------------------------+-----------------+ > > > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > > +--------+--------------------------------+-----------------+ > > > > > > Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the > specific > > > NSP I mentioned. > > > > > Maybe i am not understanding what you have in mind. > > Could you put an concrete example of a scenario involving the IPv6 > > internet that requires the host to distinguish that the=20 > address of its > > peer is synthetic? >=20 > +-------------------+ > | | > +-------------+ | IPv6 Internet | +--------------+ > | +---+ +--++---++ IPv4 only > |Dual-stack | +-------------------+ |NAT64| | > | +-----+ | ++---++ +-----+| > | | H1 | | +-------------------+ | | H2 || > | +-----+ +---++ +---+ +-----+| > +-------------+ | IPv4 Internet | +--------------+ > | | > +-------------------+ >=20 > In the above scenario, after obtaining a synthesized IPv6=20 > address of H2 > (IPv4 host) through some way, H1 (dual-stack host) will initialize > communication to H2 using IPv6 since it could not identify whether the > resolved IPv6 address is synthetic or not. However, it's=20 > better to use IPv4 > for the communication between them. That implies that H1 would prefer IPv4 over IPv6 if the IPv6 address contains the "is_translated" bit pattern. But I can draw another picture where it's better to use IPv6 between them because of multiple NAT44's on the path: +-------------------+ | | +-------------+ | IPv6 Internet | +--------------+ | +---+ +--++---++ IPv4 only |Dual-stack | +-------------------+ |NAT64| | | +-----+ | ++---++ +-----+| | | H1 | | +-------------+ | | H2 || | +-----+ +-NAT44+ +--NAT44-+ +-----+| +-------------+ |IPv4 Internet| +------------+ | | +-------------+ which tells me that we need more complex rules in H1 to identify this situation and decide the 'best' path. Note the NAT64 might be stateless (and thus allow SCTP, among=20 other things) whereas the NAT44's only understand TCP&UDP. If I want to use SCTP, the 'best' path is the top. If I am running a protocol that is sensitive to address family changes (such as FTP and its PASV and EPSV), I would want to use the bottom path (to stay all IPv4). These kinds of complications are why many of us are interested in the GROBJ effort and the GROBJ BoF in Hiroshima. =20 -d > Does that make sense? >=20 > Xiaohu > =20 >=20 > > >> > > >> > > >> > > > > > > > > > > > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From xuxh@huawei.com Thu Dec 17 01:38:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0AB3A685D for ; Thu, 17 Dec 2009 01:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.871 X-Spam-Level: * X-Spam-Status: No, score=1.871 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjt7QP4LU7hb for ; Thu, 17 Dec 2009 01:38:27 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B2C393A67B0 for ; Thu, 17 Dec 2009 01:38:26 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00ACKIR8S3@szxga02-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 17:37:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00G38IR8NP@szxga02-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 17:37:56 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS008DPIR7F9@szxml04-in.huawei.com> for behave@ietf.org; Thu, 17 Dec 2009 17:37:56 +0800 (CST) Date: Thu, 17 Dec 2009 17:37:55 +0800 From: Xu Xiaohu In-reply-to: <04e101ca7ef1$e660c480$c4f0200a@cisco.com> To: 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <005d01ca7efc$9cc8bca0$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp8uQ10NALxb5B0TBuaqpPNenKQAgCLPeFAAAKl3uAAAfMDUA== Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 09:38:28 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 16:21 > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > > Sent: Wednesday, December 16, 2009 11:15 PM > > To: 'marcelo bagnulo braun' > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > apply to ALL non-0::/3 IPv6 addresses ? > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > apply to ALL > > > non-0::/3 IPv6 addresses ? > > > > > > Xu Xiaohu escribi=A8=AE: > > > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > >> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > > >> =B3=AD=CB=CD: behave@ietf.org > > > >> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = to > > apply to ALL > > > >> non-0::/3 IPv6 addresses ? > > > >> > > > >> > > > >>> There are three choice for the WKP in the address-format = draft: > > > >>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as > > specified in RFC > > > >>> 2765 Section 2.1; > > > >>> o request IANA to allocate a /32 prefix, > > > >>> o or request allocation of a new /96 prefix. > > > >>> > > > >>> Could you tell me which one is equivalent to the specific NSP = I > > > >>> > > > > mentioned, > > > > > > > >>> which starts with a special binary value? > > > >>> > > > >> I just submitted an update to the address format draft: > > > >> > > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > > format-02.tx > > > >> t > > > >> In draft-02, we propose to use the Well Known Prefix > > 64:FF9B::/96. > > > >> > > > > > > > > "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 > > Internet > > > to > > > > an IPv4 network), as this would lead to using the > > Well-Known Prefix with > > non > > > > global IPv4 addresses". However, the specific NSP starting with = a > > special > > > > binary value (depicted as follows) could be used in the > > above scenario > > since > > > > the Network Specific Parts is topologically aggregatable. > > That is to > > say, > > > > the specific NSP is a hybrid type of 96/ prefix which > > starts with a > > > > well-known binary (e.g., 00010101) while the remaining > > part is network > > > > specific. > > > > > > > > +--------+--------------------------------+-----------------+ > > > > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > > > +--------+--------------------------------+-----------------+ > > > > > > > > Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to = the > > specific > > > > NSP I mentioned. > > > > > > > Maybe i am not understanding what you have in mind. > > > Could you put an concrete example of a scenario involving the IPv6 > > > internet that requires the host to distinguish that the > > address of its > > > peer is synthetic? > > > > +-------------------+ > > | | > > +-------------+ | IPv6 Internet | +--------------+ > > | +---+ +--++---++ IPv4 only > > |Dual-stack | +-------------------+ |NAT64| | > > | +-----+ | ++---++ +-----+| > > | | H1 | | +-------------------+ | | H2 || > > | +-----+ +---++ +---+ +-----+| > > +-------------+ | IPv4 Internet | +--------------+ > > | | > > +-------------------+ > > > > In the above scenario, after obtaining a synthesized IPv6 > > address of H2 > > (IPv4 host) through some way, H1 (dual-stack host) will initialize > > communication to H2 using IPv6 since it could not identify whether = the > > resolved IPv6 address is synthetic or not. However, it's > > better to use IPv4 > > for the communication between them. >=20 > That implies that H1 would prefer IPv4 over IPv6 if the > IPv6 address contains the "is_translated" bit pattern. >=20 > But I can draw another picture where it's better to use > IPv6 between them because of multiple NAT44's on the path: >=20 > +-------------------+ > | | > +-------------+ | IPv6 Internet | +--------------+ > | +---+ +--++---++ IPv4 only > |Dual-stack | +-------------------+ |NAT64| | > | +-----+ | ++---++ +-----+| > | | H1 | | +-------------+ | | H2 || > | +-----+ +-NAT44+ +--NAT44-+ +-----+| > +-------------+ |IPv4 Internet| +------------+ > | | > +-------------+ >=20 > which tells me that we need more complex rules in H1 to > identify this situation and decide the 'best' path. >=20 > Note the NAT64 might be stateless (and thus allow SCTP, among > other things) whereas the NAT44's only understand TCP&UDP. If > I want to use SCTP, the 'best' path is the top. If I am running > a protocol that is sensitive to address family changes (such > as FTP and its PASV and EPSV), I would want to use the bottom > path (to stay all IPv4). It's too complex. Before you choose to use IPv6, you would have to = determine the NAT64 is stateless. To make things simple, IMHO, it'd better that = native connectivity (even address-only translation) is ALWAYS preferred to = address family translation. Xiaohu > These kinds of complications are why many of us are interested > in the GROBJ effort and the GROBJ BoF in Hiroshima. >=20 > -d >=20 >=20 > > Does that make sense? > > > > Xiaohu > > > > > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From marka@isc.org Thu Dec 17 02:17:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2290B3A6843 for ; Thu, 17 Dec 2009 02:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO8AbA26Lacg for ; Thu, 17 Dec 2009 02:17:49 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id C90783A69B9 for ; Thu, 17 Dec 2009 02:17:48 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id E48A6E60A3; Thu, 17 Dec 2009 10:17:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBHAHUef099528; Thu, 17 Dec 2009 21:17:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912171017.nBHAHUef099528@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <200912170601.nBH61mR3087916@drugs.dv.isc.org> <048401ca7ee0$62373600$c4f0200a@cisco.com> In-reply-to: Your message of "Wed, 16 Dec 2009 22:15:51 -0800." <048401ca7ee0$62373600$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 21:17:30 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:17:50 -0000 In message <048401ca7ee0$62373600$c4f0200a@cisco.com>, "Dan Wing" writes: Also most of the servfails arn't. > > > SERVFAIL: > > > www.livejasmin.com works > > > www.ynet.com works > > > www.awempire.com works > > > www.ikea.com works > > > www.hc360.com broken, referral to self. gslb.hc360.com. 3600 IN NS shdns.hc360.com.cn. gslb.hc360.com. 3600 IN NS bjdns.hc360.com.cn. ;; Received 88 bytes from 203.134.246.111#53(ns1.hc360.com) in 421 ms gslb.hc360.com. 669 IN NS bjdns.hc360.com.cn. gslb.hc360.com. 669 IN NS shdns.hc360.com.cn. ;; Received 120 bytes from 203.134.246.9#53(bjdns.hc360.com.cn) in 429 ms > > > www.vnet.cn works > > > www.bramjnet.com works > > > www.miibeian.gov.cn works > > > www.startpagina.nl works > > > www.sznews.com broken, root referral. > > > www.yingjiesheng.com works > > > www.rueducommerce.fr works > > > www.shortnews.de works > > > www.heavy.com works > > > www.penny-arcade.com works > > > www.nouvelobs.com works > > > www.eventim.de works > > > www.cdcovers.cc works > > > www.soccerway.com works > > > www.pathfinder.gr broken, misconfigured load balance, wrong backing zone. www.pathfinder.gr. 10800 IN NS lpsb.phaistosnetworks.gr. www.pathfinder.gr. 10800 IN NS lptb.phaistosnetworks.gr. www.pathfinder.gr. 10800 IN NS lp.phaistosnetworks.gr. ;; Received 155 bytes from 94.136.45.31#53(dnsuk.phaistosnetworks.gr) in 1008 ms pathfinder.gr. 86400 IN SOA pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 7200 604800 86400 ;; Received 124 bytes from 194.0.185.253#53(lptb.phaistosnetworks.gr) in 410 ms > > > www.gazetaesportiva.net works > > > www.5giay.vn works > > > www.ratp.info works -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohamed.boucadair@orange-ftgroup.com Thu Dec 17 02:39:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815E83A6B3D for ; Thu, 17 Dec 2009 02:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqWIKHfJ6yJA for ; Thu, 17 Dec 2009 02:39:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 8677B3A6B3A for ; Thu, 17 Dec 2009 02:39:37 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 92D553B4586; Thu, 17 Dec 2009 11:39:22 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6CD6838406B; Thu, 17 Dec 2009 11:39:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 17 Dec 2009 11:39:22 +0100 From: To: Xu Xiaohu , 'marcelo bagnulo braun' Date: Thu, 17 Dec 2009 11:39:20 +0100 Thread-Topic: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? Thread-Index: Acp8uQ10NALxb5B0TBuaqpPNenKQAgCLPeFAAAee75A= Message-ID: <2257_1261046362_4B2A0A5A_2257_2002_1_94C682931C08B048B7A8645303FDC9F30EF2CB1F04@PUEXCB1B.nanterre.francetelecom.fr> References: <4B262F83.6050505@it.uc3m.es> <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> In-Reply-To: <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.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.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.22.64218 Cc: BURGEY Eric RD-CORE , "behave@ietf.org" Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:39:38 -0000 =20 Dear Xiaohu, Please see inline. Cheers Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Xu Xiaohu Envoy=E9 : jeudi 17 d=E9cembre 2009 08:15 =C0 : 'marcelo bagnulo braun' Cc : behave@ietf.org Objet : Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL n= on-0::/3 IPv6 addresses ? [SNIP] +-------------------+ | | +-------------+ | IPv6 Internet | +--------------+ | +---+ +--++---++ IPv4 only |Dual-stack | +-------------------+ |NAT64| | | +-----+ | ++---++ +-----+| | | H1 | | +-------------------+ | | H2 || | +-----+ +---++ +---+ +-----+| +-------------+ | IPv4 Internet | +--------------+ | | +-------------------+ In the above scenario, after obtaining a synthesized IPv6 address of H2 (IPv4 host) through some way, H1 (dual-stack host) will initialize communication to H2 using IPv6 since it could not identify whether the resolved IPv6 address is synthetic or not. However, it's better to use IPv4 for the communication between them. Does that make sense? Med: This scenario is one of the motivations why we proposed the A64 record= proposal (see: http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-0= 1) to offload the NAT64. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From iljitsch@muada.com Thu Dec 17 03:39:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C372828C102 for ; Thu, 17 Dec 2009 03:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7Qt5W9fDz08 for ; Thu, 17 Dec 2009 03:39:57 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 32EFE28C0EB for ; Thu, 17 Dec 2009 03:39:57 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBHBcviW071259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Dec 2009 12:38:58 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 12:39:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> To: "Dan Wing" X-Mailer: Apple Mail (2.1077) Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 11:39:59 -0000 On 17 dec 2009, at 6:30, Dan Wing wrote: >> Just being persistant and request an A record whenever we=20 >> don't get an AAAA answer for any (?) reason (timeout,=20 >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a=20 >> reasonable tradeoff. However, that would be a slight=20 >> departure from the current draft. > Optimizing for NXDOMAIN is tempting, but it means DNS64 > would be ineffective for many websites, Well, AFAIK with things like REFUSED and SERVFAIL you can argue that = this result is particular to the AAAA query and the A query may give a = different result. With NXDOMAIN the answer authoritatively states that = the domain doesn't exist, so the only way the A query can produce a = different answer is if someone is completely breaking the = specifications. If the DNS64 is doing recursive queries itself it SHOULD never encounter = REFUSED, because then there would be a break in the delegation chain, so = I'm not worried about generating a few more queries in that case. If = there is a resolver in the middle it could be that the resolver doesn't = want to resolve for the DNS64, but in that case the whole setup doesn't = work so the users will give up and again, a few extra packets is not an = issue. Not sure where SERVFAIL would come from in the authoritative case, but = in the resolver case it can obviously result from a REFUSED = authoritative response so again no problem querying for an A record. However, the NXDOMAIN case will normally be the result of a query for a = non-existant domain. If there is a large amount of such queries doubling = it is not a good idea. People configuring their DNS server to send out REFUSED for AAAA queries = is something that I can kinda-sorta-but-not-really follow, but NXDOMAIN = when there is in fact an A record is just plain wrong on every level so = generating lots of extra queries when there is NXDOMAIN for AAAA or by = always doing A first even when we don't need the A record is probably a = bridge too far for the IETF to mandate. > Of those 5000, their nameservers returned: > NOERROR, 4766 (95.3%)=20 > NXDOMAIN, 37 (0.74%) > REFUSED, 18 (0.36%) > SERVFAIL, 23 (0.46%) What about the remaining 156? Timeout? (For instance, one on Mark's list = that I tried replied in 4800 ms for me...) Would be interesting to see the results for A. As we saw in the FTP = case, there is always a percent or two that just don't do anything = reasonable. (Although with top 5000 popular sites this is probably = better than an old list of FTP sites.) From marcelo@it.uc3m.es Thu Dec 17 03:45:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51BF3A693C for ; Thu, 17 Dec 2009 03:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 tagged_above=-999 required=5 tests=[AWL=-1.354, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ8tfDSZ9U1K for ; Thu, 17 Dec 2009 03:45:39 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 50C373A6924 for ; Thu, 17 Dec 2009 03:45:39 -0800 (PST) Received: from r190-135-7-154.dialup.adsl.anteldata.net.uy (r190-135-7-154.dialup.adsl.anteldata.net.uy [190.135.7.154]) by smtp03.uc3m.es (Postfix) with ESMTP id 8C4FE731105; Thu, 17 Dec 2009 12:45:21 +0100 (CET) Message-ID: <4B2A19CF.4010402@it.uc3m.es> Date: Thu, 17 Dec 2009 12:45:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Xu Xiaohu References: <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> In-Reply-To: <005a01ca7ee8$9ca0d960$e30c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 11:45:40 -0000 Xu Xiaohu escribi¨®: > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ14ÈÕ 20:29 >> ÊÕ¼þÈË: Xu Xiaohu >> ³­ËÍ: 'Christian Huitema'; behave@ietf.org >> Ö÷Ìâ: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> Xu Xiaohu escribi¨®: >> >>>> -----ÓʼþÔ­¼þ----- >>>> ·¢¼þÈË: Christian Huitema [mailto:huitema@microsoft.com] >>>> ·¢ËÍʱ¼ä: 2009Äê12ÔÂ14ÈÕ 13:02 >>>> ÊÕ¼þÈË: Xu Xiaohu; 'marcelo bagnulo braun' >>>> ³­ËÍ: behave@ietf.org >>>> Ö÷Ìâ: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >>>> non-0::/3 IPv6 addresses ? >>>> >>>> >>>> >>>>> There are three choice for the WKP in the address-format draft: >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC >>>>> 2765 Section 2.1; >>>>> o request IANA to allocate a /32 prefix, >>>>> o or request allocation of a new /96 prefix. >>>>> >>>>> Could you tell me which one is equivalent to the specific NSP I >>>>> >>>>> >>> mentioned, >>> >>> >>>>> which starts with a special binary value? >>>>> >>>>> >>>> I just submitted an update to the address format draft: >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.tx >> >>>> t >>>> In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96. >>>> >>>> >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 >>> > Internet > >> to >> >>> an IPv4 network), as this would lead to using the Well-Known Prefix with >>> > non > >>> global IPv4 addresses". However, the specific NSP starting with a >>> > special > >>> binary value (depicted as follows) could be used in the above scenario >>> > since > >>> the Network Specific Parts is topologically aggregatable. That is to >>> > say, > >>> the specific NSP is a hybrid type of 96/ prefix which starts with a >>> well-known binary (e.g., 00010101) while the remaining part is network >>> specific. >>> >>> +--------+--------------------------------+-----------------+ >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| >>> +--------+--------------------------------+-----------------+ >>> >>> Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the >>> > specific > >>> NSP I mentioned. >>> >>> >> Maybe i am not understanding what you have in mind. >> Could you put an concrete example of a scenario involving the IPv6 >> internet that requires the host to distinguish that the address of its >> peer is synthetic? >> > > +-------------------+ > | | > +-------------+ | IPv6 Internet | +--------------+ > | +---+ +--++---++ IPv4 only > |Dual-stack | +-------------------+ |NAT64| | > | +-----+ | ++---++ +-----+| > | | H1 | | +-------------------+ | | H2 || > | +-----+ +---++ +---+ +-----+| > +-------------+ | IPv4 Internet | +--------------+ > | | > +-------------------+ > > In the above scenario, after obtaining a synthesized IPv6 address of H2 > (IPv4 host) through some way, H1 (dual-stack host) will initialize > communication to H2 using IPv6 since it could not identify whether the > resolved IPv6 address is synthetic or not. However, it's better to use IPv4 > for the communication between them. > > Does that make sense? > i see the scenario now, i used a similar argument for supporting the use of the Well know prefix a while ago, and the arguments against this argument (by Dan, who wrote then a draft about referals, correct me if i am wrong) was that there is actual no applications that actually do that today and that the reasonable thing to do for an app was to pass the ipv4 address and then allow the receiving end to synthesize the IPv6 address if needed. Regards, marcelo > Xiaohu > > > >>>> >>>> >>> >>> >>> > > > From root@core3.amsl.com Thu Dec 17 05:30:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 24EEC28C0F0; Thu, 17 Dec 2009 05:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217133002.24EEC28C0F0@core3.amsl.com> Date: Thu, 17 Dec 2009 05:30:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-framework-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Framework for IPv4/IPv6 Translation Author(s) : F. Baker, et al. Filename : draft-ietf-behave-v6v4-framework-04.txt Pages : 30 Date : 2009-12-17 This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-framework-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17052525.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Dec 17 05:30:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2B46228C11A; Thu, 17 Dec 2009 05:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217133002.2B46228C11A@core3.amsl.com> Date: Thu, 17 Dec 2009 05:30:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-05.txt Pages : 26 Date : 2009-12-17 This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment without maintaining state in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage [I-D.ietf-behave-v6v4-framework]. 2. Moving the address format to the address format document [I-D.ietf-behave-address-format], to coordinate with other drafts on the topic. 3. Describing both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references. Requirements 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]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17052926.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Dec 17 05:45:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C773B3A69E0; Thu, 17 Dec 2009 05:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217134501.C773B3A69E0@core3.amsl.com> Date: Thu, 17 Dec 2009 05:45:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-07.txt Pages : 42 Date : 2009-12-17 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how it should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17053944.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Thu Dec 17 05:45:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE45C3A685A for ; Thu, 17 Dec 2009 05:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0kM+eLOxFbk for ; Thu, 17 Dec 2009 05:45:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A521B3A6B31 for ; Thu, 17 Dec 2009 05:45:34 -0800 (PST) Received: from momo.viagenie.ca (unknown [IPv6:2620:0:230:c000:20a:95ff:febc:7f66]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0AE6221BEF; Thu, 17 Dec 2009 08:45:19 -0500 (EST) Message-ID: <4B2A35EF.9000601@viagenie.ca> Date: Thu, 17 Dec 2009 08:45:19 -0500 From: Simon Perreault User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091217115747.83B7.B01659E3@sablenetworks.net> In-Reply-To: <20091217115747.83B7.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG , Xing Li Subject: Re: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:45:36 -0000 First, thank you for this excellent analysis. This is exactly what I had in mind. If this text is adopted it will fulfill all my needs. Kentaro Ebisawa wrote: > For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to > this. We can either drop it, or decide to use 0 or 1. > Maybe we can use 0 since if we have any problem in version field, we > wouldn't have sent the packet triggering this ICMP message anyway. I think it should be 1, for two reasons: - The fact that it would be the same as IPv4 would make it a little bit more likely that it would also be interpreted in the same way. - If there was a problem with the flow label the value would be 3 instead. > For C, there are 3 cases. 1 for IPv4->IPv6 and 2 for IPv6->IPv4. > C-1. v4->v6 : pointer=0, Version/IHL > C-2. v6->v4 : pointer=0, Version/Traffic Class > C-3. v6->v4 : pointer=1, Traffic Class/Flow Label > > For C-1, I think we can drop this. We wouldn't have sent the packet > triggering this ICMP message if the version field had problem, and > there is no corresponding field for IHL in v6. Agreed. > For C-2, we can either drop this or translate to 1 (Type of Service), > assuming we won't send original packet with incorrect Version. > But I would preffer dropping this to avoid sending fales alert. Agreed. > For C-3, I think we should drop it since there are no way to distinguish > if the sender wanted to point to Traffic Class or Flow lable. Disagree. I think 1 clearly means traffic class. (Who/what is the authority on this?) > For E, we can add Fragment Header and point to it (v4->v6). Also, we > can parse the Extention header and if it was Fragment header, we can > point to corresponding Fragment related field (v6->v4). > But if we try to translate, we will need to think about the case don't > fragment bit is set since we can not insert Fragment Header in such > case. > So perfer simply dropping this but would like to hear more comments. Well, the point is that the fragmentation parameters on each side are likely to be very different. So an ICMP received on either side wouldn't really apply on the other. Therefore, I would also like to drop this. There are two other cases which I think also need to be considered: F. The pointer points inside the payload to a parameter which the translator changes (e.g. UDP source port). G. The pointer points inside the payload to something the translator doesn't change (e.g. UDP data). In F, the ICMP is of interest to the translator, not the originator of the packet. So besides using the information usefully if it can, the translator should drop the packet. In G, we can forward after offsetting the pointer so that it points at the same data after translation. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From rpenno@juniper.net Thu Dec 17 06:06:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564E33A68AD for ; Thu, 17 Dec 2009 06:06:46 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNsgEZbxCjzo for ; Thu, 17 Dec 2009 06:06:45 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with SMTP id 5B3C93A63C9 for ; Thu, 17 Dec 2009 06:06:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSyo65Y4eatFp5lkhY6y7YOiJmIct9Z+w@postini.com; Thu, 17 Dec 2009 06:06:31 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 17 Dec 2009 05:59:12 -0800 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; Thu, 17 Dec 2009 08:59:11 -0500 From: Reinaldo Penno To: marcelo bagnulo braun Date: Thu, 17 Dec 2009 08:59:06 -0500 Thread-Topic: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 Thread-Index: Acp+UqEax/T2yFyvRyOAztfPSYCbbgAznesW Message-ID: In-Reply-To: <4B28DEBD.8000506@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 14:06:46 -0000 That is fine. I checked version 07 and that is not captured in the spec yet= . On 12/16/09 5:21 AM, "marcelo bagnulo braun" wrote: >> Finally it says ' If a packet other than a RST packet is received". If B >> sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the >> connection open? >>=20 >> =20 > yes, but we can limit it to data segments and we could limit it packet > flying from the end the received the RST. I don't have a problem with > that neither. From ajs@shinkuro.com Thu Dec 17 06:17:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4541228C0DF for ; Thu, 17 Dec 2009 06:17:50 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY4Xz-QwiMpj for ; Thu, 17 Dec 2009 06:17:49 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 76D743A6405 for ; Thu, 17 Dec 2009 06:17:49 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6F1952FE8CEE for ; Thu, 17 Dec 2009 14:17:34 +0000 (UTC) Date: Thu, 17 Dec 2009 09:17:32 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091217141732.GC43572@shinkuro.com> References: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 14:17:50 -0000 On Thu, Dec 17, 2009 at 12:39:27PM +0100, Iljitsch van Beijnum wrote: > > Well, AFAIK with things like REFUSED and SERVFAIL you can argue that > this result is particular to the AAAA query and the A query may give > a different result. With NXDOMAIN the answer authoritatively states > that the domain doesn't exist, so the only way the A query can > produce a different answer is if someone is completely breaking the > specifications. Completely agree. So the real question is how dual-stack handles this. We're trying to do something not quite as good as dual stack, but with a minimum of user surprise. I confess that what clients really do is above the layer where I really know what I'm talking about (ok, ok, many will say there _is_ no such layer. But let's pretend). Here's my naive belief about what dual-stack hosts do. They query AAAA first. If they get NXDOMAIN, they treat that as a failure at the name and give up. If they get another error then [ . . . ]. If they get noerror with an empty answer they query for A. The above has been my model so far, where the ellipsis was "they return the error". People seem to be suggesting I'm wrong about that. So what happens? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marcelo@it.uc3m.es Thu Dec 17 07:10:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780A63A690E for ; Thu, 17 Dec 2009 07:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VpDraeK-3DQ for ; Thu, 17 Dec 2009 07:10:16 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 22A0D3A681C for ; Thu, 17 Dec 2009 07:10:14 -0800 (PST) Received: from r190-135-66-132.dialup.adsl.anteldata.net.uy (r190-135-66-132.dialup.adsl.anteldata.net.uy [190.135.66.132]) by smtp02.uc3m.es (Postfix) with ESMTP id A19826C2C96; Thu, 17 Dec 2009 16:09:57 +0100 (CET) Message-ID: <4B2A49C4.3040308@it.uc3m.es> Date: Thu, 17 Dec 2009 16:09:56 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17076.000 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:10:17 -0000 Reinaldo Penno escribió: > That is fine. I checked version 07 and that is not captured in the spec yet. > > > On 12/16/09 5:21 AM, "marcelo bagnulo braun" wrote: > > >>> Finally it says ' If a packet other than a RST packet is received". If B >>> sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the >>> connection open? >>> >>> >>> >> yes, but we can limit it to data segments and we could limit it packet >> flying from the end the received the RST. I don't have a problem with >> that neither. >> > > > In the interim meeting yesterday, the feedback that the WG provided was against this and that they would rather to keep it as it is. Hence, i have not changed that. Regards, marcelo From rpenno@juniper.net Thu Dec 17 07:19:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2751E28C138 for ; Thu, 17 Dec 2009 07:19:41 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnGohm2PGZ6M for ; Thu, 17 Dec 2009 07:19:40 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 4721828C132 for ; Thu, 17 Dec 2009 07:19:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSypL+x5IEvQvJy7/pD1jgkTe9XgonVha@postini.com; Thu, 17 Dec 2009 07:19:26 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 17 Dec 2009 07:13:40 -0800 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; Thu, 17 Dec 2009 10:13:39 -0500 From: Reinaldo Penno To: marcelo bagnulo braun Date: Thu, 17 Dec 2009 10:13:37 -0500 Thread-Topic: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 Thread-Index: Acp/KwKZE0tAjoTCTM+umheeq04VkAAAH8fp Message-ID: In-Reply-To: <4B2A49C4.3040308@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:19:41 -0000 Thanks, What was the reason given? On 12/17/09 7:09 AM, "marcelo bagnulo braun" wrote: > Reinaldo Penno escribi=F3: >> That is fine. I checked version 07 and that is not captured in the spec = yet. >>=20 >>=20 >> On 12/16/09 5:21 AM, "marcelo bagnulo braun" wrote: >>=20 >> =20 >>>> Finally it says ' If a packet other than a RST packet is received". If= B >>>> sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep t= he >>>> connection open? >>>>=20 >>>> =20 >>>> =20 >>> yes, but we can limit it to data segments and we could limit it packet >>> flying from the end the received the RST. I don't have a problem with >>> that neither. >>> =20 >>=20 >>=20 >> =20 > In the interim meeting yesterday, the feedback that the WG provided was > against this and that they would rather to keep it as it is. > Hence, i have not changed that. >=20 > Regards, marcelo >=20 From marcelo@it.uc3m.es Thu Dec 17 07:28:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0033A67CC for ; Thu, 17 Dec 2009 07:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rwxawfywfCK for ; Thu, 17 Dec 2009 07:28:24 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CE2CF3A6930 for ; Thu, 17 Dec 2009 07:28:23 -0800 (PST) Received: from r190-135-66-132.dialup.adsl.anteldata.net.uy (r190-135-66-132.dialup.adsl.anteldata.net.uy [190.135.66.132]) by smtp02.uc3m.es (Postfix) with ESMTP id E9C096C24E3; Thu, 17 Dec 2009 16:28:06 +0100 (CET) Message-ID: <4B2A4E05.4080806@it.uc3m.es> Date: Thu, 17 Dec 2009 16:28:05 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17076.000 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TCP RST RCV in v6v4-xlate-stateful-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:28:25 -0000 Reinaldo Penno escribió: > Thanks, > > What was the reason given? > What i understood was that the NAT64 should try to minimize as much as possible to second guess what is going on, so, being more conservative is better and in particular in this issue, that is not critical for interop, just an optimization for the nat behaviour not sure if i missed some of other argument Regards, marcelo > > On 12/17/09 7:09 AM, "marcelo bagnulo braun" wrote: > > >> Reinaldo Penno escribió: >> >>> That is fine. I checked version 07 and that is not captured in the spec yet. >>> >>> >>> On 12/16/09 5:21 AM, "marcelo bagnulo braun" wrote: >>> >>> >>> >>>>> Finally it says ' If a packet other than a RST packet is received". If B >>>>> sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the >>>>> connection open? >>>>> >>>>> >>>>> >>>>> >>>> yes, but we can limit it to data segments and we could limit it packet >>>> flying from the end the received the RST. I don't have a problem with >>>> that neither. >>>> >>>> >>> >>> >> In the interim meeting yesterday, the feedback that the WG provided was >> against this and that they would rather to keep it as it is. >> Hence, i have not changed that. >> >> Regards, marcelo >> >> > > > From root@core3.amsl.com Thu Dec 17 07:30:03 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BE0EE3A6A5D; Thu, 17 Dec 2009 07:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217153003.BE0EE3A6A5D@core3.amsl.com> Date: Thu, 17 Dec 2009 07:30:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-address-format-03.txt Pages : 17 Date : 2009-12-17 This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a Well-Known Prefix for use in algorithmic translations, while allowing organizations to also use Network Specific Prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-address-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17072725.I-D@ietf.org> --NextPart-- From dwing@cisco.com Thu Dec 17 09:32:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF613A694F for ; Thu, 17 Dec 2009 09:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iEMHN7v1qH2 for ; Thu, 17 Dec 2009 09:32:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BA3FE3A68F6 for ; Thu, 17 Dec 2009 09:32:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4gALH5KUurR7Hu/2dsb2JhbACCX4YAgRaNLqhKlysChCsEgWOKUg X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208";a="451502220" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 17 Dec 2009 17:32:20 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBHHWK0T023419; Thu, 17 Dec 2009 17:32:20 GMT From: "Dan Wing" To: References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <200912170601.nBH61mR3087916@drugs.dv.isc.org> <048401ca7ee0$62373600$c4f0200a@cisco.com> <200912171017.nBHAHUef099528@drugs.dv.isc.org> Date: Thu, 17 Dec 2009 09:32:20 -0800 Message-ID: <018801ca7f3e$e30fe4d0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200912171017.nBHAHUef099528@drugs.dv.isc.org> Thread-Index: Acp/AiYj82FcXG++QuiTejCwrgsPvQAPKDFA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:32:35 -0000 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Thursday, December 17, 2009 2:18 AM > To: Dan Wing > Cc: 'Andrew Sullivan'; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > > In message <048401ca7ee0$62373600$c4f0200a@cisco.com>, "Dan > Wing" writes: > > Also most of the servfails arn't. > > > > > SERVFAIL: > > > > www.livejasmin.com > > works Not for me. Pray tell, what I am doing wrong. > dig +short livejasmin.com ns ns1.lalibco.com. ns2.lalibco.com. > dig @ns1.lalibco.com aaaa www.livejasmin.com ; <<>> DiG 9.6.1-P1 <<>> @ns1.lalibco.com aaaa www.livejasmin.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15506 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.livejasmin.com. IN AAAA ;; AUTHORITY SECTION: livejasmin.com. 14400 IN SOA ns1.lalibco.com. hostmaster.lalibco.com. 2009111003 28800 7200 604800 14400 ;; Query time: 8 msec ;; SERVER: 93.93.50.1#53(93.93.50.1) ;; WHEN: Thu Dec 17 09:31:16 2009 ;; MSG SIZE rcvd: 95 > dig @ns2.lalibco.com aaaa www.livejasmin.com ; <<>> DiG 9.6.1-P1 <<>> @ns2.lalibco.com aaaa www.livejasmin.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30271 <<<<<<<<<<<<<<<<<<<<<<<< ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.livejasmin.com. IN AAAA ;; Query time: 8 msec ;; SERVER: 93.93.51.1#53(93.93.51.1) ;; WHEN: Thu Dec 17 09:31:20 2009 ;; MSG SIZE rcvd: 36 -d > > > > www.ynet.com > > works > > > > > www.awempire.com > > works > > > > > www.ikea.com > > works > > > > > www.hc360.com > > broken, referral to self. > > gslb.hc360.com. 3600 IN NS shdns.hc360.com.cn. > gslb.hc360.com. 3600 IN NS bjdns.hc360.com.cn. > ;; Received 88 bytes from 203.134.246.111#53(ns1.hc360.com) in 421 ms > > gslb.hc360.com. 669 IN NS bjdns.hc360.com.cn. > gslb.hc360.com. 669 IN NS shdns.hc360.com.cn. > ;; Received 120 bytes from > 203.134.246.9#53(bjdns.hc360.com.cn) in 429 ms > > > > > www.vnet.cn > > works > > > > > www.bramjnet.com > > works > > > > > www.miibeian.gov.cn > > works > > > > > www.startpagina.nl > > works > > > > > www.sznews.com > > broken, root referral. > > > > > www.yingjiesheng.com > > works > > > > > www.rueducommerce.fr > > works > > > > > www.shortnews.de > > works > > > > > www.heavy.com > > works > > > > > www.penny-arcade.com > > works > > > > > www.nouvelobs.com > > works > > > > > www.eventim.de > > works > > > > > www.cdcovers.cc > > works > > > > > www.soccerway.com > > works > > > > > www.pathfinder.gr > > broken, misconfigured load balance, wrong backing zone. > > www.pathfinder.gr. 10800 IN NS > lpsb.phaistosnetworks.gr. > www.pathfinder.gr. 10800 IN NS > lptb.phaistosnetworks.gr. > www.pathfinder.gr. 10800 IN NS > lp.phaistosnetworks.gr. > ;; Received 155 bytes from > 94.136.45.31#53(dnsuk.phaistosnetworks.gr) in 1008 ms > > pathfinder.gr. 86400 IN SOA > pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 > 7200 604800 86400 > > ;; Received 124 bytes from > 194.0.185.253#53(lptb.phaistosnetworks.gr) in 410 ms > > > > > www.gazetaesportiva.net > > works > > > > > www.5giay.vn > > works > > > > > www.ratp.info > > works > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Thu Dec 17 09:39:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C580A3A6984 for ; Thu, 17 Dec 2009 09:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRfWHgcKirl3 for ; Thu, 17 Dec 2009 09:39:48 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E409A3A68F6 for ; Thu, 17 Dec 2009 09:39:48 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAIP7KUurR7Hu/2dsb2JhbACIX4EWtWaXK4QtBIFj X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208";a="205875526" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Dec 2009 17:39:34 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBHHdY0Y000223; Thu, 17 Dec 2009 17:39:34 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 09:39:34 -0800 Message-ID: <019301ca7f3f$e5de0380$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acp/DZ7bSOizIF73QpK3Qj4eeFnFMgAMYHng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:39:50 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, December 17, 2009 3:39 AM > To: Dan Wing > Cc: 'Andrew Sullivan'; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > On 17 dec 2009, at 6:30, Dan Wing wrote: > > >> Just being persistant and request an A record whenever we > >> don't get an AAAA answer for any (?) reason (timeout, > >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > >> reasonable tradeoff. However, that would be a slight > >> departure from the current draft. > > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > > would be ineffective for many websites, > > Well, AFAIK with things like REFUSED and SERVFAIL you can > argue that this result is particular to the AAAA query and > the A query may give a different result. With NXDOMAIN the > answer authoritatively states that the domain doesn't exist, > so the only way the A query can produce a different answer is > if someone is completely breaking the specifications. > > If the DNS64 is doing recursive queries itself it SHOULD > never encounter REFUSED, because then there would be a break > in the delegation chain, so I'm not worried about generating > a few more queries in that case. If there is a resolver in > the middle it could be that the resolver doesn't want to > resolve for the DNS64, but in that case the whole setup > doesn't work so the users will give up and again, a few extra > packets is not an issue. > > Not sure where SERVFAIL would come from in the authoritative > case, but in the resolver case it can obviously result from a > REFUSED authoritative response so again no problem querying > for an A record. > > However, the NXDOMAIN case will normally be the result of a > query for a non-existant domain. If there is a large amount > of such queries doubling it is not a good idea. > > People configuring their DNS server to send out REFUSED for > AAAA queries is something that I can > kinda-sorta-but-not-really follow, but NXDOMAIN when there is > in fact an A record is just plain wrong on every level so > generating lots of extra queries when there is NXDOMAIN for > AAAA or by always doing A first even when we don't need the A > record is probably a bridge too far for the IETF to mandate. How do dual-stacked Windows and OSX, with their built-in telnet and with various common web browsers (Firefox, IE, Safari, Opera, Chrome) behave when they get a SERVFAIL in response to an AAAA query? I bet a beer they try an A. Does anyone know? > > Of those 5000, their nameservers returned: > > > NOERROR, 4766 (95.3%) > > NXDOMAIN, 37 (0.74%) > > REFUSED, 18 (0.36%) > > SERVFAIL, 23 (0.46%) > > What about the remaining 156? Timeout? (For instance, one on > Mark's list that I tried replied in 4800 ms for me...) > > Would be interesting to see the results for A. As we saw in > the FTP case, there is always a percent or two that just > don't do anything reasonable. (Although with top 5000 popular > sites this is probably better than an old list of FTP sites.) Yes, A records fail, too. When I run my weekly test of the top 25000 web hosts (using Alexa's list), I get a 0.9% failure rate to get an A record. For that test, my program calls getaddrinfo() and times out or gets an error. -d From iljitsch@muada.com Thu Dec 17 09:56:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636EA3A6994 for ; Thu, 17 Dec 2009 09:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgP1OTW3-7AG for ; Thu, 17 Dec 2009 09:56:56 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 711093A67DB for ; Thu, 17 Dec 2009 09:56:56 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBHHtwjh073451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Dec 2009 18:55:59 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <019301ca7f3f$e5de0380$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 18:56:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1077) Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:56:57 -0000 On 17 dec 2009, at 18:39, Dan Wing wrote: > How do dual-stacked Windows and OSX, with their built-in telnet=20 > and with various common web browsers (Firefox, IE, Safari, Opera, > Chrome) behave when they get a SERVFAIL in response to an AAAA > query? I bet a beer they try an A. > Does anyone know? I did some quick tests with strange results. It seems that one = ingredient here is whether there is a CNAME involved. Haven't had time = to figure it out conclusively. (Doesn't help that the new MacOS has a = bug with AAAA records and CNAMEs.) Two points: 1. Applications very rarely do their own DNS lookups, this is all piped = through the system APIs which use all kinds of black magic to resolve = stuff from hosts.txt, WINS, yellow pages, you name it. And oh yes, the = DNS. 2. I think we mostly agree that doing an A query after a SERVFAIL for = AAAA is reasonable, the problem is NXDOMAIN.= From root@core3.amsl.com Thu Dec 17 10:15:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 655703A67EA; Thu, 17 Dec 2009 10:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217181502.655703A67EA@core3.amsl.com> Date: Thu, 17 Dec 2009 10:15:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN) Extension for IPv6 Author(s) : S. Perreault, G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-08.txt Pages : 13 Date : 2009-12-17 This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17101036.I-D@ietf.org> --NextPart-- From dwing@cisco.com Thu Dec 17 10:21:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C763A68E2 for ; Thu, 17 Dec 2009 10:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHQt0jh948F2 for ; Thu, 17 Dec 2009 10:21:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2D59A3A67A4 for ; Thu, 17 Dec 2009 10:21:24 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAFoFKkurR7Ht/2dsb2JhbACIX4EWtXCXLYQtBIFj X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208";a="229355102" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 17 Dec 2009 18:21:10 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBHIL9xF002906; Thu, 17 Dec 2009 18:21:09 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> Date: Thu, 17 Dec 2009 10:21:09 -0800 Message-ID: <01c601ca7f45$b52e1e90$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acp/Qklu28P4tybCQ36e9cU9y1GflgAAyP0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:21:25 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, December 17, 2009 9:56 AM > To: Dan Wing > Cc: 'Andrew Sullivan'; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > On 17 dec 2009, at 18:39, Dan Wing wrote: > > > How do dual-stacked Windows and OSX, with their built-in telnet > > and with various common web browsers (Firefox, IE, Safari, Opera, > > Chrome) behave when they get a SERVFAIL in response to an AAAA > > query? I bet a beer they try an A. > > > Does anyone know? > > I did some quick tests with strange results. It seems that > one ingredient here is whether there is a CNAME involved. > Haven't had time to figure it out conclusively. (Doesn't help > that the new MacOS has a bug with AAAA records and CNAMEs.) > > Two points: > > 1. Applications very rarely do their own DNS lookups, this is > all piped through the system APIs which use all kinds of > black magic to resolve stuff from hosts.txt, WINS, yellow > pages, you name it. And oh yes, the DNS. And some applications call getaddrinfo() and trust the right thing will occur, and others call it twice (once asking for IPv4 addresses, again for IPv6) and apply their own preference/priority logic to the results. > 2. I think we mostly agree that doing an A query after a > SERVFAIL for AAAA is reasonable, the problem is NXDOMAIN. Yes, the problem is deciding if we want to optimize NXDOMAIN versus risk some domains being inaccessible to IPv6-only hosts using a DNS64. -d From simon.perreault@viagenie.ca Thu Dec 17 10:32:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E96F28C12A for ; Thu, 17 Dec 2009 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G30BuUQg+bqp for ; Thu, 17 Dec 2009 10:32:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 28ADD3A69BB for ; Thu, 17 Dec 2009 10:32:41 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id A8D7120E36 for ; Thu, 17 Dec 2009 13:32:26 -0500 (EST) Message-ID: <4B2A793A.4000502@viagenie.ca> Date: Thu, 17 Dec 2009 13:32:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> In-Reply-To: <046901ca7eda$19473db0$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:32:42 -0000 Dan Wing wrote, on 2009-12-17 00:30: > Of those 5000, their nameservers returned: > > NOERROR, 4766 (95.3%) > NXDOMAIN, 37 (0.74%) > REFUSED, 18 (0.36%) > SERVFAIL, 23 (0.46%) > > NXDOMAIN: > www.1e100.net > www.uimserv.net > www.yimg.com > www.rmxads.com > www.ggpht.com > www.edgesuite.net > www.webry.info > www.images-amazon.com > www.pgmediaserve.com > www.livefilestore.com > www.googlesyndication.com > www.ytimg.com > www.myfiles-express.com > www.myspacecdn.com > www.fbgdc.com > www.say-move.org > www.www.ne.jp > www.ucom.ne.jp > www.xtshare.com > www.nocookie.net > www.bingj.com > www.k12.ca.us > www.wateen.net > www.2mdn.net > www.kvors.com > www.yahoofs.jp > www.xii.jp > www.ebayrtm.com > www.atwola.com > www.twimg.com > www.www.gov.cn > www.movie-japan.com > www.mofile.com > www.donetsk.ua > www.gnspf.com > www.bannch.jp All these also return NXDOMAIN for the A query. > www.ecshop.com This one doesn't return NXDOMAIN for either A or AAAA, at least for me. Therefore, I think we should not try an A query when the AAAA query returns NXDOMAIN. But we should on any other error. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Thu Dec 17 10:37:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC2C3A68F2 for ; Thu, 17 Dec 2009 10:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSjghm3s2n+D for ; Thu, 17 Dec 2009 10:37:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C7FC43A67A3 for ; Thu, 17 Dec 2009 10:37:25 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 5844121BA8 for ; Thu, 17 Dec 2009 13:37:11 -0500 (EST) Message-ID: <4B2A7A53.5050107@viagenie.ca> Date: Thu, 17 Dec 2009 13:37:07 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> <01c601ca7f45$b52e1e90$c4f0200a@cisco.com> In-Reply-To: <01c601ca7f45$b52e1e90$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:37:26 -0000 Dan Wing wrote, on 2009-12-17 13:21: > Yes, the problem is deciding if we want to optimize > NXDOMAIN versus risk some domains being inaccessible > to IPv6-only hosts using a DNS64. I think this is backwards. NXDOMAIN means that the domain doesn't exist. So the "right" thing to do is to infer that the A query would also return NXDOMAIN, and not try it. The optimization would be to accommodate broken servers by also trying an A query. From my other post, I think this is not necessary since no domain in the Alexa top 5000 for which the AAAA query returns NXDOMAIN doesn't also return NXDOMAIN for the A query. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From marka@isc.org Thu Dec 17 13:08:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A202A3A693D for ; Thu, 17 Dec 2009 13:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVZoo+NUPwem for ; Thu, 17 Dec 2009 13:08:55 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 47D173A6918 for ; Thu, 17 Dec 2009 13:08:55 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EDF10E609F; Thu, 17 Dec 2009 21:08:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBHL8WjE015107; Fri, 18 Dec 2009 08:08:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912172108.nBHL8WjE015107@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <200912170601.nBH61mR3087916@drugs.dv.isc.org> <048401ca7ee0$62373600$c4f0200a@cisco.com> <200912171017.nBHAHUef099528@drugs.dv.isc.org> <018801ca7f3e$e30fe4d0$c4f0200a@cisco.com> In-reply-to: Your message of "Thu, 17 Dec 2009 09:32:20 -0800." <018801ca7f3e$e30fe4d0$c4f0200a@cisco.com> Date: Fri, 18 Dec 2009 08:08:32 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 21:08:56 -0000 In message <018801ca7f3e$e30fe4d0$c4f0200a@cisco.com>, "Dan Wing" writes: > > > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Sent: Thursday, December 17, 2009 2:18 AM > > To: Dan Wing > > Cc: 'Andrew Sullivan'; behave@ietf.org > > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > > record available > > > > > > In message <048401ca7ee0$62373600$c4f0200a@cisco.com>, "Dan > > Wing" writes: > > > > Also most of the servfails arn't. > > > > > > > SERVFAIL: > > > > > www.livejasmin.com > > > > works > > Not for me. Pray tell, what I am doing wrong. > > > dig +short livejasmin.com ns > ns1.lalibco.com. > ns2.lalibco.com. > > dig @ns1.lalibco.com aaaa www.livejasmin.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns1.lalibco.com aaaa www.livejasmin.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15506 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.livejasmin.com. IN AAAA > > ;; AUTHORITY SECTION: > livejasmin.com. 14400 IN SOA ns1.lalibco.com. > hostmaster.lalibco.com. 2009111003 28800 7200 604800 14400 > > ;; Query time: 8 msec > ;; SERVER: 93.93.50.1#53(93.93.50.1) > ;; WHEN: Thu Dec 17 09:31:16 2009 > ;; MSG SIZE rcvd: 95 > > > dig @ns2.lalibco.com aaaa www.livejasmin.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns2.lalibco.com aaaa www.livejasmin.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30271 > <<<<<<<<<<<<<<<<<<<<<<<< > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.livejasmin.com. IN AAAA > > ;; Query time: 8 msec > ;; SERVER: 93.93.51.1#53(93.93.51.1) > ;; WHEN: Thu Dec 17 09:31:20 2009 > ;; MSG SIZE rcvd: 36 The server is just lame. www.livejasmin.com is up however as the other server is answering correctly for both A and AAAA. Mark ; <<>> DiG 9.3.6-P1 <<>> @ns2.lalibco.com a www.livejasmin.com +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24128 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.livejasmin.com. IN A ;; Query time: 171 msec ;; SERVER: 93.93.51.1#53(93.93.51.1) ;; WHEN: Fri Dec 18 08:06:57 2009 ;; MSG SIZE rcvd: 36 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Thu Dec 17 14:38:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2687D3A6999 for ; Thu, 17 Dec 2009 14:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGJKWY7K7ZB7 for ; Thu, 17 Dec 2009 14:38:09 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 4588E3A6814 for ; Thu, 17 Dec 2009 14:38:09 -0800 (PST) Received: by ywh15 with SMTP id 15so2714970ywh.5 for ; Thu, 17 Dec 2009 14:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WRGgtz0fwaXBzhN9Tt7q0fdkWi7bRpGuhFP8ZhJWQV0=; b=nu1ds+QENZN1kYiDGmrcrN5go3UKfZ2zuv6DQCDo2X7lXurNefo5BKh2YoaTp9mzlv LkkBSxgb6g51Li7rWjc6E76lphyc5OgK6LkeiZjSWso+9ebCoaf31+CASPEMKc1eg4mO sTv8esB67L2inBT9f5H9Xd5vcw1ySrfLxZZJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Z0glpDC9gwULyodRf2lRVhB02q1euf+57CcvL/qnJNLR8/iTNvC7N95/6ZXO6QovgW OMjl5pJxnjwz7hsZxNc8jg0tN+8dUXvDNoMTN0KC+950axnPrW6v7ZH3czpF5gevTNJ0 cQUunWWqnqLCgvvpOSIeK9c2haYvmOUwSzQkM= Received: by 10.151.5.11 with SMTP id h11mr3841980ybi.305.1261089462943; Thu, 17 Dec 2009 14:37:42 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 6sm899385ywd.37.2009.12.17.14.37.39 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 14:37:41 -0800 (PST) Message-ID: <4B2AB2AF.4030106@gmail.com> Date: Fri, 18 Dec 2009 11:37:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xu Xiaohu References: <005d01ca7efc$9cc8bca0$e30c6f0a@china.huawei.com> In-Reply-To: <005d01ca7efc$9cc8bca0$e30c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 22:38:10 -0000 On 2009-12-17 22:37, Xu Xiaohu wrote: ... > It's too complex. Before you choose to use IPv6, you would have to determine > the NAT64 is stateless. To make things simple, IMHO, it'd better that native > connectivity (even address-only translation) is ALWAYS preferred to address > family translation. Not if identifying native connectivity is itself complicated. And also, this whole issue is an optimisation for a coexistence technique that we all hope has a short (maybe ten years) lifetime. > Xiaohu > >> These kinds of complications are why many of us are interested >> in the GROBJ effort and the GROBJ BoF in Hiroshima. Yes, but we have to admit that this pushes the problem up to the transport layer or higher. And maybe some sort of super-REAP that actually *measures* the best path will be the answer there, or of course MPTCP that intrinsically optimises traffic flow. Brian From root@core3.amsl.com Thu Dec 17 16:15:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 723B63A6984; Thu, 17 Dec 2009 16:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091218001501.723B63A6984@core3.amsl.com> Date: Thu, 17 Dec 2009 16:15:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-ftp64-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 00:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6-to-IPv4 translation FTP considerations Author(s) : I. van Beijnum Filename : draft-ietf-behave-ftp64-00.txt Pages : 14 Date : 2009-12-17 The File Transfer Protocol has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers are IPv6-only while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers don't support this mode, and some clients don't ask for it. This document describes server, client and middlebox (if any) behavior that minimizes this problem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-ftp64-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17161102.I-D@ietf.org> --NextPart-- From xuxh@huawei.com Thu Dec 17 17:30:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5553A680D for ; Thu, 17 Dec 2009 17:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxBkqy+wVlyD for ; Thu, 17 Dec 2009 17:30:19 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id CA0D23A66B4 for ; Thu, 17 Dec 2009 17:30:18 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT00K9DQTTK1@szxga01-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:29:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT00GOVQTT11@szxga01-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:29:53 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUT001XXQTTLF@szxml06-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:29:53 +0800 (CST) Date: Fri, 18 Dec 2009 09:29:53 +0800 From: Xu Xiaohu In-reply-to: <4B2A19CF.4010402@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <005101ca7f81$997f0e70$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQ Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 01:30:20 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > marcelo bagnulo braun > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > Xu Xiaohu escribi=A8=AE: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> Xu Xiaohu escribi=A8=AE: > >> > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > >>>> =B3=AD=CB=CD: behave@ietf.org > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL > >>>> non-0::/3 IPv6 addresses ? > >>>> > >>>> > >>>> > >>>>> There are three choice for the WKP in the address-format draft: > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified = in RFC > >>>>> 2765 Section 2.1; > >>>>> o request IANA to allocate a /32 prefix, > >>>>> o or request allocation of a new /96 prefix. > >>>>> > >>>>> Could you tell me which one is equivalent to the specific NSP I > >>>>> > >>>>> > >>> mentioned, > >>> > >>> > >>>>> which starts with a special binary value? > >>>>> > >>>>> > >>>> I just submitted an update to the address format draft: > >>>> > >>>> > >> > = http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.t= x > >> > >>>> t > >>>> In draft-02, we propose to use the Well Known Prefix = 64:FF9B::/96. > >>>> > >>>> > >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 > >>> > > Internet > > > >> to > >> > >>> an IPv4 network), as this would lead to using the Well-Known = Prefix with > >>> > > non > > > >>> global IPv4 addresses". However, the specific NSP starting with a > >>> > > special > > > >>> binary value (depicted as follows) could be used in the above = scenario > >>> > > since > > > >>> the Network Specific Parts is topologically aggregatable. That is = to > >>> > > say, > > > >>> the specific NSP is a hybrid type of 96/ prefix which starts with = a > >>> well-known binary (e.g., 00010101) while the remaining part is = network > >>> specific. > >>> > >>> +--------+--------------------------------+-----------------+ > >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > >>> +--------+--------------------------------+-----------------+ > >>> > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the > >>> > > specific > > > >>> NSP I mentioned. > >>> > >>> > >> Maybe i am not understanding what you have in mind. > >> Could you put an concrete example of a scenario involving the IPv6 > >> internet that requires the host to distinguish that the address of = its > >> peer is synthetic? > >> > > > > +-------------------+ > > | | > > +-------------+ | IPv6 Internet | +--------------+ > > | +---+ +--++---++ IPv4 only > > |Dual-stack | +-------------------+ |NAT64| | > > | +-----+ | ++---++ +-----+| > > | | H1 | | +-------------------+ | | H2 || > > | +-----+ +---++ +---+ +-----+| > > +-------------+ | IPv4 Internet | +--------------+ > > | | > > +-------------------+ > > > > In the above scenario, after obtaining a synthesized IPv6 address of = H2 > > (IPv4 host) through some way, H1 (dual-stack host) will initialize > > communication to H2 using IPv6 since it could not identify whether = the > > resolved IPv6 address is synthetic or not. However, it's better to = use IPv4 > > for the communication between them. > > > > Does that make sense? > > >=20 > i see the scenario now, >=20 > i used a similar argument for supporting the use of the Well know = prefix > a while ago, and the arguments against this argument (by Dan, who = wrote > then a draft about referals, correct me if i am wrong) was that there = is > actual no applications that actually do that today and that the > reasonable thing to do for an app was to pass the ipv4 address and = then > allow the receiving end to synthesize the IPv6 address if needed. +-------------------+ | | +-------------+ | IPv6 Internet | +--------------+ | +---+ +---++---++ IPv4 only | IPv6 only | +-------------------+ |NAT64| | | +-----+ | ++---++ +-----+| | | H1 | | +-------------------+ | | H2 || | +-----+ NAT64?- + +---+ +-----+| +-------------+ | IPv4 Internet | +--------------+ | | +-------------------+ If I understand your statement correctly, An IPv6 only site (e.g., left = site in the above figure) MUST have a connection to the IPv4 Internet via = NAT64 in order to access hosts located in an IPv4 only site (e.g., right site = in the above figure). Besides, the IPv6 only host (e.g. H1) MUST be able to synthesize IPv6 address by itself. If either of the above two conditions = is not satisfied, the communication between H1 and H2 is impossible. Xiaohu > > Xiaohu > > > > > > > >>>> > >>>> > >>> > >>> > >>> > > > > > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Thu Dec 17 17:34:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A8D3A6A22 for ; Thu, 17 Dec 2009 17:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.623 X-Spam-Level: * X-Spam-Status: No, score=1.623 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn-zIRo7lMIs for ; Thu, 17 Dec 2009 17:34:04 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B38233A68CF for ; Thu, 17 Dec 2009 17:34:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT002XKR00YM@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:33:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT008AIR00GD@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:33:36 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUT006H7R007J@szxml04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:33:36 +0800 (CST) Date: Fri, 18 Dec 2009 09:33:36 +0800 From: Xu Xiaohu In-reply-to: <4B2AB2AF.4030106@gmail.com> To: 'Brian E Carpenter' Message-id: <005201ca7f82$1e578a50$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/aZMeeZHRgN5LR3OKWTXGCIFOlAAGBNbw Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 01:34:05 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Brian E Carpenter = [mailto:brian.e.carpenter@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 6:38 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Dan Wing'; 'marcelo bagnulo braun'; behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > On 2009-12-17 22:37, Xu Xiaohu wrote: > ... > > It's too complex. Before you choose to use IPv6, you would have to determine > > the NAT64 is stateless. To make things simple, IMHO, it'd better = that native > > connectivity (even address-only translation) is ALWAYS preferred to address > > family translation. >=20 > Not if identifying native connectivity is itself complicated. And = also, Could you give a concrete example where identifying native connectivity = is itself complicated? Xiaohu > this whole issue is an optimisation for a coexistence technique that > we all hope has a short (maybe ten years) lifetime. >=20 > > Xiaohu > > > >> These kinds of complications are why many of us are interested > >> in the GROBJ effort and the GROBJ BoF in Hiroshima. >=20 > Yes, but we have to admit that this pushes the problem > up to the transport layer or higher. And maybe some sort of > super-REAP that actually *measures* the best path will be the > answer there, or of course MPTCP that intrinsically optimises > traffic flow. >=20 > Brian From xuxh@huawei.com Thu Dec 17 17:55:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D463A691F for ; Thu, 17 Dec 2009 17:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.642 X-Spam-Level: * X-Spam-Status: No, score=1.642 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zRQSSLo800r for ; Thu, 17 Dec 2009 17:54:59 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 51C943A6807 for ; Thu, 17 Dec 2009 17:54:59 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT00K4ARYYK1@szxga01-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:54:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT00G5ZRYY11@szxga01-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:54:34 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUT006Y9RYX7J@szxml04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 09:54:34 +0800 (CST) Date: Fri, 18 Dec 2009 09:54:33 +0800 From: Xu Xiaohu In-reply-to: <005101ca7f81$997f0e70$e30c6f0a@china.huawei.com> To: 'marcelo bagnulo braun' Message-id: <005901ca7f85$0b967c70$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAHA/hA= Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 01:55:03 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Xu > Xiaohu > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 9:30 > =CA=D5=BC=FE=C8=CB: 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > > marcelo bagnulo braun > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > > non-0::/3 IPv6 addresses ? > > > > Xu Xiaohu escribi=A8=AE: > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL > > >> non-0::/3 IPv6 addresses ? > > >> > > >> Xu Xiaohu escribi=A8=AE: > > >> > > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > >>>> =B3=AD=CB=CD: behave@ietf.org > > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to > ALL > > >>>> non-0::/3 IPv6 addresses ? > > >>>> > > >>>> > > >>>> > > >>>>> There are three choice for the WKP in the address-format = draft: > > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified = in > RFC > > >>>>> 2765 Section 2.1; > > >>>>> o request IANA to allocate a /32 prefix, > > >>>>> o or request allocation of a new /96 prefix. > > >>>>> > > >>>>> Could you tell me which one is equivalent to the specific NSP = I > > >>>>> > > >>>>> > > >>> mentioned, > > >>> > > >>> > > >>>>> which starts with a special binary value? > > >>>>> > > >>>>> > > >>>> I just submitted an update to the address format draft: > > >>>> > > >>>> > > >> > > > = http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.t= x > > >> > > >>>> t > > >>>> In draft-02, we propose to use the Well Known Prefix = 64:FF9B::/96. > > >>>> > > >>>> > > >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 > > >>> > > > Internet > > > > > >> to > > >> > > >>> an IPv4 network), as this would lead to using the Well-Known = Prefix > with > > >>> > > > non > > > > > >>> global IPv4 addresses". However, the specific NSP starting with = a > > >>> > > > special > > > > > >>> binary value (depicted as follows) could be used in the above scenario > > >>> > > > since > > > > > >>> the Network Specific Parts is topologically aggregatable. That = is to > > >>> > > > say, > > > > > >>> the specific NSP is a hybrid type of 96/ prefix which starts = with a > > >>> well-known binary (e.g., 00010101) while the remaining part is network > > >>> specific. > > >>> > > >>> +--------+--------------------------------+-----------------+ > > >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > >>> +--------+--------------------------------+-----------------+ > > >>> > > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to = the > > >>> > > > specific > > > > > >>> NSP I mentioned. > > >>> > > >>> > > >> Maybe i am not understanding what you have in mind. > > >> Could you put an concrete example of a scenario involving the = IPv6 > > >> internet that requires the host to distinguish that the address = of its > > >> peer is synthetic? > > >> > > > > > > +-------------------+ > > > | | > > > +-------------+ | IPv6 Internet | +--------------+ > > > | +---+ +--++---++ IPv4 only > > > |Dual-stack | +-------------------+ |NAT64| | > > > | +-----+ | ++---++ +-----+| > > > | | H1 | | +-------------------+ | | H2 || > > > | +-----+ +---++ +---+ +-----+| > > > +-------------+ | IPv4 Internet | +--------------+ > > > | | > > > +-------------------+ > > > > > > In the above scenario, after obtaining a synthesized IPv6 address = of H2 > > > (IPv4 host) through some way, H1 (dual-stack host) will initialize > > > communication to H2 using IPv6 since it could not identify whether = the > > > resolved IPv6 address is synthetic or not. However, it's better to = use > IPv4 > > > for the communication between them. > > > > > > Does that make sense? > > > > > > > i see the scenario now, > > > > i used a similar argument for supporting the use of the Well know = prefix > > a while ago, and the arguments against this argument (by Dan, who = wrote > > then a draft about referals, correct me if i am wrong) was that = there is > > actual no applications that actually do that today and that the > > reasonable thing to do for an app was to pass the ipv4 address and = then > > allow the receiving end to synthesize the IPv6 address if needed. >=20 > +-------------------+ > | | > +-------------+ | IPv6 Internet | +--------------+ > | +---+ +---++---++ IPv4 only > | IPv6 only | +-------------------+ |NAT64| | > | +-----+ | ++---++ +-----+| > | | H1 | | +-------------------+ | | H2 || > | +-----+ NAT64?- + +---+ +-----+| > +-------------+ | IPv4 Internet | +--------------+ > | | > +-------------------+ > If I understand your statement correctly, An IPv6 only site (e.g., = left site > in the above figure) MUST have a connection to the IPv4 Internet via = NAT64 > in order to access hosts located in an IPv4 only site (e.g., right = site in > the above figure). Besides, the IPv6 only host (e.g. H1) MUST be able = to > synthesize IPv6 address by itself. If either of the above two = conditions is > not satisfied, the communication between H1 and H2 is impossible. Oh, the second condition can also be replaced by synthesizing IPv6 = address on DNS64 server. Then, what is the meaning of the IPv6 Internet to IPv4 network scenario? Xiaohu > > > > > > > > > > > >>>> > > >>>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Dec 17 19:28:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152C23A691F for ; Thu, 17 Dec 2009 19:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4diJZBiXDgD for ; Thu, 17 Dec 2009 19:28:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1EDDF3A690C for ; Thu, 17 Dec 2009 19:28:33 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUQABaFKkurR7Ht/2dsb2JhbACCX4YAgRaNLKdplyKELQSBY4pS X-IronPort-AV: E=Sophos;i="4.47,416,1257120000"; d="scan'208";a="121687553" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2009 03:28:18 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI3SInZ004104; Fri, 18 Dec 2009 03:28:18 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com><4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com><046901ca7eda$19473db0$c4f0200a@cisco.com> <4B2A793A.4000502@viagenie.ca> Date: Thu, 17 Dec 2009 19:28:19 -0800 Message-ID: <03f301ca7f92$24edd6c0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B2A793A.4000502@viagenie.ca> Thread-Index: Acp/R1nU8F6apH7LRB+h2oHEsswOpgASsVFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:28:34 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Thursday, December 17, 2009 10:32 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > Dan Wing wrote, on 2009-12-17 00:30: > > Of those 5000, their nameservers returned: > > > > NOERROR, 4766 (95.3%) > > NXDOMAIN, 37 (0.74%) > > REFUSED, 18 (0.36%) > > SERVFAIL, 23 (0.46%) > > > > NXDOMAIN: > > www.1e100.net > > www.uimserv.net > > www.yimg.com > > www.rmxads.com > > www.ggpht.com > > www.edgesuite.net > > www.webry.info > > www.images-amazon.com > > www.pgmediaserve.com > > www.livefilestore.com > > www.googlesyndication.com > > www.ytimg.com > > www.myfiles-express.com > > www.myspacecdn.com > > www.fbgdc.com > > www.say-move.org > > www.www.ne.jp > > www.ucom.ne.jp > > www.xtshare.com > > www.nocookie.net > > www.bingj.com > > www.k12.ca.us > > www.wateen.net > > www.2mdn.net > > www.kvors.com > > www.yahoofs.jp > > www.xii.jp > > www.ebayrtm.com > > www.atwola.com > > www.twimg.com > > www.www.gov.cn > > www.movie-japan.com > > www.mofile.com > > www.donetsk.ua > > www.gnspf.com > > www.bannch.jp > > All these also return NXDOMAIN for the A query. You're right. Thanks for checking that! -d > > www.ecshop.com > > This one doesn't return NXDOMAIN for either A or AAAA, at > least for me. > > Therefore, I think we should not try an A query when the AAAA > query returns > NXDOMAIN. But we should on any other error. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Thu Dec 17 19:31:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41B83A67A7 for ; Thu, 17 Dec 2009 19:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qLpwRChYVyJ for ; Thu, 17 Dec 2009 19:31:48 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id DBAAC3A63D3 for ; Thu, 17 Dec 2009 19:31:47 -0800 (PST) Received: by gxk28 with SMTP id 28so2647957gxk.9 for ; Thu, 17 Dec 2009 19:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kLcYzO683osXhTFyVBscVVFmMrjooPEbGHeJJxS/wc8=; b=eAomI5Hb0Z4MUCbvhn4lsebGRa0Afqja0xnLJaBFw+J2FWlNuxzNmTFILEKv7Y+jXK svfiEzVrrXrYmoZfoMLNpfbcchvSSZTuuu9/s5QcnlNQ0arkiljgFy/6c0GTK4v8KV93 lczZLzyTsjIclOMvpou08jBTKJEWu853Qt8fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vd2HB2KhISuPWwi6nRyrnp1tSPdaF2zvklOqkabzVkklQNEKAZ9qRH8/32iqY7p0AJ pFQQC0GSV1EXcT8aDDEF+tDBiU661X1Lt0eDL+xpa7o3Pc23qpY3irieKmy2Gyo/K7ba 2O9cXaoh5Fk4t0jhzyD47jbS+mUExJ3Il0mIU= Received: by 10.150.234.15 with SMTP id g15mr5360098ybh.194.1261107089777; Thu, 17 Dec 2009 19:31:29 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 23sm984485ywh.3.2009.12.17.19.31.27 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 19:31:29 -0800 (PST) Message-ID: <4B2AF789.4090608@gmail.com> Date: Fri, 18 Dec 2009 16:31:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xu Xiaohu References: <005201ca7f82$1e578a50$e30c6f0a@china.huawei.com> In-Reply-To: <005201ca7f82$1e578a50$e30c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:31:49 -0000 On 2009-12-18 14:33, Xu Xiaohu wrote: >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian E Carpenter [mailto:brian.e.carpent= er@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=8818=E6=97= =A5 6:38 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu >> =E6=8A=84=E9=80=81: 'Dan Wing'; 'marcelo bagnulo braun'; behave@ietf.o= rg >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> On 2009-12-17 22:37, Xu Xiaohu wrote: >> ... >>> It's too complex. Before you choose to use IPv6, you would have to > determine >>> the NAT64 is stateless. To make things simple, IMHO, it'd better that= > native >>> connectivity (even address-only translation) is ALWAYS preferred to > address >>> family translation. >> Not if identifying native connectivity is itself complicated. And also= , >=20 > Could you give a concrete example where identifying native connectivity= is > itself complicated? It doesn't seem safe to assume that just because a host has a global IPv6 address and the correspondent has a global IPv6 address, there is native connectivity between them. The running code examples of this are for IPv4 - there are many scenarios where two non-RFC1918 addresses can only communicate via NAT. Basically I think that trying to deduce scope or address realm by examining bits in an address is unsafe (in the general case). Brian >=20 > Xiaohu >=20 >> this whole issue is an optimisation for a coexistence technique that >> we all hope has a short (maybe ten years) lifetime. >> >>> Xiaohu >>> >>>> These kinds of complications are why many of us are interested >>>> in the GROBJ effort and the GROBJ BoF in Hiroshima. >> Yes, but we have to admit that this pushes the problem >> up to the transport layer or higher. And maybe some sort of >> super-REAP that actually *measures* the best path will be the >> answer there, or of course MPTCP that intrinsically optimises >> traffic flow. >> >> Brian >=20 >=20 From ajs@shinkuro.com Thu Dec 17 19:34:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79ECA3A681F for ; Thu, 17 Dec 2009 19:34:06 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmQa7OawDbDt for ; Thu, 17 Dec 2009 19:34:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9BD233A67CC for ; Thu, 17 Dec 2009 19:34:05 -0800 (PST) Received: from crankycanuck.ca (unknown [206.47.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 60E1C2FE8CEE for ; Fri, 18 Dec 2009 03:33:50 +0000 (UTC) Date: Thu, 17 Dec 2009 22:33:48 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091218033348.GB47068@shinkuro.com> References: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:34:06 -0000 On Thu, Dec 17, 2009 at 06:56:28PM +0100, Iljitsch van Beijnum wrote: > > 2. I think we mostly agree that doing an A query after a SERVFAIL for AAAA is reasonable, the problem is NXDOMAIN. Yes. I am currently editing (at this very moment) the -04 draft and it is going to say this. It is a replacement for §5.1.2: 5.1.2. The answer when there is an error If the query results in a response with RCODE other than 0, then there are two possibilities. A result with RCODE=3 is handled according to normal DNS operation (which is normally to return the error to the client). This stage is still prior to any synthesis having happened, so a response to be returned to the client does not need any special assembly than would usually happen in DNS operation. Any other RCODE is treated as though the RCODE were 0 and the answer section were empty. This is because of the large number of different responses from deployed name servers when they receive AAAA queries without a AAAA record being available. It is important to note that, as of this writing, some servers respond with RCODE=3 to a AAAA query even if there is an A record available for that owner name. Those servers are in clear violation of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases. If you don't like this or have some suggested alternative text, it would be welcome; but please hurry. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu Dec 17 19:35:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0413A681F for ; Thu, 17 Dec 2009 19:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.78 X-Spam-Level: X-Spam-Status: No, score=-4.78 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqnrpM55oRdw for ; Thu, 17 Dec 2009 19:35:38 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 466EA3A67DD for ; Thu, 17 Dec 2009 19:35:38 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAH6GKkurR7Ht/2dsb2JhbACEC4RUgRa1GYZ6CJAjgSuBAoEqVgSBYw X-IronPort-AV: E=Sophos;i="4.47,416,1257120000"; d="scan'208";a="64512950" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2009 03:34:23 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI3YNfE007259; Fri, 18 Dec 2009 03:34:23 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'marcelo bagnulo braun'" References: <4B2A19CF.4010402@it.uc3m.es> <005101ca7f81$997f0e70$e30c6f0a@china.huawei.com> Date: Thu, 17 Dec 2009 19:34:24 -0800 Message-ID: <03fd01ca7f92$fea4dad0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <005101ca7f81$997f0e70$e30c6f0a@china.huawei.com> Thread-Index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:35:39 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > Sent: Thursday, December 17, 2009 5:30 PM > To: 'marcelo bagnulo braun' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALL non-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > > marcelo bagnulo braun > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALL > > non-0::/3 IPv6 addresses ? > >=20 > > Xu Xiaohu escribi=A8=AE: > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to=20 > apply to ALL > > >> non-0::/3 IPv6 addresses ? > > >> > > >> Xu Xiaohu escribi=A8=AE: > > >> > > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > >>>> =B3=AD=CB=CD: behave@ietf.org > > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = > to apply to > ALL > > >>>> non-0::/3 IPv6 addresses ? > > >>>> > > >>>> > > >>>> > > >>>>> There are three choice for the WKP in the=20 > address-format draft: > > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as=20 > specified in > RFC > > >>>>> 2765 Section 2.1; > > >>>>> o request IANA to allocate a /32 prefix, > > >>>>> o or request allocation of a new /96 prefix. > > >>>>> > > >>>>> Could you tell me which one is equivalent to the=20 > specific NSP I > > >>>>> > > >>>>> > > >>> mentioned, > > >>> > > >>> > > >>>>> which starts with a special binary value? > > >>>>> > > >>>>> > > >>>> I just submitted an update to the address format draft: > > >>>> > > >>>> > > >> > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > format-02.tx > > >> > > >>>> t > > >>>> In draft-02, we propose to use the Well Known Prefix=20 > 64:FF9B::/96. > > >>>> > > >>>> > > >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 > > >>> > > > Internet > > > > > >> to > > >> > > >>> an IPv4 network), as this would lead to using the=20 > Well-Known Prefix > with > > >>> > > > non > > > > > >>> global IPv4 addresses". However, the specific NSP=20 > starting with a > > >>> > > > special > > > > > >>> binary value (depicted as follows) could be used in the=20 > above scenario > > >>> > > > since > > > > > >>> the Network Specific Parts is topologically=20 > aggregatable. That is to > > >>> > > > say, > > > > > >>> the specific NSP is a hybrid type of 96/ prefix which=20 > starts with a > > >>> well-known binary (e.g., 00010101) while the remaining=20 > part is network > > >>> specific. > > >>> > > >>> +--------+--------------------------------+-----------------+ > > >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > >>> +--------+--------------------------------+-----------------+ > > >>> > > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not=20 > equivalent to the > > >>> > > > specific > > > > > >>> NSP I mentioned. > > >>> > > >>> > > >> Maybe i am not understanding what you have in mind. > > >> Could you put an concrete example of a scenario=20 > involving the IPv6 > > >> internet that requires the host to distinguish that the=20 > address of its > > >> peer is synthetic? > > >> > > > > > > +-------------------+ > > > | | > > > +-------------+ | IPv6 Internet | +--------------+ > > > | +---+ +--++---++ IPv4 only > > > |Dual-stack | +-------------------+ |NAT64| | > > > | +-----+ | ++---++ +-----+| > > > | | H1 | | +-------------------+ | | H2 || > > > | +-----+ +---++ +---+ +-----+| > > > +-------------+ | IPv4 Internet | +--------------+ > > > | | > > > +-------------------+ > > > > > > In the above scenario, after obtaining a synthesized IPv6=20 > address of H2 > > > (IPv4 host) through some way, H1 (dual-stack host) will initialize > > > communication to H2 using IPv6 since it could not=20 > identify whether the > > > resolved IPv6 address is synthetic or not. However, it's=20 > better to use > IPv4 > > > for the communication between them. > > > > > > Does that make sense? > > > > >=20 > > i see the scenario now, > >=20 > > i used a similar argument for supporting the use of the=20 > Well know prefix > > a while ago, and the arguments against this argument (by=20 > Dan, who wrote > > then a draft about referals, correct me if i am wrong) was=20 > that there is > > actual no applications that actually do that today and that the > > reasonable thing to do for an app was to pass the ipv4=20 > address and then > > allow the receiving end to synthesize the IPv6 address if needed. >=20 > +-------------------+ > | | > +-------------+ | IPv6 Internet | +--------------+ > | +---+ +---++---++ IPv4 only > | IPv6 only | +-------------------+ |NAT64| | > | +-----+ | ++---++ +-----+| > | | H1 | | +-------------------+ | | H2 || > | +-----+ NAT64?- + +---+ +-----+| > +-------------+ | IPv4 Internet | +--------------+ > | | > +-------------------+ > If I understand your statement correctly, An IPv6 only site=20 > (e.g., left site > in the above figure) MUST have a connection to the IPv4=20 > Internet via NAT64 > in order to access hosts located in an IPv4 only site (e.g.,=20 > right site in > the above figure). Besides, the IPv6 only host (e.g. H1) MUST=20 > be able to > synthesize IPv6 address by itself. If either of the above two=20 > conditions is > not satisfied, the communication between H1 and H2 is impossible. Yep -- because IPv4-only applications don't know anything about IPv6 = addresses -- IPv4-only applications don't know how to parse IPv6 addresses, how to include them in referrals, etc. We won't have any influence on those IPv4-only applications that are = already written that can't parse IPv6 addresses and have no idea what to do with = an IPv6 address (e.g., IPv4-only applications inside of personal video = recorders, SIP phones, etc.). Besides, if you give an IPv4-only host an IPv6 = address, it can't get to that IPv6 address; if the IPv4-only host is running Teredo = or ISATAP or its router is running 6to4, it isn't (strictly speaking) an IPv4-"only" host -- the host (and its application) is capable of IPv6, = too -- so it is effectively dual-stack. We can provide guidance to applications that are evolving (adding = features and functions, including becoming more aware of IPv6 interworking). That is = the hope of GROBJ, and the purpose of draft-wing-behave-learn-prefix and draft-wing-v6ops-v6app-v4server. -d > Xiaohu >=20 > > > Xiaohu > > > > > > > > > > > >>>> > > >>>> > > >>> > > >>> > > >>> > > > > > > > > > > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From xuxh@huawei.com Thu Dec 17 19:44:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848E13A68DD for ; Thu, 17 Dec 2009 19:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.66 X-Spam-Level: * X-Spam-Status: No, score=1.66 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoxdfsKQvbRY for ; Thu, 17 Dec 2009 19:44:13 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9E7943A67CC for ; Thu, 17 Dec 2009 19:44:13 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT009F1X105L@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:43:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT005YNX10D1@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:43:48 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUT00AQ9X10UL@szxml04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:43:48 +0800 (CST) Date: Fri, 18 Dec 2009 11:43:48 +0800 From: Xu Xiaohu In-reply-to: <4B2AF789.4090608@gmail.com> To: 'Brian E Carpenter' Message-id: <005b01ca7f94$4ec1c6d0$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/kp9qvt35cnVbS9675v/VXcpeYQAASf4w Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:44:14 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Brian > E Carpenter > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 11:31 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: behave@ietf.org; 'Dan Wing' > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > non-0::/3 IPv6 addresses ? >=20 > On 2009-12-18 14:33, Xu Xiaohu wrote: > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: Brian E Carpenter = [mailto:brian.e.carpenter@gmail.com] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 6:38 > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > >> =B3=AD=CB=CD: 'Dan Wing'; 'marcelo bagnulo braun'; behave@ietf.org > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> On 2009-12-17 22:37, Xu Xiaohu wrote: > >> ... > >>> It's too complex. Before you choose to use IPv6, you would have to > > determine > >>> the NAT64 is stateless. To make things simple, IMHO, it'd better = that > > native > >>> connectivity (even address-only translation) is ALWAYS preferred = to > > address > >>> family translation. > >> Not if identifying native connectivity is itself complicated. And = also, > > > > Could you give a concrete example where identifying native = connectivity is > > itself complicated? >=20 > It doesn't seem safe to assume that just because a host has a global > IPv6 address and the correspondent has a global IPv6 address, there is > native connectivity between them. The running code examples of this > are for IPv4 - there are many scenarios where two non-RFC1918 = addresses > can only communicate via NAT. I'm a bit confused. Could you list one scenario where two non-RFC1918 addresses can only communicate via NAT? Xiaohu > Basically I think that trying to deduce scope or address realm by > examining bits in an address is unsafe (in the general case). >=20 > Brian >=20 > > > > Xiaohu > > > >> this whole issue is an optimisation for a coexistence technique = that > >> we all hope has a short (maybe ten years) lifetime. > >> > >>> Xiaohu > >>> > >>>> These kinds of complications are why many of us are interested > >>>> in the GROBJ effort and the GROBJ BoF in Hiroshima. > >> Yes, but we have to admit that this pushes the problem > >> up to the transport layer or higher. And maybe some sort of > >> super-REAP that actually *measures* the best path will be the > >> answer there, or of course MPTCP that intrinsically optimises > >> traffic flow. > >> > >> Brian > > > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Thu Dec 17 19:50:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF373A67CC for ; Thu, 17 Dec 2009 19:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.677 X-Spam-Level: * X-Spam-Status: No, score=1.677 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIBMPpG2t9Cf for ; Thu, 17 Dec 2009 19:50:56 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B36CB3A67DD for ; Thu, 17 Dec 2009 19:50:55 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT00LL3XC6G6@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:50:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUT006A5XC694@szxga03-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:50:30 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUT00940XC56H@szxml04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 11:50:30 +0800 (CST) Date: Fri, 18 Dec 2009 11:50:29 +0800 From: Xu Xiaohu In-reply-to: <03fd01ca7f92$fea4dad0$c4f0200a@cisco.com> To: 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <005c01ca7f95$3e26df30$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXAAAJiU0A== Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:50:57 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Dan > Wing > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 11:34 > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > > Sent: Thursday, December 17, 2009 5:30 PM > > To: 'marcelo bagnulo braun' > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > apply to ALL non-0::/3 IPv6 addresses ? > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > > > marcelo bagnulo braun > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > =B3=AD=CB=CD: behave@ietf.org > > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > apply to ALL > > > non-0::/3 IPv6 addresses ? > > > > > > Xu Xiaohu escribi=A8=AE: > > > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to > > apply to ALL > > > >> non-0::/3 IPv6 addresses ? > > > >> > > > >> Xu Xiaohu escribi=A8=AE: > > > >> > > > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > > >>>> =B3=AD=CB=CD: behave@ietf.org > > > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 = format > > to apply to > > ALL > > > >>>> non-0::/3 IPv6 addresses ? > > > >>>> > > > >>>> > > > >>>> > > > >>>>> There are three choice for the WKP in the > > address-format draft: > > > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as > > specified in > > RFC > > > >>>>> 2765 Section 2.1; > > > >>>>> o request IANA to allocate a /32 prefix, > > > >>>>> o or request allocation of a new /96 prefix. > > > >>>>> > > > >>>>> Could you tell me which one is equivalent to the > > specific NSP I > > > >>>>> > > > >>>>> > > > >>> mentioned, > > > >>> > > > >>> > > > >>>>> which starts with a special binary value? > > > >>>>> > > > >>>>> > > > >>>> I just submitted an update to the address format draft: > > > >>>> > > > >>>> > > > >> > > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > > format-02.tx > > > >> > > > >>>> t > > > >>>> In draft-02, we propose to use the Well Known Prefix > > 64:FF9B::/96. > > > >>>> > > > >>>> > > > >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the = IPv6 > > > >>> > > > > Internet > > > > > > > >> to > > > >> > > > >>> an IPv4 network), as this would lead to using the > > Well-Known Prefix > > with > > > >>> > > > > non > > > > > > > >>> global IPv4 addresses". However, the specific NSP > > starting with a > > > >>> > > > > special > > > > > > > >>> binary value (depicted as follows) could be used in the > > above scenario > > > >>> > > > > since > > > > > > > >>> the Network Specific Parts is topologically > > aggregatable. That is to > > > >>> > > > > say, > > > > > > > >>> the specific NSP is a hybrid type of 96/ prefix which > > starts with a > > > >>> well-known binary (e.g., 00010101) while the remaining > > part is network > > > >>> specific. > > > >>> > > > >>> +--------+--------------------------------+-----------------+ > > > >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > > >>> +--------+--------------------------------+-----------------+ > > > >>> > > > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not > > equivalent to the > > > >>> > > > > specific > > > > > > > >>> NSP I mentioned. > > > >>> > > > >>> > > > >> Maybe i am not understanding what you have in mind. > > > >> Could you put an concrete example of a scenario > > involving the IPv6 > > > >> internet that requires the host to distinguish that the > > address of its > > > >> peer is synthetic? > > > >> > > > > > > > > +-------------------+ > > > > | | > > > > +-------------+ | IPv6 Internet | +--------------+ > > > > | +---+ +--++---++ IPv4 only > > > > |Dual-stack | +-------------------+ |NAT64| | > > > > | +-----+ | ++---++ +-----+| > > > > | | H1 | | +-------------------+ | | H2 || > > > > | +-----+ +---++ +---+ +-----+| > > > > +-------------+ | IPv4 Internet | +--------------+ > > > > | | > > > > +-------------------+ > > > > > > > > In the above scenario, after obtaining a synthesized IPv6 > > address of H2 > > > > (IPv4 host) through some way, H1 (dual-stack host) will = initialize > > > > communication to H2 using IPv6 since it could not > > identify whether the > > > > resolved IPv6 address is synthetic or not. However, it's > > better to use > > IPv4 > > > > for the communication between them. > > > > > > > > Does that make sense? > > > > > > > > > > i see the scenario now, > > > > > > i used a similar argument for supporting the use of the > > Well know prefix > > > a while ago, and the arguments against this argument (by > > Dan, who wrote > > > then a draft about referals, correct me if i am wrong) was > > that there is > > > actual no applications that actually do that today and that the > > > reasonable thing to do for an app was to pass the ipv4 > > address and then > > > allow the receiving end to synthesize the IPv6 address if needed. > > > > +-------------------+ > > | | > > +-------------+ | IPv6 Internet | +--------------+ > > | +---+ +---++---++ IPv4 only > > | IPv6 only | +-------------------+ |NAT64| | > > | +-----+ | ++---++ +-----+| > > | | H1 | | +-------------------+ | | H2 || > > | +-----+ NAT64?- + +---+ +-----+| > > +-------------+ | IPv4 Internet | +--------------+ > > | | > > +-------------------+ > > If I understand your statement correctly, An IPv6 only site > > (e.g., left site > > in the above figure) MUST have a connection to the IPv4 > > Internet via NAT64 > > in order to access hosts located in an IPv4 only site (e.g., > > right site in > > the above figure). Besides, the IPv6 only host (e.g. H1) MUST > > be able to > > synthesize IPv6 address by itself. If either of the above two > > conditions is > > not satisfied, the communication between H1 and H2 is impossible. >=20 > Yep -- because IPv4-only applications don't know anything about IPv6 addresses > -- IPv4-only applications don't know how to parse IPv6 addresses, how = to > include them in referrals, etc. Note that H1 in the above scenario is IPv6 only, but not IPv4 only. = Hence I'm wondering whether the statement you made is relevant to the above scenario. Xiaohu > We won't have any influence on those IPv4-only applications that are already > written that can't parse IPv6 addresses and have no idea what to do = with an > IPv6 address (e.g., IPv4-only applications inside of personal video recorders, > SIP phones, etc.). Besides, if you give an IPv4-only host an IPv6 address, > it > can't get to that IPv6 address; if the IPv4-only host is running = Teredo or > ISATAP or its router is running 6to4, it isn't (strictly speaking) an > IPv4-"only" host -- the host (and its application) is capable of IPv6, = too -- > so it is effectively dual-stack. >=20 > We can provide guidance to applications that are evolving (adding = features and > functions, including becoming more aware of IPv6 interworking). That = is the > hope of GROBJ, and the purpose of draft-wing-behave-learn-prefix and > draft-wing-v6ops-v6app-v4server. >=20 > -d >=20 >=20 > > Xiaohu > > > > > > Xiaohu > > > > > > > > > > > > > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Thu Dec 17 19:56:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6273A6874 for ; Thu, 17 Dec 2009 19:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmdeDrKEUVvi for ; Thu, 17 Dec 2009 19:56:23 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 257F93A63D3 for ; Thu, 17 Dec 2009 19:56:23 -0800 (PST) Received: by yxe30 with SMTP id 30so3082623yxe.29 for ; Thu, 17 Dec 2009 19:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=b3hJeO0P+5No1IAxbgLG32kF/IiJYU0YbSyH7pgP0Tc=; b=JglxBPL7Gi5zbknXJT6vxi7V14pB4BdCcRt2DSfDwvwzK8nH5XAXnR2o72daIKMI0X 9eZKZbFIydx7R0OVRltbbRSsa/13LiHnxybfh9Lt2K+jrt7iiLC25Cc2uF6aLQ+gLxp9 rcYxFaZMGGh+PLNAzPgKu6jWoH+hRS2LHu8/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=oysSQ16rBzfoCMCqDe4w2gVVzjGlyRB9iCFCV5qDKJTDxZ1yExD59or2cGdJ/mHvWO rC1EFCRTxvfVddj2HsdgYP1JXsFZtaVD054IzmTU/kieJFgLbGPbU/Uzs3NCQkMIEFAH zUGbAbrQuP/3q0duyZksuxyHAyYnSEtIVZnvQ= Received: by 10.91.152.16 with SMTP id e16mr309989ago.25.1261108564371; Thu, 17 Dec 2009 19:56:04 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 5sm987078ywd.23.2009.12.17.19.56.02 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 19:56:04 -0800 (PST) Message-ID: <4B2AFD53.6060104@gmail.com> Date: Fri, 18 Dec 2009 16:56:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xu Xiaohu References: <005b01ca7f94$4ec1c6d0$e30c6f0a@china.huawei.com> In-Reply-To: <005b01ca7f94$4ec1c6d0$e30c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:56:24 -0000 On 2009-12-18 16:43, Xu Xiaohu wrote: >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org [mailto:behave-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 > Brian >> E Carpenter >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=8818=E6=97= =A5 11:31 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu >> =E6=8A=84=E9=80=81: behave@ietf.org; 'Dan Wing' >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> On 2009-12-18 14:33, Xu Xiaohu wrote: >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian E Carpenter [mailto:brian.e.carpe= nter@gmail.com] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=8818=E6=97= =A5 6:38 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu >>>> =E6=8A=84=E9=80=81: 'Dan Wing'; 'marcelo bagnulo braun'; behave@ietf= =2Eorg >>>> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] Reason(s) for Modified EUI-64 forma= t to apply to ALL >>>> non-0::/3 IPv6 addresses ? >>>> >>>> On 2009-12-17 22:37, Xu Xiaohu wrote: >>>> ... >>>>> It's too complex. Before you choose to use IPv6, you would have to >>> determine >>>>> the NAT64 is stateless. To make things simple, IMHO, it'd better th= at >>> native >>>>> connectivity (even address-only translation) is ALWAYS preferred to= >>> address >>>>> family translation. >>>> Not if identifying native connectivity is itself complicated. And al= so, >>> Could you give a concrete example where identifying native connectivi= ty > is >>> itself complicated? >> It doesn't seem safe to assume that just because a host has a global >> IPv6 address and the correspondent has a global IPv6 address, there is= >> native connectivity between them. The running code examples of this >> are for IPv4 - there are many scenarios where two non-RFC1918 addresse= s >> can only communicate via NAT. >=20 > I'm a bit confused. Could you list one scenario where two non-RFC1918 > addresses can only communicate via NAT? Sure. Every company, and there are many, that runs globally unique IPv4 addresses internally but does not route them across border routers to the Internet, putting NAT at the border instead. In this case the addresses look like global addresses but behave like RFC1918 addresses. (Of course, this mainly applies to companies old enough to have their own PI space in IPv4. I used to work for one of them. ) Brian >=20 > Xiaohu >=20 >> Basically I think that trying to deduce scope or address realm by >> examining bits in an address is unsafe (in the general case). >> >> Brian >> >>> Xiaohu >>> >>>> this whole issue is an optimisation for a coexistence technique that= >>>> we all hope has a short (maybe ten years) lifetime. >>>> >>>>> Xiaohu >>>>> >>>>>> These kinds of complications are why many of us are interested >>>>>> in the GROBJ effort and the GROBJ BoF in Hiroshima. >>>> Yes, but we have to admit that this pushes the problem >>>> up to the transport layer or higher. And maybe some sort of >>>> super-REAP that actually *measures* the best path will be the >>>> answer there, or of course MPTCP that intrinsically optimises >>>> traffic flow. >>>> >>>> Brian >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 >=20 From root@core3.amsl.com Thu Dec 17 20:00:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B0FA3A684F; Thu, 17 Dec 2009 20:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091218040001.9B0FA3A684F@core3.amsl.com> Date: Thu, 17 Dec 2009 20:00:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 04:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-05.txt Pages : 31 Date : 2009-12-17 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-dns64-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17195646.I-D@ietf.org> --NextPart-- From dwing@cisco.com Thu Dec 17 20:00:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6204E3A67A7 for ; Thu, 17 Dec 2009 20:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA+EM1nsC9Tt for ; Thu, 17 Dec 2009 20:00:01 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1D9DD3A63D3 for ; Thu, 17 Dec 2009 20:00:01 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAFWNKkurR7Ht/2dsb2JhbACEC4RUgRa0doZ6CJAhgSuBAoEqVgSBYw X-IronPort-AV: E=Sophos;i="4.47,416,1257120000"; d="scan'208";a="121700122" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2009 03:59:46 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI3xkrJ018026; Fri, 18 Dec 2009 03:59:46 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'marcelo bagnulo braun'" References: <03fd01ca7f92$fea4dad0$c4f0200a@cisco.com> <005c01ca7f95$3e26df30$e30c6f0a@china.huawei.com> Date: Thu, 17 Dec 2009 19:59:46 -0800 Message-ID: <040e01ca7f96$89b23520$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <005c01ca7f95$3e26df30$e30c6f0a@china.huawei.com> Thread-Index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXAAAJiU0AAAYicg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 04:00:02 -0000 =20 > -----Original Message----- > From: Xu Xiaohu [mailto:xuxh@huawei.com]=20 > Sent: Thursday, December 17, 2009 7:50 PM > To: 'Dan Wing'; 'marcelo bagnulo braun' > Cc: behave@ietf.org > Subject: re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Dan > > Wing > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 11:34 > > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > > ALLnon-0::/3 IPv6 addresses ? > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: behave-bounces@ietf.org > > > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > > > Sent: Thursday, December 17, 2009 5:30 PM > > > To: 'marcelo bagnulo braun' > > > Cc: behave@ietf.org > > > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > > apply to ALL non-0::/3 IPv6 addresses ? > > > > > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > > > > marcelo bagnulo braun > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > > > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > > =B3=AD=CB=CD: behave@ietf.org > > > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to > > > apply to ALL > > > > non-0::/3 IPv6 addresses ? > > > > > > > > Xu Xiaohu escribi=A8=AE: > > > > > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > > > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 = format to > > > apply to ALL > > > > >> non-0::/3 IPv6 addresses ? > > > > >> > > > > >> Xu Xiaohu escribi=A8=AE: > > > > >> > > > > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > > > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > > > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > > > >>>> =B3=AD=CB=CD: behave@ietf.org > > > > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 = format > > > to apply to > > > ALL > > > > >>>> non-0::/3 IPv6 addresses ? > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>> There are three choice for the WKP in the > > > address-format draft: > > > > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as > > > specified in > > > RFC > > > > >>>>> 2765 Section 2.1; > > > > >>>>> o request IANA to allocate a /32 prefix, > > > > >>>>> o or request allocation of a new /96 prefix. > > > > >>>>> > > > > >>>>> Could you tell me which one is equivalent to the > > > specific NSP I > > > > >>>>> > > > > >>>>> > > > > >>> mentioned, > > > > >>> > > > > >>> > > > > >>>>> which starts with a special binary value? > > > > >>>>> > > > > >>>>> > > > > >>>> I just submitted an update to the address format draft: > > > > >>>> > > > > >>>> > > > > >> > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > > > format-02.tx > > > > >> > > > > >>>> t > > > > >>>> In draft-02, we propose to use the Well Known Prefix > > > 64:FF9B::/96. > > > > >>>> > > > > >>>> > > > > >>> "The Well-Known Prefix MUST NOT be used for=20 > scenario 3 (the IPv6 > > > > >>> > > > > > Internet > > > > > > > > > >> to > > > > >> > > > > >>> an IPv4 network), as this would lead to using the > > > Well-Known Prefix > > > with > > > > >>> > > > > > non > > > > > > > > > >>> global IPv4 addresses". However, the specific NSP > > > starting with a > > > > >>> > > > > > special > > > > > > > > > >>> binary value (depicted as follows) could be used in the > > > above scenario > > > > >>> > > > > > since > > > > > > > > > >>> the Network Specific Parts is topologically > > > aggregatable. That is to > > > > >>> > > > > > say, > > > > > > > > > >>> the specific NSP is a hybrid type of 96/ prefix which > > > starts with a > > > > >>> well-known binary (e.g., 00010101) while the remaining > > > part is network > > > > >>> specific. > > > > >>> > > > > >>>=20 > +--------+--------------------------------+-----------------+ > > > > >>> |00010101|Network Specific Parts (88 bits)|IPv4=20 > addr (32bit)| > > > > >>>=20 > +--------+--------------------------------+-----------------+ > > > > >>> > > > > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not > > > equivalent to the > > > > >>> > > > > > specific > > > > > > > > > >>> NSP I mentioned. > > > > >>> > > > > >>> > > > > >> Maybe i am not understanding what you have in mind. > > > > >> Could you put an concrete example of a scenario > > > involving the IPv6 > > > > >> internet that requires the host to distinguish that the > > > address of its > > > > >> peer is synthetic? > > > > >> > > > > > > > > > > +-------------------+ > > > > > | | > > > > > +-------------+ | IPv6 Internet | +--------------+ > > > > > | +---+ +--++---++ IPv4 only > > > > > |Dual-stack | +-------------------+ |NAT64| | > > > > > | +-----+ | ++---++ +-----+| > > > > > | | H1 | | +-------------------+ | | H2 || > > > > > | +-----+ +---++ +---+ +-----+| > > > > > +-------------+ | IPv4 Internet | +--------------+ > > > > > | | > > > > > +-------------------+ > > > > > > > > > > In the above scenario, after obtaining a synthesized IPv6 > > > address of H2 > > > > > (IPv4 host) through some way, H1 (dual-stack host)=20 > will initialize > > > > > communication to H2 using IPv6 since it could not > > > identify whether the > > > > > resolved IPv6 address is synthetic or not. However, it's > > > better to use > > > IPv4 > > > > > for the communication between them. > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > i see the scenario now, > > > > > > > > i used a similar argument for supporting the use of the > > > Well know prefix > > > > a while ago, and the arguments against this argument (by > > > Dan, who wrote > > > > then a draft about referals, correct me if i am wrong) was > > > that there is > > > > actual no applications that actually do that today and that the > > > > reasonable thing to do for an app was to pass the ipv4 > > > address and then > > > > allow the receiving end to synthesize the IPv6 address=20 > if needed. > > > > > > +-------------------+ > > > | | > > > +-------------+ | IPv6 Internet | +--------------+ > > > | +---+ +---++---++ IPv4 only > > > | IPv6 only | +-------------------+ |NAT64| | > > > | +-----+ | ++---++ +-----+| > > > | | H1 | | +-------------------+ | | H2 || > > > | +-----+ NAT64?- + +---+ +-----+| > > > +-------------+ | IPv4 Internet | +--------------+ > > > | | > > > +-------------------+ > > > If I understand your statement correctly, An IPv6 only site > > > (e.g., left site > > > in the above figure) MUST have a connection to the IPv4 > > > Internet via NAT64 > > > in order to access hosts located in an IPv4 only site (e.g., > > > right site in > > > the above figure). Besides, the IPv6 only host (e.g. H1) MUST > > > be able to > > > synthesize IPv6 address by itself. If either of the above two > > > conditions is > > > not satisfied, the communication between H1 and H2 is impossible. > >=20 > > Yep -- because IPv4-only applications don't know anything about IPv6 > addresses > > -- IPv4-only applications don't know how to parse IPv6=20 > addresses, how to > > include them in referrals, etc. >=20 > Note that H1 in the above scenario is IPv6 only, but not IPv4=20 > only. Hence > I'm wondering whether the statement you made is relevant to the above > scenario. But H2 is IPv4-only. But nobody can know how the referral happened; the address referral may have come=20 through H3, not shown in the diagram, which might itself=20 be IPv4-only (that is, an IPv6-unaware version of this=20 application that is sending referrals around. For=20 example, a SIP phone (Alice calls Bill which is forwarded to Carol which is forwarded to Debbi) or an older=20 version of a BitTorrent client that lacks IPv6 awareness=20 / support - and we know how torrent trackers share things around all over the place). -d > Xiaohu >=20 > > We won't have any influence on those IPv4-only applications that are > already > > written that can't parse IPv6 addresses and have no idea=20 > what to do with > an > > IPv6 address (e.g., IPv4-only applications inside of personal video > recorders, > > SIP phones, etc.). Besides, if you give an IPv4-only host an IPv6 > address, > > it > > can't get to that IPv6 address; if the IPv4-only host is=20 > running Teredo or > > ISATAP or its router is running 6to4, it isn't (strictly=20 > speaking) an > > IPv4-"only" host -- the host (and its application) is=20 > capable of IPv6, too > -- > > so it is effectively dual-stack. > >=20 > > We can provide guidance to applications that are evolving=20 > (adding features > and > > functions, including becoming more aware of IPv6=20 > interworking). That is > the > > hope of GROBJ, and the purpose of draft-wing-behave-learn-prefix and > > draft-wing-v6ops-v6app-v4server. > >=20 > > -d > >=20 > >=20 > > > Xiaohu > > > > > > > > Xiaohu > > > > > > > > > > > > > > > > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 From ajs@shinkuro.com Thu Dec 17 20:03:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606DE3A68E5 for ; Thu, 17 Dec 2009 20:03:09 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzI3zsKoarfa for ; Thu, 17 Dec 2009 20:03:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 592B43A68DD for ; Thu, 17 Dec 2009 20:03:08 -0800 (PST) Received: from crankycanuck.ca (unknown [206.47.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 752822FE8CEE for ; Fri, 18 Dec 2009 04:02:53 +0000 (UTC) Date: Thu, 17 Dec 2009 23:02:51 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091218040251.GG47068@shinkuro.com> References: <20091218040001.9B0FA3A684F@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091218040001.9B0FA3A684F@core3.amsl.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 04:03:09 -0000 On Thu, Dec 17, 2009 at 08:00:01PM -0800, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-behave-dns64-05.txt > Pages : 31 > Date : 2009-12-17 This update is to address the concerns about dealing with (RCODE != 0 && RCODE != 3). See the thread on SERVFAIL and DNS64 for discussion. I also added a "no action" IANA considerations section, because idnits complained. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ebisawa@sablenetworks.net Thu Dec 17 22:23:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F183A6A37 for ; Thu, 17 Dec 2009 22:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpPhe7wlfQrg for ; Thu, 17 Dec 2009 22:22:25 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id CFB303A6A4C for ; Thu, 17 Dec 2009 22:18:08 -0800 (PST) Received: (qmail 16965 invoked by SAV 20091217.051 by uid 0); 18 Dec 2009 15:17:52 +0900 Received: from unknown (HELO ?192.168.14.50?) (ebisawa@122.220.29.26) by dc12.etius.jp (202.229.133.90) with ESMTPA; 18 Dec 2009 15:17:52 +0900 Date: Fri, 18 Dec 2009 15:17:39 +0900 From: Kentaro Ebisawa To: Simon Perreault In-Reply-To: <4B2A35EF.9000601@viagenie.ca> References: <20091217115747.83B7.B01659E3@sablenetworks.net> <4B2A35EF.9000601@viagenie.ca> Message-Id: <20091218141656.83D9.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.50 [ja] Cc: Behave WG , Xing Li Subject: Re: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 06:23:52 -0000 Hi, Thanks for the comments. I agree with your comments on additional cases, F and G. For remaining items related to v6 Traffic Class and flow lable : > > For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to > > this. We can either drop it, or decide to use 0 or 1. > > Maybe we can use 0 since if we have any problem in version field, we > > wouldn't have sent the packet triggering this ICMP message anyway. >=20 > I think it should be 1, for two reasons: >=20 > - The fact that it would be the same as IPv4 would make it a little bit > more likely that it would also be interpreted in the same way. >=20 > - If there was a problem with the flow label the value would be 3 instead. Here are the first 4 octets of IPv6 Header From RFC2460 "3.IPv6 Header Form= at". 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In octet "1", the latter 4 bits of Traffic Class and the first 4 bits of Flow Lable is included. The definition of the pointer per RFC792 is "identifies the octet where an error was detected." and doesn't mention it MUST or SHOULD be an octet including first bit nor last bit of the field. Thus, unless documented in other RFC etc. which I missed, it's implementer's choice to use 1, 2 or 3 for the Flow Label. Do you know how current implementations actually select pointer value ? I briefly looked into Linux code but could not find a code where it's sending Parameter problem for Header field. (I could only find for options field) > > C-3. v6->v4 : pointer=3D1, Traffic Class/Flow Label =2E.. > > For C-3, I think we should drop it since there are no way to distingui= sh > > if the sender wanted to point to Traffic Class or Flow lable. >=20 > Disagree. I think 1 clearly means traffic class. (Who/what is the > authority on this?) As said above, I am not aware of any documents discussing or defining about relationship between pointer value and header field, and thus thinking it was not defined anywhere and it's up to implementers to select 0 or 1 for IPv6 Traffic Class. I'm also wondering who/what is the authority on this. So would be very helpfull if anyone can let us know pointer to any documents or discussions. Thanks, --=20 Kentaro Ebisawa On Thu, 17 Dec 2009 08:45:19 -0500 Simon Perreault wrote: > First, thank you for this excellent analysis. This is exactly what I had > in mind. If this text is adopted it will fulfill all my needs. >=20 > Kentaro Ebisawa wrote: > > For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to > > this. We can either drop it, or decide to use 0 or 1. > > Maybe we can use 0 since if we have any problem in version field, we > > wouldn't have sent the packet triggering this ICMP message anyway. >=20 > I think it should be 1, for two reasons: >=20 > - The fact that it would be the same as IPv4 would make it a little bit > more likely that it would also be interpreted in the same way. >=20 > - If there was a problem with the flow label the value would be 3 instead. >=20 > > For C, there are 3 cases. 1 for IPv4->IPv6 and 2 for IPv6->IPv4. > > C-1. v4->v6 : pointer=3D0, Version/IHL > > C-2. v6->v4 : pointer=3D0, Version/Traffic Class > > C-3. v6->v4 : pointer=3D1, Traffic Class/Flow Label > >=20 > > For C-1, I think we can drop this. We wouldn't have sent the packet > > triggering this ICMP message if the version field had problem, and > > there is no corresponding field for IHL in v6. >=20 > Agreed. >=20 > > For C-2, we can either drop this or translate to 1 (Type of Service), > > assuming we won't send original packet with incorrect Version. > > But I would preffer dropping this to avoid sending fales alert. >=20 > Agreed. >=20 > > For C-3, I think we should drop it since there are no way to distingui= sh > > if the sender wanted to point to Traffic Class or Flow lable. >=20 > Disagree. I think 1 clearly means traffic class. (Who/what is the > authority on this?) >=20 > > For E, we can add Fragment Header and point to it (v4->v6). Also, we > > can parse the Extention header and if it was Fragment header, we can > > point to corresponding Fragment related field (v6->v4). > > But if we try to translate, we will need to think about the case don't > > fragment bit is set since we can not insert Fragment Header in such > > case. > > So perfer simply dropping this but would like to hear more comments. >=20 > Well, the point is that the fragmentation parameters on each side are > likely to be very different. So an ICMP received on either side wouldn't > really apply on the other. Therefore, I would also like to drop this. >=20 > There are two other cases which I think also need to be considered: >=20 > F. The pointer points inside the payload to a parameter which the > translator changes (e.g. UDP source port). >=20 > G. The pointer points inside the payload to something the translator > doesn't change (e.g. UDP data). >=20 > In F, the ICMP is of interest to the translator, not the originator of > the packet. So besides using the information usefully if it can, the > translator should drop the packet. >=20 > In G, we can forward after offsetting the pointer so that it points at > the same data after translation. >=20 > Thanks, > Simon > --=20 > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org From xuxh@huawei.com Thu Dec 17 22:24:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D863A6A4A for ; Thu, 17 Dec 2009 22:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.693 X-Spam-Level: * X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeLoiRB75x2c for ; Thu, 17 Dec 2009 22:24:00 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 978BF3A6A50 for ; Thu, 17 Dec 2009 22:23:05 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUU00EJV487AU@szxga04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 14:19:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUU00D4N486JY@szxga04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 14:19:18 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUU004OI4862L@szxml04-in.huawei.com> for behave@ietf.org; Fri, 18 Dec 2009 14:19:18 +0800 (CST) Date: Fri, 18 Dec 2009 14:19:18 +0800 From: Xu Xiaohu In-reply-to: <005c01ca7f95$3e26df30$e30c6f0a@china.huawei.com> To: 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <000001ca7faa$081a0010$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXAAAJiU0AAAPVpA Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 06:24:13 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Xu > Xiaohu > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 11:50 > =CA=D5=BC=FE=C8=CB: 'Dan Wing'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED Dan > > Wing > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 11:34 > > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > > ALLnon-0::/3 IPv6 addresses ? > > > > > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org > > > [mailto:behave-bounces@ietf.org] On Behalf Of Xu Xiaohu > > > Sent: Thursday, December 17, 2009 5:30 PM > > > To: 'marcelo bagnulo braun' > > > Cc: behave@ietf.org > > > Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > > apply to ALL non-0::/3 IPv6 addresses ? > > > > > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA =B1=ED > > > > marcelo bagnulo braun > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C217=C8=D5 19:45 > > > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > > =B3=AD=CB=CD: behave@ietf.org > > > > =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 format = to > > > apply to ALL > > > > non-0::/3 IPv6 addresses ? > > > > > > > > Xu Xiaohu escribi=A8=AE: > > > > > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > >> =B7=A2=BC=FE=C8=CB: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es] > > > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 20:29 > > > > >> =CA=D5=BC=FE=C8=CB: Xu Xiaohu > > > > >> =B3=AD=CB=CD: 'Christian Huitema'; behave@ietf.org > > > > >> =D6=F7=CC=E2: Re: [BEHAVE] Reason(s) for Modified EUI-64 = format to > > > apply to ALL > > > > >> non-0::/3 IPv6 addresses ? > > > > >> > > > > >> Xu Xiaohu escribi=A8=AE: > > > > >> > > > > >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > >>>> =B7=A2=BC=FE=C8=CB: Christian Huitema = [mailto:huitema@microsoft.com] > > > > >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C214=C8=D5 13:02 > > > > >>>> =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'marcelo bagnulo braun' > > > > >>>> =B3=AD=CB=CD: behave@ietf.org > > > > >>>> =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 = format > > > to apply to > > > ALL > > > > >>>> non-0::/3 IPv6 addresses ? > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>> There are three choice for the WKP in the > > > address-format draft: > > > > >>>>> o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as > > > specified in > > > RFC > > > > >>>>> 2765 Section 2.1; > > > > >>>>> o request IANA to allocate a /32 prefix, > > > > >>>>> o or request allocation of a new /96 prefix. > > > > >>>>> > > > > >>>>> Could you tell me which one is equivalent to the > > > specific NSP I > > > > >>>>> > > > > >>>>> > > > > >>> mentioned, > > > > >>> > > > > >>> > > > > >>>>> which starts with a special binary value? > > > > >>>>> > > > > >>>>> > > > > >>>> I just submitted an update to the address format draft: > > > > >>>> > > > > >>>> > > > > >> > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address- > > > format-02.tx > > > > >> > > > > >>>> t > > > > >>>> In draft-02, we propose to use the Well Known Prefix > > > 64:FF9B::/96. > > > > >>>> > > > > >>>> > > > > >>> "The Well-Known Prefix MUST NOT be used for scenario 3 (the = IPv6 > > > > >>> > > > > > Internet > > > > > > > > > >> to > > > > >> > > > > >>> an IPv4 network), as this would lead to using the > > > Well-Known Prefix > > > with > > > > >>> > > > > > non > > > > > > > > > >>> global IPv4 addresses". However, the specific NSP > > > starting with a > > > > >>> > > > > > special > > > > > > > > > >>> binary value (depicted as follows) could be used in the > > > above scenario > > > > >>> > > > > > since > > > > > > > > > >>> the Network Specific Parts is topologically > > > aggregatable. That is to > > > > >>> > > > > > say, > > > > > > > > > >>> the specific NSP is a hybrid type of 96/ prefix which > > > starts with a > > > > >>> well-known binary (e.g., 00010101) while the remaining > > > part is network > > > > >>> specific. > > > > >>> > > > > >>> = +--------+--------------------------------+-----------------+ > > > > >>> |00010101|Network Specific Parts (88 bits)|IPv4 addr = (32bit)| > > > > >>> = +--------+--------------------------------+-----------------+ > > > > >>> > > > > >>> Hence, the Well Known Prefix 64:FF9B::/96 is not > > > equivalent to the > > > > >>> > > > > > specific > > > > > > > > > >>> NSP I mentioned. > > > > >>> > > > > >>> > > > > >> Maybe i am not understanding what you have in mind. > > > > >> Could you put an concrete example of a scenario > > > involving the IPv6 > > > > >> internet that requires the host to distinguish that the > > > address of its > > > > >> peer is synthetic? > > > > >> > > > > > > > > > > +-------------------+ > > > > > | | > > > > > +-------------+ | IPv6 Internet | +--------------+ > > > > > | +---+ +--++---++ IPv4 only > > > > > |Dual-stack | +-------------------+ |NAT64| | > > > > > | +-----+ | ++---++ +-----+| > > > > > | | H1 | | +-------------------+ | | H2 || > > > > > | +-----+ +---++ +---+ +-----+| > > > > > +-------------+ | IPv4 Internet | +--------------+ > > > > > | | > > > > > +-------------------+ > > > > > > > > > > In the above scenario, after obtaining a synthesized IPv6 > > > address of H2 > > > > > (IPv4 host) through some way, H1 (dual-stack host) will = initialize > > > > > communication to H2 using IPv6 since it could not > > > identify whether the > > > > > resolved IPv6 address is synthetic or not. However, it's > > > better to use > > > IPv4 > > > > > for the communication between them. > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > i see the scenario now, > > > > > > > > i used a similar argument for supporting the use of the > > > Well know prefix > > > > a while ago, and the arguments against this argument (by > > > Dan, who wrote > > > > then a draft about referals, correct me if i am wrong) was > > > that there is > > > > actual no applications that actually do that today and that the > > > > reasonable thing to do for an app was to pass the ipv4 > > > address and then > > > > allow the receiving end to synthesize the IPv6 address if = needed. > > > > > > +-------------------+ > > > | | > > > +-------------+ | IPv6 Internet | +--------------+ > > > | +---+ +---++---++ IPv4 only > > > | IPv6 only | +-------------------+ |NAT64| | > > > | +-----+ | ++---++ +-----+| > > > | | H1 | | +-------------------+ | | H2 || > > > | +-----+ NAT64?- + +---+ +-----+| > > > +-------------+ | IPv4 Internet | +--------------+ > > > | | > > > +-------------------+ > > > If I understand your statement correctly, An IPv6 only site > > > (e.g., left site > > > in the above figure) MUST have a connection to the IPv4 > > > Internet via NAT64 > > > in order to access hosts located in an IPv4 only site (e.g., > > > right site in > > > the above figure). Besides, the IPv6 only host (e.g. H1) MUST > > > be able to > > > synthesize IPv6 address by itself. If either of the above two > > > conditions is > > > not satisfied, the communication between H1 and H2 is impossible. > > > > Yep -- because IPv4-only applications don't know anything about IPv6 > addresses > > -- IPv4-only applications don't know how to parse IPv6 addresses, = how to > > include them in referrals, etc. >=20 > Note that H1 in the above scenario is IPv6 only, but not IPv4 only. = Hence > I'm wondering whether the statement you made is relevant to the above > scenario. Let me explain the scenario a bit more, in the above scenario, the communication is initiated by H1 (IPv6 only host), but not H2 (IPv4 only host). To make that communication possible, should a NAT64 be deployed between the IPv6 only site (left site) and the IPv4 Internet although = there is already a NAT64 between the IPv4 site (right site) and the IPv6 = Internet? If so, what's the meaning of IPv6 Internet to IPv4 network scenario? Xiaohu >=20 > > We won't have any influence on those IPv4-only applications that are > already > > written that can't parse IPv6 addresses and have no idea what to do = with > an > > IPv6 address (e.g., IPv4-only applications inside of personal video > recorders, > > SIP phones, etc.). Besides, if you give an IPv4-only host an IPv6 > address, > > it > > can't get to that IPv6 address; if the IPv4-only host is running = Teredo or > > ISATAP or its router is running 6to4, it isn't (strictly speaking) = an > > IPv4-"only" host -- the host (and its application) is capable of = IPv6, too > -- > > so it is effectively dual-stack. > > > > We can provide guidance to applications that are evolving (adding features > and > > functions, including becoming more aware of IPv6 interworking). = That is > the > > hope of GROBJ, and the purpose of draft-wing-behave-learn-prefix and > > draft-wing-v6ops-v6app-v4server. > > > > -d > > > > > > > Xiaohu > > > > > > > > Xiaohu > > > > > > > > > > > > > > > > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ebisawa@sablenetworks.net Thu Dec 17 22:24:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0299A3A69C7 for ; Thu, 17 Dec 2009 22:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msS9dqTK9mAi for ; Thu, 17 Dec 2009 22:24:39 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id BC0733A6A55 for ; Thu, 17 Dec 2009 22:23:57 -0800 (PST) Received: (qmail 15539 invoked by SAV 20091217.051 by uid 0); 18 Dec 2009 15:23:04 +0900 Received: from unknown (HELO ?192.168.14.50?) (ebisawa@122.220.29.26) by dc12.etius.jp (202.229.133.90) with ESMTPA; 18 Dec 2009 15:23:04 +0900 Date: Fri, 18 Dec 2009 15:22:50 +0900 From: Kentaro Ebisawa To: Simon Perreault In-Reply-To: <4B28FE5E.6020800@viagenie.ca> References: <4B28FE5E.6020800@viagenie.ca> Message-Id: <20091218152154.83DC.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: Behave WG Subject: Re: [BEHAVE] What ICMP to send when not reassembling UDP with checksum 0 because out of resources X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 06:24:43 -0000 Hi Simon, I also think it would be better to be in sync with RFC5508 as much as possible. Thanks, -- Kentaro Ebisawa On Wed, 16 Dec 2009 10:35:58 -0500 Simon Perreault wrote: > In the interim, the question of what ICMP type/code to send when the > translator does not reassemble a UDP packet with zero checksum because > it is out of resources. It was proposed to send an ICMP Parameter > Problem pointing to the UDP checksum field. > > However, I think we should follow the guidance of RFC 5508: > > REQ-8: When a NAT device is unable to establish a NAT Session for a > new transport-layer (TCP, UDP, ICMP, etc.) flow due to > resource constraints or administrative restrictions, the NAT > device SHOULD send an ICMP destination unreachable message, > with a code of 13 (Communication administratively prohibited) > to the sender, and drop the original packet. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Dec 17 23:47:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8443A63EC for ; Thu, 17 Dec 2009 23:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7DFcaPFDYdZ for ; Thu, 17 Dec 2009 23:47:33 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A00E23A6816 for ; Thu, 17 Dec 2009 23:47:33 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAAbCKkurR7Ht/2dsb2JhbACIX4EWs2yXKIQtBIFj X-IronPort-AV: E=Sophos;i="4.47,417,1257120000"; d="scan'208";a="451976425" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2009 07:47:19 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI7lJ4l008401; Fri, 18 Dec 2009 07:47:19 GMT From: "Dan Wing" To: Date: Thu, 17 Dec 2009 23:47:19 -0800 Message-ID: <048501ca7fb6$536824f0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp/tlMlXLA0zx/IS+mTGYnqZhfkbg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] WGLC for translation documents (6 documents) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 07:47:34 -0000 We appear ready to start the working group last call for our set of IPv6/IPv4 translation documents. This is a two-week WGLC. We need 5 reviewers to say a document is ready before we will forward the documents to the IESG. A few people have already volunteered, but we need more! Please see http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart. If you are already reading the document, this is easy -- just email the chairs after your review. The documents starting WGLC are: http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-04 http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-07 http://tools.ietf.org/html/draft-ietf-behave-dns64-05 http://tools.ietf.org/html/draft-ietf-behave-address-format-03 http://tools.ietf.org/html/draft-ietf-behave-ftp64-00 This is a two week WGLC finishing on December 31. Please send substantive review comments to behave@ietf.org and (if possible) send editorial comments only to the authors at DRAFTNAME@tools.ietf.org. Thanks, -Dan and Dave From dwing@cisco.com Fri Dec 18 00:04:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA6E3A6828 for ; Fri, 18 Dec 2009 00:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al+YY4YxDpip for ; Fri, 18 Dec 2009 00:04:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 404113A67C1 for ; Fri, 18 Dec 2009 00:04:38 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFALfGKkurR7Ht/2dsb2JhbACIX4EWs3GXKYQtBIFj X-IronPort-AV: E=Sophos;i="4.47,417,1257120000"; d="scan'208";a="451982804" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2009 08:04:23 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI84Nhn014963; Fri, 18 Dec 2009 08:04:23 GMT From: "Dan Wing" To: Date: Fri, 18 Dec 2009 00:04:23 -0800 Message-ID: <049401ca7fb8$b6132b20$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp/uLXcl2Zx3UubR8uiG65d0k/K4w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org Subject: [BEHAVE] completed WGLC of draft-ietf-behave-turn-ipv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 08:04:39 -0000 Our WGLC for draft-ietf-behave-turn-ipv6 has concluded, with no comments received. The PROTO writeup is below. -d ----- (1.a) Who is the Document Shepherd for this document? draft-ietf-behave-turn-ipv6-08 Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received significant review from the community. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. None. (1.e) How solid is the WG consensus behind this document? Fairly solid. Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has a good understanding of, and agreement with, this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such threats or appeals. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Yes. Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? The document does not specify a MIB, media type, or URI, and thus does not need to meet those review criteria. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended Status: Standards Track (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All normative references are upward references, and all are RFCs. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes. Are the IANA registries clearly identified? Yes. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? The document does not create a new IANA registry. Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no such formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This specification extends TURN (I-D.ietf-behave-turn) to support IPv6 communications to the remote peer. TURN-IPv6 was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality Are there existing implementations of the protocol? Yes. Have a significant number of vendors indicated their plan to implement the specification? Yes. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They are listed in the document's acknowledgement section If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? No such reviews were necessary. Personnel Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Who is the Responsible Area Director? Magnus Westerlund, magnus.westerlund@ericsson.com If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document doesn't require IANA experts. The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From dwing@cisco.com Fri Dec 18 00:49:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDE63A69C7 for ; Fri, 18 Dec 2009 00:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS1UgVbG2UoR for ; Fri, 18 Dec 2009 00:49:53 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EDC043A6856 for ; Fri, 18 Dec 2009 00:49:52 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEzRKkurR7Ht/2dsb2JhbACIX4EWs3KXLYQtBIFj X-IronPort-AV: E=Sophos;i="4.47,417,1257120000"; d="scan'208";a="452005319" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2009 08:49:38 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBI8nbdw007957; Fri, 18 Dec 2009 08:49:38 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'marcelo bagnulo braun'" References: <005c01ca7f95$3e26df30$e30c6f0a@china.huawei.com> <000001ca7faa$081a0010$e30c6f0a@china.huawei.com> Date: Fri, 18 Dec 2009 00:49:37 -0800 Message-ID: <04ac01ca7fbf$080d7060$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000001ca7faa$081a0010$e30c6f0a@china.huawei.com> Thread-Index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXAAAJiU0AAAPVpAAAkc9NA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 08:49:53 -0000 > > > > +-------------------+ > > > > | | > > > > +-------------+ | IPv6 Internet | +--------------+ > > > > | +---+ +---++---++ IPv4 only > > > > | IPv6 only | +-------------------+ |NAT64| | > > > > | +-----+ | ++---++ +-----+| > > > > | | H1 | | +-------------------+ | | H2 || > > > > | +-----+ NAT64?- + +---+ +-----+| > > > > +-------------+ | IPv4 Internet | +--------------+ > > > > | | > > > > +-------------------+ > > > > If I understand your statement correctly, An IPv6 only site > > > > (e.g., left site > > > > in the above figure) MUST have a connection to the IPv4 > > > > Internet via NAT64 > > > > in order to access hosts located in an IPv4 only site (e.g., > > > > right site in > > > > the above figure). Besides, the IPv6 only host (e.g. H1) MUST > > > > be able to > > > > synthesize IPv6 address by itself. If either of the above two > > > > conditions is > > > > not satisfied, the communication between H1 and H2 is > impossible. > > > > > > Yep -- because IPv4-only applications don't know anything > about IPv6 > > addresses > > > -- IPv4-only applications don't know how to parse IPv6 > addresses, how to > > > include them in referrals, etc. > > > > Note that H1 in the above scenario is IPv6 only, but not > IPv4 only. Hence > > I'm wondering whether the statement you made is relevant to > the above > > scenario. > > Let me explain the scenario a bit more, in the above scenario, the > communication is initiated by H1 (IPv6 only host), but not H2 > (IPv4 only > host). To make that communication possible, should a NAT64 be deployed > between the IPv6 only site (left site) and the IPv4 Internet > although there > is already a NAT64 between the IPv4 site (right site) and the > IPv6 Internet? > If so, what's the meaning of IPv6 Internet to IPv4 network scenario? The "IPv6 Internet to IPv4 network" scenario applies to the ISP on the right. Detail: The ISP on the left is a business, and they made the decision to operate an IPv6-only network with IPv6-only hosts. Their subscribers want access to (and/or from) the IPv4 Internet, so that ISP provides a NAT64 (and associated DNS64, of course). This is the "an IPv6 network to the IPv4 Internet" scenario (when the connection is initiated from the IPv6 host) and is the "the IPv4 Internet to an IPv6 network" (when the connection is initiated from the IPv4 side). Note that a stateful NAT64 will generally not support "the IPv4 Internet to an IPv6 network" unless port mappings are configured on the stateful NAT64. The ISP on the right is another, separate business, and they made the decision to keep their subscribers running IPv4. Their subscribers want access to (and/or from) the IPv6 Internet. This is "an IPv4 network to the IPv6 Internet" (when the connection is initiated from the IPv4 side) and is "the IPv6 Internet to an IPv4 network" (when the connection is initiated from the IPv6 side). -d From ssenthil@cisco.com Fri Dec 18 11:01:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509793A6890 for ; Fri, 18 Dec 2009 11:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+fmT+Tsctmn for ; Fri, 18 Dec 2009 11:01:31 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 090303A6AA7 for ; Fri, 18 Dec 2009 11:01:31 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEVgK0urR7H+/2dsb2JhbAC+ZZcbhC4EgWQ X-IronPort-AV: E=Sophos;i="4.47,419,1257120000"; d="scan'208";a="229572986" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2009 19:01:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBIJ1GdQ020980; Fri, 18 Dec 2009 19:01:16 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 11:01:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Dec 2009 11:01:14 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBA8@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4B28DA13.8020903@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt Thread-Index: Acp+T9mny1oGV0VRQz2aieE1rcVBLwBxD7kA References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> <4B27FA9E.1040206@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB090569E1@xmb-sjc-236.amer.cisco.com> <4B28DA13.8020903@it.uc3m.es> From: "Senthil Sivakumar (ssenthil)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 18 Dec 2009 19:01:16.0365 (UTC) FILETIME=[79BD97D0:01CA8014] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 19:01:32 -0000 =20 -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Wednesday, December 16, 2009 8:01 AM To: Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on = draft-ietf-behave-v6v4-xlate-stateful-03.txt Senthil Sivakumar (ssenthil) escribi=F3: > =20 > > =20 >>> Section 1.2.3 >>> >>> I don't understand this >>> >>> "Filtering on the IPv6 interface is not supported, as mappings are=20 >>> only created by packets traveling in the IPv6 --> IPv4 direction." >>> >>> Can you explain why one cannot filter on ipv6 interface? >>> >>> =20 >>> =20 >>> =20 >> good question >> NAT64 supports dynamically initiated connections only from the IPv6 = side. So filtering on the IPv6 side seems some how orthogonal to the NAT = behaviour. I mean you could do that, but you wouldn't be using NAT state = in order to do so, i think. >> OTOH, filtering in the IPv4 interface is different. Since NAT64=20 >> cannot support communications iniitated in the IPv4 side, when there=20 >> is a hole in the NAT opened by an IPv6 connection and because we are=20 >> doing endpoint independent mappings, we end up with the question on=20 >> whehter we do accept this new communication that has been initiated=20 >> from the >> IPv4 side or not (keep in mind that this is possible only because=20 >> there is a hole open and would not be possible in other case) >> >> So, while the NAT could filter in the IPv6 interface, this seems to = be orthogonal to the NAT behaviour, but filtering in the IPv4 interface = i tightly couple to the nat64 state, hence need to be specified. >> >> In any case, i have rephrased the previous sentence to >> >> Filtering of incoming IPv6 packets is not described in this = specification. >> >> [Senthil] I guess I was thinking filtering even before the session = can be created.=20 >> For example, one would want all the IPv6 hosts to have access to = internet but except for a handful of specific hosts. Another filtering = technique is all hosts are allowed except the ones that talk to a = specific port or set of ports. These types of filtering is common and = they protect the NAT64 resources (addresses & ports).=20 >> >> in order to make it clearer that is not that is not supported, but = that is not specified here. >> =20 >> =20 > > right, i agree with that, but i still think this is orthogonal to the > nat64 (e.g. firewalls have the same issues) so i am not sure what to = say about this in the draft... any suggestion? > > [Senthil] True. I was thinking some text along these lines. > > "NAT64 device can do filtering of IPv6 packets based on the = administrative rules to create BIB and session entries. The filtering = can be flexible enough and broad enough but the idea of the filtering is = to provide the operators necessary control to avoid DoS attacks that = would result in exhaustion of NAT64 address, port, memory and CPU = resources". > > =20 Ok, i will add that text to the draft, thanks >> =20 >> =20 >>> Section 3.2.2 >>> Paragraph starting "After bootstrapping...." >>> >>> What does it mean all TCP sessions are in closed state? Where is=20 >>> this tracked? >>> =20 >>> =20 >>> =20 >> Again, this is similar to the TCP CLOSED state >> >> The closed state is somehow special, cause it means that there is no = state for the particular connection. I have tried to make this clearer = in the document by adding the following description: >> >> CLOSED: Analogous to , CLOSED is a fictional >> because it represents the state when there is = no state for this particular 5-tuple, and therefore, >> no connection. >> >> >> [Senthil] The state of a session is tracked via the session table, >> =20 > no. > the state is tracked by the state. I mean, current session table does=20 > not have a "STATE" column defined.Additional data is needed to track=20 > the state, sicne the state a given connection is is a piece of=20 > information that needs to be stored somewhere. We could define all the = > data strcutures needed for the implementation, but i fail to see the=20 > need for that > > [Senthil] Let me ask you this, as an implementor when the doc says = "After bootstrapping all the devices should set its connection state for = all the sessions to CLOSED." How do I do that?=20 > =20 you don't create any state for any connection, hence they are all in = CLOSED state. > Again, I didn't mean to say the state should be tracked within a = session, but the state is per-session and hence keyed off of the = session. You cant get to the state of the session without knowing what = the session keys are.=20 > > =20 the keys are the connection identifier. You search among the connections that have state, If you can't find=20 state for the connection you are searching, it means it is in closed = state. Again, CLOSED state is a _fictional_ state that represents that no state = is available for that connection and hence there is no connection. Again, this is exactly the same as 793, >> but the text indicates that all the TCP sessions are in closed = state. My question is what is this "all TCP sessions" and how do you = track a session state without a session.=20 >> >> =20 >> =20 > as i mentioned earlier, the CLOSED state is a fictional state (similar = to the the one for TCP) that represents that there is no state for a = connection. > In other words, in a normal TCP stack (in any regular host, no nat64 > involved) all non existent connections are in CLOSED state... so = where does a TCP stack store the state for those connections? Nowhere, = cause the CLOSED stated in fact means that there is no state. > > [Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and = there is a time period when the connections are in CLOSED state.=20 from RFC793 page 21 CLOSED is fictional because it represents the state when there is no TCB, and therefore, no connection. and then in page 22 CLOSED - represents no connection state at all. [Senthil] Ok, I am fine with the text as is. Just for clarity can you = add a reference to 793 when you are describing CLOSED? >> =20 >> =20 >>> Section 3.2.3 >>> >>> For port allocation, the text says if the port is even an even port=20 >>> must be allocated and same for odd. What if there are no even ports=20 >>> to allocate but there are odd ports, should the packet be dropped or = >>> allocated a odd port. I understand some application require that the = >>> port parity to be maintained but majority of the apps don't care. So = >>> making this a recommendation on the best effort basis is ok but=20 >>> making it a mandatory requirement sounds unreasonable. Note RFC 4787 = >>> recommends this behavior but this text mandates it. >>> =20 >>> =20 >>> =20 >> Right, i have changed this to a should. >> >> [Senthil] I am thinking that this should be a configurable parameter, = that is the admin can decide if the device should strictly allocate = even-for-even and odd-for-odd or it should do the first available port.=20 >> >> =20 >> =20 > but that is not what is reccomended by the behave requirements, right? > > I mean, what is required is what you mentioned earlier and that i have = tried to relfect in the document with the text above. > If we want to reccomend something else than what is described in the = behave requirements, then we need to go against prior consensus. We can = do that, but it would require strong WG consenus. > > [Senthil] From RFC4787, > > REQ-4: It is RECOMMENDED that a NAT have a "Port parity > preservation" behavior of "Yes". > > It does not say SHOULD.=20 From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [Senthil] Ok. That sounds good. Thanks Senthil > So what you have in this draft is going above what has been said in = the RFC4787. > > =20 not sure i understand what you mean Regards, marcelo > Thanks > Senthil > > Regards, marcelo > > > =20 >> Senthil >> >> =20 >> =20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> =20 >>> =20 >>> =20 >> =20 >> =20 > > > =20 From ssenthil@cisco.com Fri Dec 18 11:26:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27743A6ABD for ; Fri, 18 Dec 2009 11:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVUD1smrytwi for ; Fri, 18 Dec 2009 11:26:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8A2D23A6ABF for ; Fri, 18 Dec 2009 11:26:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAI9mK0urRN+J/2dsb2JhbACECrpVhnsBkCSBLIERgRxVBIFki0w X-IronPort-AV: E=Sophos;i="4.47,420,1257120000"; d="scan'208";a="64918224" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2009 19:26:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBIJQ6IH020973; Fri, 18 Dec 2009 19:26:06 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 11:26:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Fri, 18 Dec 2009 11:26:04 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4B28E30E.9000308@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 Thread-Index: Acp+VTnGNP4xZ0fCR42XyvIjMIZWZwBv4Xyg References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> <4B28E30E.9000308@cernet.edu.cn> From: "Senthil Sivakumar (ssenthil)" To: "Xing Li" X-OriginalArrivalTime: 18 Dec 2009 19:26:06.0938 (UTC) FILETIME=[F230FBA0:01CA8017] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 19:26:22 -0000 -----Original Message----- From: Xing Li [mailto:xing@cernet.edu.cn] Sent: Wednesday, December 16, 2009 8:39 AM To: Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 Hi, Senthil, Thanks for the review. Senthil Sivakumar (ssenthil) $B General Comments > Overall, the document is in a good shape and is ready for last call. > Some general comments/behavior. > 1. An example flow either in sections 2 & 3 or in the appendix would > help understand the translation process easily. I believe something > like this was in the initial ivi document. > The IVI reference will be added. > Abstract: > Paragraph starting "Significant issues exist..." > > I don't know what issues are being referred to here but there is no > description of the issues nor there is a pointer to a document that > describes/addresses the issues. I think we should either drop this > paragraph or describe the issues or point it to another relevant > document. > It is like saying "There are significant issues with stateful & > stateless modes, we wont tell you what they are but we don't plan to > address them in this document". That doesn't give me a good feeling > when I start to read this document. > Deleted. > Editorial comments. > 1. Section 1.2 Para "The translating function specified in ..." > > There is a reference to RFC2765 that is hanging here. I don't know > what is the intention of bringing in the reference without properly > relating it to the context. > Modified. (same as in [RFC2765]). > 2. Section 1.2 Para "Fragmented IPv4 UDP packet...." > > "use over wide-areas in the Internet" - did you mean over wide-area > networks? If not, what does wide-areas mean here? > wide-area deleted. > 3. Section 1.4 Para 1. > s/must send packet to big/must send packet too big > Corrected. > 4. Section 2 > Para "However, when the IPv4 sender does..." > > s/needed should the packet pass through an IP/ICMP translator/needed > should the packet pass through another IP/ICMP translator > I think we still mean this IP/ICMP translator. [Senthil] Maybe I am confused, what does this sentence mean "That is needed should the packet pass through an IP/ICMP translator." The packet is already passing through this translator and hence adding a fragment header does not help this device. What I thought you meant was if the packet has to pass through another IP/ICMP translator, then that translator (translating back from v6->v4) knows it can fragment the packet. If that is not the intention, I don$B!G(Jt see what is the value add for this sentence. > 5.Section 2.1 > > Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." > > Why is this a MUST? Isnt this upto the implementation? How can you > verify the conformance? > How can you detect if the nat64 device fragments it and translates it > or translates it and fragments it? > This is discussed in para However, when the IPv4 sender does not set the DF bit, the translator has to ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size. [Senthil] My question is -- why is it a MUST to fragment the packet and then translate as opposed to translate and fragment. "If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the IPv4 packet MUST be fragmented prior to translating it." The above sentence says one *must* fragment prior to translating. Let's take an example. NAT64 receives a IPv4 packet without the DF bit set and the length of the payload (not including IP header) is 1480 bytes. NAT64 MUST do this. - Translate the packet, add the fragment header. - Send two packets out -- one with 1232 bytes of data + 48 bytes of IPv6 header (40 bytes of ipv6 + 8 bytes of frag hdr). -- one with 248 bytes of data + 48 bytes of ipv6 header. What the text indicates though is NAT64 must first fragment the packet into two. 1232 byte packet, 248 byte packet. Then translate and add the fragment header on 1st packet, then do the same on the 2nd packet. The text bothers me is "prior to translating it". > 6. Section 2.1 > Hop Limit: I think the recommendation should be to decrement the TTL > and send ICMP TTL exceeded before translation. Translating the packet > and decrementing TTL to find out the TTL expired and restoring the > packet to its original form seems to be unnecessarily complicating > things. We shouldn't even suggest that. > We think this leaves the space for different implementation. The text is from the RFC2765. If the consensus is there, we are fine to make the modification. [Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn$B!G(Jt be a reason for us not to do better. > 7. Section 2.2 > Para 2 "When a stateless translator...." > The text says "translator SHOULD drop the packet and generate a system > management > event specifying at least" > > Is the SHOULD for dropping the packet and generating the event? I > think generating the event should be optional/MAY. > Again, this is from RFC2765. Any comments from the WG? > 8. Section 3.1 > Time to Live - Same comment as hoplimit for IPv6. > The same question to the WG. > 9. Section 5 - Security considerations. > This document does not address any potential issues that might arise > by extracting a IPv4 address from the IPv6 address - particularly > addresses like broadcast or loopback addresses etc. I think adding > some text around that might be of help. > How about adding: There are potential issues that might arise by extracting a IPv4 address from the IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. Special action SHOULD be taken to avoid security problems. [Senthil] Sounds good. Thanks Senthil Thanks. xing > Senthil > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From xing@cernet.edu.cn Fri Dec 18 16:56:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD6128C11C for ; Fri, 18 Dec 2009 16:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5wJc8FYFMKK for ; Fri, 18 Dec 2009 16:56:39 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 0069728C11A for ; Fri, 18 Dec 2009 16:56:38 -0800 (PST) Received: from [192.168.1.100]([125.34.41.233]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04b2c9a32; Sat, 19 Dec 2009 08:56:22 +0800 Message-ID: <4B2C24B1.3080701@cernet.edu.cn> Date: Sat, 19 Dec 2009 08:56:17 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091217115747.83B7.B01659E3@sablenetworks.net> In-Reply-To: <20091217115747.83B7.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: G5WcnVXB Cc: Behave WG Subject: Re: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 00:56:40 -0000 Hi, Kentaro, Thank you very much for the analysis concerning the ICMP Pointer. We have add them in the new version (05) of the xlate draft. Please see the document at http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 and the diff at http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-05.txt Please check if they are reflecting your comments. Regards, xing Kentaro Ebisawa 写é“: > Hi, > > In the yesterday's interim conf call, there was comment that we should > add more guidance to how to translate the pointer. I've classified to > 5 classes (A~E) when translating a pointer so it would be eaiser to > think through. > > # Summarized list of pointer value and classes are at the tail of this e-mail. > > BTW, my assumption is we will drop if the pointer is pointing to Options > (IPv4:20+) or Extention headers(IPv6:40+) since we are not going to > translate them and thus no way to translate the pointer.0 (For Fragment > Header, I explicitly classified this to case E since it has field in > IPv4 header.) > > /// Classification and my comments to how to handle them /// > > A. There is one-to-one mapping and can be translated with no ambiguity. > B. The translated field is spread among multiple octets. > We can translate but need to define which octet to use. > C. Multiple fiels are included in the octet original pointer is pointing > to, and can not distinguish which field it's pointing to. > We can NOT translate unless we are aware of which value normally used > in current (and future) implementations. > D. There is no corresponding filed in the translated protocol(IPv4/IPv6) > E. Pointer is pointing to fragment related header (IPv4) or Fragment > Extention Header(IPv6). > > For A and D, it's simple. We can translate(A) or drop(D) based on the > chart below. > > For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to > this. We can either drop it, or decide to use 0 or 1. > Maybe we can use 0 since if we have any problem in version field, we > wouldn't have sent the packet triggering this ICMP message anyway. > > For C, there are 3 cases. 1 for IPv4->IPv6 and 2 for IPv6->IPv4. > C-1. v4->v6 : pointer=0, Version/IHL > C-2. v6->v4 : pointer=0, Version/Traffic Class > C-3. v6->v4 : pointer=1, Traffic Class/Flow Label > > For C-1, I think we can drop this. We wouldn't have sent the packet > triggering this ICMP message if the version field had problem, and > there is no corresponding field for IHL in v6. > > For C-2, we can either drop this or translate to 1 (Type of Service), > assuming we won't send original packet with incorrect Version. > But I would preffer dropping this to avoid sending fales alert. > > For C-3, I think we should drop it since there are no way to distinguish > if the sender wanted to point to Traffic Class or Flow lable. > > For E, we can add Fragment Header and point to it (v4->v6). Also, we > can parse the Extention header and if it was Fragment header, we can > point to corresponding Fragment related field (v6->v4). > But if we try to translate, we will need to think about the case don't > fragment bit is set since we can not insert Fragment Header in such > case. > So perfer simply dropping this but would like to hear more comments. > > > /// Summarized list of pointer value and classes /// > * Translating from IPv4 to IPv6: > > | Original IPv4 Pointer | | Translated IPv6 Pointer Vaule | > +-----------------------------+ +--------------------------------+ > | 0 | Version/IHL | C | 0 | Version/Traffic Class | > | 1 | Type Of Service | B | 0or1| Traffic Class/Flow Label | > | 2,3 | Total Length | A | 4,5 | Payload Length | > | 4,5 | Identification | E | - | | > | 6 | Flags/Fragment Offset | E | - | | > | 7 | Fragment Offset | E | - | | > | 8 | Time to Live | A | 7 | Hop Limit | > | 9 | Protocol | A | 6 | Next Header | > |10,11| Header Checksum | D | - | | > |12-15| Source Address | A | 8-23| Source Address | > |16-19| Destination Address | A |24-39| Destination Address | > +-----------------------------+ +--------------------------------+ > > > * Translating from IPv6 to IPv4: > > | Original IPv6 Pointer | | Translated IPv4 Pointer Vaule | > +--------------------------------+ +-------------------------------+ > | 0 | Version/Traffic Class | C | 0or1| Version/IHL, Type Of Ser| > | 1 | Traffic Class/Flow Label | C | 1 | Type Of Service | > | 2,3 | Flow Label | D | - | | > | 4,5 | Payload Length | A | 2,3 | Total Length | > | 6 | Next Header | A | 9 | Protocol | > | 7 | Hop Limit | A | 8 | Time to Live | > | 8-23| Source Address | A |12-15| Source Address | > |24-39| Destination Address | A |16-19| Destination Address | > +--------------------------------+ +-------------------------------+ > > > /// FYI: pointer value and header field included in the octet /// > > | IPv4 Pointer | | IPv6 Pointer | > +-----------------------------+ +--------------------------------+ > | 0 | Version/IHL | | 0 | Version/Traffic Class | > | 1 | Type Of Service | | 1 | Traffic Class/Flow Label | > | | | | 2,3 | Flow Label | > | 2,3 | Total Length | | 4,5 | Payload Length | > | 4,5 | Identification | | - | | > | 6 | Flags/Fragment Offset | | - | | > | 7 | Fragment Offset | | - | | > | 8 | Time to Live | | 7 | Hop Limit | > | 9 | Protocol | | 6 | Next Header | > |10,11| Header Checksum | | - | | > |12-15| Source Address | | 8-23| Source Address | > |16-19| Destination Address | |24-39| Destination Address | > | 20+ | Options | | 40+ | extension header | > +-----------------------------+ +--------------------------------+ > > Thanks, > From xing@cernet.edu.cn Fri Dec 18 17:06:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272A128C122 for ; Fri, 18 Dec 2009 17:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo5m4azu8KmI for ; Fri, 18 Dec 2009 17:06:34 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id A166828C11C for ; Fri, 18 Dec 2009 17:06:33 -0800 (PST) Received: from [192.168.1.100]([125.34.41.233]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm124b2c9c85; Sat, 19 Dec 2009 09:06:17 +0800 Message-ID: <4B2C270C.3090100@cernet.edu.cn> Date: Sat, 19 Dec 2009 09:06:20 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kentaro Ebisawa References: <20091217115747.83B7.B01659E3@sablenetworks.net> <4B2A35EF.9000601@viagenie.ca> <20091218141656.83D9.B01659E3@sablenetworks.net> In-Reply-To: <20091218141656.83D9.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: G1xlnVXB Cc: Behave WG Subject: Re: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 01:06:35 -0000 Hi, Kentaro and Simon, Thanks for the discussion. Since the xlate draft is in WGLC, we cannot update it during this time slot. Let's wait for the working group's comments, so we can update the appendix later. * Translating from IPv4 to IPv6: | Original IPv4 Pointer | Translated IPv6 Pointer Vaule | +--------------------------------+--------------------------------+ | 0 | Version/IHL | 0 | Version/Traffic Class | | 1 | Type Of Service | 0or1| Traffic Class/Flow Label | | 2,3 | Total Length | 4,5 | Payload Length | | 4,5 | Identification | - | | | 6 | Flags/Fragment Offset | - | | | 7 | Fragment Offset | - | | | 8 | Time to Live | 7 | Hop Limit | | 9 | Protocol | 6 | Next Header | |10,11| Header Checksum | - | | |12-15| Source Address | 8-23| Source Address | |16-19| Destination Address |24-39| Destination Address | +--------------------------------+--------------------------------+ * Translating from IPv6 to IPv4: | Original IPv6 Pointer | Translated IPv4 Pointer Vaule | +--------------------------------+--------------------------------+ | 0 | Version/Traffic Class | 0or1| Version/IHL, Type Of Ser | | 1 | Traffic Class/Flow Label | 1 | Type Of Service | | 2,3 | Flow Label | - | | | 4,5 | Payload Length | 2,3 | Total Length | | 6 | Next Header | 9 | Protocol | | 7 | Hop Limit | 8 | Time to Live | | 8-23| Source Address |12-15| Source Address | |24-39| Destination Address |16-19| Destination Address | +--------------------------------+--------------------------------+ Figure 6 regards, xing Kentaro Ebisawa 写é“: > Hi, > > Thanks for the comments. > I agree with your comments on additional cases, F and G. > > For remaining items related to v6 Traffic Class and flow lable : > > >>> For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to >>> this. We can either drop it, or decide to use 0 or 1. >>> Maybe we can use 0 since if we have any problem in version field, we >>> wouldn't have sent the packet triggering this ICMP message anyway. >>> >> I think it should be 1, for two reasons: >> >> - The fact that it would be the same as IPv4 would make it a little bit >> more likely that it would also be interpreted in the same way. >> >> - If there was a problem with the flow label the value would be 3 instead. >> > > Here are the first 4 octets of IPv6 Header From RFC2460 "3.IPv6 Header Format". > > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In octet "1", the latter 4 bits of Traffic Class and the first 4 bits > of Flow Lable is included. The definition of the pointer per RFC792 > is "identifies the octet where an error was detected." and doesn't > mention it MUST or SHOULD be an octet including first bit nor last > bit of the field. > > Thus, unless documented in other RFC etc. which I missed, it's > implementer's choice to use 1, 2 or 3 for the Flow Label. > > Do you know how current implementations actually select pointer value ? > I briefly looked into Linux code but could not find a code where > it's sending Parameter problem for Header field. (I could only find > for options field) > > > >>> C-3. v6->v4 : pointer=1, Traffic Class/Flow Label >>> > ... > >>> For C-3, I think we should drop it since there are no way to distinguish >>> if the sender wanted to point to Traffic Class or Flow lable. >>> >> Disagree. I think 1 clearly means traffic class. (Who/what is the >> authority on this?) >> > > As said above, I am not aware of any documents discussing or defining > about relationship between pointer value and header field, and thus > thinking it was not defined anywhere and it's up to implementers to > select 0 or 1 for IPv6 Traffic Class. > > I'm also wondering who/what is the authority on this. So would be very > helpfull if anyone can let us know pointer to any documents or discussions. > > Thanks, > From rpenno@juniper.net Fri Dec 18 18:44:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF95228C11C for ; Fri, 18 Dec 2009 18:44:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blPsSRXc24oa for ; Fri, 18 Dec 2009 18:44:27 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with SMTP id 06F1E3A659B for ; Fri, 18 Dec 2009 18:44:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSyw9/Pg/hKMWTaspCWP+eTDRtxkr6/YZ@postini.com; Fri, 18 Dec 2009 18:44:12 PST 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.1.393.1; Fri, 18 Dec 2009 18:41:32 -0800 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; Fri, 18 Dec 2009 21:41:32 -0500 From: Reinaldo Penno To: "behave@ietf.org" Date: Fri, 18 Dec 2009 21:41:29 -0500 Thread-Topic: New Version Notification for draft-penno-behave-64-analysis-01 Thread-Index: AcqAVJv+j9jYRUPlT3mgf6lCeHONTgAACgqB Message-ID: In-Reply-To: <20091219024033.E8A4C3A677E@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-penno-behave-64-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 02:44:28 -0000 ------ Forwarded Message From: IETF I-D Submission Tool Date: Fri, 18 Dec 2009 21:40:33 -0500 To: Reinaldo Penno Cc: Tarun Saxena , "dwing@cisco.com" Subject: New Version Notification for draft-penno-behave-64-analysis-01 A new version of I-D, draft-penno-behave-64-analysis-01.txt has been successfuly submitted by Reinaldo Penno and posted to the IETF repository. Filename: draft-penno-behave-64-analysis Revision: 01 Title: Analysis of 64 Translation Creation_date: 2009-12-18 WG ID: Independent Submission Number_of_pages: 10 Abstract: Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6/IPv4 translation. Since then, new work has commenced which standardizes new mechanisms to perform IPv6/IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. =20 The IETF Secretariat. ------ End of Forwarded Message From xing@cernet.edu.cn Fri Dec 18 18:46:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0043A6821 for ; Fri, 18 Dec 2009 18:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXLLxJQEbW8U for ; Fri, 18 Dec 2009 18:46:50 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 294833A659B for ; Fri, 18 Dec 2009 18:46:48 -0800 (PST) Received: from [192.168.1.100]([125.34.41.233]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b2cb404; Sat, 19 Dec 2009 10:46:32 +0800 Message-ID: <4B2C3E87.2050107@cernet.edu.cn> Date: Sat, 19 Dec 2009 10:46:31 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <6B55F0F93C3E9D45AF283313B8D342BA211F4EEB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB08FCE365@xmb-sjc-236.amer.cisco.com> <4B28E30E.9000308@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: G9yUpVXB Cc: Xing Li , behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 02:46:51 -0000 Hi, Senthil, The version 05 of xlate is uploaded, which reflects your comments in the previous mail, please check http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-05.txt some comments is inline. I provide some new wordings for the mailing list. If we reach consensus, I will modify the draft after WGLC. Senthil Sivakumar (ssenthil) $B> > 4. Section 2 > > I think we still mean this IP/ICMP translator. > > [Senthil] Maybe I am confused, what does this sentence mean > "That is needed should the packet pass through an IP/ICMP translator." The packet is already passing through this translator and hence adding a fragment header does not help this device. What I thought you meant was if the packet has to pass through another IP/ICMP translator, then that translator (translating back from v6->v4) knows it can fragment the packet. If that is not the intention, I don$B!G(Bt see what is the value add for this sentence. > > How about we delete the last sentence. So the wording is However, when the IPv4 sender does not set the DF bit, the translator has to ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size. Also, when the IPv4 sender does not set the DF bit the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation. >> 5.Section 2.1 >> >> Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." >> >> Got the idea. How about we change the wording from MSUT to SHOULD? If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented prior to translating it. > >> 6. Section 2.1 >> >> [Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn$B!G(Bt be a reason for us not to do better. >> >> How about Hop Limit: TTL value copied from IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement the IPv4 TTL before the translation. As part of decrementing the TTL, the translator (as any router) needs to check for zero and send the ICMPv4 "ttl exceeded" error. >> >> 7. Section 2.2 >> Para 2 "When a stateless translator...." >> The text says "translator SHOULD drop the packet and generate a system >> management >> event specifying at least" >> >> Is the SHOULD for dropping the packet and generating the event? I >> think generating the event should be optional/MAY. >> >> > > Any comments from the list for changing SHOULD to MAY? > Again, this is from RFC2765. Any comments from the WG? > > >> 8. Section 3.1 >> Time to Live - Same comment as hoplimit for IPv6. >> >> > > How about the wording Time to Live: Hop Limit value copied from IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement the IPv6 Hop Limit before the translation. As part of decrementing the Hop Limit, the translator (as any router) needs to check for zero and send the ICMPv6 "hop limit exceeded" error. regards, xing From phdgang@gmail.com Sat Dec 19 01:44:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8351128C131 for ; Sat, 19 Dec 2009 01:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pop0ZKhblJ40 for ; Sat, 19 Dec 2009 01:44:49 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 8371B28C12F for ; Sat, 19 Dec 2009 01:44:49 -0800 (PST) Received: by iwn33 with SMTP id 33so2684800iwn.29 for ; Sat, 19 Dec 2009 01:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=egpVAPiijinWNlI2/Os3io1fvtusioADg+InhMfqSZM=; b=LtMs0HUKM2fPPg2ksq+RTw4Jgq8gAjQ2NkJEh4clLdz2E22mSnBh3ELAFQce0YkwGH uFP3/kfBFGuQuI/9rTawYVL8UbZASDLhyBj23WwXv4pRcpWAROT1Y0XwbOBRsqUHqIfD +sTw1uMedTAZ02NvKP4G37ik0rLudKcnAfS40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BPLSa4K4dWy5g6EEW1XhJOy9ehbebsVykRBrw4PvjncYUGTSAb3d90kkbZGECxclHf Zf92B6DjLZHsnB+S894jL5KlC1chcSO2weQpNZ4lL3/4n4heru1KQk7CWo4i153OybAR /Cl50ZxIc0m/GJhsezN5zH0qdqDsBQwfJlW+k= MIME-Version: 1.0 Received: by 10.231.157.131 with SMTP id b3mr1230784ibx.19.1261215870148; Sat, 19 Dec 2009 01:44:30 -0800 (PST) Date: Sat, 19 Dec 2009 17:44:30 +0800 Message-ID: <36ba02b00912190144h698f3f05ufe693208c9222ad6@mail.gmail.com> From: GangChen To: Behave WG Content-Type: multipart/alternative; boundary=005045016740ece104047b11b361 Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-framework-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 09:44:50 -0000 --005045016740ece104047b11b361 Content-Type: text/plain; charset=ISO-8859-1 Some technical comments: 1. In section 2, "The intention of this document is to focus on * network-based* translations solutions under all kinds of situations". After the interim meeting, the draft has updated definitons of both IPv4 network and IPv6 network, which indicates that A NETWORK could be a A HOST. Corresponding to the changes, the draft is suggested to remove the limitation of "network-based". Although the "network-based" could cover "host-based" according to the new defined terms, but it could be better to reword the statement to avoid confusions. 2. In section 1.4, "Transition Phase: This is the last stage of "S" curve." According to the context, I guess it should be middle stage. Some Editorial comments: 1. In section 1, "What if the process of moving a network and its components...." It could be easy to understand if we seperate the whole long sentence into several sub-sentences. How about this, "What if the process of moving a network and its components or customers is too late for contract cycles to affect IPv6 turn-up on important parts? At this point, it becomes uneconomical to deploy global IPv4 addresses in new services." 2.In section 1.1, "but configuring IPv4 routing is not in the network operator's view the most desirable strategy" How about: "but configuring IPv4 routing is not the most desirable strategy from the network operator's view" BRs Gang --005045016740ece104047b11b361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Some technical comments:

1. In section 2, "The intention of this document is to focus on network-based translations solutions under all kinds of situa= tions".

After the interim meeting, the draft has updated definitons of both IPv4= network and IPv6 network, which indicates that A NETWORK could be a A HOST= . Corresponding to the changes, the draft is suggested to remove the limita= tion of "network-based". Although the "network-based" c= ould cover "host-based" according to the new defined terms, but i= t could be better to reword the statement to avoid confusions.
=A0
2. In section 1.4, "Transition Phase:=A0 This is the last stag= e of "S" curve."

According to the context, I guess it should be middle stage.

Some Editorial comments:

1. In section 1, "What if the process of moving a network and its c= omponents...."

It could be easy to understand if we seperate the whole long sentence in= to several sub-sentences. How about this,
"What if the process of m= oving a network and its components or customers is too late for contract cy= cles to affect IPv6 turn-up on important parts? At this point, it becomes u= neconomical to deploy global IPv4 addresses in new services."

2.In section 1.1, "but configuring IPv4 routing is not in the netwo= rk operator's view the most desirable strategy"

How about: "but configuring IPv4 routing is not the most desirabl= e strategy from the network operator's view"
=A0
BRs
=A0
Gang
--005045016740ece104047b11b361-- From marcelo@it.uc3m.es Sat Dec 19 12:56:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9D93A68C7 for ; Sat, 19 Dec 2009 12:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZIY2Csl+F7h for ; Sat, 19 Dec 2009 12:56:58 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A75A13A6877 for ; Sat, 19 Dec 2009 12:56:56 -0800 (PST) X-uc3m-safe: yes Received: from r190-135-10-101.dialup.adsl.anteldata.net.uy (r190-135-10-101.dialup.adsl.anteldata.net.uy [190.135.10.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2CD616C5F06; Sat, 19 Dec 2009 21:56:36 +0100 (CET) Message-ID: <4B2D3E02.6080601@it.uc3m.es> Date: Sat, 19 Dec 2009 21:56:34 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09055F79@xmb-sjc-236.amer.cisco.com> <4B257875.4020503@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB09055FC9@xmb-sjc-236.amer.cisco.com> <4B27FA9E.1040206@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB090569E1@xmb-sjc-236.amer.cisco.com> <4B28DA13.8020903@it.uc3m.es> <85B2F271FDF6B949B3672BA5A7BB62FB090FEBA8@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBA8@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17080.002 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 20:56:59 -0000 Senthil Sivakumar (ssenthil) escribió: > > > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Wednesday, December 16, 2009 8:01 AM > To: Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt > > Senthil Sivakumar (ssenthil) escribió: > >> >> >> >> >>>> Section 1.2.3 >>>> >>>> I don't understand this >>>> >>>> "Filtering on the IPv6 interface is not supported, as mappings are >>>> only created by packets traveling in the IPv6 --> IPv4 direction." >>>> >>>> Can you explain why one cannot filter on ipv6 interface? >>>> >>>> >>>> >>>> >>>> >>> good question >>> NAT64 supports dynamically initiated connections only from the IPv6 side. So filtering on the IPv6 side seems some how orthogonal to the NAT behaviour. I mean you could do that, but you wouldn't be using NAT state in order to do so, i think. >>> OTOH, filtering in the IPv4 interface is different. Since NAT64 >>> cannot support communications iniitated in the IPv4 side, when there >>> is a hole in the NAT opened by an IPv6 connection and because we are >>> doing endpoint independent mappings, we end up with the question on >>> whehter we do accept this new communication that has been initiated >>> from the >>> IPv4 side or not (keep in mind that this is possible only because >>> there is a hole open and would not be possible in other case) >>> >>> So, while the NAT could filter in the IPv6 interface, this seems to be orthogonal to the NAT behaviour, but filtering in the IPv4 interface i tightly couple to the nat64 state, hence need to be specified. >>> >>> In any case, i have rephrased the previous sentence to >>> >>> Filtering of incoming IPv6 packets is not described in this specification. >>> >>> [Senthil] I guess I was thinking filtering even before the session can be created. >>> For example, one would want all the IPv6 hosts to have access to internet but except for a handful of specific hosts. Another filtering technique is all hosts are allowed except the ones that talk to a specific port or set of ports. These types of filtering is common and they protect the NAT64 resources (addresses & ports). >>> >>> in order to make it clearer that is not that is not supported, but that is not specified here. >>> >>> >>> >> right, i agree with that, but i still think this is orthogonal to the >> nat64 (e.g. firewalls have the same issues) so i am not sure what to say about this in the draft... any suggestion? >> >> [Senthil] True. I was thinking some text along these lines. >> >> "NAT64 device can do filtering of IPv6 packets based on the administrative rules to create BIB and session entries. The filtering can be flexible enough and broad enough but the idea of the filtering is to provide the operators necessary control to avoid DoS attacks that would result in exhaustion of NAT64 address, port, memory and CPU resources". >> >> >> > Ok, i will add that text to the draft, thanks > > >>> >>> >>> >>>> Section 3.2.2 >>>> Paragraph starting "After bootstrapping...." >>>> >>>> What does it mean all TCP sessions are in closed state? Where is >>>> this tracked? >>>> >>>> >>>> >>>> >>> Again, this is similar to the TCP CLOSED state >>> >>> The closed state is somehow special, cause it means that there is no state for the particular connection. I have tried to make this clearer in the document by adding the following description: >>> >>> CLOSED: Analogous to , CLOSED is a fictional >>> because it represents the state when there is no state for this particular 5-tuple, and therefore, >>> no connection. >>> >>> >>> [Senthil] The state of a session is tracked via the session table, >>> >>> >> no. >> the state is tracked by the state. I mean, current session table does >> not have a "STATE" column defined.Additional data is needed to track >> the state, sicne the state a given connection is is a piece of >> information that needs to be stored somewhere. We could define all the >> data strcutures needed for the implementation, but i fail to see the >> need for that >> >> [Senthil] Let me ask you this, as an implementor when the doc says "After bootstrapping all the devices should set its connection state for all the sessions to CLOSED." How do I do that? >> >> > > you don't create any state for any connection, hence they are all in CLOSED state. > > > >> Again, I didn't mean to say the state should be tracked within a session, but the state is per-session and hence keyed off of the session. You cant get to the state of the session without knowing what the session keys are. >> >> >> > the keys are the connection identifier. > You search among the connections that have state, If you can't find > state for the connection you are searching, it means it is in closed state. > Again, CLOSED state is a _fictional_ state that represents that no state > is available for that connection and hence there is no connection. > > Again, this is exactly the same as 793, > > >>> but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. >>> >>> >>> >>> >> as i mentioned earlier, the CLOSED state is a fictional state (similar to the the one for TCP) that represents that there is no state for a connection. >> In other words, in a normal TCP stack (in any regular host, no nat64 >> involved) all non existent connections are in CLOSED state... so where does a TCP stack store the state for those connections? Nowhere, cause the CLOSED stated in fact means that there is no state. >> >> [Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and there is a time period when the connections are in CLOSED state. >> > > from RFC793 page 21 > > CLOSED is fictional > because it represents the state when there is no TCB, and therefore, > no connection. > > and then in page 22 > > CLOSED - represents no connection state at all. > > [Senthil] Ok, I am fine with the text as is. Just for clarity can you add a reference to 793 when you are describing CLOSED? > > > it is already in the draft: it reads: CLOSED: Analogous to [RFC0793], CLOSED is a fictional state because it represents the state when there is no state for this particular 5-tuple, and therefore, no connection. Regards, marcelo >>> >>> >>> >>>> Section 3.2.3 >>>> >>>> For port allocation, the text says if the port is even an even port >>>> must be allocated and same for odd. What if there are no even ports >>>> to allocate but there are odd ports, should the packet be dropped or >>>> allocated a odd port. I understand some application require that the >>>> port parity to be maintained but majority of the apps don't care. So >>>> making this a recommendation on the best effort basis is ok but >>>> making it a mandatory requirement sounds unreasonable. Note RFC 4787 >>>> recommends this behavior but this text mandates it. >>>> >>>> >>>> >>>> >>> Right, i have changed this to a should. >>> >>> [Senthil] I am thinking that this should be a configurable parameter, that is the admin can decide if the device should strictly allocate even-for-even and odd-for-odd or it should do the first available port. >>> >>> >>> >>> >> but that is not what is reccomended by the behave requirements, right? >> >> I mean, what is required is what you mentioned earlier and that i have tried to relfect in the document with the text above. >> If we want to reccomend something else than what is described in the behave requirements, then we need to go against prior consensus. We can do that, but it would require strong WG consenus. >> >> [Senthil] From RFC4787, >> >> REQ-4: It is RECOMMENDED that a NAT have a "Port parity >> preservation" behavior of "Yes". >> >> It does not say SHOULD. >> > > From RFC 2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > [Senthil] Ok. That sounds good. > > Thanks > Senthil > >> So what you have in this draft is going above what has been said in the RFC4787. >> >> >> > not sure i understand what you mean > > > Regards, marcelo > > >> Thanks >> Senthil >> >> Regards, marcelo >> >> >> >> >>> Senthil >>> >>> >>> >>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > > From maxpassion@gmail.com Sat Dec 19 20:50:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4682F3A6853 for ; Sat, 19 Dec 2009 20:50:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vWiN0QoUYpJ for ; Sat, 19 Dec 2009 20:50:50 -0800 (PST) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BC5603A659A for ; Sat, 19 Dec 2009 20:50:50 -0800 (PST) Received: by pxi9 with SMTP id 9so3003283pxi.32 for ; Sat, 19 Dec 2009 20:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=caY732jtNJ5SyHVLzJJwmeaAeqYxm52bUglwr+Zg/lk=; b=fVb8pZ8Y38MwHKa/RyJzRk3GdoXLC1DI2m19D54/Iib/JcoN15jbnXnilpqzR4MJVl KdbjJOA+iRtR6cphR4+EFbg/aQhemA8AHK5OfVfpRUqrMvKCUbm3ScUxTLbAe92PQBms ew/tcKwXpJmGXXsBN8IIsLIAHiV9TWcSUSvAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TW3BWFMpfHUgYYU9G+e7EwfCze8wCSiSLQQ1LCcG41wPrwAXrsTTmOrDNxZXZP4yds 6xGsP6zW0DgLXYNMs+DLi6JrHE+txWAlSQC93BpFWXvw0i4lta3tq3Dwn3hpmhHVu9vT BIZt7sZA0kE58FXie7rmXq7WJkzVPttnVp3co= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr3740297wfa.157.1261284633054; Sat, 19 Dec 2009 20:50:33 -0800 (PST) In-Reply-To: <4B290A5D.1040700@viagenie.ca> References: <4B290A5D.1040700@viagenie.ca> Date: Sun, 20 Dec 2009 12:50:30 +0800 Message-ID: <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> From: liu dapeng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: Behave WG Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 04:50:52 -0000 Hi Simon, SERVFAIL means "The name server was unable to process this query due to a problem with the name server (RFC1035)" . I tried to query type=AAAA for ciscosales.webex.com using my laptop and using Wireshark to capture the packet then verify that it indeed returns a response which has the RCODE set to 2 (server failure). That excludes that this is caused by your DNS64 implementation. Regarding to how to fix this, I do not know if the DNS64 simply also to query A record when querying AAAA fails will cause any other potential problems? Best wishes, Dapeng Liu 2009/12/17, Simon Perreault : > Hello, > > Today I attended the interim meeting on WebEx over NAT64. I had only one > problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an > A query is successful. > > Now, section 5.1.2 prevents the DNS64 from synthesizing a record in this > situations. > > What to do? Try an A query even when the AAAA query fails? > > In my case, I just edited /etc/hosts... ;) > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sat Dec 19 20:53:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09883A659A for ; Sat, 19 Dec 2009 20:53:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMXfM2EL3GMS for ; Sat, 19 Dec 2009 20:53:34 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id E63773A67DD for ; Sat, 19 Dec 2009 20:53:34 -0800 (PST) Received: by pzk6 with SMTP id 6so3119451pzk.29 for ; Sat, 19 Dec 2009 20:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=B0GaupQ/Z6F9s0KHbc3eU7rEMeEPkeUQv5jui69H9R4=; b=ROwWo3K2pmg7tXxfFte8aFVp7irWsCFeTpFSaH0smFyqBux3zCZygXzr+FfYWL6nZH doLB7jaoPNgFWIEIqiMih4vRflAdA2eIUzNvY9T+iS535EUMRpQDMrxZTh6ojBg36hef 5RfzqBmfqMJJMZnOCOKKwMYfvSy7YoE399dAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nh+zi7+XEfVeK4fcm29UnjbaEQz2fQnou9LrXh6x21E3CDfVAm4o6/AdgcYkQxJT5l RTxOlIhn9tO13LGsKD7DVHnVALdsO0d5v5KKJMSK/15NWJtT1Va0+lXf3Xojo31dKSOg 2SdWKDmfSPl+o1M/leGKfENQnkzMTRqcTVHng= MIME-Version: 1.0 Received: by 10.142.121.3 with SMTP id t3mr3878176wfc.6.1261284796873; Sat, 19 Dec 2009 20:53:16 -0800 (PST) In-Reply-To: <20091216165953.GE37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> Date: Sun, 20 Dec 2009 12:53:16 +0800 Message-ID: <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> From: liu dapeng To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 04:53:35 -0000 Hi Andrew: I get Server failure when try to query AAAA for ciscosales.webex.com. Do you set the query type to AAAA to your resolver? Best wishes, Dapeng Liu 2009/12/17, Andrew Sullivan : > On Wed, Dec 16, 2009 at 11:30:49AM -0500, Andrew Sullivan wrote: >> On Wed, Dec 16, 2009 at 11:27:09AM -0500, Simon Perreault wrote: >> > Hello, >> > >> > Today I attended the interim meeting on WebEx over NAT64. I had only one >> > problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an >> > A query is successful. >> >> Do we know why it returned SERVFAIL? Do all the servers return >> SERVFAIL? I'm trying to understand whether there is a good reason > > Hmm, curiouser. When I query those nameservers for AAAA for > ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your > DSN64 returning SERVFAIL when it gets REFUSED? > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sat Dec 19 21:01:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2412F3A6875 for ; Sat, 19 Dec 2009 21:01:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0yeE8BWVaNr for ; Sat, 19 Dec 2009 21:01:34 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 07E6C3A6853 for ; Sat, 19 Dec 2009 21:01:34 -0800 (PST) Received: by pwi20 with SMTP id 20so2870767pwi.29 for ; Sat, 19 Dec 2009 21:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=v1LRs133nEuCJzpipHqcJmjCgRHdSE4+EZzsmDxnq0M=; b=Zjykzu0myPrwkMqEK9GLpXqHsU4hjdP9PWBN2JnICPVTKyuXmmHEkl0ZlNSZJRlLuO SQqeoNC+Ecef4lNmQ6qW2Z7BCuVxDLRI+mNTx0NNYQly9VXLXf0aD3mmswhuD+ujHcZR M27gVOzXry5+XMrfuO9rpGRWyDdAez16IiDrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LYLwqjsIBk8p/7mjfmCkoDE0SPW0AWadelOdMTTBjZvTrQm2TRY9UQ9SAY1Ilml4i3 +AJk60Er9WcpNFe6mxcDIxO3h0eslId1ljw671Rp9eVn7z65936/70b636wl7MeSVXwm F/RLMvu5PiIE/JR5BOpkkNjqbVlO1qJoDLDuU= MIME-Version: 1.0 Received: by 10.142.7.40 with SMTP id 40mr3750805wfg.120.1261285276411; Sat, 19 Dec 2009 21:01:16 -0800 (PST) In-Reply-To: <20091216183850.GJ37010@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> Date: Sun, 20 Dec 2009 13:01:16 +0800 Message-ID: <25e1aaa40912192101y4028f5acp357a76342ad46131@mail.gmail.com> From: liu dapeng To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 05:01:35 -0000 Hi Andrew, 2009/12/17, Andrew Sullivan : > On Wed, Dec 16, 2009 at 12:54:10PM -0500, Simon Perreault wrote: >> Andrew Sullivan wrote, on 2009-12-16 11:59: >> > Hmm, curiouser. When I query those nameservers for AAAA for >> > ciscosales.webex.com, I don't get SERVFAIL. I get REFUSED. Is your >> > DSN64 returning SERVFAIL when it gets REFUSED? >> >> This seems to be normal Bind behaviour. Both normal Bind and my DNS64-Bind >> return SERVFAIL when they get REFUSED. > > Interesting. Well, I can see the justification for either answer for > an iterative mode resolver, so it's not wrong. It _feels_ wrong to > me, but intuition is a lousy guide to correctness in these tricky > cases, I'd say, and as someone already observed "SERVFAIL" is a > coherent response for the server part of the recursive server. > >> Why wouldn't we want to try an A query when the AAAA query fails? >> >> The failure could be due to a multitude of valid reasons, not just >> misconfiguration or misbehaving. For example, the AAAA record might be >> sitting >> on a failed disk partition while the A record is OK. Yes this is >> far-fetched, >> but it is just an example. The point is that you can't assume anything >> about the >> availability of the A records when the AAAA query fails (or is refused, or >> whatever else). > > But we're trying to solve _just one_ problem: that you can't get to a > host that doesn't have AAAA, but that does have A at the same owner > name. We're not trying to make IPv6 connectivity work whenever some > bozo's DNS servers are broken, misconfigured, hiding behind a > misconfigured and packet mangling firewall, or any of these other > things. If we take on the scope, "Fix broken DNS when querying for > AAAA," we will spend until the heat death of the universe nailing down > all the ways this could be wrong. > > In this particular case, REFUSED means "go away". If the point of the > REFUSED response code was to say, "We don't do AAAA," then I submit > the server is broken. We have a perfectly good response code for > that: RCODE 4, NOTIMP. > > I am, however, susceptible to the argument that we ought to try an A > query in the event of RCODE 4 on the AAAA query. What do people > think? Only when the DNS server which does not has AAAA record and when response to AAAA query it will sets RCODE=4 to the response packet will make this approach more suitable, right? but is that the common practice? Best wishes, Dapeng Liu > By the way, despite my resistance to querying for A no matter what the > non-positive answer is (since I think that will just drive up > error-encumbered traffic), this is an incredibly valuable bit of > feedback, and I really appreciate it. Thank you very much > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sat Dec 19 21:27:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C8F3A67DD for ; Sat, 19 Dec 2009 21:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlSn-3xn1R6d for ; Sat, 19 Dec 2009 21:27:11 -0800 (PST) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B0E2C3A659A for ; Sat, 19 Dec 2009 21:27:11 -0800 (PST) Received: by pxi9 with SMTP id 9so3013840pxi.32 for ; Sat, 19 Dec 2009 21:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MMryxNbGNOkGE2wAvbQ1f5rGAVTu36uYGAu7sU3bXqo=; b=KEHc2RLJrGAQEjkDwmE+RqTrFCsQbAtGiWvd3SC/DjC4y+LnjlfKtrnYXwS37TiTsR LKD1M53zC/ldp/JGe6idK1YtWgCAtzbfzmDAdhTgkX7qKwgJfR3T94pyIq2wdpXSp8k7 Y6MZeT7JLIyPkioZBSKE0lok0tT12FIf3ti74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EFuWbYs/Dl00VqkY8iAxVahTC7Ewg8XWRcB2f5JZ9DyHPIk9jFDfzbNnWXq26mBrii AheyfKOdK/zzvMhv3XGTNB2CVaJZfWgT0TdQ80/TwCR7Nkj4Gne9fxkCCjRkjifilSUT 35rVr5HZNNNYhOllPP1AORbJeeVE+DitxZbB0= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr3755463wfa.157.1261286814004; Sat, 19 Dec 2009 21:26:54 -0800 (PST) In-Reply-To: <046901ca7eda$19473db0$c4f0200a@cisco.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Sun, 20 Dec 2009 13:26:53 +0800 Message-ID: <25e1aaa40912192126w212ec4b0u4d5ded3c544821e8@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 05:27:12 -0000 Hi Dan, I query AAAA for www.ecshop.com could success, the RCODE is 0 (no error). And the response is a CNAME. I am wondering why your experiment result is NXDOMAIN, what caused this unconsistency (other results are the same)? I use nslookup for query and set the query type to AAAA. Best wishes, Dapeng Liu 2009/12/17, Dan Wing : > Iljitsch van Beijnum wrote: > >> Just being persistant and request an A record whenever we >> don't get an AAAA answer for any (?) reason (timeout, >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a >> reasonable tradeoff. However, that would be a slight >> departure from the current draft. > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > would be ineffective for many websites, including popular > ones. I checked the top 5000 websites (according to Alexa, > see http://www.alexa.com/topsites) to see how they handle > AAAA queries. > > Of those 5000, their nameservers returned: > > NOERROR, 4766 (95.3%) > NXDOMAIN, 37 (0.74%) > REFUSED, 18 (0.36%) > SERVFAIL, 23 (0.46%) > > There is some inconsistency because my script is simplistic > (the results don't add up to 5000), but I was mostly intending > to get a feel for real numbers that would affect DNS64 if > DNS64 did not provide effective service to an NXDOMAIN > response. > > > Below, I summarized the domains that returned errors when > queried for AAAA. > > The command I used for the test was: > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > dig @J aaaa www.DOMAINNAME | grep status > and the log file is at > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > -d > > ----- > > NXDOMAIN: > www.1e100.net > www.uimserv.net > www.yimg.com > www.rmxads.com > www.ggpht.com > www.edgesuite.net > www.webry.info > www.images-amazon.com > www.pgmediaserve.com > www.livefilestore.com > www.googlesyndication.com > www.ytimg.com > www.myfiles-express.com > www.myspacecdn.com > www.fbgdc.com > www.say-move.org > www.www.ne.jp > www.ucom.ne.jp > www.xtshare.com > www.nocookie.net > www.bingj.com > www.k12.ca.us > www.wateen.net > www.2mdn.net > www.kvors.com > www.yahoofs.jp > www.ecshop.com > www.xii.jp > www.ebayrtm.com > www.atwola.com > www.twimg.com > www.www.gov.cn > www.movie-japan.com > www.mofile.com > www.donetsk.ua > www.gnspf.com > www.bannch.jp > > REFUSED: > www.ehow.com > www.sanspo.com > www.cracked.com > www.nbc.com > www.answerbag.com > www.mozilla-europe.org > www.hindustantimes.com > www.treehugger.com > www.blogsome.com > www.gamershell.com > www.rotoworld.com > www.books.com.tw > www.nbcsports.com > www.livestrong.com > www.longporntube.com > www.airliners.net > www.essortment.com > www.greenpeace.org > > SERVFAIL: > www.livejasmin.com > www.ynet.com > www.awempire.com > www.ikea.com > www.hc360.com > www.vnet.cn > www.bramjnet.com > www.miibeian.gov.cn > www.startpagina.nl > www.sznews.com > www.yingjiesheng.com > www.rueducommerce.fr > www.shortnews.de > www.heavy.com > www.penny-arcade.com > www.nouvelobs.com > www.eventim.de > www.cdcovers.cc > www.soccerway.com > www.pathfinder.gr > www.gazetaesportiva.net > www.5giay.vn > www.ratp.info > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sat Dec 19 21:59:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB9C3A677C for ; Sat, 19 Dec 2009 21:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSOpLUU6rWGX for ; Sat, 19 Dec 2009 21:59:24 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 3C2173A65A5 for ; Sat, 19 Dec 2009 21:59:24 -0800 (PST) Received: by pzk6 with SMTP id 6so3135122pzk.29 for ; Sat, 19 Dec 2009 21:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UZVY6be/x3gF96zWSiTiUUnWhr9U0EBYR6GLaxR4PJk=; b=TZ8ewsKWb3rwGEhPXstY65blF/3shyCzcaGVE6pWUQ/SGsLaFnip63DtTOID9R7L5K xcQcBp9L+1MhjIeKs+UrB+8CpTiFTaqsHt8hwBHNzehMAY0swWpkbrBEJ8e5I9KEDbQT aCngaoLsLSNj7ZBAIg6oMdnNv9xwGs5/eCjIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rnRO7hw+RfMMvCiRoKmlUa87oxbDFUdO64VoPRq3AJo7I6unRjYa2rF7WnifydMMg2 8iB5BIWNoWVJ3TxwDor3GSQnT8LsYjkP/fetLnbx1hDLAzIgNv8TUovmD90EXcRhjVVi TkHD2DHfWM4wQ+JD1C7ZpgQM/IIGvt2kg19iE= MIME-Version: 1.0 Received: by 10.142.6.1 with SMTP id 1mr3801556wff.224.1261288746036; Sat, 19 Dec 2009 21:59:06 -0800 (PST) In-Reply-To: References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Sun, 20 Dec 2009 13:59:05 +0800 Message-ID: <25e1aaa40912192159g523b4302s72da20f34b289c30@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Sullivan , behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 05:59:25 -0000 2009/12/17, Iljitsch van Beijnum : > On 17 dec 2009, at 6:30, Dan Wing wrote: > >>> Just being persistant and request an A record whenever we >>> don't get an AAAA answer for any (?) reason (timeout, >>> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a >>> reasonable tradeoff. However, that would be a slight >>> departure from the current draft. > >> Optimizing for NXDOMAIN is tempting, but it means DNS64 >> would be ineffective for many websites, > > Well, AFAIK with things like REFUSED and SERVFAIL you can argue that this > result is particular to the AAAA query and the A query may give a different > result. With NXDOMAIN the answer authoritatively states that the domain > doesn't exist, so the only way the A query can produce a different answer is > if someone is completely breaking the specifications. > > If the DNS64 is doing recursive queries itself it SHOULD never encounter > REFUSED, because then there would be a break in the delegation chain, so I'm > not worried about generating a few more queries in that case. If there is a > resolver in the middle it could be that the resolver doesn't want to resolve > for the DNS64, but in that case the whole setup doesn't work so the users > will give up and again, a few extra packets is not an issue. > > Not sure where SERVFAIL would come from in the authoritative case, but in > the resolver case it can obviously result from a REFUSED authoritative > response so again no problem querying for an A record. > > However, the NXDOMAIN case will normally be the result of a query for a > non-existant domain. If there is a large amount of such queries doubling it > is not a good idea. > > People configuring their DNS server to send out REFUSED for AAAA queries is > something that I can kinda-sorta-but-not-really follow, but NXDOMAIN when > there is in fact an A record is just plain wrong on every level so > generating lots of extra queries when there is NXDOMAIN for AAAA or by > always doing A first even when we don't need the A record is probably a > bridge too far for the IETF to mandate. Agree in some degree. Besides, dose sending A query if AAAA query responses a NXDOMAIN will cause security issue? Hackers could send lots AAAA queries for non-exist domain and the DNS64 continue to convert them to A queries will use up all the resources of DNS64? Best wishes, Dapeng Liu >> Of those 5000, their nameservers returned: > >> NOERROR, 4766 (95.3%) >> NXDOMAIN, 37 (0.74%) >> REFUSED, 18 (0.36%) >> SERVFAIL, 23 (0.46%) > > What about the remaining 156? Timeout? (For instance, one on Mark's list > that I tried replied in 4800 ms for me...) > > Would be interesting to see the results for A. As we saw in the FTP case, > there is always a percent or two that just don't do anything reasonable. > (Although with top 5000 popular sites this is probably better than an old > list of FTP sites.) > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sat Dec 19 22:56:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4C53A68CC for ; Sat, 19 Dec 2009 22:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ula-tFP0oH0j for ; Sat, 19 Dec 2009 22:56:47 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 52F593A683E for ; Sat, 19 Dec 2009 22:56:47 -0800 (PST) Received: by pzk6 with SMTP id 6so3151075pzk.29 for ; Sat, 19 Dec 2009 22:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4aSMP2EQCnQAIbaaNnZJfzJcIMAcDgc6bGryoc3Hgoc=; b=CfKP2J04OGm5N7qIuPQOuqaTWjybRMpIt+hsVvDdedj+BV+tFBPN186j0PuLkkW7s5 8RY3piurR2EQ39J/qcVR+Z+F3y9f6PX3RQp/6N3BBGNqB8jKYxeAOXMvveFPou8ZKGWk LzPanknDb6iXg4VjIfu1IXjQqrI5Z7Pu3rmmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y7YnByiBvHKAcRYCAI7To8u62Eu6NKgONaw/KbD7jjx30OUEsO9cjAL9oYarNc6GZS vd58hpfFtu8Yc/CcHKKESDS9nrcIIBEFxMFfYyZXNKIpabQnfv7T8XVn3QmNwSCHTI3l kY6KNqFzM7IcLqaMFvboWu9O+ZSqn4kDbqIDg= MIME-Version: 1.0 Received: by 10.142.9.32 with SMTP id 32mr3809189wfi.112.1261292189170; Sat, 19 Dec 2009 22:56:29 -0800 (PST) In-Reply-To: <20091218033348.GB47068@shinkuro.com> References: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> <20091218033348.GB47068@shinkuro.com> Date: Sun, 20 Dec 2009 14:56:29 +0800 Message-ID: <25e1aaa40912192256h64f80b3freb382fe522135e64@mail.gmail.com> From: liu dapeng To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 06:56:48 -0000 Hi Andrew, 2009/12/18, Andrew Sullivan : > On Thu, Dec 17, 2009 at 06:56:28PM +0100, Iljitsch van Beijnum wrote: >> >> 2. I think we mostly agree that doing an A query after a SERVFAIL for AA= AA >> is reasonable, the problem is NXDOMAIN. > > Yes. I am currently editing (at this very moment) the -04 draft and > it is going to say this. It is a replacement for =A75.1.2: > > 5.1.2. The answer when there is an error > > If the query results in a response with RCODE other than 0, then > there are two possibilities. A result with RCODE=3D3 is handled > according to normal DNS operation (which is normally to return the > error to the client). This stage is still prior to any synthesis > having happened, so a response to be returned to the client does > not need any special assembly than would usually happen in DNS > operation. > > Any other RCODE is treated as though the RCODE were 0 and the > answer section were empty. This is because of the large number of > different responses from deployed name servers when they receive > AAAA queries without a AAAA record being available. > > It is important to note that, as of this writing, some servers > respond with RCODE=3D3 to a AAAA query even if there is an A record > available for that owner name. Those servers are in clear > violation of the meaning of RCODE 3, and it is expected that they > will decline in use as IPv6 deployment increases. this means in the early stage of IPv6 depleoyment, many site can not access using DNS64+NAT64, I am not sure whether it is a good approach... Best wishes, Dapeng Liu > If you don't like this or have some suggested alternative text, it > would be welcome; but please hurry. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sun Dec 20 00:29:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E613A690E for ; Sun, 20 Dec 2009 00:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXguJ35shtVy for ; Sun, 20 Dec 2009 00:29:14 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id AE27E3A67D1 for ; Sun, 20 Dec 2009 00:29:14 -0800 (PST) Received: by pzk6 with SMTP id 6so3182522pzk.29 for ; Sun, 20 Dec 2009 00:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1oZ3lYib08+SC2f00THqezxN3lSIBV7430sQfgcP+d0=; b=s6nS+k5aq6wq5tmdh1eurWdHGG7DbB6XY8D7XXpHkG40yrKxRXBZDXTUYHSzp6NwxQ iTO8rqJWtgd9Em7ebIY+tOMwYUZ6XCbgg1NOAU07CTjAYaah1F5baTzOXeKRKetLvVAW liezmKxxvbFQSOils4XqU/TvQKOY35B9Ap2ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EVJn9SMYj1wFhouwkOO0qkwuIi9eiVdv/EH3KMGe0yWAhx7c2NglZvpBtFGWr82U9g yvmcCGlaM77yJ8AeWDq1R58kdtnlGDje5hIGDcpKj0sXtwkOLj3y684T7denxzDqgOhR mORKMCjHNXzjk/oAAeajH8frYg5WYjBXhqumI= MIME-Version: 1.0 Received: by 10.143.153.41 with SMTP id f41mr1254144wfo.331.1261297736491; Sun, 20 Dec 2009 00:28:56 -0800 (PST) In-Reply-To: <046901ca7eda$19473db0$c4f0200a@cisco.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> Date: Sun, 20 Dec 2009 16:28:56 +0800 Message-ID: <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 08:29:15 -0000 Hi Dan, I find that www.blogsome.com could response correctly for AAAA query. The response message have no answer record for AAAA RR but with a RCODE=0. But most of the remaining servers listed in "REFUSED" section could indeed have a response with RCODE=0; For the "SERVFAIL" section: www.pathfinder.gr/ www.sznews.com/www.bramjnet.com indeed response Server failure ; www.hc360.com time out. But all others could have a response with RCODE=0; Best wishes, Dapeng Liu 2009/12/17, Dan Wing : > Iljitsch van Beijnum wrote: > >> Just being persistant and request an A record whenever we >> don't get an AAAA answer for any (?) reason (timeout, >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a >> reasonable tradeoff. However, that would be a slight >> departure from the current draft. > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > would be ineffective for many websites, including popular > ones. I checked the top 5000 websites (according to Alexa, > see http://www.alexa.com/topsites) to see how they handle > AAAA queries. > > Of those 5000, their nameservers returned: > > NOERROR, 4766 (95.3%) > NXDOMAIN, 37 (0.74%) > REFUSED, 18 (0.36%) > SERVFAIL, 23 (0.46%) > > There is some inconsistency because my script is simplistic > (the results don't add up to 5000), but I was mostly intending > to get a feel for real numbers that would affect DNS64 if > DNS64 did not provide effective service to an NXDOMAIN > response. > > > Below, I summarized the domains that returned errors when > queried for AAAA. > > The command I used for the test was: > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > dig @J aaaa www.DOMAINNAME | grep status > and the log file is at > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > -d > > ----- > > NXDOMAIN: > www.1e100.net > www.uimserv.net > www.yimg.com > www.rmxads.com > www.ggpht.com > www.edgesuite.net > www.webry.info > www.images-amazon.com > www.pgmediaserve.com > www.livefilestore.com > www.googlesyndication.com > www.ytimg.com > www.myfiles-express.com > www.myspacecdn.com > www.fbgdc.com > www.say-move.org > www.www.ne.jp > www.ucom.ne.jp > www.xtshare.com > www.nocookie.net > www.bingj.com > www.k12.ca.us > www.wateen.net > www.2mdn.net > www.kvors.com > www.yahoofs.jp > www.ecshop.com > www.xii.jp > www.ebayrtm.com > www.atwola.com > www.twimg.com > www.www.gov.cn > www.movie-japan.com > www.mofile.com > www.donetsk.ua > www.gnspf.com > www.bannch.jp > > REFUSED: > www.ehow.com > www.sanspo.com > www.cracked.com > www.nbc.com > www.answerbag.com > www.mozilla-europe.org > www.hindustantimes.com > www.treehugger.com > www.blogsome.com > www.gamershell.com > www.rotoworld.com > www.books.com.tw > www.nbcsports.com > www.livestrong.com > www.longporntube.com > www.airliners.net > www.essortment.com > www.greenpeace.org > > SERVFAIL: > www.livejasmin.com > www.ynet.com > www.awempire.com > www.ikea.com > www.hc360.com > www.vnet.cn > www.bramjnet.com > www.miibeian.gov.cn > www.startpagina.nl > www.sznews.com > www.yingjiesheng.com > www.rueducommerce.fr > www.shortnews.de > www.heavy.com > www.penny-arcade.com > www.nouvelobs.com > www.eventim.de > www.cdcovers.cc > www.soccerway.com > www.pathfinder.gr > www.gazetaesportiva.net > www.5giay.vn > www.ratp.info > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From maxpassion@gmail.com Sun Dec 20 00:34:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B473A6926 for ; Sun, 20 Dec 2009 00:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+9uLlYHADU7 for ; Sun, 20 Dec 2009 00:34:46 -0800 (PST) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 07F8D3A690E for ; Sun, 20 Dec 2009 00:34:46 -0800 (PST) Received: by pxi9 with SMTP id 9so3068782pxi.32 for ; Sun, 20 Dec 2009 00:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UnBVIPsFbQdtaDi2Zq2TwC1JDnsL4jdmmY3vvhlfIeA=; b=i0eX/hFhbSh+MXazhXK/MrRAVrjdg0AuPyfhlUYP/IxYpSlje1/G7gihN9yvnb5ir9 pOK2toSNS03MATyGq6/6nnF6zkhM3qA+XEvS+Yr4GPSq609Ikce4blpCOLnUms1gWlN5 PbkgqQHX7zcsJF1OSCoG5H6BGvqFiaWJLv3yM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XclTIKul377bXMsnKd9jGTgBvaO43XUjF3r0F4/vLTkYQePHmJp+c6m+KtUdiYz54o 4Q0RKTWK/JcJlgp+h4QnYdn0yLUSAAAf0uBBtOjradB99nFMxhaK6ChIkOkjLc148yzx viuj/Uc6CJALrGf+i+9Hdri5YmVh/G7LwYGFk= MIME-Version: 1.0 Received: by 10.142.4.12 with SMTP id 12mr3882694wfd.133.1261298068087; Sun, 20 Dec 2009 00:34:28 -0800 (PST) In-Reply-To: <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> Date: Sun, 20 Dec 2009 16:34:27 +0800 Message-ID: <25e1aaa40912200034w5a25123m92af41698cdfdc70@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 08:34:47 -0000 www.ratp.info listed in "SERVFAIL" section could also response with RCODE=0 when queried with tye=AAAA. The response message does not have any RRes. Dapeng Liu 2009/12/20, liu dapeng : > Hi Dan, > > I find that www.blogsome.com could response correctly for AAAA query. > The response message have no answer record for AAAA RR but with a > RCODE=0. But most of the remaining servers listed in "REFUSED" section > could indeed have a response with RCODE=0; > > For the "SERVFAIL" section: www.pathfinder.gr/ > www.sznews.com/www.bramjnet.com indeed response Server failure ; > www.hc360.com time out. But all others could have a response with > RCODE=0; > > Best wishes, > Dapeng Liu > > 2009/12/17, Dan Wing : >> Iljitsch van Beijnum wrote: >> >>> Just being persistant and request an A record whenever we >>> don't get an AAAA answer for any (?) reason (timeout, >>> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a >>> reasonable tradeoff. However, that would be a slight >>> departure from the current draft. >> >> Optimizing for NXDOMAIN is tempting, but it means DNS64 >> would be ineffective for many websites, including popular >> ones. I checked the top 5000 websites (according to Alexa, >> see http://www.alexa.com/topsites) to see how they handle >> AAAA queries. >> >> Of those 5000, their nameservers returned: >> >> NOERROR, 4766 (95.3%) >> NXDOMAIN, 37 (0.74%) >> REFUSED, 18 (0.36%) >> SERVFAIL, 23 (0.46%) >> >> There is some inconsistency because my script is simplistic >> (the results don't add up to 5000), but I was mostly intending >> to get a feel for real numbers that would affect DNS64 if >> DNS64 did not provide effective service to an NXDOMAIN >> response. >> >> >> Below, I summarized the domains that returned errors when >> queried for AAAA. >> >> The command I used for the test was: >> dig +short DOMAINNAME ns | xargs -t -n 1 -I J >> dig @J aaaa www.DOMAINNAME | grep status >> and the log file is at >> ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt >> >> -d >> >> ----- >> >> NXDOMAIN: >> www.1e100.net >> www.uimserv.net >> www.yimg.com >> www.rmxads.com >> www.ggpht.com >> www.edgesuite.net >> www.webry.info >> www.images-amazon.com >> www.pgmediaserve.com >> www.livefilestore.com >> www.googlesyndication.com >> www.ytimg.com >> www.myfiles-express.com >> www.myspacecdn.com >> www.fbgdc.com >> www.say-move.org >> www.www.ne.jp >> www.ucom.ne.jp >> www.xtshare.com >> www.nocookie.net >> www.bingj.com >> www.k12.ca.us >> www.wateen.net >> www.2mdn.net >> www.kvors.com >> www.yahoofs.jp >> www.ecshop.com >> www.xii.jp >> www.ebayrtm.com >> www.atwola.com >> www.twimg.com >> www.www.gov.cn >> www.movie-japan.com >> www.mofile.com >> www.donetsk.ua >> www.gnspf.com >> www.bannch.jp >> >> REFUSED: >> www.ehow.com >> www.sanspo.com >> www.cracked.com >> www.nbc.com >> www.answerbag.com >> www.mozilla-europe.org >> www.hindustantimes.com >> www.treehugger.com >> www.blogsome.com >> www.gamershell.com >> www.rotoworld.com >> www.books.com.tw >> www.nbcsports.com >> www.livestrong.com >> www.longporntube.com >> www.airliners.net >> www.essortment.com >> www.greenpeace.org >> >> SERVFAIL: >> www.livejasmin.com >> www.ynet.com >> www.awempire.com >> www.ikea.com >> www.hc360.com >> www.vnet.cn >> www.bramjnet.com >> www.miibeian.gov.cn >> www.startpagina.nl >> www.sznews.com >> www.yingjiesheng.com >> www.rueducommerce.fr >> www.shortnews.de >> www.heavy.com >> www.penny-arcade.com >> www.nouvelobs.com >> www.eventim.de >> www.cdcovers.cc >> www.soccerway.com >> www.pathfinder.gr >> www.gazetaesportiva.net >> www.5giay.vn >> www.ratp.info >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From iljitsch@muada.com Sun Dec 20 03:18:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14433A689A for ; Sun, 20 Dec 2009 03:18:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW7i1Z7zqdg7 for ; Sun, 20 Dec 2009 03:18:37 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id C34C43A67C2 for ; Sun, 20 Dec 2009 03:18:36 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBKBHeN9014526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Dec 2009 12:17:41 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1077) From: Iljitsch van Beijnum In-Reply-To: <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> Date: Sun, 20 Dec 2009 12:18:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <669AB0B7-66EB-4925-A263-69906D0DE2EF@muada.com> References: <004201ca7882$6ad70b00$d40c6f0a@china.huawei.com> To: Behave WG X-Mailer: Apple Mail (2.1077) Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 11:18:38 -0000 There is this huge thread and every message starts with several screens = like this and is therefore almost unreadable: >=20 >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Christian Huitema = [mailto:huitema@microsoft.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B412=E6=9C=889=E6=97=A5= 10:26 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xu Xiaohu; 'R=C3=A9mi Despr=C3=A9s'; = behave@ietf.org; ipv6@ietf.org >> =E4=B8=BB=E9=A2=98: RE: [BEHAVE] Reason(s) for Modified EUI-64 format = to apply to ALL >> non-0::/3 IPv6 addresses ? >>=20 >>> It seems ok to redefine the specification once the constraint on >>> IPv4-embeded IPv6 addresses has been removed, just as what we are = now > doing >>> on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and > IPv4-Mapped >>> IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted = IPv6 >>> address respectively). Can someone summerize?= From phdgang@gmail.com Sun Dec 20 05:28:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4C13A6781; Sun, 20 Dec 2009 05:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQjqijY-+naG; Sun, 20 Dec 2009 05:28:25 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 8496C3A657C; Sun, 20 Dec 2009 05:28:25 -0800 (PST) Received: by iwn33 with SMTP id 33so3129836iwn.29 for ; Sun, 20 Dec 2009 05:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Gay4DRND2iJwn1OdcCFxxdjTlyYMP4laj3NTWzt6rFM=; b=d2ynoM20hqrCkXoNKcvfZZ7o9FOgcQRnHzUXBZkaxzr7nQyk5UjCzhBh9IslO9E/rq /72MYHRnTP5LQxQZZ1JO6OlXpIKjkn9/9lMf/tQLmYS6HYmOiVC5jNekij9t+x4u2lU2 Xfuituc5HDRYrM9W5zsvlIT8yoO+IKENGXTWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uAxBTSqh5rkqza0AhpI0WrcMlhI7fgzI7lPq65GM8hHTLHX8rh0k9C0rlE+eht6/+b Biwdk3AaU8bxd+9lZFL9uo3PsOgXq6ijJbTyTwu/gfdEIyz1Sbqe5FC1/Cc3odtdc+sM /SBTpmLCGE2FVR3lw09FvbtgAxlg+cUTBBq4k= MIME-Version: 1.0 Received: by 10.231.146.2 with SMTP id f2mr2614549ibv.23.1261315687299; Sun, 20 Dec 2009 05:28:07 -0800 (PST) In-Reply-To: <4B1EC795.7040407@gmail.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> Date: Sun, 20 Dec 2009 21:28:07 +0800 Message-ID: <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> From: GangChen To: Brian E Carpenter Content-Type: multipart/alternative; boundary=0016e64c06167dbb01047b28f13b Cc: Behave WG , eric.burgey@orange-ftgroup.com, xing@cernet.edu.cn, Xu Xiaohu , ipv6@ietf.org Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 13:28:26 -0000 --0016e64c06167dbb01047b28f13b Content-Type: text/plain; charset=ISO-8859-1 > > > > My question is: Should the IPv4-embeded IPv6 address still be in > accordance with the specification defined in RFC4291 as "...For all unicast > addresses, except those that start with the binary value 000, Interface IDs > are required to be 64 bits long and to be constructed in Modified EUI-64 > format..."? If the answer is yes, why? (In other words, is there any > practical meaning/usage for that constraint in the IPv4/IPv6 translation > process?) > > I thought we'd discussed that a lot. Maybe it was not on the BEHAVE list. > > The idea of protecting the semantics of the u/g bit (which is most cleanly > done by skipping the whole byte) is that it is a very fundamental part of > the IPv6 design and we simply do not know when or how it might be relied > on. It may have no value in currently understood cases of 1:1 communication > via a NAT64, but we don't know where it might be important in p2p > communications, > referrals, etc. > I have a concern about that specified rule of "bits 64 to 71" doesn't protect the semantics of the u/g bit. In the case of adopting WKP, the U-bits should be 1, since WKP is only concatenated with global IPv4 address to guarantee the uniqueness of IPv4-Converted IPv6 addresses. Following statement is quoted from draft-ietf-bahave-address-format-03. "When using a /96 prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero." If this rule is applied to WKP case, it might even break the semantics of the u/g bit. BRs Gang --0016e64c06167dbb01047b28f13b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> My question is: Should = the IPv4-embeded IPv6 address still be in accordance with the specification= defined in RFC4291 as "...For all unicast addresses, except those tha= t start with the binary value 000, Interface IDs are required to be 64 bits= long and to be constructed in Modified EUI-64 format..."? =A0If the a= nswer is yes, why? (In other words, is there any practical meaning/usage fo= r that constraint in the IPv4/IPv6 translation process?)

I thought we'd discussed that a lot. Maybe it was not on the BEHAVE= list.

The idea of protecting the semantics of the u/g bit (which is= most cleanly
done by skipping the whole byte) is that it is a very fund= amental part of
the IPv6 design and we simply do not know when or how it might be reliedon. It may have no value in currently understood cases of 1:1 communicatio= n
via a NAT64, but we don't know where it might be important in p2p = communications,
referrals, etc.
=A0
I have a concern about that specified rule of "bits 64 to 71"= ; doesn't protect the semantics of the u/g bit. In the case of adopting= WKP, the U-bits should be 1, since WKP is only concatenated with global IP= v4 address to guarantee the uniqueness of IPv4-Converted IPv6 addresses. Fo= llowing statement is quoted from draft-ietf-bahave-address-format-03.

"When using a /96 prefix, the administrators MUST ensure that= the bits 64 to 71 are set to zero."

If this rule is applied to WKP case, it might even break the seman= tics of the u/g bit.
=A0
BRs
=A0
Gang
=A0
--0016e64c06167dbb01047b28f13b-- From ajs@shinkuro.com Sun Dec 20 08:03:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232483A69C5 for ; Sun, 20 Dec 2009 08:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TscTZferzCC0 for ; Sun, 20 Dec 2009 08:03:55 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 58B8F3A69AF for ; Sun, 20 Dec 2009 08:03:55 -0800 (PST) Received: from crankycanuck.ca (unknown [12.189.125.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 61B012FE8CE7 for ; Sun, 20 Dec 2009 16:03:38 +0000 (UTC) Date: Sun, 20 Dec 2009 11:03:19 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091220160319.GA58888@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 16:03:56 -0000 On Sun, Dec 20, 2009 at 12:53:16PM +0800, liu dapeng wrote: > Hi Andrew: > > I get Server failure when try to query AAAA for ciscosales.webex.com. > Do you set the query type to AAAA to your resolver? I bet you're querying through a recursive resolver. That's not the right way to test this. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Sun Dec 20 08:50:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2A23A6895 for ; Sun, 20 Dec 2009 08:50:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x49YFZ0RY3-5 for ; Sun, 20 Dec 2009 08:50:43 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 80F3A3A6918 for ; Sun, 20 Dec 2009 08:50:43 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBKGnlIj016196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Dec 2009 17:49:47 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20091220160319.GA58888@shinkuro.com> Date: Sun, 20 Dec 2009 17:50:19 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 16:50:44 -0000 On 20 dec 2009, at 17:03, Andrew Sullivan wrote: > I bet you're querying through a recursive resolver. That's not the > right way to test this. Do we assume a DNS64 will perform its own recursion? Iljitsch From huitema@microsoft.com Sun Dec 20 09:00:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F303B3A69EA; Sun, 20 Dec 2009 09:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRABgoQzlcyB; Sun, 20 Dec 2009 09:00:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 17E0E3A699C; Sun, 20 Dec 2009 09:00:05 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 20 Dec 2009 09:00:21 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Sun, 20 Dec 2009 08:59:49 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 20 Dec 2009 08:59:48 -0800 From: Christian Huitema To: GangChen , Brian E Carpenter Thread-Topic: [BEHAVE] address-format: bits 64 to 71 Thread-Index: AQHKgXhil3dOuVhfwUyFpimr48Sle5FuJ6mQ Date: Sun, 20 Dec 2009 16:59:44 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> In-Reply-To: <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xing@cernet.edu.cn" , "eric.burgey@orange-ftgroup.com" , Behave WG , "ipv6@ietf.org" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 17:00:09 -0000 > I have a concern about that specified rule of "bits 64 to 71" doesn't pro= tect the semantics=20 > of the u/g bit. In the case of adopting WKP, the U-bits should be 1, sinc= e WKP is only=20 > concatenated with global IPv4 address to guarantee the uniqueness of IPv4= -Converted=20 > IPv6 addresses. Following statement is quoted from draft-ietf-bahave-addr= ess-format-03. >=20 > "When using a /96 prefix, the administrators MUST ensure that the bits 64= to 71 are set to zero." >=20 > If this rule is applied to WKP case, it might even break the semantics of= the u/g bit. No. The "uniqueness" property is defined as "guaranteed to not collide with an = IEEE802 identifier." IPv4 addresses do not have that property. Besides, the WKP prefix (64:FF9B::/96) falls in the ::/8 range reserved for= the IETF, the only range in which the U/G requirements do not apply. -- Christian Huitema =20 From simon.perreault@viagenie.ca Sun Dec 20 09:11:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8493A6861 for ; Sun, 20 Dec 2009 09:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiZuNVfgWwpd for ; Sun, 20 Dec 2009 09:11:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 97C913A67BD for ; Sun, 20 Dec 2009 09:11:51 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CC9B321B8B; Sun, 20 Dec 2009 12:11:35 -0500 (EST) Message-ID: <4B2E5AC7.2010804@viagenie.ca> Date: Sun, 20 Dec 2009 12:11:35 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: liu dapeng References: <4B290A5D.1040700@viagenie.ca> <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> In-Reply-To: <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 17:11:54 -0000 On 12/19/2009 11:50 PM, liu dapeng wrote: > I tried to query > type=AAAA for ciscosales.webex.com using my laptop and using Wireshark > to capture the packet then verify that it indeed returns a response > which has the RCODE set to 2 (server failure). I'm pretty sure the authoritative name server returns REFUSED: $ dig @ns104-b.webex.com ciscosales.webex.com aaaa ; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>> @ns104-b.webex.com ciscosales.webex.com aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17297 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ciscosales.webex.com. IN AAAA ;; Query time: 42 msec ;; SERVER: 64.68.104.8#53(64.68.104.8) ;; WHEN: Sun Dec 20 12:10:08 2009 ;; MSG SIZE rcvd: 38 Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sun Dec 20 09:15:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6112E3A6861 for ; Sun, 20 Dec 2009 09:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPRdgUslhGTK for ; Sun, 20 Dec 2009 09:15:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6B3763A67EE for ; Sun, 20 Dec 2009 09:15:00 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B3D7521B8B for ; Sun, 20 Dec 2009 12:14:44 -0500 (EST) Message-ID: <4B2E5B84.9010708@viagenie.ca> Date: Sun, 20 Dec 2009 12:14:44 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> In-Reply-To: <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 17:15:01 -0000 On 12/20/2009 11:50 AM, Iljitsch van Beijnum wrote: > Do we assume a DNS64 will perform its own recursion? I hope not. It should be able to forward to another recursor. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Sun Dec 20 11:21:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A543A68E2 for ; Sun, 20 Dec 2009 11:21:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPaZ3ua8rJuB for ; Sun, 20 Dec 2009 11:21:45 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 992F53A67DB for ; Sun, 20 Dec 2009 11:21:45 -0800 (PST) Received: from [10.127.116.220] (unknown [24.114.235.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E88AD2FE8CE7; Sun, 20 Dec 2009 19:21:28 +0000 (UTC) From: Andrew Sullivan To: Simon Perreault In-Reply-To: <4B2E5B84.9010708@viagenie.ca> X-Mailer: iPhone Mail (7D11) References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> Message-Id: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 20 Dec 2009 14:21:20 -0500 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 19:21:53 -0000 No, it definitely will break if it's behind a plain resolver. We had that discussion in Stockholm. If this isn't clear in the draft, please let me know. -- Andrew Sullivan On 2009-12-20, at 12:14, Simon Perreault wrote: > On 12/20/2009 11:50 AM, Iljitsch van Beijnum wrote: >> Do we assume a DNS64 will perform its own recursion? > > I hope not. It should be able to forward to another recursor. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Sun Dec 20 13:41:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB263A67AB for ; Sun, 20 Dec 2009 13:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImAeNZRsZKZc for ; Sun, 20 Dec 2009 13:41:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0B71D3A68E4 for ; Sun, 20 Dec 2009 13:41:05 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2512021519; Sun, 20 Dec 2009 16:40:49 -0500 (EST) Message-ID: <4B2E99E0.5090700@viagenie.ca> Date: Sun, 20 Dec 2009 16:40:48 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Andrew Sullivan References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> In-Reply-To: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 21:41:06 -0000 On 12/20/2009 02:21 PM, Andrew Sullivan wrote: > No, it definitely will break if it's behind a plain resolver. We had > that discussion in Stockholm. If this isn't clear in the draft, please > let me know. Are you referring to section 6.1? I understand from that section that a mixed-mode iterative and forwarding DNS resolver cannot work as intended when using a DNS64 as a forwarder. I fail to see how this is relevant to the case where a DNS64 is forwarding to a plain resolver. (Side remark: I do find the section confusing because it is clear to me that *any* direct querying of authoritative name servers by IPv6-only hosts, thus bypassing the DNS64, cannot work, and am left wondering why this section is only talking about the special case of "(mis)configured [...] mixed-mode iterative and forwarding resolvers".) Are you also referring to the discussion in this thread? http://www.ietf.org/mail-archive/web/behave/current/msg06384.html Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sun Dec 20 13:55:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A373A6937 for ; Sun, 20 Dec 2009 13:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDxugLq6xPVi for ; Sun, 20 Dec 2009 13:54:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6C1D83A692C for ; Sun, 20 Dec 2009 13:54:58 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 759FA20E20 for ; Sun, 20 Dec 2009 16:54:42 -0500 (EST) Message-ID: <4B2E9D21.2090805@viagenie.ca> Date: Sun, 20 Dec 2009 16:54:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> In-Reply-To: <4B2E99E0.5090700@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 21:55:00 -0000 On 12/20/2009 04:40 PM, Simon Perreault wrote: > Are you also referring to the discussion in this thread? > http://www.ietf.org/mail-archive/web/behave/current/msg06384.html Copy-pasting error. I meant this one: http://www.ietf.org/mail-archive/web/behave/current/msg06386.html Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xuxh@huawei.com Sun Dec 20 17:41:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1254A3A68ED for ; Sun, 20 Dec 2009 17:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.709 X-Spam-Level: * X-Spam-Status: No, score=1.709 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I2zDul0zCtY for ; Sun, 20 Dec 2009 17:41:34 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CC3263A68B7 for ; Sun, 20 Dec 2009 17:41:33 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ007UGBCJAC@szxga02-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 09:41:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ0060YBCJ8C@szxga02-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 09:41:07 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ00KJMBCJ9I@szxml04-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 09:41:07 +0800 (CST) Date: Mon, 21 Dec 2009 09:41:06 +0800 From: Xu Xiaohu In-reply-to: <04ac01ca7fbf$080d7060$c4f0200a@cisco.com> To: 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <001b01ca81de$aa4e2010$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/Do3fPC1qAeQTRD27HNcHfefRBQAbptZQAAVIHXAAAJiU0AAAPVpAAAkc9NAAh3kaYA== Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 01:41:35 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 16:50 > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 >=20 > > > > > +-------------------+ > > > > > | | > > > > > +-------------+ | IPv6 Internet | = +--------------+ > > > > > | +---+ +---++---++ IPv4 = only > > > > > | IPv6 only | +-------------------+ |NAT64| = | > > > > > | +-----+ | ++---++ = +-----+| > > > > > | | H1 | | +-------------------+ | | H2 = || > > > > > | +-----+ NAT64?- + +---+ = +-----+| > > > > > +-------------+ | IPv4 Internet | = +--------------+ > > > > > | | > > > > > +-------------------+ > > > > > If I understand your statement correctly, An IPv6 only site > > > > > (e.g., left site > > > > > in the above figure) MUST have a connection to the IPv4 > > > > > Internet via NAT64 > > > > > in order to access hosts located in an IPv4 only site (e.g., > > > > > right site in > > > > > the above figure). Besides, the IPv6 only host (e.g. H1) MUST > > > > > be able to > > > > > synthesize IPv6 address by itself. If either of the above two > > > > > conditions is > > > > > not satisfied, the communication between H1 and H2 is > > impossible. > > > > > > > > Yep -- because IPv4-only applications don't know anything > > about IPv6 > > > addresses > > > > -- IPv4-only applications don't know how to parse IPv6 > > addresses, how to > > > > include them in referrals, etc. > > > > > > Note that H1 in the above scenario is IPv6 only, but not > > IPv4 only. Hence > > > I'm wondering whether the statement you made is relevant to > > the above > > > scenario. > > > > Let me explain the scenario a bit more, in the above scenario, the > > communication is initiated by H1 (IPv6 only host), but not H2 > > (IPv4 only > > host). To make that communication possible, should a NAT64 be = deployed > > between the IPv6 only site (left site) and the IPv4 Internet > > although there > > is already a NAT64 between the IPv4 site (right site) and the > > IPv6 Internet? > > If so, what's the meaning of IPv6 Internet to IPv4 network scenario? >=20 > The "IPv6 Internet to IPv4 network" scenario applies to the ISP on the right. >=20 > Detail: >=20 > The ISP on the left is a business, and they made the decision to = operate an > IPv6-only network with IPv6-only hosts. Their subscribers want access = to > (and/or from) the IPv4 Internet, so that ISP provides a NAT64 (and associated > DNS64, of course). This is the "an IPv6 network to the IPv4 Internet" > scenario (when the connection is initiated from the IPv6 host) and is = the "the > IPv4 Internet to an IPv6 network" (when the connection is initiated = from the > IPv4 side). Note that a stateful NAT64 will generally not support = "the IPv4 > Internet to an IPv6 network" unless port mappings are configured on = the > stateful NAT64. >=20 > The ISP on the right is another, separate business, and they made the decision > to keep their subscribers running IPv4. Their subscribers want access = to > (and/or from) the IPv6 Internet. This is "an IPv4 network to the IPv6 > Internet" (when the connection is initiated from the IPv4 side) and is "the > IPv6 Internet to an IPv4 network" (when the connection is initiated = from the > IPv6 side). +-------------+ | IPv6 only | | +-----+ | | | H3 | | | +-----+ | +------+------+ | +---------+---------+ | | +-------------+ | IPv6 Internet | +----------------+ | +------+ +-----+-+-----+ IPv4 only| | IPv6 only | +-------------------+ |NAT64-2| | | +-----+ | +-+-----+ +-----+| | | H1 | +-------+ +-------------------+ | | H2 || | +-----+ |NAT64-1+- + +------+ +-----+| | DNS64 +--+----+ | IPv4 Internet | +----------------+ +-------------+ | | +-------------------+ In the above scenario, if H3 and H1 send a DNS query for the AAAA record = of H2 respectively, they should obtain different results, e.g., H3 gets an = IPv6 address which is synthesized with a NSP used by NAT64-2, while H1 = receives an IPv6 address which is synthesized with a WKP used by NAT64-1. That's = to say, the authoritative DNS server for H2 will return an IPv6 address = which is synthesized with a NSP used by NAT64-2 to a DNS client which is an = IPv6 only host without NAT64 (e.g., H3), while returned a null to those DNS clients which is either an IPv6 only host with NAT64 (e.g., H1) or a dual-stack host. The latter DNS clients or their DNS64 will send a DNS = query for A record once the resolution for AAAA record fails.). Is the above statement in accordance with your assumption? If so, how = does the authoritative DNS server for H2 determine whether the DNS client = (e.g., H1, H3) is an IPv6 only host w/o NAT64 or an IPv6 only host but with = NAT64 (or even dual-stack host)?=20 Xiaohu From maxpassion@gmail.com Sun Dec 20 18:03:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97833A690A for ; Sun, 20 Dec 2009 18:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMRmFY3I-8+9 for ; Sun, 20 Dec 2009 18:03:38 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id CBB0B3A68FE for ; Sun, 20 Dec 2009 18:03:38 -0800 (PST) Received: by pxi42 with SMTP id 42so3301776pxi.5 for ; Sun, 20 Dec 2009 18:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cNUVHLCfuAWQCd604VT4nk1GawUFY48JDeZEW/+ISY0=; b=HEMOCItRTiJW1FkOE07LhpWG7Jeu49+juBlV/1cxwLhCDxQuOxYOYLgh/BZiGfjD86 I+F/lumFgj8AcPupk/+WFj+PBZ0SvRqUYa8v1qohVKDjVYrjcomWJfv8eq0WNKIzig0g i60rf5wHzhAgy4Ol8y7wy2W3ng5m1DnQuK2cU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YrzLGP6F13R/2pTN6DZa6cfg7bM/COQTKmfp0zjv3ExvDVTYmcQXypSDI2pPtKEoI+ annwNguMCfED+z1Yjpbiqqrh+TfPPWynULMRVtIBUFQTYqgddxnK8sa4SDSKATNrqtdk 8u3ARasLfrUio3FgL64pQLT0HWCQyRIsSCwJA= MIME-Version: 1.0 Received: by 10.142.9.32 with SMTP id 32mr4359124wfi.112.1261360999035; Sun, 20 Dec 2009 18:03:19 -0800 (PST) In-Reply-To: <4B2E5AC7.2010804@viagenie.ca> References: <4B290A5D.1040700@viagenie.ca> <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> <4B2E5AC7.2010804@viagenie.ca> Date: Mon, 21 Dec 2009 10:03:18 +0800 Message-ID: <25e1aaa40912201803h44d9fb67nb5cf3db35d5ff2bb@mail.gmail.com> From: liu dapeng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: Behave WG Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 02:03:40 -0000 2009/12/21, Simon Perreault : > On 12/19/2009 11:50 PM, liu dapeng wrote: >> I tried to query >> type=AAAA for ciscosales.webex.com using my laptop and using Wireshark >> to capture the packet then verify that it indeed returns a response >> which has the RCODE set to 2 (server failure). > > I'm pretty sure the authoritative name server returns REFUSED: > > $ dig @ns104-b.webex.com ciscosales.webex.com aaaa Hi Simon, Why ns104-b.webex.com return REFUSED but default server return SERVFAIL? > ; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>> @ns104-b.webex.com > ciscosales.webex.com aaaa > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17297 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;ciscosales.webex.com. IN AAAA > > ;; Query time: 42 msec > ;; SERVER: 64.68.104.8#53(64.68.104.8) > ;; WHEN: Sun Dec 20 12:10:08 2009 > ;; MSG SIZE rcvd: 38 > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > From marka@isc.org Sun Dec 20 18:56:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FF63A67F7 for ; Sun, 20 Dec 2009 18:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyi0xQmlWJ9o for ; Sun, 20 Dec 2009 18:56:44 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 62D523A635F for ; Sun, 20 Dec 2009 18:56:44 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 62214E601C; Mon, 21 Dec 2009 02:56:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBL2uMnc072891; Mon, 21 Dec 2009 13:56:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912210256.nBL2uMnc072891@drugs.dv.isc.org> To: liu dapeng From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca> <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> <4B2E5AC7.2010804@viagenie.ca> <25e1aaa40912201803h44d9fb67nb5cf3db35d5ff2bb@mail.gmail.com> In-reply-to: Your message of "Mon, 21 Dec 2009 10:03:18 +0800." <25e1aaa40912201803h44d9fb67nb5cf3db35d5ff2bb@mail.gmail.com> Date: Mon, 21 Dec 2009 13:56:22 +1100 Sender: marka@isc.org Cc: Behave WG Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 02:56:46 -0000 In message <25e1aaa40912201803h44d9fb67nb5cf3db35d5ff2bb@mail.gmail.com>, liu d apeng writes: > 2009/12/21, Simon Perreault : > > On 12/19/2009 11:50 PM, liu dapeng wrote: > >> I tried to query > >> type=AAAA for ciscosales.webex.com using my laptop and using Wireshark > >> to capture the packet then verify that it indeed returns a response > >> which has the RCODE set to 2 (server failure). > > > > I'm pretty sure the authoritative name server returns REFUSED: > > > > $ dig @ns104-b.webex.com ciscosales.webex.com aaaa > > Hi Simon, Why ns104-b.webex.com return REFUSED but default server > return SERVFAIL? Firstly why is anyone asking ns104-b.webex.com about ciscosales.webex.com? ns104-b.webex.com DOES NOT SERVE ciscosales.webex.com. It serves galaxyac.webex.com. ciscosales.webex.com is served by {ns01,ns03,ns05,ns06,ns07,ns08}.webex.com and is a CNAME to galaxyac.webex.com. ciscosales.webex.com. 600 IN CNAME galaxyac.webex.com. galaxyac.webex.com. 600 IN NS ns104-b.webex.com. galaxyac.webex.com. 600 IN NS sjc2-ns-gh-mip1.webex.com. "dig galaxyac.webex.com @ns104-b.webex.com aaaa" returns REFUSED which results in the local recursive server returning SERVFAIL after it has exhausted all the possible servers. > > ; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>> @ns104-b.webex.com > > ciscosales.webex.com aaaa > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17297 > > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; WARNING: recursion requested but not available > > > > ;; QUESTION SECTION: > > ;ciscosales.webex.com. IN AAAA > > > > ;; Query time: 42 msec > > ;; SERVER: 64.68.104.8#53(64.68.104.8) > > ;; WHEN: Sun Dec 20 12:10:08 2009 > > ;; MSG SIZE rcvd: 38 > > > > Simon > > -- > > DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > vCard 4.0 --> http://www.vcarddav.org > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Sun Dec 20 19:05:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39E73A697C for ; Sun, 20 Dec 2009 19:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-IDKVXnqKbI for ; Sun, 20 Dec 2009 19:05:40 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DF84E3A697B for ; Sun, 20 Dec 2009 19:05:39 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E3B1C20E20; Sun, 20 Dec 2009 22:05:23 -0500 (EST) Message-ID: <4B2EE5F3.1060901@viagenie.ca> Date: Sun, 20 Dec 2009 22:05:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews References: <4B290A5D.1040700@viagenie.ca> <25e1aaa40912192050k1fedc788icda4ef655f6460ea@mail.gmail.com> <4B2E5AC7.2010804@viagenie.ca> <25e1aaa40912201803h44d9fb67nb5cf3db35d5ff2bb@mail.gmail.com> <200912210256.nBL2uMnc072891@drugs.dv.isc.org> In-Reply-To: <200912210256.nBL2uMnc072891@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 03:05:41 -0000 On 12/20/2009 09:56 PM, Mark Andrews wrote: > Firstly why is anyone asking ns104-b.webex.com about ciscosales.webex.com? > ns104-b.webex.com DOES NOT SERVE ciscosales.webex.com. It serves > galaxyac.webex.com. > > ciscosales.webex.com is served by {ns01,ns03,ns05,ns06,ns07,ns08}.webex.com > and is a CNAME to galaxyac.webex.com. > > ciscosales.webex.com. 600 IN CNAME galaxyac.webex.com. > galaxyac.webex.com. 600 IN NS ns104-b.webex.com. > galaxyac.webex.com. 600 IN NS sjc2-ns-gh-mip1.webex.com. > > "dig galaxyac.webex.com @ns104-b.webex.com aaaa" returns REFUSED > which results in the local recursive server returning SERVFAIL after > it has exhausted all the possible servers. Yes, you're right of course. Sorry for the confusion, and thanks for the correction. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From caozhenpku@gmail.com Sun Dec 20 22:11:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2CA3A68EC for ; Sun, 20 Dec 2009 22:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YugHd57ZWKR4 for ; Sun, 20 Dec 2009 22:10:55 -0800 (PST) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E8FF53A697E for ; Sun, 20 Dec 2009 22:10:54 -0800 (PST) Received: by pxi9 with SMTP id 9so3522001pxi.32 for ; Sun, 20 Dec 2009 22:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8wY6O9nvLN57G52GTA/ishsU8HZUY1QxUzQap70ygx8=; b=vKxwOBJaTJpx3EtyjjOXzU2Rq0lmbco3eg6WQ/je/DcbSXIm3DIT2fxmht7i0Lmoy3 KGq6aByZtnzThyqqDUwKtovs70sRVBVZ1RHzlA0a4HVTGnNWxOQrT1I26uwgaAggtgwY xjbaVzKMZxVnoDx62kUoLlaMx5Nb958aR0cp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t+QimxuUbc5WcoTcs7DznMireGqAtEu+Or4AX6+eFkhl8uEx7yV2Q1pQ90B3T7O3fR cvH4DHIuJEJlXQKyfn3hl6mnG6/QtYKXbyJ5XAOKTeTOckGjk9UrqHOSWquLqvkqai9G AhJhpCA7/oMdky1R935ve3CQ0zcrWNvrgDtag= MIME-Version: 1.0 Received: by 10.142.249.24 with SMTP id w24mr2001829wfh.325.1261375836240; Sun, 20 Dec 2009 22:10:36 -0800 (PST) In-Reply-To: References: <4ADCD710.5070302@wichorus.com> Date: Mon, 21 Dec 2009 14:10:36 +0800 Message-ID: From: Zhen Cao To: Dave Thaler Content-Type: multipart/alternative; boundary=005045018098a5bdb6047b36f28b Cc: "Charles E. Perkins" , "behave@ietf.org" Subject: Re: [BEHAVE] SIPNAT documents posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 06:11:05 -0000 --005045018098a5bdb6047b36f28b Content-Type: text/plain; charset=ISO-8859-1 Hi all, I also have one comment. In the example of the draft, fooNS (name server for foo.net) needs to contact the NAT box to get an IPv4 address. But the fooNS may not know the address of the NAT box. There might be multiple NAT boxes, but only one name server for the foo.net. The name server does not know which NAT box to contact and get the address. Thanks, Zhen On Sat, Dec 12, 2009 at 10:48 AM, Dave Thaler wrote: > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Charles E. Perkins > > Sent: Monday, October 19, 2009 2:16 PM > > To: behave@ietf.org > > Subject: [BEHAVE] SIPNAT documents posted > > > > > > Hello folks, > > > > At 1:59:30pm Pacific Time today, I posted the following draft: > > "Payload-assisted Delivery for SIPNAT" > > http://www.ietf.org/internet-drafts/draft-perkins-behave-dpinat- > > 00.txt > > > > There is also a revision to the base SIPNAT document: > > "Translating IPv4 to IPv6 based on source IPv4 address" > > http://www.ietf.org/internet-drafts/draft-perkins-sourceipnat- > > 01.txt > > > > Comments are appreciated. Thanks to those who have helped > > me to improve these documents before submission. > > > > Regards, > > Charlie P. > > Two comments: > > 1) The documents do not address the problem whereby some recursive > resolvers (aka DNS servers) used by clients cache answers for > some time (like 30 seconds) even if the record TTL is less. > Multiple clients can get the same answer and only the first one > will work and the rest will break. > > 2) In the dpinat document, it discusses using the HTTP GET in the > NAT for demultiplexing. However, it can't get an HTTP GET until > after a TCP connection is established, which means it would need > to terminate the TCP connections itself and act more like an > HTTP proxy rather than a NAT. (Which is what is discussed in > http://tools.ietf.org/html/draft-wing-behave-http-46-relay) > > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --005045018098a5bdb6047b36f28b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,=A0

I also have one comment. In the exa= mple of the draft, fooNS (name server for foo.ne= t) needs to contact the NAT box to get an IPv4 address. But the fooNS m= ay not know the address of the NAT box. There might be multiple NAT boxes, = but only one name server for the foo.net. Th= e name server does not know which NAT box to contact and get the address.= =A0

Thanks,
Zhen
On Sat, Dec 12, 2009 at 10:48 AM, Dave Thaler = <dthaler@micr= osoft.com> wrote:
> -----Original Message-----
> From: beh= ave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Charles E. Perkins
> Sent: Monday, October 19, 2009 2:16 PM
> To: behave@ietf.o= rg
> Subject: [BEHAVE] SIPNAT documents posted
>
>
> Hello folks,
>
> At 1:59:30pm Pacific Time today, I posted the following draft:
> =A0 =A0 "Payload-assisted Delivery for SIPNAT"
> =A0 =A0 http://www.ietf.org/internet-drafts/draft-= perkins-behave-dpinat-
> 00.txt
>
> There is also a revision to the base SIPNAT document:
> =A0 =A0 "Translating IPv4 to IPv6 based on source IPv4 address&qu= ot;
> =A0 =A0 http://www.ietf.org/internet-drafts/draft-pe= rkins-sourceipnat-
> 01.txt
>
> Comments are appreciated. =A0Thanks to those who have helped
> me to improve these documents before submission.
>
> Regards,
> Charlie P.

Two comments:

1) The documents do not address the problem whereby some recursive
=A0 resolvers (aka DNS servers) used by clients cache answers for
=A0 some time (like 30 seconds) even if the record TTL is less.
=A0 Multiple clients can get the same answer and only the first one
=A0 will work and the rest will break.

2) In the dpinat document, it discusses using the HTTP GET in the
=A0 NAT for demultiplexing. =A0However, it can't get an HTTP GET until=
=A0 after a TCP connection is established, which means it would need
=A0 to terminate the TCP connections itself and act more like an
=A0 HTTP proxy rather than a NAT. =A0(Which is what is discussed in
=A0 http://tools.ietf.org/html/draft-wing-behave-http-46-rel= ay)

-Dave
_______________________________________________=
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--005045018098a5bdb6047b36f28b-- From phdgang@gmail.com Sun Dec 20 22:56:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791623A697E; Sun, 20 Dec 2009 22:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6br-nJVuHuXY; Sun, 20 Dec 2009 22:56:44 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 7A5D93A677C; Sun, 20 Dec 2009 22:56:44 -0800 (PST) Received: by iwn33 with SMTP id 33so3466870iwn.29 for ; Sun, 20 Dec 2009 22:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=K1jyeaEZ5o52hDaCgwb2/qyYcRxZzB5QIX4Cishz6Pc=; b=p4AhrxfNUcZx+wTYUYCvr48BG7qmmLK7FFoUS5gCMvpnUlp7clSamUYuYbKnEyFuDM ZVl411uZbywggLmkofxZn204VlSwoO/3iERLqnT5+aWRIxQyl0dMF+sx8nTy+OXTU7QM MSrHM4Mr7zOKrlfLzCh8vt8hytA5R2vGtAG9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K+fPRxcQOpTBb5Hek7Ukb5fflGZXT0yO6MDTCkyhbcKJ/+jZkqmkIi+rbH32F9wEnY +vPFc2RDUjF4M64FTUp4HIba0uSL57dRhaGjr88wWHT7twaIfneS9FOXZ3da/QWb0sBs sQvYmSTmnbyBy3KQzYIbScmgUjINDGqdRGSCI= MIME-Version: 1.0 Received: by 10.231.25.160 with SMTP id z32mr4319542ibb.5.1261378583869; Sun, 20 Dec 2009 22:56:23 -0800 (PST) In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 21 Dec 2009 14:56:23 +0800 Message-ID: <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> From: GangChen To: Christian Huitema Content-Type: multipart/alternative; boundary=00151774041c6b38f4047b3796bc Cc: "xing@cernet.edu.cn" , "eric.burgey@orange-ftgroup.com" , Behave WG , "ipv6@ietf.org" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 06:56:45 -0000 --00151774041c6b38f4047b3796bc Content-Type: text/plain; charset=ISO-8859-1 > > > > No. > > The "uniqueness" property is defined as "guaranteed to not collide with an > IEEE802 identifier." IPv4 addresses do not have that property. > > Besides, the WKP prefix (64:FF9B::/96) falls in the ::/8 range reserved for > the IETF, the only range in which the U/G requirements do not apply. > Thanks for the clarification. If WKP(64:FF9B::/96) is the consensus, it better to state clearly that WKP should not apply U/G requirements in the draft, right? Especially, in the section 2 "When using a /96 prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero." How about this: "When using a /96 prefix, except the WKP that start with the binary value 000, the administrators MUST ensure that the bits 64 to 71 are set to zero." It's more clear. BRs Gang --00151774041c6b38f4047b3796bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=A0
No.

The "uniqueness" proper= ty is defined as "guaranteed to not collide with an IEEE802 identifier= ." IPv4 addresses do not have that property.

Besides, the WKP p= refix (64:FF9B::/96) falls in the ::/8 range reserved for the IETF, the onl= y range in which the U/G requirements do not apply.=
=A0
Thanks for the clarification.
=A0
If WKP(64:FF9B::/96) is the consensus, it better to state clearly that= WKP should not apply U/G requirements in the draft, right?
=A0
Especially, in the section 2 "When using a /96 prefix, the admini= strators MUST ensure that the bits 64 to 71 are set to zero."
=A0
How about this:=A0 "When using a /96 prefix, except the WKP that = start with the binary
=A0=A0 value 000, the administrators MUST ensure t= hat the bits 64 to 71 are set to zero."
=A0
It's more clear.
=A0
BRs
=A0
Gang
=A0
=A0
=A0

--00151774041c6b38f4047b3796bc-- From Xiangsong.Cui@huawei.com Sun Dec 20 23:36:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EF23A6908 for ; Sun, 20 Dec 2009 23:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMySXJLpV0UX for ; Sun, 20 Dec 2009 23:36:52 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 38ACA3A6923 for ; Sun, 20 Dec 2009 23:36:52 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ005YHRSQ8K@szxga03-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 15:36:26 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ0038RRSPV3@szxga03-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 15:36:25 +0800 (CST) Date: Mon, 21 Dec 2009 15:36:25 +0800 From: Xiangsong Cui To: Dan Wing , behave@ietf.org Message-id: <014201ca8210$4d15ea90$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <048501ca7fb6$536824f0$c4f0200a@cisco.com> Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] comments on draft-dns64-05 // Re: WGLC for translation documents (6 documents) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 07:36:53 -0000 Dear chairs and all, I have read the draft ietf-behave-dns64-05, I have some comments. Technical comments: section 5.2, the second paragraph, The same algorithm to create an IPv6 address from an IPv4 address MUST be used by both the DNS64 to create the IPv6 address to be returned in the synthetic AAAA RR from the IPv4 address contained in original A RR, and by the IPv6/IPv4 translator to create the IPv6 address to be included in the destination address field of ^^^^^^^^^^^^^^ the outgoing IPv6 packets from the IPv4 address included in the destination address field of the incoming IPv4 packet. in my understanding, the *destination address* with remark should be *source address*, is that right? Some typos comments, section 2, The main different in the nature of the two types of prefixes is that =>The main difference in the nature of the two types of prefixes is that Section 5.2 of IPv4 addresses defined Section 2 of => of IPv4 addresses defined in Section 2 of whole document, a AAAA => an AAAA Others are OK, thanks the authors for the good job! Regards Xiangsong ----- Original Message ----- From: "Dan Wing" To: Cc: Sent: Friday, December 18, 2009 3:47 PM Subject: [BEHAVE] WGLC for translation documents (6 documents) > We appear ready to start the working group last call for our set of IPv6/IPv4 > translation documents. This is a two-week WGLC. > > We need 5 reviewers to say a document is ready before we will forward the > documents to the IESG. A few people have already volunteered, but we need > more! Please see http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart. > If you are already reading the document, this is easy -- just email the chairs > after your review. > > The documents starting WGLC are: > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-04 > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-07 > http://tools.ietf.org/html/draft-ietf-behave-dns64-05 > http://tools.ietf.org/html/draft-ietf-behave-address-format-03 > http://tools.ietf.org/html/draft-ietf-behave-ftp64-00 > > This is a two week WGLC finishing on December 31. Please send substantive > review comments to behave@ietf.org and (if possible) send editorial comments > only to the authors at DRAFTNAME@tools.ietf.org. > > Thanks, > -Dan and Dave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From remi.despres@free.fr Mon Dec 21 01:19:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861903A6989; Mon, 21 Dec 2009 01:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP6CWEBkPu9N; Mon, 21 Dec 2009 01:19:40 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A87043A63EC; Mon, 21 Dec 2009 01:19:38 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 246D1E080B9; Mon, 21 Dec 2009 10:19:17 +0100 (CET) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E874AE0811B; Mon, 21 Dec 2009 10:19:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20091217153003.BE0EE3A6A5D@core3.amsl.com> Date: Mon, 21 Dec 2009 10:19:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50D350FD-90BE-440F-B89B-36C6F1EACF52@free.fr> References: <20091217153003.BE0EE3A6A5D@core3.amsl.com> To: Christian Huitema X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org, i-d-announce@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 09:19:42 -0000 Christian, The suggestion I made on Dec. 11 (see below) as taken care of in draft = 02, but is no longer in draft 03. It still holds. Regards, RD=20 Le 17 d=E9c. 2009 =E0 16:30, Internet-Drafts@ietf.org a =E9crit : > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. >=20 >=20 > Title : IPv6 Addressing of IPv4/IPv6 Translators > Author(s) : C. Huitema, et al. > Filename : draft-ietf-behave-address-format-03.txt > Pages : 17 > Date : 2009-12-17 >=20 Le 11 d=E9c. 2009 =E0 15:01, R=E9mi Despr=E9s a =E9crit : > Christian, >=20 > Just a minor suggestion at the top of page 5: after "host identifier = format defined in the IPv6 addressing architecture", add "of [RFC = 4291]". >=20 > Thus, if the 'u' octet constraint is eventually relaxed, no update of = your text will be needed. From Xiangsong.Cui@huawei.com Mon Dec 21 01:42:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0293A6932 for ; Mon, 21 Dec 2009 01:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbY8YFAJ6vij for ; Mon, 21 Dec 2009 01:42:08 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 399813A68F7 for ; Mon, 21 Dec 2009 01:42:08 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ00B2AXLH6S@szxga04-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 17:41:41 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ008OVXLGP3@szxga04-in.huawei.com> for behave@ietf.org; Mon, 21 Dec 2009 17:41:41 +0800 (CST) Date: Mon, 21 Dec 2009 17:41:41 +0800 From: Xiangsong Cui To: Dan Wing , behave@ietf.org Message-id: <01d501ca8221$ccf04330$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <048501ca7fb6$536824f0$c4f0200a@cisco.com> Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] Comments on draft-v6v4-xlate-stateful-07 // Re: WGLC for translation documents (6 documents) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 09:42:09 -0000 Dear chairs and all, I have read the draft behave-v6v4-xlate-stateful-07, and I have some comments. Technical comments, (similar to DNS64 draft) section 3.2.4 The NAT64 to create the IPv6 address to be included in the destination address field of the outgoing IPv6 packets from the ^^^^^^^^ IPv4 address included in the destination address field of the ^^^^^^^^ incoming IPv4 packet. => The NAT64 to create the IPv6 address to be included in the source address field of the outgoing IPv6 packets from the IPv4 address included in the source address field of the incoming IPv4 packet. right? Editorial comments: page 6, two interfaces, an IPv4 interface connected to the the IPv4 network, => two interfaces, an IPv4 interface connected to the IPv4 network, page 14, result of the flow of packets as described in the Section 3.2 but the => result of the flow of packets as described in the Section 3.2 but they page 15, (1st) For each Session Table Entry (STE), there are then five columns: => For each TCP or UDP Session Table Entry (STE), there are then five columns: (2nd) For each Session Table Entry (STE), there are then six columns: => For each ICMP Query Session Table Entry (STE), there are then six columns: a incoming => an incoming, a ICMP => an ICMP Others are OK, thanks the authors for the good job. Regards Xiangsong ----- Original Message ----- From: "Dan Wing" To: Cc: Sent: Friday, December 18, 2009 3:47 PM Subject: [BEHAVE] WGLC for translation documents (6 documents) > We appear ready to start the working group last call for our set of IPv6/IPv4 > translation documents. This is a two-week WGLC. > > We need 5 reviewers to say a document is ready before we will forward the > documents to the IESG. A few people have already volunteered, but we need > more! Please see http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart. > If you are already reading the document, this is easy -- just email the chairs > after your review. > > The documents starting WGLC are: > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-04 > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-07 > http://tools.ietf.org/html/draft-ietf-behave-dns64-05 > http://tools.ietf.org/html/draft-ietf-behave-address-format-03 > http://tools.ietf.org/html/draft-ietf-behave-ftp64-00 > > This is a two week WGLC finishing on December 31. Please send substantive > review comments to behave@ietf.org and (if possible) send editorial comments > only to the authors at DRAFTNAME@tools.ietf.org. > > Thanks, > -Dan and Dave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Mon Dec 21 05:02:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B069B3A695F for ; Mon, 21 Dec 2009 05:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITrXqAFQL0EK for ; Mon, 21 Dec 2009 05:02:26 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 59D803A6948 for ; Mon, 21 Dec 2009 05:02:25 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBLD1L3a021889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Dec 2009 14:01:22 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 14:01:42 +0100 Message-Id: <73EC726F-8407-4BD1-94A0-112886D4696F@muada.com> To: Behave WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [BEHAVE] Review: draft-ietf-behave-v6v4-framework-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 13:02:27 -0000 This is my review of draft-ietf-behave-v6v4-framework-04. The document is too wordy. It needs to be edited for length. = Alternatively, it could be merged with an applicability statement. Specific remarks: One could - and in the 6NET we did - build an overlay network using the new protocol inside tunnels. These are not equivalent. A tunnel can't make an IPv4 host talk to an = IPv6 host. They are also not opposites, as with tunneling there will still be = translation in the form of IPv4 NAT because the whole point of the = exercise is the lack of sufficient IPv4 addresses. Also, not sure the "as we did" aside is appropriate in this document. Dual-Stack implementation: A Dual-Stack implementation, in this context, comprises an IPv4/IPv6 enabled end system stack, applications plus routing in the network. It implies that two application instances are capable of communicating using either IPv4 or IPv6 - they have stacks, they have addresses, and they have any necessary network support including routing. I don't think this is good terminology, as "implementation" could also = apply to soft- or hardware that is capabable of both protocols, but only = one is actually provisioned. Note that "dual stack implementation" = doesn't occur anywhere else in the document, anyway. About the -converted and -translatable addresses: I would prefer = "translator IPv4 address(es)" etc, this is more obvious. Again, "IPv4-converted" and "IPv4-translatable addresses" don't occur = outside the terminology section, and neither do "Network-Specific = Prefix" or "Well-Known Prefix". Defining terminology that remains unused = is a waste of the reader's time. "Stateful translation": I think this needs to mention that multiple IPv6 = hosts share a single IPv4 address, otherwise the level of abstraction is = extremely high. applications with - any other system running the same application This is strange. Does my web browser talk to other web browsers? Client/Server Application: Per whatis.com Could be clearer that this is a quotation. (Remember, not everyone has = English as a first, second or third language.) program, the server, which fulfills the request." In networking, the behavior of the applications the =3D these? Better: client-server applications Examples include mail handling between an end user and his mail system (POP3, IMAP, and MUA->MTA SMTP), FTP FTP doesn't belong in this list because of the active mode. Peer-to-Peer (P2P) Application: A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts The term "peering host" is strange. What about "correspondent host"? Peer-to-peer infrastructure applications: When people use "peer-to-peer" they are NOT talking about this kind of = stuff, doing so here only confuses the issue and wastes space. of peers from history or by reputation. They use the long-term sessions to map content availability. Short-term sessions are used to exchange content. Untrue, BitTorrent uses very short connections to the tracker, there is = no ongoing long term connection. Again, unnecessary, potentially = confusing detail that only takes up space. A distinction that may be more useful (but probably too detailed here) = is whether a peer must be able to connect to any given peer for the = application to work (like in VoIP) or the ability of each peer to talk = to a subset of all peers as long as there are some peers that can talk = to all other peers (like BitTorrent) is sufficient. o We need a technology that will enable systems that act as clients to be able to open sessions with other systems that act as servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. We do? As long as all the servers are on the IPv4 side we don't need the = IPv4->IPv6 direction. o We also need a technology that will allow peers to connect with each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Again, it would be ideal if this was stateless, but a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed. o In many situations, hosts are purely clients. In those situations, we do not need an algorithm to enable connections to those hosts Huh? Which is it? I think the second needs to be removed, we can't be in the business of = giving people excuses to provide one-way connectivity. It's not the = translator's place to determine whether a host needs incoming = connectivity or not. This bears a striking resemblance to this scenario as well Be more explicit. 2.2. Scenario 2: the IPv4 Internet to an IPv6 network This scenario is predicted to become increasingly important as the network administrators are under pressure to put IPv6-only servers in its network There is a big difference between the general interconnection of a full = IPv6 network and making available only a limited set of servers. The = latter can be done with some static mappings, the former requires much = more elaborate mechanisms. So this needs to be split into two different = cases. 2.3. Scenario 3: the IPv6 Internet to an IPv4 network [...] The stateless translation will not work for this scenario, because an IPv4 network needs to communicate with all of the IPv6 Internet, not just a small subset, and stateless can only support a small subset. Incorrect. We are talking about the IPv6->IPv4 direction here, which can = easily be done with stateless translation. The IPv4->IPv6 direction is = the problem, this is scenario 4. 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet [...] Due to the huge difference in size between the address spaces of the IPv4 Internet and the IPv6 Internet, there is no viable translation technique to handle unlimited IPv6 address translation. Again, that's part of a different scenario. But the authors knew that, because they repeat the same text there: 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet [...] Due to the huge difference in size between the address spaces of the IPv4 Internet and the IPv6 Internet, there is no viable translation technique to handle unlimited IPv6 address translation. Repeating the same text is bad writing in general, and even worse here = because the text doesn't apply in 2.7 but only in 2.8. I'm missing a discussion on how the scenarios can be combined. For = instance, people will likely want to combine 1 and 5 but without = specifically addressing that situation that could be hard. 3. Framework Having laid Pointing back to what was said earlier in the same document adds no = value but increases size, don't do it. [I-D.ietf-behave-dns64] and possible future documents describes describe mechanisms by which a DNS translator is intended to operate. It is designed to operate on the basis of known but fixed state: No, the DNS64 doesn't maintain any state, unless that includes the = translation prefix, but that isn't state, but rather, configuration. = I.e., a DNS64 can reboot in the middle of a user session and apart from = the delays while the DNS64 is down there is no interruption of service. There are at least two possible implementations of a DNS64 and DNS46: Static records: No, if the records are static we're talking about a regular DNS. A DNS64 = adds extra functionality on top of a regular DNS implementation that = makes static records unnecessary. Dynamic Translation of static records I would reserve that term for DNS46 where the records are mapped = dynamically based on the availability of addresses in a pool. I would = use "algorithmic translation" (no capital T) for DNS64. In addition, some applications require special support. An example is FTP. FTP's active mode doesn't work well across NATs=20 at all Across NATs, it generally uses passive mode. FTP clients generally use passive mode May want to add some references. However, the designers of FTP inexplicably wrote different and incompatible passive mode implementations for IPv4 and IPv6 networks. ??? The original passive mode is incompatible with IPv6 because RFC 959 = (which wasn't the first FTP spec, btw) predates RFC 1883 (the first IPv6 = spec) by a decade. EPSV is compatible with both IPv4 and IPv6 (because it only mentions a = port number) but (obviously) not with implementations that stick to RFC = 959 and don't implement RFC 2428. As a general rule, a simple operational recommendation will work around many application issues, which is that there should be a server in each domain Domain =3D IP version? Unclear. Stateless translation can be used for Scenarios 1, 2, 5 and 6 Only if there are sufficient IPv4 addresses, in which case it would be = possible to run dual stack, too. Needs to be pointed out. For Scenario 1, any IPv6 addresses in an IPv6 network can use stateful translation, however it typically only supports initiation from the IPv6 side (NAT64 doesn't support IPv4-initiation), and does not result in stable addresses that can be used in DNS, other protocols and applications that do not deal well with highly dynamic addresses. There is no reason that the IPv4 address involved in stateful scenario 1 = translation are very dynamic. If they are, ICE will not work very well. The FTP ALG and other documents refer to the Address Format, IP/ICMP Translation and Table Maintenance documents. Actually, the FTP64 document only points to RFC 2765, xlate and = xlate-stateful. The address format is not relevant to the FTP ALG. Currently, there are two proposed solutions for this scenario: NAT64 [I-D.bagnulo-behave-nat64] as the stateful translation and IVI [I-D.xli-behave-ivi] What about I-D.ietf-behave-v6v4-xlate? From ajs@shinkuro.com Mon Dec 21 07:20:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1293A657C for ; Mon, 21 Dec 2009 07:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLNWFAMPHIKD for ; Mon, 21 Dec 2009 07:20:54 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E873E3A6A22 for ; Mon, 21 Dec 2009 07:20:53 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F17302FE8CE8 for ; Mon, 21 Dec 2009 15:20:36 +0000 (UTC) Date: Mon, 21 Dec 2009 10:20:32 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091221152031.GA59143@shinkuro.com> References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E99E0.5090700@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:20:55 -0000 On Sun, Dec 20, 2009 at 04:40:48PM -0500, Simon Perreault wrote: > On 12/20/2009 02:21 PM, Andrew Sullivan wrote: >> No, it definitely will break if it's behind a plain resolver. We had >> that discussion in Stockholm. If this isn't clear in the draft, please >> let me know. > > Are you referring to section 6.1? Yes, sorry for being both inaccurate and too brief. (This'll teach me to answer mailing lists from an iphone while stuck by a snowstorm and even more addle-brained than usual. One hopes this is not a lesson one needs again :-) > I understand from that section that a mixed-mode iterative and > forwarding DNS resolver cannot work as intended when using a DNS64 as a > forwarder. I fail to see how this is relevant to the case where a DNS64 > is forwarding to a plain resolver. To be more clear, I believe that a forwarding, not-iterative mode resolver could do DNS64 for a stub resolver; that is, it must be a pure forwarded and never cache anything. > (Side remark: I do find the section confusing because it is clear to me > that *any* direct querying of authoritative name servers by IPv6-only > hosts, thus bypassing the DNS64, cannot work, and am left wondering why > this section is only talking about the special case of "(mis)configured > [...] mixed-mode iterative and forwarding resolvers".) The reason we're calling it out explicitly is because we know there are deployed today mixed-mode forwarders. (I know this, for instance, because there's one sitting on my desk.) Many of the little wireless routers people use have a forwarder in them that, to "help", do some caching. Often this can be defeated, but that's how they ship. > Are you also referring to the discussion in this thread? The thread you corrected it to, yes. Sorry for being unclear about this. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From huitema@microsoft.com Mon Dec 21 07:24:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BB13A6969; Mon, 21 Dec 2009 07:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO5dymkT7LA8; Mon, 21 Dec 2009 07:24:55 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 888803A69DF; Mon, 21 Dec 2009 07:24:55 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 21 Dec 2009 07:25:11 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 21 Dec 2009 07:24:39 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 21 Dec 2009 07:24:40 -0800 From: Christian Huitema To: GangChen Thread-Topic: [BEHAVE] address-format: bits 64 to 71 Thread-Index: AQHKgXhil3dOuVhfwUyFpimr48Sle5FuJ6mQgAFw7ICAAAbFsA== Date: Mon, 21 Dec 2009 15:24:34 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211FFC28@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> In-Reply-To: <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xing@cernet.edu.cn" , "eric.burgey@orange-ftgroup.com" , Behave WG , "ipv6@ietf.org" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:24:56 -0000 > If WKP(64:FF9B::/96) is the consensus, it better to state clearly that WK= P should not apply U/G requirements in the=20 > draft, right? The U/G bits in 64:FF9B::/96 are set to zero, so there is no need for an ex= ception. > How about this:=A0 "When using a /96 prefix, except the WKP that start wi= th the binary > value 000, the administrators MUST ensure that the bits 64 to 71 are set = to zero." =A0 Except this requirement applies to "administrators", who cannot legitimatel= y obtain a prefix in ::/8. These prefixes can only be defined by IETF actio= n. -- Christian Huitema From ajs@shinkuro.com Mon Dec 21 07:26:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A353A6969 for ; Mon, 21 Dec 2009 07:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5MmirmNPvEX for ; Mon, 21 Dec 2009 07:26:07 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D92463A657C for ; Mon, 21 Dec 2009 07:26:06 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 245592FE8CE8 for ; Mon, 21 Dec 2009 15:25:50 +0000 (UTC) Date: Mon, 21 Dec 2009 10:25:48 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091221152547.GB59143@shinkuro.com> References: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <019301ca7f3f$e5de0380$c4f0200a@cisco.com> <20091218033348.GB47068@shinkuro.com> <25e1aaa40912192256h64f80b3freb382fe522135e64@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25e1aaa40912192256h64f80b3freb382fe522135e64@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:26:08 -0000 On Sun, Dec 20, 2009 at 02:56:29PM +0800, liu dapeng wrote: > > It is important to note that, as of this writing, some servers > > respond with RCODE=3 to a AAAA query even if there is an A record > > available for that owner name. Those servers are in clear > > violation of the meaning of RCODE 3, and it is expected that they > > will decline in use as IPv6 deployment increases. > this means in the early stage of IPv6 depleoyment, many site can not > access using DNS64+NAT64, I am not sure whether it is a good > approach... Two things: 1. Because I was in a hurry last week, I didn't double-check the results that Dan posted. Simon since has, and it appears that there were few, if any, actual RCODE=3 responses for AAAA when the RNAME had an A record. So I think the text you quoted should be removed from the draft. I'm quite sure I've seen cases of Name Error for a AAAA that was outside the RFCs (because I will confidently predict that, if it is possible to mess up the implementation of DNS in any way, someone has in fact done it). But I don't think this is a widely deployed problem, and I was mildly surprised by the extent of Dan's report. 2. If there are in fact such deployed servers today, they are frankly already so broken that it's a wonder they work at all. I have no hesitation in saying that they're irredeemable and need to be fixed, even if that causes DNS64 to work slightly less well than we'd prefer. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon.perreault@viagenie.ca Mon Dec 21 07:58:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E263A67D9 for ; Mon, 21 Dec 2009 07:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbPfu27nCgdu for ; Mon, 21 Dec 2009 07:58:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DA3DB3A67F6 for ; Mon, 21 Dec 2009 07:57:59 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 9C85F210F9 for ; Mon, 21 Dec 2009 10:57:43 -0500 (EST) Message-ID: <4B2F9AF7.3020504@viagenie.ca> Date: Mon, 21 Dec 2009 10:57:43 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> In-Reply-To: <20091221152031.GA59143@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:58:01 -0000 Andrew Sullivan wrote, on 2009-12-21 10:20: > To be more clear, I believe that a forwarding, not-iterative mode > resolver could do DNS64 for a stub resolver; that is, it must be a > pure forwarded and never cache anything. What does caching have to do with it? The records given by a DNS64 (synthetic or not) are cacheable. If they were not, we would be in big trouble. > The reason we're calling it out explicitly is because we know there > are deployed today mixed-mode forwarders. (I know this, for instance, > because there's one sitting on my desk.) Many of the little wireless > routers people use have a forwarder in them that, to "help", do some > caching. Often this can be defeated, but that's how they ship. I understand. Might I suggest some improvements to make this section clearer? Here's an attempt. I added normative text to make clear what the operational recommendation is. "Any DNS query originated from the network serviced by the DNS64 and destined to a server upstream of the DNS64 is problematic. This can happen when a DNS resolver including iterative functionality, whether it be fully iterative or mixed-mode iterative/forwarding, tries to contact authoritative name servers directly, without forwarding to the DNS64. This will create a discrepancy between the answers given by that server and those given by the DNS64. As a result, all queries originated from the network serviced by the DNS64 SHOULD be forwarded to the DNS64." But the initial use case we were talking about, and which you affirmed doesn't work, was that of a DNS64 operating strictly in forwarding mode, synthesizing records when the upstream resolver doesn't return data for AAAA. I would really like to read your expanded thoughts on this, as this is exactly how one of my implementations operates. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Mon Dec 21 08:09:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA0428C0F7 for ; Mon, 21 Dec 2009 08:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z7AEpCu6CMJ for ; Mon, 21 Dec 2009 08:09:44 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 0614A3A6A25 for ; Mon, 21 Dec 2009 08:09:44 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 70B6A2FE8CE8 for ; Mon, 21 Dec 2009 16:09:26 +0000 (UTC) Date: Mon, 21 Dec 2009 11:09:24 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091221160924.GE59143@shinkuro.com> References: <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2F9AF7.3020504@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:09:44 -0000 On Mon, Dec 21, 2009 at 10:57:43AM -0500, Simon Perreault wrote: > Andrew Sullivan wrote, on 2009-12-21 10:20: > > To be more clear, I believe that a forwarding, not-iterative mode > > resolver could do DNS64 for a stub resolver; that is, it must be a > > pure forwarded and never cache anything. > > What does caching have to do with it? The records given by a DNS64 (synthetic or > not) are cacheable. If they were not, we would be in big trouble. Well, strictly you're right in that the records from the answer section ought to be cachable. The problem is that the records in the additional section also get cached, and they're the thing that'll cause us pain if they get promoted or anything like that. People shouldn't do that, but they do. > I understand. Might I suggest some improvements to make this section clearer? > Here's an attempt. I added normative text to make clear what the operational > recommendation is. > > "Any DNS query originated from the network serviced by the DNS64 and destined to > a server upstream of the DNS64 is problematic. This can happen when a DNS > resolver including iterative functionality, whether it be fully iterative or > mixed-mode iterative/forwarding, tries to contact authoritative name servers > directly, without forwarding to the DNS64. This will create a discrepancy > between the answers given by that server and those given by the DNS64. As a > result, all queries originated from the network serviced by the DNS64 SHOULD be > forwarded to the DNS64." Very helpful. Thanks. > But the initial use case we were talking about, and which you affirmed doesn't > work, was that of a DNS64 operating strictly in forwarding mode, synthesizing > records when the upstream resolver doesn't return data for AAAA. I would really > like to read your expanded thoughts on this, as this is exactly how one of my > implementations operates. No, no, that was what I was trying to correct in my last message. I was simply wrong in what I said (though not what I meant, but you couldn't tell that from what I wrote!). A DNS64 in the mode you describe above _better_ work, or the entire program is doomed. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From phdgang@gmail.com Mon Dec 21 08:37:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8477928C0F9; Mon, 21 Dec 2009 08:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZpMuBbPUJR4; Mon, 21 Dec 2009 08:37:02 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 90E403A67F6; Mon, 21 Dec 2009 08:37:02 -0800 (PST) Received: by iwn33 with SMTP id 33so3746018iwn.29 for ; Mon, 21 Dec 2009 08:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Llzv6S4wj6an3qDtT8nUdMoXEoIR/YbMIZD0DkdfMWM=; b=bTQFvs5CuAHDySSnR+JpmGryZvvFmZ1z62t+8ysLWX6yKBsd3fn9VqpJWgCWpnxFSz Stk72aACIK4Z709gWwlXhmdR6MxqWSqjfDUPAWu+j+yPvES8XCPyMRO1inkzyfxzgEh/ FKGNdxYUjyWlWYViHbRhRoNQmSJ1UPQXage+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GZwvZS6w5ViaM+43EIietD3nd1fa6fHLokwPpuhVmApqXYs/R7Q7e6I4C1ZXSVb/uL rgI+DO88xs8f8nFyRjauKro/Xox8oHbwOOFK18dlqajeZv+9KIK8Ji2QD01DYQKfRTTP DwIeulidpe455+kKbc9PRBUjkUOzmDNkMDOTA= MIME-Version: 1.0 Received: by 10.231.9.33 with SMTP id j33mr981734ibj.37.1261413403669; Mon, 21 Dec 2009 08:36:43 -0800 (PST) In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211FFC28@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FFC28@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 22 Dec 2009 00:36:43 +0800 Message-ID: <36ba02b00912210836r593f9520td2a2f21e9b0a947a@mail.gmail.com> From: GangChen To: Christian Huitema Content-Type: multipart/alternative; boundary=00151774155ad73695047b3fb1b9 Cc: "xing@cernet.edu.cn" , "eric.burgey@orange-ftgroup.com" , Behave WG , "ipv6@ietf.org" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:37:03 -0000 --00151774155ad73695047b3fb1b9 Content-Type: text/plain; charset=ISO-8859-1 2009/12/21 Christian Huitema > > If WKP(64:FF9B::/96) is the consensus, it better to state clearly that > WKP should not apply U/G requirements in the > > draft, right? > > The U/G bits in 64:FF9B::/96 are set to zero, so there is no need for an > exception. > This is not an exception. This is a right way to compatible with RFC4291. There are no restrains to set U/G bits in 64:FF9B::/96 to zero. We even could set U/G bit to 1, as long as WKP maintains checksum neutral. > > > How about this: "When using a /96 prefix, except the WKP that start with > the binary > > value 000, the administrators MUST ensure that the bits 64 to 71 are set > to zero." > > Except this requirement applies to "administrators", who cannot > legitimately obtain a prefix in ::/8. These prefixes can only be defined by > IETF action. > Does this requirement only apply to the NSP that administrators can legitimately obtain ? --Gang > > > --00151774155ad73695047b3fb1b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/12/21 Christian Huitema &= lt;huitema@microsoft.com>
> If WKP(64:FF9B::/96) is the consensus, it better to = state clearly that WKP should not apply U/G requirements in the
> dra= ft, right?

The U/G bits in 64:FF9B::/96 are set to zero, so th= ere is no need for an exception.
=A0
This is not an exception. This is a right way to compatible with RFC42= 91. There=A0are no restrains to set U/G bits in 64:FF9B::/96=A0to zero.=A0W= e even could set U/G bit to 1, as long as WKP maintains checksum neutral.
=A0

> How about this:=A0 "When using a /96 prefix= , except the WKP that start with the binary
> value 000, the administ= rators MUST ensure that the bits 64 to 71 are set to zero."
=A0
=
Except this requirement applies to "administrators", who cannot l= egitimately obtain a prefix in ::/8. These prefixes can only be defined by = IETF action.
=A0
Does=A0this requirement only apply=A0to the NSP that administrators ca= n legitimately obtain
?=A0
=A0
--Gang


= =A0

--00151774155ad73695047b3fb1b9-- From simon.perreault@viagenie.ca Mon Dec 21 08:37:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0EE28C13E for ; Mon, 21 Dec 2009 08:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57BSxmNPhXid for ; Mon, 21 Dec 2009 08:37:57 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 47EA93A67F6 for ; Mon, 21 Dec 2009 08:37:53 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 2026421105 for ; Mon, 21 Dec 2009 11:37:37 -0500 (EST) Message-ID: <4B2FA450.2060301@viagenie.ca> Date: Mon, 21 Dec 2009 11:37:36 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> In-Reply-To: <20091221160924.GE59143@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:37:58 -0000 Andrew Sullivan wrote, on 2009-12-21 11:09: > The problem is that the records in the > additional section also get cached, and they're the thing that'll > cause us pain if they get promoted or anything like that. People > shouldn't do that, but they do. Can you expand on this? Is this specific to DNS64 or applies to DNS in general? Is it already in the text? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From huitema@microsoft.com Mon Dec 21 09:55:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2526B3A6A80 for ; Mon, 21 Dec 2009 09:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4MF1rErAWz4 for ; Mon, 21 Dec 2009 09:55:50 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7C04E3A68AA for ; Mon, 21 Dec 2009 09:55:50 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 21 Dec 2009 09:56:06 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 21 Dec 2009 09:55:34 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 21 Dec 2009 09:55:33 -0800 From: Christian Huitema To: GangChen Thread-Topic: [BEHAVE] address-format: bits 64 to 71 Thread-Index: AQHKgXhil3dOuVhfwUyFpimr48Sle5FuJ6mQgAFw7ICAAAbFsIAAm2CA//+PPDA= Date: Mon, 21 Dec 2009 17:55:32 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211FFD54@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FFC28@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912210836r593f9520td2a2f21e9b0a947a@mail.gmail.com> In-Reply-To: <36ba02b00912210836r593f9520td2a2f21e9b0a947a@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG , "eric.burgey@orange-ftgroup.com" , "xing@cernet.edu.cn" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 17:55:51 -0000 >>> How about this:=A0 "When using a /96 prefix, except the WKP that start = with the binary >>> value 000, the administrators MUST ensure that the bits 64 to 71 are se= t to zero." >>=A0 >> Except this requirement applies to "administrators", who cannot legitima= tely obtain a prefix=20 >> in ::/8. These prefixes can only be defined by IETF action. >=A0 > Does=A0this requirement only apply=A0to the NSP that administrators can l= egitimately obtain?=A0 By opposition to administrator who decide to ignore IETF recommendations an= d do their own thing? I don't think RFC need to cater to those. Do you? -- Christian Huitema =A0 From dwing@cisco.com Mon Dec 21 10:09:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896893A6A8A for ; Mon, 21 Dec 2009 10:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsgySeJ00EPZ for ; Mon, 21 Dec 2009 10:09:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 751CE3A68E7 for ; Mon, 21 Dec 2009 10:09:29 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAANJL0urR7Hu/2dsb2JhbACIXoEWklmkdZVGhC4EgWU X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="454043193" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 Dec 2009 18:09:13 +0000 Received: from dwingwxp01 (sjc-vpn4-1295.cisco.com [10.21.85.14]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBLI9DLl023505; Mon, 21 Dec 2009 18:09:13 GMT From: "Dan Wing" To: "'liu dapeng'" References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912192126w212ec4b0u4d5ded3c544821e8@mail.gmail.com> Date: Mon, 21 Dec 2009 10:09:16 -0800 Message-ID: <0a5001ca8268$b5a57690$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40912192126w212ec4b0u4d5ded3c544821e8@mail.gmail.com> Thread-Index: AcqBNQpT5zIF94wHS5ip+tQMIp6UNABMk0Dw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:09:30 -0000 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com] > Sent: Saturday, December 19, 2009 9:27 PM > To: Dan Wing > Cc: Iljitsch van Beijnum; Andrew Sullivan; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > Hi Dan, > > I query AAAA for www.ecshop.com could success, the RCODE is 0 (no > error). And the response is a CNAME. I am wondering why your > experiment result is NXDOMAIN, what caused this unconsistency (other > results are the same)? I use nslookup for query and set the query type > to AAAA. I am seeing NXDOMAIN, when querying the remote nameservers directly, for both A and AAAA queries. Both A and AAAA responses give me a CNAME. Summary, AAAA query showing NXDOMAIN responses (detail is below): > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com | grep status dig @ns.xinnetdns.com. aaaa www.ecshop.com ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45448 dig @ns.xinnet.cn. aaaa www.ecshop.com ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62146 Summary, A query showing NXDOMAIN responses (detail is below): > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com | grep status dig @ns.xinnet.cn. a www.ecshop.com ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27991 dig @ns.xinnetdns.com. a www.ecshop.com ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53739 -d ----- > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com dig @ns.xinnet.cn. aaaa www.ecshop.com ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. aaaa www.ecshop.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11752 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ecshop.com. IN AAAA ;; ANSWER SECTION: www.ecshop.com. 120 IN CNAME n100.shopex.cn. ;; AUTHORITY SECTION: shopex.cn. 3600 IN SOA ns.xinnetdns.com. hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 ;; Query time: 231 msec ;; SERVER: 202.10.73.9#53(202.10.73.9) ;; WHEN: Mon Dec 21 10:06:55 2009 ;; MSG SIZE rcvd: 133 dig @ns.xinnetdns.com. aaaa www.ecshop.com ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. aaaa www.ecshop.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26800 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ecshop.com. IN AAAA ;; ANSWER SECTION: www.ecshop.com. 120 IN CNAME n100.shopex.cn. ;; AUTHORITY SECTION: shopex.cn. 3600 IN SOA ns.xinnetdns.com. hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 ;; Query time: 234 msec ;; SERVER: 202.10.73.8#53(202.10.73.8) ;; WHEN: Mon Dec 21 10:06:55 2009 ;; MSG SIZE rcvd: 133 > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com dig @ns.xinnetdns.com. a www.ecshop.com ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. a www.ecshop.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30721 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ecshop.com. IN A ;; ANSWER SECTION: www.ecshop.com. 120 IN CNAME n100.shopex.cn. ;; AUTHORITY SECTION: shopex.cn. 3600 IN SOA ns.xinnetdns.com. hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 ;; Query time: 231 msec ;; SERVER: 202.10.73.8#53(202.10.73.8) ;; WHEN: Mon Dec 21 10:07:09 2009 ;; MSG SIZE rcvd: 133 dig @ns.xinnet.cn. a www.ecshop.com ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. a www.ecshop.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4793 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ecshop.com. IN A ;; ANSWER SECTION: www.ecshop.com. 120 IN CNAME n100.shopex.cn. ;; AUTHORITY SECTION: shopex.cn. 3600 IN SOA ns.xinnetdns.com. hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 ;; Query time: 232 msec ;; SERVER: 202.10.73.9#53(202.10.73.9) ;; WHEN: Mon Dec 21 10:07:09 2009 ;; MSG SIZE rcvd: 133 From dwing@cisco.com Mon Dec 21 10:10:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B013A6A8A for ; Mon, 21 Dec 2009 10:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTiiT3OtigHQ for ; Mon, 21 Dec 2009 10:10:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B3FFC3A6A7E for ; Mon, 21 Dec 2009 10:10:09 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAANJL0urR7H+/2dsb2JhbACIXoEWt06VRoQuBIFl X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="454043718" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Dec 2009 18:09:53 +0000 Received: from dwingwxp01 (sjc-vpn4-1295.cisco.com [10.21.85.14]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBLI9rsm009851; Mon, 21 Dec 2009 18:09:53 GMT From: "Dan Wing" To: "'liu dapeng'" , "'Iljitsch van Beijnum'" References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912192159g523b4302s72da20f34b289c30@mail.gmail.com> Date: Mon, 21 Dec 2009 10:09:57 -0800 Message-ID: <0a5101ca8268$cdaf2e20$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40912192159g523b4302s72da20f34b289c30@mail.gmail.com> Thread-Index: AcqBOYnjCKJgxCwyTgmXX6GGdLI44gBLzewg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:10:11 -0000 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com] > Sent: Saturday, December 19, 2009 9:59 PM > To: Iljitsch van Beijnum > Cc: Dan Wing; Andrew Sullivan; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > 2009/12/17, Iljitsch van Beijnum : > > On 17 dec 2009, at 6:30, Dan Wing wrote: > > > >>> Just being persistant and request an A record whenever we > >>> don't get an AAAA answer for any (?) reason (timeout, > >>> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > >>> reasonable tradeoff. However, that would be a slight > >>> departure from the current draft. > > > >> Optimizing for NXDOMAIN is tempting, but it means DNS64 > >> would be ineffective for many websites, > > > > Well, AFAIK with things like REFUSED and SERVFAIL you can > argue that this > > result is particular to the AAAA query and the A query may > give a different > > result. With NXDOMAIN the answer authoritatively states > that the domain > > doesn't exist, so the only way the A query can produce a > different answer is > > if someone is completely breaking the specifications. > > > > If the DNS64 is doing recursive queries itself it SHOULD > never encounter > > REFUSED, because then there would be a break in the > delegation chain, so I'm > > not worried about generating a few more queries in that > case. If there is a > > resolver in the middle it could be that the resolver > doesn't want to resolve > > for the DNS64, but in that case the whole setup doesn't > work so the users > > will give up and again, a few extra packets is not an issue. > > > > Not sure where SERVFAIL would come from in the > authoritative case, but in > > the resolver case it can obviously result from a REFUSED > authoritative > > response so again no problem querying for an A record. > > > > However, the NXDOMAIN case will normally be the result of a > query for a > > non-existant domain. If there is a large amount of such > queries doubling it > > is not a good idea. > > > > People configuring their DNS server to send out REFUSED for > AAAA queries is > > something that I can kinda-sorta-but-not-really follow, but > NXDOMAIN when > > there is in fact an A record is just plain wrong on every level so > > generating lots of extra queries when there is NXDOMAIN for > AAAA or by > > always doing A first even when we don't need the A record > is probably a > > bridge too far for the IETF to mandate. > Agree in some degree. Besides, dose sending A query if AAAA query > responses a NXDOMAIN will cause security issue? Hackers could send > lots AAAA queries for non-exist domain and the DNS64 continue to > convert them to A queries will use up all the resources of DNS64? (Unlike NAT-PT,) there aren't any resources in the DNS64 to consume. -d > Best wishes, > Dapeng Liu > >> Of those 5000, their nameservers returned: > > > >> NOERROR, 4766 (95.3%) > >> NXDOMAIN, 37 (0.74%) > >> REFUSED, 18 (0.36%) > >> SERVFAIL, 23 (0.46%) > > > > What about the remaining 156? Timeout? (For instance, one > on Mark's list > > that I tried replied in 4800 ms for me...) > > > > Would be interesting to see the results for A. As we saw in > the FTP case, > > there is always a percent or two that just don't do > anything reasonable. > > (Although with top 5000 popular sites this is probably > better than an old > > list of FTP sites.) > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Mon Dec 21 10:21:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8753A6A83 for ; Mon, 21 Dec 2009 10:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-2.101, BAYES_40=-0.185, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEJVH1YKaz2E for ; Mon, 21 Dec 2009 10:21:16 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1D4CE3A6823 for ; Mon, 21 Dec 2009 10:21:16 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQVAAtLL0urR7Hu/2dsb2JhbABVggmGAIEWjRuqSpVGhC4EgWWKWg X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="282067026" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2009 18:21:00 +0000 Received: from dwingwxp01 ([10.21.72.152]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBLIKxtl004919; Mon, 21 Dec 2009 18:20:59 GMT From: "Dan Wing" To: "'liu dapeng'" References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com><2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com><046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> Date: Mon, 21 Dec 2009 10:21:03 -0800 Message-ID: <0a5801ca826a$5ab9c9f0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> Thread-Index: AcqBTnyE2TGg7zQxSYOgqPT/D43H7QBGlQrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:21:18 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng > Sent: Sunday, December 20, 2009 12:29 AM > To: Dan Wing > Cc: Andrew Sullivan; behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > Hi Dan, > > I find that www.blogsome.com could response correctly for AAAA query. > The response message have no answer record for AAAA RR but with a > RCODE=0. But most of the remaining servers listed in "REFUSED" section > could indeed have a response with RCODE=0; You're using nslookup, so here is the output of my command: > nslookup -q=ns blogsome.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: blogsome.com nameserver = ns2.browseireland.com. blogsome.com nameserver = ns3.browseireland.com. blogsome.com nameserver = ns1.browseireland.com. Authoritative answers can be found from: ns1.browseireland.com internet address = 212.147.136.30 ns2.browseireland.com internet address = 216.55.166.148 ns3.browseireland.com internet address = 212.147.136.3 querying ns2, I get REFUSED: > nslookup -query=aaaa www.blogsome.com. ns2.browseireland.com. Server: ns2.browseireland.com. Address: 216.55.166.148#53 ** server can't find www.blogsome.com: REFUSED Showing similar output using Dig: > dig +short blogsome.com ns | xargs -t -n 1 -I J dig @J aaaa www.blogsome.com | grep status dig @ns2.browseireland.com. aaaa www.blogsome.com ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45888 dig @ns1.browseireland.com. aaaa www.blogsome.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42073 dig @ns3.browseireland.com. aaaa www.blogsome.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55319 > For the "SERVFAIL" section: www.pathfinder.gr/ > www.sznews.com/www.bramjnet.com indeed response Server failure ; > www.hc360.com time out. But all others could have a response with > RCODE=0; *shrug*. I don't know why the results are different. -d > Best wishes, > Dapeng Liu > > 2009/12/17, Dan Wing : > > Iljitsch van Beijnum wrote: > > > >> Just being persistant and request an A record whenever we > >> don't get an AAAA answer for any (?) reason (timeout, > >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > >> reasonable tradeoff. However, that would be a slight > >> departure from the current draft. > > > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > > would be ineffective for many websites, including popular > > ones. I checked the top 5000 websites (according to Alexa, > > see http://www.alexa.com/topsites) to see how they handle > > AAAA queries. > > > > Of those 5000, their nameservers returned: > > > > NOERROR, 4766 (95.3%) > > NXDOMAIN, 37 (0.74%) > > REFUSED, 18 (0.36%) > > SERVFAIL, 23 (0.46%) > > > > There is some inconsistency because my script is simplistic > > (the results don't add up to 5000), but I was mostly intending > > to get a feel for real numbers that would affect DNS64 if > > DNS64 did not provide effective service to an NXDOMAIN > > response. > > > > > > Below, I summarized the domains that returned errors when > > queried for AAAA. > > > > The command I used for the test was: > > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > > dig @J aaaa www.DOMAINNAME | grep status > > and the log file is at > > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > > > -d > > > > ----- > > > > NXDOMAIN: > > www.1e100.net > > www.uimserv.net > > www.yimg.com > > www.rmxads.com > > www.ggpht.com > > www.edgesuite.net > > www.webry.info > > www.images-amazon.com > > www.pgmediaserve.com > > www.livefilestore.com > > www.googlesyndication.com > > www.ytimg.com > > www.myfiles-express.com > > www.myspacecdn.com > > www.fbgdc.com > > www.say-move.org > > www.www.ne.jp > > www.ucom.ne.jp > > www.xtshare.com > > www.nocookie.net > > www.bingj.com > > www.k12.ca.us > > www.wateen.net > > www.2mdn.net > > www.kvors.com > > www.yahoofs.jp > > www.ecshop.com > > www.xii.jp > > www.ebayrtm.com > > www.atwola.com > > www.twimg.com > > www.www.gov.cn > > www.movie-japan.com > > www.mofile.com > > www.donetsk.ua > > www.gnspf.com > > www.bannch.jp > > > > REFUSED: > > www.ehow.com > > www.sanspo.com > > www.cracked.com > > www.nbc.com > > www.answerbag.com > > www.mozilla-europe.org > > www.hindustantimes.com > > www.treehugger.com > > www.blogsome.com > > www.gamershell.com > > www.rotoworld.com > > www.books.com.tw > > www.nbcsports.com > > www.livestrong.com > > www.longporntube.com > > www.airliners.net > > www.essortment.com > > www.greenpeace.org > > > > SERVFAIL: > > www.livejasmin.com > > www.ynet.com > > www.awempire.com > > www.ikea.com > > www.hc360.com > > www.vnet.cn > > www.bramjnet.com > > www.miibeian.gov.cn > > www.startpagina.nl > > www.sznews.com > > www.yingjiesheng.com > > www.rueducommerce.fr > > www.shortnews.de > > www.heavy.com > > www.penny-arcade.com > > www.nouvelobs.com > > www.eventim.de > > www.cdcovers.cc > > www.soccerway.com > > www.pathfinder.gr > > www.gazetaesportiva.net > > www.5giay.vn > > www.ratp.info > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Dec 21 10:26:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC913A6A88 for ; Mon, 21 Dec 2009 10:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.717 X-Spam-Level: X-Spam-Status: No, score=-4.717 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FNxp6FxWlUW for ; Mon, 21 Dec 2009 10:26:13 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6969A3A6A87 for ; Mon, 21 Dec 2009 10:26:13 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMFAIZML0urR7Ht/2dsb2JhbACECoRUgRa3UYZ6CI5EgSuCLVYEgWU X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="282069692" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2009 18:25:57 +0000 Received: from dwingwxp01 ([10.21.72.152]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBLIPvST021277; Mon, 21 Dec 2009 18:25:57 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'marcelo bagnulo braun'" References: <04ac01ca7fbf$080d7060$c4f0200a@cisco.com> <001b01ca81de$aa4e2010$e30c6f0a@china.huawei.com> Date: Mon, 21 Dec 2009 10:25:57 -0800 Message-ID: <0a5901ca826b$09e84910$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001b01ca81de$aa4e2010$e30c6f0a@china.huawei.com> Thread-Index: AcqB3q7ePPOJ893wQ2OMdc74GevqDgAi7lCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:26:14 -0000 =20 > -----Original Message----- > From: Xu Xiaohu [mailto:xuxh@huawei.com]=20 > Sent: Sunday, December 20, 2009 5:41 PM > To: 'Dan Wing'; 'marcelo bagnulo braun' > Cc: behave@ietf.org > Subject: re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 16:50 > > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > > ALLnon-0::/3 IPv6 addresses ? > >=20 > >=20 > > > > > > +-------------------+ > > > > > > | | > > > > > > +-------------+ | IPv6 Internet | =20 > +--------------+ > > > > > > | +---+ =20 > +---++---++ IPv4 only > > > > > > | IPv6 only | +-------------------+ =20 > |NAT64| | > > > > > > | +-----+ | =20 > ++---++ +-----+| > > > > > > | | H1 | | +-------------------+ | =20 > | H2 || > > > > > > | +-----+ NAT64?- + +---+ =20 > +-----+| > > > > > > +-------------+ | IPv4 Internet | =20 > +--------------+ > > > > > > | | > > > > > > +-------------------+ > > > > > > If I understand your statement correctly, An IPv6 only site > > > > > > (e.g., left site > > > > > > in the above figure) MUST have a connection to the IPv4 > > > > > > Internet via NAT64 > > > > > > in order to access hosts located in an IPv4 only site (e.g., > > > > > > right site in > > > > > > the above figure). Besides, the IPv6 only host=20 > (e.g. H1) MUST > > > > > > be able to > > > > > > synthesize IPv6 address by itself. If either of the=20 > above two > > > > > > conditions is > > > > > > not satisfied, the communication between H1 and H2 is > > > impossible. > > > > > > > > > > Yep -- because IPv4-only applications don't know anything > > > about IPv6 > > > > addresses > > > > > -- IPv4-only applications don't know how to parse IPv6 > > > addresses, how to > > > > > include them in referrals, etc. > > > > > > > > Note that H1 in the above scenario is IPv6 only, but not > > > IPv4 only. Hence > > > > I'm wondering whether the statement you made is relevant to > > > the above > > > > scenario. > > > > > > Let me explain the scenario a bit more, in the above scenario, the > > > communication is initiated by H1 (IPv6 only host), but not H2 > > > (IPv4 only > > > host). To make that communication possible, should a=20 > NAT64 be deployed > > > between the IPv6 only site (left site) and the IPv4 Internet > > > although there > > > is already a NAT64 between the IPv4 site (right site) and the > > > IPv6 Internet? > > > If so, what's the meaning of IPv6 Internet to IPv4=20 > network scenario? > >=20 > > The "IPv6 Internet to IPv4 network" scenario applies to the=20 > ISP on the > right. > >=20 > > Detail: > >=20 > > The ISP on the left is a business, and they made the=20 > decision to operate > an > > IPv6-only network with IPv6-only hosts. Their subscribers=20 > want access to > > (and/or from) the IPv4 Internet, so that ISP provides a NAT64 (and > associated > > DNS64, of course). This is the "an IPv6 network to the=20 > IPv4 Internet" > > scenario (when the connection is initiated from the IPv6=20 > host) and is the > "the > > IPv4 Internet to an IPv6 network" (when the connection is=20 > initiated from > the > > IPv4 side). Note that a stateful NAT64 will generally not=20 > support "the > IPv4 > > Internet to an IPv6 network" unless port mappings are=20 > configured on the > > stateful NAT64. > >=20 > > The ISP on the right is another, separate business, and=20 > they made the > decision > > to keep their subscribers running IPv4. Their subscribers=20 > want access to > > (and/or from) the IPv6 Internet. This is "an IPv4 network=20 > to the IPv6 > > Internet" (when the connection is initiated from the IPv4=20 > side) and is > "the > > IPv6 Internet to an IPv4 network" (when the connection is=20 > initiated from > the > > IPv6 side). >=20 >=20 > +-------------+ > | IPv6 only | > | +-----+ | > | | H3 | | > | +-----+ | > +------+------+ > | > +---------+---------+ > | | > +-------------+ | IPv6 Internet | =20 > +----------------+ > | +------+ +-----+-+-----+=20 > IPv4 only| > | IPv6 only | +-------------------+ |NAT64-2|=20 > | > | +-----+ | +-+-----+=20 > +-----+| > | | H1 | +-------+ +-------------------+ | =20 > | H2 || > | +-----+ |NAT64-1+- + +------+ =20 > +-----+| > | DNS64 +--+----+ | IPv4 Internet | =20 > +----------------+ > +-------------+ | | > +-------------------+ >=20 > In the above scenario, if H3 and H1 send a DNS query for the=20 > AAAA record of > H2 respectively, they should obtain different results, e.g.,=20 > H3 gets an IPv6 > address which is synthesized with a NSP used by NAT64-2,=20 > while H1 receives > an IPv6 address which is synthesized with a WKP used by=20 > NAT64-1. That's to > say, the authoritative DNS server for H2 will return an IPv6=20 > address which > is synthesized with a NSP used by NAT64-2 to a DNS client=20 > which is an IPv6 > only host without NAT64 (e.g., H3), while returned a null to those DNS > clients which is either an IPv6 only host with NAT64 (e.g., H1) or a > dual-stack host. The latter DNS clients or their DNS64 will=20 > send a DNS query > for A record once the resolution for AAAA record fails.). >=20 > Is the above statement in accordance with your assumption? =20 No. In all cases, because H2's network is operating a NAT64, its network will also return AAAA's that cause incoming IPv6 connections to be translated to IPv4 and to be routed to H2. Those AAAAs might be static or might be dynamically created by the DNS64 function operated by H2's network. -d > If so, how does > the authoritative DNS server for H2 determine whether the DNS=20 > client (e.g., > H1, H3) is an IPv6 only host w/o NAT64 or an IPv6 only host=20 > but with NAT64 > (or even dual-stack host)?=20 >=20 > Xiaohu >=20 From baford@mpi-sws.org Sun Dec 20 08:32:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EA33A67AE for ; Sun, 20 Dec 2009 08:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9MyMR91nv3c for ; Sun, 20 Dec 2009 08:32:52 -0800 (PST) Received: from hera.mpi-sb.mpg.de (hera.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id BE29F3A67D6 for ; Sun, 20 Dec 2009 08:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Cc:Message-Id:From:To: In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version: Subject:Date:References; bh=1GJCa+Q3loXU8SCmb4KnXlP7EP5f1nklrq+Q md/1E+M=; b=CZN1Lfdw76NkQMOk5+HmHpL62KFgR1lIabEJCfJzbXwrhBD8fUxH 9BqI8Fxb05RhtenfadBpiOgDLOjU8xxTGsxiFT8NKfZJjzEDcU+yNtlFFDsiwPC6 Lq+lHT0gahLYUcGxp1WzRbQ5rRiISFJGWfh8ctRBDLJzu3d5EM0eJxw= Received: from infao0710.mpi-sb.mpg.de ([139.19.1.28]:48541 helo=newzak.mpi-sb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1NMOhq-0000u3-70; Sun, 20 Dec 2009 17:32:33 +0100 Received: from dhcp184-48-87-198.pcr.snd.wayport.net ([184.48.87.198]:62210) by newzak.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1NMOhn-00082C-Kv; Sun, 20 Dec 2009 17:32:29 +0100 Message-Id: <345ECBBB-D91E-4E9A-8E94-FD4083F9697B@mpi-sws.org> From: Bryan Ford To: marcelo bagnulo braun In-Reply-To: <4B2B5C6E.3060805@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 20 Dec 2009 08:32:21 -0800 References: <4B2B5C6E.3060805@it.uc3m.es> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 21 Dec 2009 10:32:04 -0800 Cc: IETF BEHAVE WG Subject: Re: [BEHAVE] Review of the NAT64 document? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 16:32:54 -0000 Hi Marcelo, Here are some comments on draft-ietf-behave-v6v4-xlate- stateful-07.txt. This message is divided into three sections: (a) technical issues that may require some list discussion; (b) clarity issues with what exactly is specified and now, that you can probably just fix yourself; (c) minor editorial/writing nitpicks that can certainly be fixed unilaterally. --- Technical issues (apologies if any of these have already been discussed extensively and I just don't know it because I haven't been keeping up with the list): * First, the specified rules for generating ICMP packets look to me to be dangerous in that they're liable to interfere with hole punching. For example, see the paragraph on the border between page 25 and 26: "If the security policy requires silently dropping externally initiated TCP connections, then the packet is silently discarded, else, If the destination transport address contained in the incoming V4 SYN (i.e. X,x) is not in use in the TCP BIB, then the packet is discarded and an ICMP Port Unreachable error (Type 3, Code 3) is sent back to the source of the v4 SYN. The state remains unchanged in CLOSED" This situation (the dest transport addr not in the BIB) will be commonplace in hole punching scenarios, in which one client's outgoing SYN gets to the far NAT before the other client's SYN has gotten to its own NAT. If that NAT returns an ICP Port Unreachable error, that could kill the hole punching attempt. Unless it is somehow known that all or at least most existing TCP stacks don't give up when they get an ICP Port Unreachable, I would say that a NAT64 MUST or at least SHOULD just silently discard "unsolicited" packets like these independent of security policy. * Second issue is about TCP lifetime expiry during the ESTABLISHED state, page 26. The draft suggests (requires?) that the session table merely be silently deleted when the 2-hour timer expires, which I think is far from ideal. BEHAVE-TCP explicitly suggests that NATs send keepalives to the endpoints at the expiry of this timer to "double-check" whether the connection is really still alive or not. The keepalives will hopefully solicit either an ACK or a RST, providing a definite indication. So the procedure I think this standard should specify, with at least a SHOULD, might go something like this: 1. When the 2:40:00 timer expires, send TCP keepalives to at least the internal (typical IPv6) endpoint, and possibly to both endpoints; then start a shorter 4-minute timer. 2. If within that 4-minute grace period the NAT64 sees a regular ACK, go back to the ESTABLISHED state with another 2:40:00 timer. If the NAT64 sees a RST, go to RST RCV state. 3. If the 4-minute grace period expires, drop the session state. Actually, it might be sufficient simply to make this "grace period" state behaviorally identical to the "RST RCV" state - i.e., the NAT64 goes into the RST RCV state when either it sees an explicit RST or when the ESTABLISHED timer expires, and in either case it can get back out of that state to ESTABLISHED if it sees more normal traffic. * Third issue is with session timers for UDP. (I think I brought up this on this list sometime back, but I don't know if there's been any discussion of it since then.) While just having a constant UDP session timeout of 5 minutes should be permitted behavior, what would be even better and perhaps RECOMMENDED is if the NAT increases the session timeout as the session's lifetime increases. For example, if the session survives its first 5-minute timeout (i.e., the NAT sees traffic during that time), it doubles the next period to 10 minutes, then to 20 minutes, etc., until some maximum, e.g., the 2:40:00 timeout specified for TCP in the ESTABLISHED state. This behavior still ensures NAT session state gets garbage collected before its lifetime exceeds about twice the time the UDP session is actually in-use; it won't affect UDP apps that naively just send keepalives at <5min periods; but it may greatly benefit smarter UDP apps on power-constrained mobile devices that want to reduce power consumption. In particular, if the UDP app implements a binding- timeout-testing algorithm that starts with frequent keepalives and gradually decreases the keepalive frequency, then on a "naive" NAT with a 5-min timeout the app will learn that it has to send keepalives every 5min and do that; but on a NAT with doubling session timeouts, the session will appear to the smart app to have an "infinite" (or a 2:40-min) session timeout, and the smart app will be able to gradually reduce its keepalives to a very low rate and conserve power even while holding a long-term UDP session open. --- Next, technical clarity issues with the draft: Section 3.1 - some of this text looks in need of a bit more precision, including use of the standard requirements terms MAY/SHOULD/MUST. Especially, e.g., the end of para 5 - "the incoming IP packet is silently discarded" - does that mean it SHOULD be silently discarded, or MUST be, or what? Paragraph starting "For incoming packets...", last sentence "In the latter case, subsequent fragments may arrive before the first." - what is this supposed to be saying? Yes, fragments may arrive out of order - but then what? SHOULD or MUST the NAT64 try to hold onto the out-of- order fragments until the first fragment arrives, before which it won't know the full tuple and thus won't be able to forward those out- of-order fragments? Or MAY a NAT silently drop out-of-order fragments it receives the first packet? Seems like that behavior could be dangerous - some existing hosts are known to send packets out of order out of habit; such a host's fragmented packets would always be black- holed by such a NAT. next para - what does "has enough resources" mean? Are NAT64s required to have any resources at all for this purpose, or is "always zero resources for reassembling zero-checksum packets" a legitimate design point? Seems the standard should specify this. Also, "will silently discard" - is that a MUST? 3.2.1, para containing "By default, the maximum session lifetime is 5 minutes." - what does this mean precisely? Does it mean the maximum session lifetime MUST be 5 minutes? Or MUST be _at least_ 5 minutes? Or it SHOULD be configurable and the default MUST (or SHOULD) be [at least] 5 minutes? or what? Later, in the first subpara of IPv4 processing part - "packet is dropped" - MUST be dropped? "has a type of 3" - MUST have a type of 3? Session timer para at end of section - same issue as earlier. 3.2.1.1. first para - "If the rules specify" - what/whose rules? the rules specified right here in the standard? Shouldn't the standard "know" what its own rules specify? :) Or are you referring to some rules defined by the NAT64 implementor? Please clarify. paga 26, first para - "is silently discarded" - MUST be? page 26, last para - the parenthetical expression about the NAT being able to move from RST RCV back to ESTABLISHED if the endpoints don't accept the RST is very important for DoS protection, I believe, and: (a) shouldn't be a parenthetical expression (makes it sound unimportant), and (b) this behavior needs to be specified with MUST language. 3.2.2.1, first para - another "If the rules specify" whose meaning I don't understand. (what rules?) Section 3.5 on hairpinning is inadequate, both in terms of specification and in terms of description. In terms of specification: "This step handles hairpinning if necessary." What does "if necessary" mean? Existing BEHAVE documents dictate that NATs MUST support hairpinning, don't they? Shouldn't the first paragraph of 3.5 reiterate this, instead of just reiterating what it means for a NAT to support hairpinning? In terms of description, I think the second paragraph should be expanded to a more precise, step-by-step description, like the rest of the processes described in this section. sec 4, "Attacks" section, first para - "NAT64 devices should implement" -> "MUST implement"? --- The rest are mostly writing/editorial nitpicks: 1. Intro, first para: (a) "a mechanism for IPv6-IPv4 transition" - makes it sound like we're transitioning from IPv6 to IPv4! Don't you mean "IPv4-to-IPv6 transition"? (b) "to an IPv4-only server, They also enable" - change ',' to '.' Second para is written assuming IPv4-side node is a server and IPv6- side node is a client, implicitly contradicting what the first para just said. Please clarify - is this para only supposed to apply to the "primary usage" of IPv6-client-to-IPv4-server, or does it apply to all supported communication modes? 1.1 - I don't understand what the second bullet is saying: o In the absence of any state in NAT64 regarding a given IPv6 node, only said IPv6 node can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs. 1.1, third bullet - isn't the capitalized "MAY" a misuse of standards terminology, given that its use here is just to state a fact about NAT64 and not to specify required or allowed behavior in an implementation of a protocol? Decapitalize. Also, "via one of the following mechanism" - last word should be plural. Also, third sub-bullet is missing a period at the end. 1.2, para 2 - "an NAT64 box" - change "an" to "a" 1.2.1, para 3 - change "addresses i.e. an" to just "addresses: an" 1.2.1, para starting "the IPv4 address pool is": change ", which enable" in last sentence to ", enabling". next para - delete "it is easy to understand that", and change "which address" to "whose address" 1.2.2, first para - "a IPv4 node" -> "an IPv4 node" sec. 3 - the text before the start of 3.1 is very long and should probably be split up a bit. For example: - start a new subsection titled "Binding Information Bases" just before the para beginning "A NAT64 has three Binding Information Bases..." - start a new subsection titled "Session Tables" just before the para beginning "A NAT64 also has three session tables..." - Start a new subsection titled, e.g., "Packet Processing" or "Packet Processing Overview", just before the para beginning "The NAT64 will receive packets through its interfaces..." 3.1, a few paragraphs in: "even if the arrive" -> "even if they arrive"; and "conditioned to" -> "conditioned on" 3.2, para 2: capitalize "must" in first line. Also, "will only" appears twice later in the para - should those be MUSTs? 3.2.2, V4 SYN RCV para: "waiting for a matching IPv4 packet" - don't you mean IPv6 here? 3.2.2, under *** CLOSED ***, bullet 1. - "does not exists" -> "does not exist" page 25, first para - "unchanged in CLOSED" needs a period. page 25, para "If the NAT64 is performing..." - mangled text; not sure how it's supposed to parse. At least eliminate the doubly nested parentheses. :) 3.2.2 - this is a very long section, and could be easily broken up a bit for example by adding a subsubsection for each state instead of the *** STATE *** thing. Then that structure would be reflected in the table of contents, too, which I think would be a good thing. sec 4, para "Any protocol...": "that protect" -> "that protects"; "are essentially" -> "is essentially"; delete "So,"; "inherent to" -> "inherent in". This section has a bunch of subsections (e.g., "Implications on...", "Filtering", Attacks"...) that need to be made into "real" subsections - i.e., numbered and included in the table of contents. "Attacks to NAT64" -> "Attacks on NAT64" first para of that section: delete "It should be noted that". "launch a DoS attack to" -> "launch a DoS attack on". "Avoiding hairpinning loops", first para: "will loop" -> "could loop". (Will NOT if this spec is implemented correctly, right!?) And same for next instance of "will loop". And delete another instance of "It should be noted that". "your changes" -> "the attacker's chances". "the NAT64 drops" -> "the NAT64 MUST drop ... as described in Section XXX"? --- END of comments. Thanks, Bryan From dwing@cisco.com Mon Dec 21 11:04:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533D028C124 for ; Mon, 21 Dec 2009 11:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEWYnzL9w02F for ; Mon, 21 Dec 2009 11:04:07 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C00AF28C0F0 for ; Mon, 21 Dec 2009 11:04:06 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAHlVL0urR7H+/2dsb2JhbACIXoEWtz+VTYQuBA X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="206078215" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2009 19:03:50 +0000 Received: from dwingwxp01 (sjc-vpn6-643.cisco.com [10.21.122.131]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBLJ3o25027236; Mon, 21 Dec 2009 19:03:50 GMT From: "Dan Wing" To: Date: Mon, 21 Dec 2009 11:03:50 -0800 Message-ID: <0aa801ca8270$54ed0d10$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqCcFSzm1W8tECTRa22IaWjQbBI9Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] draft-ietf-behave-turn-tcp-05 going to IESG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:04:08 -0000 (Sorry, I had let this slip off my to-do list.) We had a successful WGLC for draft-ietf-behave-turn-tcp-05, and are requesting publication. PROTO writeup is below. -d ----- (1.a) Who is the Document Shepherd for this document? draft-ietf-behave-turn-tcp-05 Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received significant review from the community. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. None. (1.e) How solid is the WG consensus behind this document? Very solid. Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has a good understanding of, and agreement with, this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such threats or appeals. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Yes. Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? The document does not specify a MIB, media type, or URI, and thus does not need to meet those review criteria. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended Status: Standards Track (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All normative references are upward references, and all are RFCs. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes. Are the IANA registries clearly identified? Yes. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? The document does not create a new IANA registry. Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no such formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This specification defines a protocol that allows the host to control the operation of a relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality Are there existing implementations of the protocol? Yes. Have a significant number of vendors indicated their plan to implement the specification? Yes. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They are listed in the document's acknowledgement section If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? No such reviews were necessary. Personnel Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Who is the Responsible Area Director? Magnus Westerlund, magnus.westerlund@ericsson.com If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document doesn't require IANA experts. The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From rpenno@juniper.net Mon Dec 21 11:08:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6378C3A6AB2 for ; Mon, 21 Dec 2009 11:08:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8-3342myUJO for ; Mon, 21 Dec 2009 11:08:12 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id F21333A694C for ; Mon, 21 Dec 2009 11:07:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSy/He58v7IANaakR4TTW5vGibbgvTOH/@postini.com; Mon, 21 Dec 2009 11:07:43 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 21 Dec 2009 11:02:56 -0800 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; Mon, 21 Dec 2009 14:02:55 -0500 From: Reinaldo Penno To: Bryan Ford , marcelo bagnulo braun Date: Mon, 21 Dec 2009 14:02:51 -0500 Thread-Topic: [BEHAVE] Review of the NAT64 document? Thread-Index: AcqCa+AjZVY4JcbxQviaMNS0v3RERAABFE+/ Message-ID: In-Reply-To: <345ECBBB-D91E-4E9A-8E94-FD4083F9697B@mpi-sws.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF BEHAVE WG Subject: Re: [BEHAVE] Review of the NAT64 document? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:08:13 -0000 Hello, Although many NATs send keep-lives (specially when the idle timeout is configured to be less than 2 hours) I do not think RFC5538 suggests that behavior, even though there is some discussion around that. Thanks, Reinaldo On 12/20/09 8:32 AM, "Bryan Ford" wrote: > BEHAVE-TCP explicitly suggests that NATs > send keepalives to the endpoints at the expiry of this timer to > "double-check" whether the connection is really still alive or not. From marka@isc.org Mon Dec 21 12:43:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B143A6774 for ; Mon, 21 Dec 2009 12:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeOKna38h0sc for ; Mon, 21 Dec 2009 12:43:11 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 3B81A3A6881 for ; Mon, 21 Dec 2009 12:43:10 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id AD6D8E60C8; Mon, 21 Dec 2009 20:42:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBLKgh7g010808; Tue, 22 Dec 2009 07:42:44 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912212042.nBLKgh7g010808@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca> <20091216163049.GD37010@shinkuro.com> <20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca> <20091216183850.GJ37010@shinkuro.com> <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com> <046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912192126w212ec4b0u4d5ded3c544821e8@mail.gmail.com> <0a5001ca8268$b5a57690$c4f0200a@cisco.com> In-reply-to: Your message of "Mon, 21 Dec 2009 10:09:16 -0800." <0a5001ca8268$b5a57690$c4f0200a@cisco.com> Date: Tue, 22 Dec 2009 07:42:43 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 20:43:12 -0000 In message <0a5001ca8268$b5a57690$c4f0200a@cisco.com>, "Dan Wing" writes: > > -----Original Message----- > > From: liu dapeng [mailto:maxpassion@gmail.com] > > Sent: Saturday, December 19, 2009 9:27 PM > > To: Dan Wing > > Cc: Iljitsch van Beijnum; Andrew Sullivan; behave@ietf.org > > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > > record available > > > > Hi Dan, > > > > I query AAAA for www.ecshop.com could success, the RCODE is 0 (no > > error). And the response is a CNAME. I am wondering why your > > experiment result is NXDOMAIN, what caused this unconsistency (other > > results are the same)? I use nslookup for query and set the query type > > to AAAA. > > I am seeing NXDOMAIN, when querying the remote nameservers directly, for both > A and AAAA queries. Both A and AAAA responses give me a CNAME. You are seeing cache poisioning attempts. ns.xinnetdns.com and ns.xinnet.cn are only authoritative for www.ecshop.com not n100.shopex.cn. named only sees the CNAME record and ignores the rest of the answer, named then goes out and resolves n100.shopex.cn/AAAA which is why people don't see anything wrong with www.ecshop.com. Mark > Summary, AAAA query showing NXDOMAIN responses (detail is below): > > > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com > | > grep status > dig @ns.xinnetdns.com. aaaa www.ecshop.com > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45448 > dig @ns.xinnet.cn. aaaa www.ecshop.com > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62146 > > Summary, A query showing NXDOMAIN responses (detail is below): > > > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com | > grep status > dig @ns.xinnet.cn. a www.ecshop.com > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27991 > dig @ns.xinnetdns.com. a www.ecshop.com > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53739 > > -d > > ----- > > > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com > dig @ns.xinnet.cn. aaaa www.ecshop.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. aaaa www.ecshop.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11752 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.ecshop.com. IN AAAA > > ;; ANSWER SECTION: > www.ecshop.com. 120 IN CNAME n100.shopex.cn. > > ;; AUTHORITY SECTION: > shopex.cn. 3600 IN SOA ns.xinnetdns.com. > hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 > > ;; Query time: 231 msec > ;; SERVER: 202.10.73.9#53(202.10.73.9) > ;; WHEN: Mon Dec 21 10:06:55 2009 > ;; MSG SIZE rcvd: 133 > > dig @ns.xinnetdns.com. aaaa www.ecshop.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. aaaa www.ecshop.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26800 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.ecshop.com. IN AAAA > > ;; ANSWER SECTION: > www.ecshop.com. 120 IN CNAME n100.shopex.cn. > > ;; AUTHORITY SECTION: > shopex.cn. 3600 IN SOA ns.xinnetdns.com. > hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 > > ;; Query time: 234 msec > ;; SERVER: 202.10.73.8#53(202.10.73.8) > ;; WHEN: Mon Dec 21 10:06:55 2009 > ;; MSG SIZE rcvd: 133 > > > > > > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com > dig @ns.xinnetdns.com. a www.ecshop.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. a www.ecshop.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30721 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.ecshop.com. IN A > > ;; ANSWER SECTION: > www.ecshop.com. 120 IN CNAME n100.shopex.cn. > > ;; AUTHORITY SECTION: > shopex.cn. 3600 IN SOA ns.xinnetdns.com. > hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 > > ;; Query time: 231 msec > ;; SERVER: 202.10.73.8#53(202.10.73.8) > ;; WHEN: Mon Dec 21 10:07:09 2009 > ;; MSG SIZE rcvd: 133 > > dig @ns.xinnet.cn. a www.ecshop.com > > ; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. a www.ecshop.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4793 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.ecshop.com. IN A > > ;; ANSWER SECTION: > www.ecshop.com. 120 IN CNAME n100.shopex.cn. > > ;; AUTHORITY SECTION: > shopex.cn. 3600 IN SOA ns.xinnetdns.com. > hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600 > > ;; Query time: 232 msec > ;; SERVER: 202.10.73.9#53(202.10.73.9) > ;; WHEN: Mon Dec 21 10:07:09 2009 > ;; MSG SIZE rcvd: 133 > > > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Dec 21 13:02:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D183A6806 for ; Mon, 21 Dec 2009 13:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIl-BpzocgiA for ; Mon, 21 Dec 2009 13:02:19 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 00BA33A6AB2 for ; Mon, 21 Dec 2009 13:02:19 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5AB9EE601C; Mon, 21 Dec 2009 21:01:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBLL1tao011026; Tue, 22 Dec 2009 08:01:56 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912212101.nBLL1tao011026@drugs.dv.isc.org> To: "Dan Wing" From: Mark Andrews References: <4B290A5D.1040700@viagenie.ca><20091216163049.GD37010@shinkuro.com><20091216165953.GE37010@shinkuro.com> <4B291EC2.4060709@viagenie.ca><20091216183850.GJ37010@shinkuro.com><2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com><046901ca7eda$19473db0$c4f0200a@cisco.com> <25e1aaa40912200028s66a32968gb5a20611b0ee3c0c@mail.gmail.com> <0a5801ca826a$5ab9c9f0$c4f0200a@cisco.com> In-reply-to: Your message of "Mon, 21 Dec 2009 10:21:03 -0800." <0a5801ca826a$5ab9c9f0$c4f0200a@cisco.com> Date: Tue, 22 Dec 2009 08:01:55 +1100 Sender: marka@isc.org Cc: 'Andrew Sullivan' , behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 21:02:21 -0000 In message <0a5801ca826a$5ab9c9f0$c4f0200a@cisco.com>, "Dan Wing" writes: > > > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng > > Sent: Sunday, December 20, 2009 12:29 AM > > To: Dan Wing > > Cc: Andrew Sullivan; behave@ietf.org > > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > > record available > > > > Hi Dan, > > > > I find that www.blogsome.com could response correctly for AAAA query. > > The response message have no answer record for AAAA RR but with a > > RCODE=0. But most of the remaining servers listed in "REFUSED" section > > could indeed have a response with RCODE=0; > > You're using nslookup, so here is the output of my command: > > > nslookup -q=ns blogsome.com > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Non-authoritative answer: > blogsome.com nameserver = ns2.browseireland.com. > blogsome.com nameserver = ns3.browseireland.com. > blogsome.com nameserver = ns1.browseireland.com. > > Authoritative answers can be found from: > ns1.browseireland.com internet address = 212.147.136.30 > ns2.browseireland.com internet address = 216.55.166.148 > ns3.browseireland.com internet address = 212.147.136.3 > > querying ns2, I get REFUSED: > > > nslookup -query=aaaa www.blogsome.com. ns2.browseireland.com. > Server: ns2.browseireland.com. > Address: 216.55.166.148#53 > > ** server can't find www.blogsome.com: REFUSED > > Showing similar output using Dig: > > > dig +short blogsome.com ns | xargs -t -n 1 -I J dig @J aaaa > www.blogsome.com | grep status > dig @ns2.browseireland.com. aaaa www.blogsome.com > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45888 > dig @ns1.browseireland.com. aaaa www.blogsome.com > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42073 > dig @ns3.browseireland.com. aaaa www.blogsome.com > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55319 > > > For the "SERVFAIL" section: www.pathfinder.gr/ > > www.sznews.com/www.bramjnet.com indeed response Server failure ; > > www.hc360.com time out. But all others could have a response with > > RCODE=0; > > *shrug*. I don't know why the results are different. > > -d www.pathfinder.gr/AAAA lookups fail because the nameservers for www.pathfinder.gr appear to be configured to serve pathfinder.gr rather than www.pathfinder.gr and you only see this in cachable negative answers. If you ask for www.pathfinder.gr/SOA or www.pathfinder.gr/TXT or www.pathfinder.gr/NS you get a non-cachable negative answer. I supect the vendor has tried to make AAAA negative answers cachable and the operator has put the wrong zone name into the configuration. www.pathfinder.gr. 10800 IN NS lp.phaistosnetworks.gr. www.pathfinder.gr. 10800 IN NS lpsb.phaistosnetworks.gr. www.pathfinder.gr. 10800 IN NS lptb.phaistosnetworks.gr. ;; Received 155 bytes from 62.103.124.3#53(phaistos.phaistosnetworks.gr) in 392 ms pathfinder.gr. 86400 IN SOA pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 7200 604800 86400 ;; Received 124 bytes from 194.0.185.253#53(lptb.phaistosnetworks.gr) in 445 ms > > Best wishes, > > Dapeng Liu > > > > 2009/12/17, Dan Wing : > > > Iljitsch van Beijnum wrote: > > > > > >> Just being persistant and request an A record whenever we > > >> don't get an AAAA answer for any (?) reason (timeout, > > >> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a > > >> reasonable tradeoff. However, that would be a slight > > >> departure from the current draft. > > > > > > Optimizing for NXDOMAIN is tempting, but it means DNS64 > > > would be ineffective for many websites, including popular > > > ones. I checked the top 5000 websites (according to Alexa, > > > see http://www.alexa.com/topsites) to see how they handle > > > AAAA queries. > > > > > > Of those 5000, their nameservers returned: > > > > > > NOERROR, 4766 (95.3%) > > > NXDOMAIN, 37 (0.74%) > > > REFUSED, 18 (0.36%) > > > SERVFAIL, 23 (0.46%) > > > > > > There is some inconsistency because my script is simplistic > > > (the results don't add up to 5000), but I was mostly intending > > > to get a feel for real numbers that would affect DNS64 if > > > DNS64 did not provide effective service to an NXDOMAIN > > > response. > > > > > > > > > Below, I summarized the domains that returned errors when > > > queried for AAAA. > > > > > > The command I used for the test was: > > > dig +short DOMAINNAME ns | xargs -t -n 1 -I J > > > dig @J aaaa www.DOMAINNAME | grep status > > > and the log file is at > > > ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt > > > > > > -d > > > > > > ----- > > > > > > NXDOMAIN: > > > www.1e100.net > > > www.uimserv.net > > > www.yimg.com > > > www.rmxads.com > > > www.ggpht.com > > > www.edgesuite.net > > > www.webry.info > > > www.images-amazon.com > > > www.pgmediaserve.com > > > www.livefilestore.com > > > www.googlesyndication.com > > > www.ytimg.com > > > www.myfiles-express.com > > > www.myspacecdn.com > > > www.fbgdc.com > > > www.say-move.org > > > www.www.ne.jp > > > www.ucom.ne.jp > > > www.xtshare.com > > > www.nocookie.net > > > www.bingj.com > > > www.k12.ca.us > > > www.wateen.net > > > www.2mdn.net > > > www.kvors.com > > > www.yahoofs.jp > > > www.ecshop.com > > > www.xii.jp > > > www.ebayrtm.com > > > www.atwola.com > > > www.twimg.com > > > www.www.gov.cn > > > www.movie-japan.com > > > www.mofile.com > > > www.donetsk.ua > > > www.gnspf.com > > > www.bannch.jp > > > > > > REFUSED: > > > www.ehow.com > > > www.sanspo.com > > > www.cracked.com > > > www.nbc.com > > > www.answerbag.com > > > www.mozilla-europe.org > > > www.hindustantimes.com > > > www.treehugger.com > > > www.blogsome.com > > > www.gamershell.com > > > www.rotoworld.com > > > www.books.com.tw > > > www.nbcsports.com > > > www.livestrong.com > > > www.longporntube.com > > > www.airliners.net > > > www.essortment.com > > > www.greenpeace.org > > > > > > SERVFAIL: > > > www.livejasmin.com > > > www.ynet.com > > > www.awempire.com > > > www.ikea.com > > > www.hc360.com > > > www.vnet.cn > > > www.bramjnet.com > > > www.miibeian.gov.cn > > > www.startpagina.nl > > > www.sznews.com > > > www.yingjiesheng.com > > > www.rueducommerce.fr > > > www.shortnews.de > > > www.heavy.com > > > www.penny-arcade.com > > > www.nouvelobs.com > > > www.eventim.de > > > www.cdcovers.cc > > > www.soccerway.com > > > www.pathfinder.gr > > > www.gazetaesportiva.net > > > www.5giay.vn > > > www.ratp.info > > > > > > > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@shinkuro.com Mon Dec 21 13:42:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CD83A6967 for ; Mon, 21 Dec 2009 13:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyfs3ZxDjMRp for ; Mon, 21 Dec 2009 13:42:00 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D69833A6851 for ; Mon, 21 Dec 2009 13:41:59 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D7B992FE8CB8 for ; Mon, 21 Dec 2009 21:41:42 +0000 (UTC) Date: Mon, 21 Dec 2009 16:41:41 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091221214140.GK59143@shinkuro.com> References: <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2FA450.2060301@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 21:42:00 -0000 On Mon, Dec 21, 2009 at 11:37:36AM -0500, Simon Perreault wrote: > Andrew Sullivan wrote, on 2009-12-21 11:09: > > The problem is that the records in the > > additional section also get cached, and they're the thing that'll > > cause us pain if they get promoted or anything like that. People > > shouldn't do that, but they do. > > Can you expand on this? Is this specific to DNS64 or applies to DNS in general? > Is it already in the text? We have this: 5.3.2. Handling the additional section DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers. The DNS64 MUST pass the additional section unchanged. Here's the problem. Suppose you have a resolver that does some caching, but it's not really an iterative mode resolver. This is the way at least some home units work today: they cache, and they work on the basis of what they have cached, but they rely entirely on whatever upstream resolver they get from DHCP. So, no root.hints, and so on. In such an arrangement, if (logically speaking) the cache happens after the DNS64 (as would make sense, or else the cache is worthless), _and_ the resolver uses its own cache to resolve names, _and_ the cache stores what's in the additional as well as the answer section, then a querying client could get the DNS64's cache of the additional section. Since it's not got any synthesized records in it, the chain could break down. This is especially true if the cache isn't rigorous, and promotes cached additional section data to answers. All that would be a sloppy and ill-thought-out configuration/implementation. I've certainly seen such implementations, however. The fact is that many implementations of various DNS bits don't really understand how the cache can affect them. Whether this is all plain from the draft (or even worth worrying about) is something the reviewers will have to tell me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon.perreault@viagenie.ca Mon Dec 21 14:04:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4CE28C100 for ; Mon, 21 Dec 2009 14:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x2LROeA2+ab for ; Mon, 21 Dec 2009 14:04:45 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B775F3A67D6 for ; Mon, 21 Dec 2009 14:04:42 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 6D22320E20 for ; Mon, 21 Dec 2009 17:04:26 -0500 (EST) Message-ID: <4B2FF0EA.7030203@viagenie.ca> Date: Mon, 21 Dec 2009 17:04:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: behave@ietf.org References: <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> In-Reply-To: <20091221214140.GK59143@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 22:04:46 -0000 Andrew Sullivan wrote, on 2009-12-21 16:41: > We have this: > > 5.3.2. Handling the additional section > > DNS64 synthesis MUST NOT be performed on any records in the > additional section of synthesized answers. The DNS64 MUST pass the > additional section unchanged. > > Here's the problem. Suppose you have a resolver that does some > caching, but it's not really an iterative mode resolver. This is the > way at least some home units work today: they cache, and they work on > the basis of what they have cached, but they rely entirely on whatever > upstream resolver they get from DHCP. So, no root.hints, and so on. > > In such an arrangement, if (logically speaking) the cache happens > after the DNS64 (as would make sense, or else the cache is worthless), > _and_ the resolver uses its own cache to resolve names, _and_ the > cache stores what's in the additional as well as the answer section, > then a querying client could get the DNS64's cache of the additional > section. I'm following you up to here. > Since it's not got any synthesized records in it, the chain > could break down. I don't see why. If the cache doesn't contain a given AAAA synthetic record, the server will try to get it from upstream. That is, unless negative caching is involved, but it shouldn't be when you just put stuff from the additional section into the cache. Maybe a concrete example with records and IP addresses would help... Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From marka@isc.org Mon Dec 21 14:10:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57D728C0EF for ; Mon, 21 Dec 2009 14:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAr2Nf6jzpxe for ; Mon, 21 Dec 2009 14:10:23 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id A5D623A6A87 for ; Mon, 21 Dec 2009 14:10:22 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EAC2EE601C; Mon, 21 Dec 2009 22:10:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBLM9xom012644; Tue, 22 Dec 2009 09:09:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912212209.nBLM9xom012644@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews References: <25e1aaa40912192053g3ff7c458i8ae813eec986bf64@mail.gmail.com> <20091220160319.GA58888@shinkuro.com> <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> In-reply-to: Your message of "Mon, 21 Dec 2009 16:41:41 CDT." <20091221214140.GK59143@shinkuro.com> Date: Tue, 22 Dec 2009 09:09:59 +1100 Sender: marka@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 22:10:23 -0000 In message <20091221214140.GK59143@shinkuro.com>, Andrew Sullivan writes: > On Mon, Dec 21, 2009 at 11:37:36AM -0500, Simon Perreault wrote: > > Andrew Sullivan wrote, on 2009-12-21 11:09: > > > The problem is that the records in the > > > additional section also get cached, and they're the thing that'll > > > cause us pain if they get promoted or anything like that. People > > > shouldn't do that, but they do. > > > > Can you expand on this? Is this specific to DNS64 or applies to DNS in gene > ral? > > Is it already in the text? > > We have this: > > 5.3.2. Handling the additional section > > DNS64 synthesis MUST NOT be performed on any records in the > additional section of synthesized answers. The DNS64 MUST pass the > additional section unchanged. > > Here's the problem. Suppose you have a resolver that does some > caching, but it's not really an iterative mode resolver. This is the > way at least some home units work today: they cache, and they work on > the basis of what they have cached, but they rely entirely on whatever > upstream resolver they get from DHCP. So, no root.hints, and so on. > > In such an arrangement, if (logically speaking) the cache happens > after the DNS64 (as would make sense, or else the cache is worthless), > _and_ the resolver uses its own cache to resolve names, _and_ the > cache stores what's in the additional as well as the answer section, > then a querying client could get the DNS64's cache of the additional > section. Since it's not got any synthesized records in it, the chain > could break down. This is especially true if the cache isn't > rigorous, and promotes cached additional section data to answers. > > All that would be a sloppy and ill-thought-out > configuration/implementation. I've certainly seen such > implementations, however. The fact is that many implementations of > various DNS bits don't really understand how the cache can affect > them. > > Whether this is all plain from the draft (or even worth worrying > about) is something the reviewers will have to tell me. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave Just don't populate the additional section. It's optional except when performing a referral. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@shinkuro.com Mon Dec 21 14:25:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FF328C0EF for ; Mon, 21 Dec 2009 14:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4pJD0dKazun for ; Mon, 21 Dec 2009 14:25:03 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 86F6B3A68C7 for ; Mon, 21 Dec 2009 14:25:03 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CDA4C2FE8CB8 for ; Mon, 21 Dec 2009 22:24:46 +0000 (UTC) Date: Mon, 21 Dec 2009 17:24:45 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091221222444.GM59143@shinkuro.com> References: <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2FF0EA.7030203@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 22:25:04 -0000 On Mon, Dec 21, 2009 at 05:04:26PM -0500, Simon Perreault wrote: > I don't see why. If the cache doesn't contain a given AAAA synthetic record, the > server will try to get it from upstream. That is, unless negative caching is > involved, but it shouldn't be when you just put stuff from the additional > section into the cache. Only if your DNS64 is sane. I agree it shouldn't normally be a problem, but I would not be at all surprised to see someone get this detail wrong. (Remember that some caches are going to assume that the cached additional is all that is available, and if the data is there it must have been useful. Or something. Honestly, I don't fully understand how some of the stranger implementations one sees get that way.) The alternative, which is what Mark suggested before, (and has just done again in this thread) is to truncate the additional. We didn't get anyone else supporting that option when it was proposed last time. But unaltered additional on the "inside" of the DNS64 is, frankly, useless anyway, so the more I think about it the more attractive that option is to me. Does anything need it? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Mon Dec 21 14:48:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4490D28C0F8 for ; Mon, 21 Dec 2009 14:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTIptrlPwUHQ for ; Mon, 21 Dec 2009 14:48:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 58AF83A6842 for ; Mon, 21 Dec 2009 14:48:43 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAKKKL0urR7H+/2dsb2JhbACIXoEWtwyWK4QuBIFl X-IronPort-AV: E=Sophos;i="4.47,433,1257120000"; d="scan'208";a="282182550" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2009 22:48:27 +0000 Received: from dwingwxp01 (sjc-vpn3-759.cisco.com [10.21.66.247]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBLMmRbA018836; Mon, 21 Dec 2009 22:48:27 GMT From: "Dan Wing" To: "'Andrew Sullivan'" , References: <2D5A6F65-B93F-4B45-98A0-7C19D8A05F0B@muada.com><046901ca7eda$19473db0$c4f0200a@cisco.com><019301ca7f3f$e5de0380$c4f0200a@cisco.com><20091218033348.GB47068@shinkuro.com><25e1aaa40912192256h64f80b3freb382fe522135e64@mail.gmail.com> <20091221152547.GB59143@shinkuro.com> Date: Mon, 21 Dec 2009 14:48:27 -0800 Message-ID: <0b8f01ca828f$b5a4a180$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091221152547.GB59143@shinkuro.com> Thread-Index: AcqCUeM/S4nSN4bLTZGMd+j8gcAqMAAPaMvw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 22:48:44 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Monday, December 21, 2009 7:26 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A > record available > > On Sun, Dec 20, 2009 at 02:56:29PM +0800, liu dapeng wrote: > > > It is important to note that, as of this writing, some servers > > > respond with RCODE=3 to a AAAA query even if there is > an A record > > > available for that owner name. Those servers are in clear > > > violation of the meaning of RCODE 3, and it is > expected that they > > > will decline in use as IPv6 deployment increases. > > this means in the early stage of IPv6 depleoyment, many site can not > > access using DNS64+NAT64, I am not sure whether it is a good > > approach... > > Two things: > > 1. Because I was in a hurry last week, I didn't double-check the > results that Dan posted. Simon since has, and it appears that > there were few, if any, actual RCODE=3 responses for AAAA when the > RNAME had an A record. So I think the text you quoted should be > removed from the draft. I'm quite sure I've seen cases of Name > Error for a AAAA that was outside the RFCs (because I will > confidently predict that, if it is possible to mess up the > implementation of DNS in any way, someone has in fact done it). > But I don't think this is a widely deployed problem, and I was > mildly surprised by the extent of Dan's report. Concur - please remove that text. (I was going to say that in my WGLC review.) Thanks for your consideration of the problem, though. Once Simon pointed out that querying those same nameservers for A gave the same result as querying for AAAA, I see the problem is not with AAAA but rather with the nameservers themselves. -d > 2. If there are in fact such deployed servers today, they are > frankly already so broken that it's a wonder they work at all. I > have no hesitation in saying that they're irredeemable and need to > be fixed, even if that causes DNS64 to work slightly less well > than we'd prefer. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Mon Dec 21 16:21:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12C43A6879 for ; Mon, 21 Dec 2009 16:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW7oQrtmBkPn for ; Mon, 21 Dec 2009 16:21:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 909CD3A67EC for ; Mon, 21 Dec 2009 16:21:46 -0800 (PST) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4CB2D2150D for ; Mon, 21 Dec 2009 19:21:30 -0500 (EST) Message-ID: <4B301109.8000306@viagenie.ca> Date: Mon, 21 Dec 2009 19:21:29 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> In-Reply-To: <20091221222444.GM59143@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 00:21:48 -0000 On 12/21/2009 05:24 PM, Andrew Sullivan wrote: > On Mon, Dec 21, 2009 at 05:04:26PM -0500, Simon Perreault wrote: >> I don't see why. If the cache doesn't contain a given AAAA synthetic record, the >> server will try to get it from upstream. That is, unless negative caching is >> involved, but it shouldn't be when you just put stuff from the additional >> section into the cache. > > Only if your DNS64 is sane. I agree it shouldn't normally be a > problem, but I would not be at all surprised to see someone get this > detail wrong. (Remember that some caches are going to assume that the > cached additional is all that is available, and if the data is there > it must have been useful. Or something. Honestly, I don't fully > understand how some of the stranger implementations one sees get that > way.) I understand now. Thank you very much for taking the time to explain this to me. > The alternative, which is what Mark suggested before, (and has just > done again in this thread) is to truncate the additional. We didn't > get anyone else supporting that option when it was proposed last time. > But unaltered additional on the "inside" of the DNS64 is, frankly, > useless anyway, so the more I think about it the more attractive that > option is to me. Does anything need it? I think this is an operational issue and the spec doesn't need to address it. The environmental conditions that give rise to these concerns may very well change over the lifetime of DNS64. So at most leave it configurable (e.g. minimal-responses with Bind). I'd prefer for the spec to be silent on this. Thanks again, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Tue Dec 22 09:35:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FF53A6A0C for ; Tue, 22 Dec 2009 09:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Umorxm3RGBJ for ; Tue, 22 Dec 2009 09:35:39 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 453183A6A45 for ; Tue, 22 Dec 2009 09:35:39 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBMHYbCs034901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2009 18:34:37 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20091221222444.GM59143@shinkuro.com> Date: Tue, 22 Dec 2009 18:35:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> References: <1C86A9DE-74D2-4FC9-9179-CF595B4A9704@muada.com> <4B2E5B84.9010708@viagenie.ca> <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 17:35:40 -0000 On 21 dec 2009, at 23:24, Andrew Sullivan wrote: > Only if your DNS64 is sane. I agree it shouldn't normally be a > problem, but I would not be at all surprised to see someone get this > detail wrong. (Remember that some caches are going to assume that the > cached additional is all that is available, and if the data is there > it must have been useful. Or something. Honestly, I don't fully > understand how some of the stranger implementations one sees get that > way.) Don't forget that we're talking about new deployments here: we don't = have a decade long history of craptastic boxes to work around. There are = probably only one or two boxes out there that actually do all this over = IPv6 today. So we have an opportunity to tell the home gateway etc = vendors to get it right. (See also the homegate bof.) About truncating the additional section: aren't we setting ourselves up = for some nasty bugs come the time people start running hybrid = authoritative/DNS64 servers? And are there any performance / cache hit issues with truncating the = additional section? Iljitsch From ajs@shinkuro.com Tue Dec 22 09:44:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1C03A6A41 for ; Tue, 22 Dec 2009 09:44:09 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiWDGd7jDIP6 for ; Tue, 22 Dec 2009 09:44:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D37AA3A6A36 for ; Tue, 22 Dec 2009 09:44:08 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 86A452FE8CDE for ; Tue, 22 Dec 2009 17:43:51 +0000 (UTC) Date: Tue, 22 Dec 2009 12:43:49 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091222174349.GB67893@shinkuro.com> References: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 17:44:09 -0000 On Tue, Dec 22, 2009 at 06:35:11PM +0100, Iljitsch van Beijnum wrote: > Don't forget that we're talking about new deployments here: we don't > have a decade long history of craptastic boxes to work around. There > are probably only one or two boxes out there that actually do all > this over IPv6 today. So we have an opportunity to tell the home > gateway etc vendors to get it right. (See also the homegate bof.) If you have a look at the work that Ray Bellis and his colleagues did about gateways, you will discover that there's a lot of home gear available from stores today (well, last year, but whatever) that get this all horribly wrong. DNS is not hard, but it is tricky, and a poor familiarity with the history and the RFCs will make one prone to simple foolish mistakes. I doubt this case is any different: the dns64 draft requires the reader to understand DNS already. > About truncating the additional section: aren't we setting ourselves > up for some nasty bugs come the time people start running hybrid > authoritative/DNS64 servers? Well, first, Don't Do That (tm). There's a long history of recommendations that one not run iterative and authoritative in the same server. The reason for this is simply that it has been the source of numerous bugs and configuration errors, most of which are all but impossible to comprehend for someone who doesn't already understand DNS. But secondly, the whole point here is that we don't want anyone relying on the additional data that might have filtered through a DNS64. So if there's an authority server that is somehow getting data out of cache that might have been fiddled with by DNS64, we can be pretty sure it's never going to work right. That seems like a poor implementation to me. > And are there any performance / cache hit issues with truncating the > additional section? I'm not worried about the cache hit, but any rewriting of the message is automatically going to cause performance hits by definition. And of course, if glue's not available from a cache, you have to fetch it. But that was always going to be a disadvantage of this work unless we rewrote the additional section, and that (as Mark argued correctly at Stockholm) will break in a much more puzzling way. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Tue Dec 22 09:48:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1F13A68CF for ; Tue, 22 Dec 2009 09:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH9-GvORzAVP for ; Tue, 22 Dec 2009 09:48:26 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id D74653A68A2 for ; Tue, 22 Dec 2009 09:48:25 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBMHlLrx034996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2009 18:47:22 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20091222174349.GB67893@shinkuro.com> Date: Tue, 22 Dec 2009 18:47:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C79497C-B901-4EDA-84B2-599DBF212A2C@muada.com> References: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> <20091222174349.GB67893@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 17:48:27 -0000 On 22 dec 2009, at 18:43, Andrew Sullivan wrote: >> Don't forget that we're talking about new deployments here: we don't >> have a decade long history of craptastic boxes to work around. There >> are probably only one or two boxes out there that actually do all >> this over IPv6 today. So we have an opportunity to tell the home >> gateway etc vendors to get it right. (See also the homegate bof.) > If you have a look at the work that Ray Bellis and his colleagues did > about gateways, you will discover that there's a lot of home gear > available from stores today (well, last year, but whatever) that get > this all horribly wrong. Yes, but I don't think any of that stuff is running IPv6. We get to = leave those boxes behind and make a fresh start with IPv6, where we have = the chance to get most of this right (of course in a few years we'll = discover what new stuff we got wrong). From joelja@bogus.com Tue Dec 22 13:15:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF1E28C0F3 for ; Tue, 22 Dec 2009 13:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juL1UqhyFWH1 for ; Tue, 22 Dec 2009 13:15:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 0859B28C0F2 for ; Tue, 22 Dec 2009 13:15:20 -0800 (PST) Received: from [192.168.11.104] (c-67-189-76-178.hsd1.wa.comcast.net [67.189.76.178]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id nBMLEweW085000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 21:15:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4B3136CC.8070103@bogus.com> Date: Tue, 22 Dec 2009 13:14:52 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> <20091222174349.GB67893@shinkuro.com> <1C79497C-B901-4EDA-84B2-599DBF212A2C@muada.com> In-Reply-To: <1C79497C-B901-4EDA-84B2-599DBF212A2C@muada.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 22 Dec 2009 21:15:03 +0000 (UTC) Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:15:21 -0000 Iljitsch van Beijnum wrote: > On 22 dec 2009, at 18:43, Andrew Sullivan wrote: > >>> Don't forget that we're talking about new deployments here: we don't >>> have a decade long history of craptastic boxes to work around. There >>> are probably only one or two boxes out there that actually do all >>> this over IPv6 today. So we have an opportunity to tell the home >>> gateway etc vendors to get it right. (See also the homegate bof.) > >> If you have a look at the work that Ray Bellis and his colleagues did >> about gateways, you will discover that there's a lot of home gear >> available from stores today (well, last year, but whatever) that get >> this all horribly wrong. > > Yes, but I don't think any of that stuff is running IPv6. We get to leave those boxes behind and make a fresh start with IPv6, where we have the chance to get most of this right (of course in a few years we'll discover what new stuff we got wrong). This isn't really a safe assumption anymore... cpe (from cisco/linkys d-link apple etc) that I see down at the local offciemax/bestbuy has ipv6 ready and windows vista logos applied. This stuff has whatever dodgy v4 implmentation it had plus whatever it chooses to do for v6 to meet that vista logo compliance requirement you can bet it does 6to4, given time to market (the firmware on my d-link was from april) that ship has sailed and we'll be living with it for quite some time. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Tue Dec 22 13:23:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1553A6884 for ; Tue, 22 Dec 2009 13:23:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12J3OgKJuqSQ for ; Tue, 22 Dec 2009 13:23:09 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 3370E3A68E7 for ; Tue, 22 Dec 2009 13:23:09 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBMLM80q038602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2009 22:22:09 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B3136CC.8070103@bogus.com> Date: Tue, 22 Dec 2009 22:22:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92A34C63-0CC8-4852-9A96-BA14810B0BDF@muada.com> References: <20E57070-7B75-4078-92A5-1D4AF21F3F56@shinkuro.com> <4B2E99E0.5090700@viagenie.ca> <20091221152031.GA59143@shinkuro.com> <4B2F9AF7.3020504@viagenie.ca> <20091221160924.GE59143@shinkuro.com> <4B2FA450.2060301@viagenie.ca> <20091221214140.GK59143@shinkuro.com> <4B2FF0EA.7030203@viagenie.ca> <20091221222444.GM59143@shinkuro.com> <6D9A21DC-0D43-449A-95DB-22AB6577E6F9@muada.com> <20091222174349.GB67893@shinkuro.com> <1C79497C-B901-4EDA-84B2-599DBF212A2C@muada.com> <4B3136CC.8070103@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1077) Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 interaction with plain resolvers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:23:10 -0000 On 22 dec 2009, at 22:14, Joel Jaeggli wrote: >> Yes, but I don't think any of that stuff is running IPv6. We get to = leave those boxes behind and make a fresh start with IPv6, where we have = the chance to get most of this right (of course in a few years we'll = discover what new stuff we got wrong). > This isn't really a safe assumption anymore... cpe (from cisco/linkys > d-link apple etc) that I see down at the local offciemax/bestbuy has > ipv6 ready and windows vista logos applied. This stuff has whatever > dodgy v4 implmentation it had plus whatever it chooses to do for v6 to > meet that vista logo compliance requirement you can bet it does 6to4, > given time to market (the firmware on my d-link was from april) that > ship has sailed and we'll be living with it for quite some time. I'm pretty sure the worst IPv6 CPEs are still much better than the worst = IPv4 CPEs with regard to DNS issues.= From xuxh@huawei.com Tue Dec 22 20:36:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F963A679C for ; Tue, 22 Dec 2009 20:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgA10Re8bUZM for ; Tue, 22 Dec 2009 20:36:26 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5744E3A68FE for ; Tue, 22 Dec 2009 20:36:26 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV30013Z8S7MB@szxga02-in.huawei.com> for behave@ietf.org; Wed, 23 Dec 2009 12:36:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV3002HL8S7JF@szxga02-in.huawei.com> for behave@ietf.org; Wed, 23 Dec 2009 12:36:07 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV30077K8S6FL@szxml04-in.huawei.com> for behave@ietf.org; Wed, 23 Dec 2009 12:36:07 +0800 (CST) Date: Wed, 23 Dec 2009 12:36:06 +0800 From: Xu Xiaohu In-reply-to: <0a5901ca826b$09e84910$c4f0200a@cisco.com> To: 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <007601ca8389$7161bf30$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcqB3q7ePPOJ893wQ2OMdc74GevqDgAi7lCwAEcZk7A= Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 04:36:27 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C222=C8=D5 2:26 > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----Original Message----- > > From: Xu Xiaohu [mailto:xuxh@huawei.com] > > Sent: Sunday, December 20, 2009 5:41 PM > > To: 'Dan Wing'; 'marcelo bagnulo braun' > > Cc: behave@ietf.org > > Subject: re: [BEHAVE] Reason(s) for Modified EUI-64 format to > > apply to ALLnon-0::/3 IPv6 addresses ? > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C218=C8=D5 16:50 > > > =CA=D5=BC=FE=C8=CB: 'Xu Xiaohu'; 'marcelo bagnulo braun' > > > =B3=AD=CB=CD: behave@ietf.org > > > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > > > ALLnon-0::/3 IPv6 addresses ? > > > > > > > > > > > > > +-------------------+ > > > > > > > | | > > > > > > > +-------------+ | IPv6 Internet | > > +--------------+ > > > > > > > | +---+ > > +---++---++ IPv4 only > > > > > > > | IPv6 only | +-------------------+ > > |NAT64| | > > > > > > > | +-----+ | > > ++---++ +-----+| > > > > > > > | | H1 | | +-------------------+ | > > | H2 || > > > > > > > | +-----+ NAT64?- + +---+ > > +-----+| > > > > > > > +-------------+ | IPv4 Internet | > > +--------------+ > > > > > > > | | > > > > > > > +-------------------+ > > > > > > > If I understand your statement correctly, An IPv6 only = site > > > > > > > (e.g., left site > > > > > > > in the above figure) MUST have a connection to the IPv4 > > > > > > > Internet via NAT64 > > > > > > > in order to access hosts located in an IPv4 only site = (e.g., > > > > > > > right site in > > > > > > > the above figure). Besides, the IPv6 only host > > (e.g. H1) MUST > > > > > > > be able to > > > > > > > synthesize IPv6 address by itself. If either of the > > above two > > > > > > > conditions is > > > > > > > not satisfied, the communication between H1 and H2 is > > > > impossible. > > > > > > > > > > > > Yep -- because IPv4-only applications don't know anything > > > > about IPv6 > > > > > addresses > > > > > > -- IPv4-only applications don't know how to parse IPv6 > > > > addresses, how to > > > > > > include them in referrals, etc. > > > > > > > > > > Note that H1 in the above scenario is IPv6 only, but not > > > > IPv4 only. Hence > > > > > I'm wondering whether the statement you made is relevant to > > > > the above > > > > > scenario. > > > > > > > > Let me explain the scenario a bit more, in the above scenario, = the > > > > communication is initiated by H1 (IPv6 only host), but not H2 > > > > (IPv4 only > > > > host). To make that communication possible, should a > > NAT64 be deployed > > > > between the IPv6 only site (left site) and the IPv4 Internet > > > > although there > > > > is already a NAT64 between the IPv4 site (right site) and the > > > > IPv6 Internet? > > > > If so, what's the meaning of IPv6 Internet to IPv4 > > network scenario? > > > > > > The "IPv6 Internet to IPv4 network" scenario applies to the > > ISP on the > > right. > > > > > > Detail: > > > > > > The ISP on the left is a business, and they made the > > decision to operate > > an > > > IPv6-only network with IPv6-only hosts. Their subscribers > > want access to > > > (and/or from) the IPv4 Internet, so that ISP provides a NAT64 (and > > associated > > > DNS64, of course). This is the "an IPv6 network to the > > IPv4 Internet" > > > scenario (when the connection is initiated from the IPv6 > > host) and is the > > "the > > > IPv4 Internet to an IPv6 network" (when the connection is > > initiated from > > the > > > IPv4 side). Note that a stateful NAT64 will generally not > > support "the > > IPv4 > > > Internet to an IPv6 network" unless port mappings are > > configured on the > > > stateful NAT64. > > > > > > The ISP on the right is another, separate business, and > > they made the > > decision > > > to keep their subscribers running IPv4. Their subscribers > > want access to > > > (and/or from) the IPv6 Internet. This is "an IPv4 network > > to the IPv6 > > > Internet" (when the connection is initiated from the IPv4 > > side) and is > > "the > > > IPv6 Internet to an IPv4 network" (when the connection is > > initiated from > > the > > > IPv6 side). > > > > > > +-------------+ > > | IPv6 only | > > | +-----+ | > > | | H3 | | > > | +-----+ | > > +------+------+ > > | > > +---------+---------+ > > | | > > +-------------+ | IPv6 Internet | > > +----------------+ > > | +------+ +-----+-+-----+ > > IPv4 only| > > | IPv6 only | +-------------------+ |NAT64-2| > > | > > | +-----+ | +-+-----+ > > +-----+| > > | | H1 | +-------+ +-------------------+ | > > | H2 || > > | +-----+ |NAT64-1+- + +------+ > > +-----+| > > | DNS64 +--+----+ | IPv4 Internet | > > +----------------+ > > +-------------+ | | > > +-------------------+ > > > > In the above scenario, if H3 and H1 send a DNS query for the > > AAAA record of > > H2 respectively, they should obtain different results, e.g., > > H3 gets an IPv6 > > address which is synthesized with a NSP used by NAT64-2, > > while H1 receives > > an IPv6 address which is synthesized with a WKP used by > > NAT64-1. That's to > > say, the authoritative DNS server for H2 will return an IPv6 > > address which > > is synthesized with a NSP used by NAT64-2 to a DNS client > > which is an IPv6 > > only host without NAT64 (e.g., H3), while returned a null to those = DNS > > clients which is either an IPv6 only host with NAT64 (e.g., H1) or a > > dual-stack host. The latter DNS clients or their DNS64 will > > send a DNS query > > for A record once the resolution for AAAA record fails.). > > > > Is the above statement in accordance with your assumption? >=20 > No. >=20 > In all cases, because H2's network is operating a NAT64, its > network will also return AAAA's that cause incoming IPv6 > connections to be translated to IPv4 and to be routed to > H2. >=20 > Those AAAAs might be static or might be dynamically > created by the DNS64 function operated by H2's network. I agree, so the statement made by Marcelo in the previous discussion is = not true. See = http://www.ietf.org/mail-archive/web/behave/current/msg07696.html. Then how about synthesizing the above AAAAs with a specific NSP which = starts with a special binary value (depicted as follows)? That is to say, the specific NSP is a 96/ prefix which starts with a well-known binary = (e.g., 00010101) while the remaining part is network specific. +--------+--------------------------------+-----------------+ |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| +--------+--------------------------------+-----------------+ This specific NSP is topologically aggregatable, hence it will not = result in routing scalability issues in the IPv6 internet. In addition, since it begins with a special binary value, the synthetic IPv6 addresses with = such a prefix can be easily distinguished from ordinary IPv6 addresses. Xiaohu =20 > > If so, how does > > the authoritative DNS server for H2 determine whether the DNS > > client (e.g., > > H1, H3) is an IPv6 only host w/o NAT64 or an IPv6 only host > > but with NAT64 > > (or even dual-stack host)? > > > > Xiaohu > > From huitema@microsoft.com Tue Dec 22 23:19:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987D928C0E6 for ; Tue, 22 Dec 2009 23:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlOV9E-lhXf5 for ; Tue, 22 Dec 2009 23:19:20 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7611B3A6951 for ; Tue, 22 Dec 2009 23:19:20 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Dec 2009 23:19:36 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.20; Tue, 22 Dec 2009 23:19:04 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 22 Dec 2009 23:19:03 -0800 From: Christian Huitema To: Xu Xiaohu , 'Dan Wing' , "'marcelo bagnulo braun'" Thread-Topic: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? Thread-Index: AQHKg4l7aUXh78SbWUm9Nlr2w13AN5FyNZpg Date: Wed, 23 Dec 2009 07:19:00 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200BCC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <0a5901ca826b$09e84910$c4f0200a@cisco.com> <007601ca8389$7161bf30$e30c6f0a@china.huawei.com> In-Reply-To: <007601ca8389$7161bf30$e30c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 07:19:21 -0000 > Then how about synthesizing the above AAAAs with a specific NSP which sta= rts > with a special binary value (depicted as follows)? That is to say, the > specific NSP is a 96/ prefix which starts with a well-known binary (e.g., > 00010101) while the remaining part is network specific. >=20 > +--------+--------------------------------+-----------------+ > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > +--------+--------------------------------+-----------------+ > > > This specific NSP is topologically aggregatable, hence it will not result= in > routing scalability issues in the IPv6 internet. In addition, since it > begins with a special binary value, the synthetic IPv6 addresses with suc= h a > prefix can be easily distinguished from ordinary IPv6 addresses. To do that, we would need to define a new class of IPv6 prefixes, with new = registry to manage the allocations. That seems like a big operational probl= em.=20 Also, you mention that these new IPv6 prefixes would be topologically aggre= gatable. That is only true if we allow the prefixes to be used for a variet= y of address allocations, e.g. both translation and allocation of regular I= Pv6 addresses. But if we do that, the well known binary prefix will become = meaningless. It seems that you are trying really hard to make sure that addresses constr= ucted by translation can be easily distinguished from regular IPv6 addresse= s. But why is that such a big issue? At worst, it means that some connectio= n will be a little bit slower than normally expected. This happens all the = time in multihoming scenario, without translation. -- Christian Huitema =20 From iljitsch@muada.com Tue Dec 22 23:37:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5423A67A8 for ; Tue, 22 Dec 2009 23:37:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvLSzYGtV1je for ; Tue, 22 Dec 2009 23:37:51 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 7FBE83A65A6 for ; Tue, 22 Dec 2009 23:37:51 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBN7aqsc045235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Dec 2009 08:36:53 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Dec 2009 08:37:26 +0100 Message-Id: To: Behave WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [BEHAVE] Some fragmentation issues X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 07:37:52 -0000 Listening to the Hiroshima MP3s, I came upon the discussion on how to = handle fragments, in particular with UDP zero checksums. First, the attacks that Marcelo talked about are mostly avoided simply = enforcing that the whole transport header is in the first fragment and = not in any other fragments. So the first fragment must be at least 80 = bytes or so (don't talk to me about the 68 bytes in RFC 791, this is = just a theoretical minimum, not something any sane person would ever = use) and non-initial fragments must have an offset of > 80 bytes. Second, I don't think going out of our way to support fragmented UDP = packets with checksum 0 makes sense. I'd say: recompute the checksum if = you get a whole UDP packet with checksum 0, but don't bother = reassembling packets just for this purpose. This is especially relevant = for stateless translators which can translate fragments individually = even out of order, but would have to buffer and reassemble UDP fragments = just in case the checksum has to computed. Both UDP with checksum 0 and fragmented UDP are rare. The intersection = must be extremely rare. Especially as in an earlier discussion the main = use of UDP with checksum 0 was identified as VoIP, where packets are = never large enough to warrant fragmentation.= From phdgang@gmail.com Wed Dec 23 01:24:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C2D3A6824 for ; Wed, 23 Dec 2009 01:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1UJdgQzsWPA for ; Wed, 23 Dec 2009 01:24:38 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 23C4F3A67E2 for ; Wed, 23 Dec 2009 01:24:38 -0800 (PST) Received: by iwn33 with SMTP id 33so4941860iwn.29 for ; Wed, 23 Dec 2009 01:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eZnSMBPDVZA2YLgtREKspUtMxsvqVmkzLHKEPWmR3k4=; b=F0vh6AWeVsF0zAjS7SnNSumY7ZLXvu7vN0W/wmPz481ZD53bf2WYUMholAzy5T7YcL B2JyZx1sFcAfGaPrz27WuEl4xOKlbstdrNvX3ZsBNGZhG0jy0ukU8zgCe2Pj7Iqysik3 cv/ibXMlDdyIwZXV6mTxIDSjphTI/Qh2tQSOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jsl/XxsLadJNxIBzHeB7wfvkMeCX87OPOdBkNh6W2SgBlJJRrDaryMlQwEjqx7JHy3 r+MkEeNqAz3GvakH7csreRB2vWkEp+w8lfrfh7gYKlyH1ruK805Yq3mR1oYrxiMYswfx ki9cTCte3ZfxE5vpYaG1xbO7FkkRJfFU/DZus= MIME-Version: 1.0 Received: by 10.231.25.199 with SMTP id a7mr867936ibc.51.1261560258618; Wed, 23 Dec 2009 01:24:18 -0800 (PST) In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211FFD54@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <004201ca77e4$05d3dce0$d40c6f0a@china.huawei.com> <4B1EC795.7040407@gmail.com> <36ba02b00912200528o2c0fc8d2n9dbd96f86e57cadc@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FF7B1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912202256q266c2619r9eb3e803a6ba723d@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FFC28@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <36ba02b00912210836r593f9520td2a2f21e9b0a947a@mail.gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA211FFD54@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 23 Dec 2009 17:24:18 +0800 Message-ID: <36ba02b00912230124n1c979d6brcf531f69df7e5c9d@mail.gmail.com> From: GangChen To: Christian Huitema Content-Type: multipart/alternative; boundary=00151774121813e51c047b61e362 Cc: Behave WG , "eric.burgey@orange-ftgroup.com" , "xing@cernet.edu.cn" Subject: Re: [BEHAVE] address-format: bits 64 to 71 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 09:24:39 -0000 --00151774121813e51c047b61e362 Content-Type: text/plain; charset=ISO-8859-1 2009/12/22 Christian Huitema > >>> How about this: "When using a /96 prefix, except the WKP that start > with the binary > >>> value 000, the administrators MUST ensure that the bits 64 to 71 are > set to zero." > >> > >> Except this requirement applies to "administrators", who cannot > legitimately obtain a prefix > >> in ::/8. These prefixes can only be defined by IETF action. > > > > Does this requirement only apply to the NSP that administrators can > legitimately obtain? > > By opposition to administrator who decide to ignore IETF recommendations > and do their own thing? I don't think RFC need to cater to those. Do you? > In other words, that only applies to the NSP. Thanks for the clarification. BRs Gang > > -- Christian Huitema > > > > > > --00151774121813e51c047b61e362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/12/22 Christian Huitema &= lt;huitema@microsoft.com>
>>> How about this:=A0 "When using a /96 pr= efix, except the WKP that start with the binary
>>> value 000, = the administrators MUST ensure that the bits 64 to 71 are set to zero."= ;
>>=A0
>> Except this requirement applies to "administra= tors", who cannot legitimately obtain a prefix
>> in ::/8. Th= ese prefixes can only be defined by IETF action.
>=A0
> Does=A0= this requirement only apply=A0to the NSP that administrators can legitimate= ly obtain?=A0

By opposition to administrator who decide to ignore IETF recommen= dations and do their own thing? I don't think RFC need to cater to thos= e. Do you?
=A0
=A0
In other words, that only applies=A0to the NSP.
Thanks for the clarification.
=A0
BRs
=A0
Gang
=A0
=A0

-- C= hristian Huitema



=A0


--00151774121813e51c047b61e362-- From iljitsch@muada.com Wed Dec 23 02:03:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64043A695C for ; Wed, 23 Dec 2009 02:03:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D0sxaOjT0IA for ; Wed, 23 Dec 2009 02:03:03 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id A54E93A690C for ; Wed, 23 Dec 2009 02:03:02 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNA20vP047149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Dec 2009 11:02:01 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Dec 2009 11:02:35 +0100 Message-Id: To: Behave WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 10:03:04 -0000 This is my review of draft-ietf-behave-address-format-03 I've been listening to the audio archives of the sessions in Hiroshima, = and I must say that I'm very surprised. One after another, people at the = microphone spoke out for simplicity. But I don't find this reflected in = the document. Apparently, the authors got swept away by considering how to best solve = a bunch of problems and thereby losing sight of whether these problems = needed solving in the first place, and whether those solutions should be = IETF standards track. In my opinion, the document needs to be rewritten such that it only = contains the text about a /96 well-known prefix and explains that = service providers are free to use their own address space for IPv6-IPv4 = translation as well, and stop there. Unless I missed something, the push to include specifications of how use = a non /96 prefix and/or non-WKP prefix came from a very small group of = people, I see no evidence that this is something that the industry as a = whole is interested in. As such, it makes much more sense to keep all of = this out of this document and create a separate document that describes = all of this if and when desired, rather than tie all this complexity to = the current NAT64 effort. The complexity that I'm talking about is additional logic in DNS64 and = translator implementations, possible additional configuration settings = that must be managed, increased difficulty when troubleshooting and = constructing individual mapped addresses by hand. I also consider = prefixes shorter than /64 wasteful, shorter than /48 unacceptably so. Apart from that, there are two things missing from the document: The first is a discussion how a well known prefix allows for referals = that work between hosts using different translators, while a network = specific prefix doesn't. Second, the document needs to update RFC 3484 by making the well known = prefix less preferred than IPv4. So a default policy table would have to = look something like this: Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 --> 64:ff9b::/96 5 1 Details: Let's start on the third line: Obsoletes: 2765 (if approved) This document only talks about the prefix. 2765 is much wider, it = specifies how to translate between IPv4 and IPv6. As such, this document = can't obsolete RFC 2765, at least not on its own. I think this would = need to be "updates". 64:FF9B::/96 It might be useful to first mention this prefix in the form = 0064:FF9B::/96. The first time I saw it I first thought this was in the = 6400:: range rather than the 0064:: range. format is common to both "IPv4-Converted" and "IPv4-Translatable" I guess this explains the presence of definitions of these terms in the = framework document. However, it is very unsatisfying to define something = in one document that is not used in that document and then use it in = another document where it's not defined. Please solve this in some way. = Also see my remarks about terminology in my review of the framework = document. Oh wait, there are terminology definitions in the notations = subsection. Not good enough, first define, then use, not the other way = around. The rest of the subsection, which explains where things are explained = later, is superfluous. In figure 1: counterintuitive that the prefix length comes first, while = it comes last in prefix notation. Adding a / would also help clarity. Why is it "4" and "8" but "zero"? Style guidelines usually say to spell = out numbers upto twelve, but using digits for 0 - 12 could be considered = more appropriate. But in that case it goes for 0, too. addresses constructed using the Well Known Prefix or a /96 Network Specific Prefix may be represented using the alternative form If you link to RFC 2119 it's a very bad idea to use the word "may" in = lower caps. And I think it should be SHOULD. Table 1: I don't think 192.0.2.33 makes for a good example address = because the 0 octet will be compressed away in certain hexadecimal = representations. There's no need to write "Table" with a capital T. The Well-Known Prefix SHOULD NOT be used to construct IPv4- Translatable addresses This is an example of why I dislike inventing terminology: it is = completely unclear to me what this sentence means, I have to go back the = terminology section (which is called "notation") to figure it out. This = sentence should be able to stand on its own, that's more efficient and = makes it possible to quote it out of the context of the document. As to the meaning: I don't think it's made sufficiently clear that the = prefix we're talking about is for representing the IPv4 address space = within the IPv6 adddress space, and NOT for numbering IPv6 hosts from. = If that were well-understood this whole warning wouldn't be necesary. The Well-Known Prefix MUST NOT be used to represent non global IPv4 addresses, such as those defined in [ RFC1918 ]. Doing so would introduce ambiguous IPv6 addresses. Say why this is a bad thing, I assume referrals etc. 3.2. Impact on Inter-Domain Routing Refer to the 6to4 prefix. Also explicitly say that the WKP MUST be = filtered by default unless special arrangements have been made, both in = incoming and outgoing route advertisements. Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network Specific Prefix to their IPv4/IPv6 translation service. Ok, maybe I'm being dense here, but why exactly? combination of the "prefix" and the IPv4 address. In theory, routers should be able to route on prefixes of any length. However, routing on prefixes larger than 64 bits may be slower. Why is this relevant to the discussion at hand? As long as you don't split the IPv4 space into blocks that are routed = differently and don't use the /64 the /96 translation prefix resides in = for something else (both bad ideas) there is no issue.=20 If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6 address, leading to excellent routing properties.=20 Right, because we want to route every translated IPv4 address = individually It would be ridiculous to waste a network specific /32 for this purpose, = even if someone were to consider routing every IPv4 address a useful = feature. Intermediate prefix lengths such as /40, /48 or /56 appear as compromises. Only some of the IPv4 bits are part of the /64 prefixes. Reverse path checks, in particular, may have a limited efficiency. One more reason to reject the idea of splitting the translated IPv4 = space into smaller pieces. The stateful nature of the translation creates a potential stability issue when the organization deploys multiple translators. If several translators use the same prefix, there is a risk that packets belonging to the same connection may be routed to different translators as the internal routing state changes. This issue can be mitigated either by assigning different prefixes to different translators, or by ensuring that all translators using same prefix coordinate their state. Nonsense. You mitigate the issue by making sure routing delivers packets = consistently to the same translator. The Well Known Prefix SHOULD be used in most scenarios, with two exceptions: o In all scenarios, the translation MAY use a Network Specific Prefix, if deemed appropriate for management reasons. A SHOULD doesn't preclude a MAY of the opposite so this point is = superfluous. In the case of stateless translation, there would be no need for the translator to recompute complement to 1 checksum if both the IPv4- Translatable addresses and the IPv4-Converted address were constructed in a "checksum-neutral" manner, More generally: if the combination of both address is checksum-neutral. = So in theory it's possible to choose any source address and then select = the (destination) translation addresses such that they compensate for = the checksum difference between the IPv6 source address and IPv4 source = address. In current scenarios that's not of much use but it could be in = a NAT464 or some such scenario, where it might be useful to compensate = the checksum differences in the source address. Not sure though why these bits would have to go in a suffix rather than = the prefix. 5. IANA Considerations The Well Known Prefix falls into the range ::/8 reserved by the IETF. The prefix definition does not require an IANA action. IANA would still have to put the WKP in = http://www.iana.org/assignments/ipv6-address-space/ though. From iljitsch@muada.com Wed Dec 23 02:53:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181A43A68D4; Wed, 23 Dec 2009 02:53:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0QpVFQfyZIN; Wed, 23 Dec 2009 02:53:50 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id B15B93A6853; Wed, 23 Dec 2009 02:53:49 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNAqlAC047461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 11:52:47 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Dec 2009 11:53:22 +0100 Message-Id: <400F18A5-235F-4BB3-85B7-76F7B7EA3CFB@muada.com> To: Behave WG , softwires@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [BEHAVE] MSS and NAT64 / DS-lite parity X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 10:53:51 -0000 [Note that I'm not up to date with softwires work, but after Alain's = comment about the MSS in the behave session in Hiroshima it seems = prudent to send this to the softwires list, too.] I was quite annoyed to hear the discussion about MSS clamping in the = audio file from the behave session in Hiroshima, because I've written = several messages about this in the summer, that, as far as I'm = concerned, put the issue to bed but apparently nobody remembered that. http://www.ietf.org/mail-archive/web/behave/current/msg06838.html http://www.ietf.org/mail-archive/web/behave/current/msg07180.html http://www.ietf.org/mail-archive/web/behave/current/msg07258.html Specifically: "I don't think it's worth the trouble to do this. The common situation = will be for all the systems involved tohave 1500-byte MTUs. In that = case, the IPv6 host will advertise a 1440- byte MSS (1500 - 40 bytes = IPv6 - 20 bytes TCP) so the IPv4 host will send TCP packets of 1480 = bytes (1440 + 20 bytes IPv4 + 20 bytes IPv4) which the translator then = translates into 1500-byte IPv6 packets." In short: when both ends use 1500-byte MTUs everything works without any = PMTUD dependencies. However. In my opinion, it would be very beneficial to have a single translator = implementation that can do both stateful NAT64 as well as provide = termination and NAT in DS-lite deployments. In DS-lite where a CPE does = the encapsulation, the hosts on either side think they can send full = size packets (which I'll assume are 1500 bytes) while in fact the extra = IPv6 header reduces this by 40 bytes. Even if we compress away the = entire IPv4 header that only brings back 20 bytes so we're still 20 = bytes short. So either a DS-lite NAT or a DS-lite CPE would have to perform MSS = clamping to avoid hitting all those PMTUD black holes that exist in the = IPv4 internet. Although MSS clamping itself is not something that is = stateful, in my opinion it is much uglier to do this in a stateless box = than a stateful box. So I would want to do this in a DS-lite NAT, and, = to maintain parity between DS-lite and stateful NAT64, perhaps in a = stateful NAT64 translator, but not in a DS-lite CPE or a stateless = IPv6-IPv4 translator. Another way to go would of course be to increase the MTU on the IPv6 = path to something that accommodates an encapsulated 1500-byte IPv4 path. = Not sure how realistic that is, but I know I would be asking for that if = I were buying a few million DS-lite capable CPEs. About the DS-lite / NAT64 translator parity and IPv4 header compression: The argument has been made that encapsulating IPv4 in IPv6 is cleaner = than translating IPv4 to IPv6 and then back to IPv4. However, that is a = very abstract argument. Something much more tangible is the ability to = use the same code and boxes to handle both NAT64 and DS-lite. So let's = look at the details: IP: Header fields can be pretty much 464 translated without loss of = information. The issues with the implied DF=3D1 in IPv6 and minimum MTU = of 1280 aren't necessary here, but as far as I can tell, there is no = harm in applying the workarounds that are necesary for 64 or 46 to 464 = as well. TCP: In principle, no issues. Only the checksum has to be recomputed. = However, see maximum packet size issues, but these apply regardless of = translation vs encapsulation. UDP: The same as TCP, except the checksum =3D 0 issue. A translator inserting = a valid checksum where there wasn't one before poses no problems and a = translator could also just forward packets with the 0 checksum when = inserting one isn't possible or desirable. ICMP: There are many ICMP types. Some can be translated without loss of = information, but not all can, especially ones that are defined after a = translator is deployed. However, dropping ICMP messages, especially = undefined/obscure ones, doesn't break applications. So basically it's doable to have a CPE translate IPv4 packets to IPv6, = which are then translated back into IPv4 by a "real" NAT64, without = breaking perceptibly more than what would break in NAT444, too. The only thing that needs to happen for this to work is that a DS-lite = CPE maintains a separate IPv6 source address for any IPv4 client that it = serves. So basically, this requires an additional /64 for this purpose. = If the CPE chooses the IPv6 address for each of the IPv4 clients such = that the whole thing becomes checksum neutral the CPE doesn't have to = look inside TCP or UDP packets, and the only additional complexity is = the translation of ICMP messages. For outgoing messages it could just = send the IPv4 ICMP message, which the NAT64 can then NAT44 (which is = simple), but without knowing whether it's talking to an IPv6 host or an = IPv4 host behind DS-lite the NAT64 wouldn't know whether to NAT64 or = NAT44 ICMP messages coming in from the IPv4 side so it would have to = NAT64 them and then the CPE would have to translate them back to IPv4.= From marcelo@it.uc3m.es Wed Dec 23 03:13:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36F93A69C7 for ; Wed, 23 Dec 2009 03:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciW5gUtw6v2V for ; Wed, 23 Dec 2009 03:13:23 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C383C3A6998 for ; Wed, 23 Dec 2009 03:13:22 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-200-135.dialup.adsl.anteldata.net.uy (unknown [190.132.200.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 7519F7F05BF; Wed, 23 Dec 2009 12:13:02 +0100 (CET) Message-ID: <4B31FB38.7020502@it.uc3m.es> Date: Wed, 23 Dec 2009 12:12:56 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17086.006 Cc: Behave WG Subject: Re: [BEHAVE] Some fragmentation issues X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 11:13:24 -0000 Iljitsch van Beijnum escribió: > Listening to the Hiroshima MP3s, I came upon the discussion on how to handle fragments, in particular with UDP zero checksums. > > First, the attacks that Marcelo talked about are mostly avoided simply enforcing that the whole transport header is in the first fragment and not in any other fragments. So the first fragment must be at least 80 bytes or so (don't talk to me about the 68 bytes in RFC 791, this is just a theoretical minimum, not something any sane person would ever use) and non-initial fragments must have an offset of > 80 bytes. > > Second, I don't think going out of our way to support fragmented UDP packets with checksum 0 makes sense. I'd say: recompute the checksum if you get a whole UDP packet with checksum 0, but don't bother reassembling packets just for this purpose. This is especially relevant for stateless translators which can translate fragments individually even out of order, but would have to buffer and reassemble UDP fragments just in case the checksum has to computed. > > Both UDP with checksum 0 and fragmented UDP are rare. The intersection must be extremely rare. Especially as in an earlier discussion the main use of UDP with checksum 0 was identified as VoIP, where packets are never large enough to warrant fragmentation. > my understanding is that all that you mention is already included in the current version of the draft. could you check it and let me know? Regards, marcelo > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From cb.list6@gmail.com Wed Dec 23 06:30:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA943A68B5 for ; Wed, 23 Dec 2009 06:30:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPNJ7SdrlN0M for ; Wed, 23 Dec 2009 06:30:44 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 72D783A6893 for ; Wed, 23 Dec 2009 06:30:44 -0800 (PST) Received: by ywh15 with SMTP id 15so7467410ywh.5 for ; Wed, 23 Dec 2009 06:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:date:to :message-id:content-type:mime-version; bh=ESRkgzQe0kwXKxTNR+IOPoseO4qTeShOQVBTc8GWR28=; b=TY+ljFR2B4FD7BeL+RnAZ37/UmNsFIjok+Pf58lUm1ZAx7dOfU/J1fBqCx4HeIxFhV m+W4DP4ibRdwYNxBVAeiBjEQApQTTY5Xg0r8RgUOXIpUKSz8/6AelAQ5l5Wu8q0Dk9c9 xr1vXqos+qnxSYopvAb1Pg/j1TaUqpwJ8P+zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:date:to:message-id:content-type:mime-version; b=gPW7A1ToKPyyRHqrPeBKawK+4wCqpikjJ0aA7EJrqxtTti6UAx7EzLN/3RemSFWYyz YrHXjeMab1LLgiz6xI5ESQPIb1i0H5n5HeYwd2fcn5TSVC5oXOIaeUFGwVcpexi9Dlp9 2Szn4MLbdvI4IAdcaM94tUGqlCYvEpHSpDEZs= Received: by 10.150.4.9 with SMTP id 9mr15873053ybd.44.1261578624108; Wed, 23 Dec 2009 06:30:24 -0800 (PST) Received: from localhost (m3f5a36d0.tmodns.net [208.54.90.63]) by mx.google.com with ESMTPS id 6sm3252178yxg.66.2009.12.23.06.30.22 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 06:30:23 -0800 (PST) From: cam byrne Date: Wed, 23 Dec 2009 09:30:17 -0500 To: behave@ietf.org Message-ID: Content-Type: multipart/mixed; boundary="----F85W34LRJ6KRN5QH0SD5G63RC5FU9S" MIME-Version: 1.0 Subject: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:30:45 -0000 ------F85W34LRJ6KRN5QH0SD5G63RC5FU9S Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CgotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tClN1YmplY3Q6IFdrcApGcm9tOiBj YW0gYnlybmUgPGNiLmxpc3Q2QGdtYWlsLmNvbT4KVG86IGJlaGF2ZUBpZXRmLm5ldApDQzogbnVs bAoKSXMgNjQ6ZmY5Yjo6Lzk2IHRoZSBvbmx5IHdlbGwga25vd24gcHJlZml4IG9yIGlzIGFueSBz dWJuZXQgb2YgaXQgd2twPyAgRm9yIGV4YW1wbGUsIGlmIEkgY2FuIGRvIDIgbmF0NjQgc3lzdGVt cyB1c2luZyA2NDpmZjliOjE6Oi85NiBhbmQgNjQ6ZmY5YjoyOjovOTYgaXQgaGVscHMgbWUgc2Nh bGUgbXVsdGlwbGUgbmF0NjQgc3B5c3RlbXMgaW4gdGhlIHNhbWUgcmVnaW9uLCB3aGljaCBpcyBj cml0aWNhbCBmb3IgYSBzZXJ2aWNlIHByb3ZpZGVyLiAgV2l0aG91dCB0aGlzLCBpdCBjYW5ub3Qg YmUgZXhwZWN0ZWQgdGhhdCBhIHNlcnZpY2UgcHJvdmlkZXIgd2lsbCB1c2UgdGhlIHdrcCBzaW5j ZSBzY2FsZSB3aWxsIGJlIGJvdW5kZWQgYnkgdmVuZG9yIGJveCBsaW1pdGF0aW9ucy4gIAoKSSB1 bmRlcnN0YW5kIHRoYXQgaWYgd2UgZG8gdGhpcywgdGhlIGhvc3Qgd29udCBiZSBhYmxlIHRvIGF1 dG9tYXRpY2FsbHkgZGlzY292ZXIgdGhlIGxvY2FsIHdrcCB1bmxlc3Mgd2UgYWxpYXMgdGhlIGJh c2Ugd2twIGFzIGFueWNhc3Qgb24gYWxsIG5hdDY0IHN5c3RlbXMgaW4gYWRkaXRpb24gdG8gZG5z NjQgaGFuZGluZyBvdXQgc3ViLXdrcCwgd2hpY2ggbWF5IG1ha2UgZXZlcnlvbmUgaGFwcHkuICAg VGhpcyB3YXkgd2UgY2FuIHNjYWxlIGxpbmVhcmx5LCBpZGVudGlmeSBuYXQnZCBmbG93cyBhdCB0 aGUgaG9zdCwgYW5kIGVuYWJsZSB0aGUgaG9zdCB0byBwYXNzIG5hdDY0IG1hbnVhbGx5IHdpdGhv dXQgZG5zNjQuCgpUaG91Z2h0cz8gICA= ------F85W34LRJ6KRN5QH0SD5G63RC5FU9S-- From iljitsch@muada.com Wed Dec 23 06:49:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3D13A6878 for ; Wed, 23 Dec 2009 06:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVZXxFO-fgJ8 for ; Wed, 23 Dec 2009 06:49:09 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E23B83A67B2 for ; Wed, 23 Dec 2009 06:49:08 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNEm2DB050148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 15:48:07 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Iljitsch van Beijnum In-Reply-To: <4B31FB38.7020502@it.uc3m.es> Date: Wed, 23 Dec 2009 15:48:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B31FB38.7020502@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Some fragmentation issues X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:49:10 -0000 On 23 dec 2009, at 12:12, marcelo bagnulo braun wrote: > Iljitsch van Beijnum escribi=F3: >> Listening to the Hiroshima MP3s, I came upon the discussion on how to = handle fragments, in particular with UDP zero checksums. >>=20 >> First, the attacks that Marcelo talked about are mostly avoided = simply enforcing that the whole transport header is in the first = fragment and not in any other fragments. So the first fragment must be = at least 80 bytes or so (don't talk to me about the 68 bytes in RFC 791, = this is just a theoretical minimum, not something any sane person would = ever use) and non-initial fragments must have an offset of > 80 bytes. >>=20 >> Second, I don't think going out of our way to support fragmented UDP = packets with checksum 0 makes sense. I'd say: recompute the checksum if = you get a whole UDP packet with checksum 0, but don't bother = reassembling packets just for this purpose. This is especially relevant = for stateless translators which can translate fragments individually = even out of order, but would have to buffer and reassemble UDP fragments = just in case the checksum has to computed. >>=20 >> Both UDP with checksum 0 and fragmented UDP are rare. The = intersection must be extremely rare. Especially as in an earlier = discussion the main use of UDP with checksum 0 was identified as VoIP, = where packets are never large enough to warrant fragmentation. > my understanding is that all that you mention is already included in = the current version of the draft. > could you check it and let me know? If the overlapping fragments issue is addressed, I managed to miss it = when reading the draft. There is no link to a reference for this (unless = it's one of the "message to the ... list ones). The checksum 0 issue is already solved this way in the xlate draft, = sorry I didn't check earlier. I hope to get around to doing a full = review of that draft. In the mean time: When a stateless translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero, the translator SHOULD drop the packet and generate a system management event specifying at least the IP addresses and port numbers in the packet. When it receives fragments other than the first it SHOULD silently drop the packet, since there is no port information to log. How exactly is the translator supposed to know that a non-initial = fragment of a UDP packet is from a UDP packet with a 0 checksum or from = a UDP packet with a valid checksum? I'll answer it myself: that's impossible without waiting for the first = fragment, and doing that defeats the purpose of not handling 0 checksum = packets. So a stateless translator needs to translate the non-initial = fragments in case they belong to a packet with a valid checksum. And = then, for simplicity, may as well forego the 0 checksum check for = initial fragments and translate these as well. The resulting packet will = be dropped by the receiver but at least that way the receiver gets to = clear its reassembly buffers. From iljitsch@muada.com Wed Dec 23 06:54:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8D43A6893 for ; Wed, 23 Dec 2009 06:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-nOms76SyMh for ; Wed, 23 Dec 2009 06:54:08 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id C5A193A680B for ; Wed, 23 Dec 2009 06:54:07 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNEr4Q7050184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 15:53:04 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 23 Dec 2009 15:53:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: cam byrne X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:54:08 -0000 On 23 dec 2009, at 15:30, cam byrne wrote: > Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? = For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and = 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same = region We had some discussion about "weak WKP" and "strong WKP" where strong =3D = everyone knows the values of all the 96 bits, and weak =3D you can = recognize the WKP when you see it, but there are some additional bits in = there that you can't predict so you still need to explicitly learn the = WKP before you can use it. The current draft doesn't address this. With a strong WKP referrals between hosts served by different = translators should work, with a weak WKP this is not necessarily the = case.= From mohamed.boucadair@orange-ftgroup.com Wed Dec 23 06:54:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89B43A68A6 for ; Wed, 23 Dec 2009 06:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH0C1qRt7Dpo for ; Wed, 23 Dec 2009 06:54:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id C46BC3A6893 for ; Wed, 23 Dec 2009 06:54:46 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 085B8324776; Wed, 23 Dec 2009 15:54:29 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D8EB235C06F; Wed, 23 Dec 2009 15:54:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 23 Dec 2009 15:54:28 +0100 From: To: cam byrne , "behave@ietf.org" Date: Wed, 23 Dec 2009 15:54:27 +0100 Thread-Topic: [BEHAVE] Wkp Thread-Index: AcqD3Hy4spFiCyKGTNe9SPbnghHP9QAAlTrA Message-ID: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.10.40326 Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:54:47 -0000 Dear Cameron, The current version of I-D.ietf-behave-address-format does not prevent you = to use sub prefixes belonging to the WKP. Nevertheless, operational issues = induced by the enforcement of such policy (e.g., for traffic engineering pu= rposes) are out of scope of I-D.ietf-behave-address-format.=20 IMHO, these considerations (and others such as how to ensure traffic symmet= ry for stateful NAT64) should be captured in a BCP like document.=20 Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= cam byrne Envoy=E9 : mercredi 23 d=E9cembre 2009 15:30 =C0 : behave@ietf.org Objet : [BEHAVE] Wkp -------- Original Message -------- Subject: Wkp From: cam byrne To: behave@ietf.net CC: null Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? For= example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/= 96 it helps me scale multiple nat64 spystems in the same region, which is c= ritical for a service provider. Without this, it cannot be expected that a= service provider will use the wkp since scale will be bounded by vendor bo= x limitations.=20=20 I understand that if we do this, the host wont be able to automatically dis= cover the local wkp unless we alias the base wkp as anycast on all nat64 sy= stems in addition to dns64 handing out sub-wkp, which may make everyone hap= py. This way we can scale linearly, identify nat'd flows at the host, and= enable the host to pass nat64 manually without dns64. Thoughts?=20=20=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From cb.list6@gmail.com Wed Dec 23 07:07:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070A13A6893 for ; Wed, 23 Dec 2009 07:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lotkp1kR-60s for ; Wed, 23 Dec 2009 07:07:37 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 00E983A680B for ; Wed, 23 Dec 2009 07:07:34 -0800 (PST) Received: by yxe30 with SMTP id 30so8254275yxe.29 for ; Wed, 23 Dec 2009 07:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q5kW+VYKUfziYPpTGY09hY0G5yFdjiUcp6ZeDbpWe1A=; b=v3lOrxhpnDykwOAaMr+s9UtVTwRX7cgNWCPD6f+gsm1JqSfTg/yWZv7eUySusmgnGC keezwt65GmQ9hdydYe7bKi5Nev5udW5mjgLcLWeKwv0s6c4UsyQ1ELMehgieDdYVQLUA N5KjvNdZv2oMYxPSXY5YbpdS42ruvGdeK5WE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GepbkVhkSGyWyCv7WCWqEPg2vjtP1oiHuCk/iegwfEZJJPnB/4NtVbKGOrhsyZPw5G qLjZ6FA3bX9cwxbmtN6PKuWPMNLYaztGo3oiIKnJ4kiR2HAsKcvjSS+lrZv8oJ3tzQa6 /UXGMmGABEZYf/LkKRrK8oQLtYjFGSa/MpnQc= MIME-Version: 1.0 Received: by 10.150.21.42 with SMTP id 42mr15837849ybu.180.1261580832770; Wed, 23 Dec 2009 07:07:12 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2009 07:07:12 -0800 Message-ID: From: Cameron Byrne To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:07:41 -0000 On Wed, Dec 23, 2009 at 6:53 AM, Iljitsch van Beijnum wrote: > On 23 dec 2009, at 15:30, cam byrne wrote: > >> Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? = =A0For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9= b:2::/96 it helps me scale multiple nat64 spystems in the same region > > We had some discussion about "weak WKP" and "strong WKP" where strong =3D= everyone knows the values of all the 96 bits, and weak =3D you can recogni= ze the WKP when you see it, but there are some additional bits in there tha= t you can't predict so you still need to explicitly learn the WKP before yo= u can use it. > > The current draft doesn't address this. > > With a strong WKP referrals between hosts served by different translators= should work, with a weak WKP this is not necessarily the case. Can you please explain in more detail how this scaling works with strong WKP? My goal is to scale linearly (n number of independent NAT64 boxes). Right now, i believe WKP does not support this. The weak WKP might help here, but you said there are some missing bits... can you be more explcit on what the down fall is? Is there still an issue if the n number of NAT64 boxes accept translations from the WKP? Or if one of n number of NAT64 in a region announces the WKN prexfix? Otherwise, i believe large service providers cannot use WKP. It is not practical for scaling. Thanks, Cameron From huitema@microsoft.com Wed Dec 23 07:35:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6A23A68BE for ; Wed, 23 Dec 2009 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo6IfFStDGO1 for ; Wed, 23 Dec 2009 07:35:39 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 929AC3A6872 for ; Wed, 23 Dec 2009 07:35:39 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 07:35:23 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 23 Dec 2009 07:35:21 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 23 Dec 2009 07:35:25 -0800 From: Christian Huitema To: cam byrne , "behave@ietf.org" Thread-Topic: [BEHAVE] Wkp Thread-Index: AQHKg9yaT1iNWeWVF0G3th8w2r3UUpFywpJw Date: Wed, 23 Dec 2009 15:35:18 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200DFB@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:35:40 -0000 PiBJcyA2NDpmZjliOjovOTYgdGhlIG9ubHkgd2VsbCBrbm93biBwcmVmaXggb3IgaXMgYW55IHN1 Ym5ldCBvZiBpdCB3a3A/ICBGb3IgZXhhbXBsZSwgaWYgSSBjYW4gZG8gMiBuYXQ2NCANCj4gc3lz dGVtcyB1c2luZyA2NDpmZjliOjE6Oi85NiBhbmQgNjQ6ZmY5YjoyOjovOTYgaXQgaGVscHMgbWUg c2NhbGUgbXVsdGlwbGUgbmF0NjQgc3B5c3RlbXMgaW4gdGhlIHNhbWUgcmVnaW9uLCANCj4gd2hp Y2ggaXMgY3JpdGljYWwgZm9yIGEgc2VydmljZSBwcm92aWRlci4gIFdpdGhvdXQgdGhpcywgaXQg Y2Fubm90IGJlIGV4cGVjdGVkIHRoYXQgYSBzZXJ2aWNlIHByb3ZpZGVyIHdpbGwgDQo+IHVzZSB0 aGUgd2twIHNpbmNlIHNjYWxlIHdpbGwgYmUgYm91bmRlZCBieSB2ZW5kb3IgYm94IGxpbWl0YXRp b25zLiAgDQoNClRoZSBkb2N1bWVudCBpcyB1bmFtYmlndW91cy4gNjQ6ZmY5Yjo6Lzk2IGFuZCA2 NDpmZjliOjE6Oi85NiBhcmUgZGlmZmVyZW50IHByZWZpeGVzLiBUbyBtYXRjaCA2NDpmZjliOjov OTYsIHlvdSBuZWVkIHRvIG1hdGNoIGFsbCA5NiBiaXRzLCBub3QganVzdCAzMiBvZiB0aGVtLiBJ ZiB5b3Ugd2FudCB0byBkbyB3aGF0IHlvdSBkZXNjcmliZSwgeW91IG5lZWQgdG8gdXNlIG5ldHdv cmsgc3BlY2lmaWMgcHJlZml4ZXMuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQoNCiAN Cg== From iljitsch@muada.com Wed Dec 23 07:38:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81A63A68D2 for ; Wed, 23 Dec 2009 07:38:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5wohmQtzr34 for ; Wed, 23 Dec 2009 07:38:55 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 94B663A680A for ; Wed, 23 Dec 2009 07:38:54 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNFbqCF051033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Dec 2009 16:37:53 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Dec 2009 16:38:27 +0100 Message-Id: To: Behave WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:38:56 -0000 In Hiroshima, the chairs put the question of whether we should work = around path MTU discovery issues in a translater to the room. I think = this question was largely misunderstood, and many of the people who = hummed also did so from a place of pedanticness, rather than sticking to = Jon Postel's robustness principle. Also, the question shouldn't have = been asked this way because in order to answer it, it's necessary to = know what the cost of the workaround is. So I want to revisit this issue. Please respond with technical = arguments. It's legal for IPv4 hosts to run PMTUD and have a path MTU < 1280. And = according to RFC 2460: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. Now IPv6 hosts will generally implement PMTUD, but operators may disable = it by using an MTU of 1280 and then filtering incoming packet too big = messages. That is certainly not breaking RFC 2460 as much as filtering = those incoming too big messages while still sending IPv4 packets with = DF=3D1 that many IPv4 networks do, even ones that know the RFCs like = Microsoft with www.microsoft.com. More importantly, MTU=3D1280 and too = big filtering doesn't break anything in IPv6. So an IPv4 practice that is ok within IPv4, and an IPv6 practice that is = ok within IPv6. Now put a translator between them, and a black hole is = born if no changes to the currently defined method of translation is = done: the IPv6 host sends a 1280-byte packet, IPv4 host says "too big, = try 576" and the IPv6 host never sees that message and keeps sending = those 1280-byte packets. Solution: simply set the DF bit to 0 for all IPv6 packets <=3D 1280 = bytes that are translated to IPv4. This doesn't get in the way if the = too bigs aren't filtered, because the fragment header is still there in = that case, but it does solve the PMTUD blackhole issue with absolutely = no disadvantages. Two lines of code, that's all. Then the handling of IPv4 packets with DF=3D0 that are translated to = IPv6. The xlate draft currently says to add a fragment header if the packet is = smaller than 1280 bytes (and DF=3D0). That fragment header on = unfragmented packets is there for the benefit of a translator that may = want to translate back into IPv4 that can then set DF=3D0. If DF is = always set to 0 for packets < 1280, then the code to detect this = condition is unnecessary, as are the cycles to add the fragment header = and 64 bits of network capacity are saved. Also, many IPv6 packet = filters play fast and loose and don't recognize a packet as TCP or UDP = if there is a fragment header in between. So not having this unnecessary = fragment header also increases robustness. Last but not least, mandating that a translator always fragment packets = with DF=3D0 > 1280 very strange, and can end up being very suboptimal. = Because there can't be any PMTUD for these packets, they need some = additional handling. Always fragmenting them is one solution, but it has = the downside that packets are fragmented even if they could have been = carried to the destination without problem because the path MTU is large = enough. The alternative is for the translator to simply send the packet = intact initially, and thereby implicitly run PTMUD. If there is then a = too big message, obviously this can't be forwarded to the original = source because with DF=3D0 that host will not expect such a message and = not reduce its packet size. So in this case the translator would have to = fragment subsequent packets. Now this seems like an imposition, but: 1. The state is per destination address, not per flow 2. There is only actual state for destination addresses with a reduced = path MTU 3. Hosts running PMTUD must do this, too, and seem to be able to without = issues Practical tradeoffs could happen in both directions: a stateless = translator implemented on a router platform with fast hardware-assisted = processing but relatively constrained state storage facilities serving = 6to4 (or similar) hosts all using a 1280-byte MTU would probably want to = simply always fragment. A stateful translator serving hosts running = native IPv6 over ethernet (which would normally have a 1500-byte MTU) = may not see many PMTUD hits and/or not be concerned with the small = increase in state. So our specifications should allow for both solutions.= From huitema@microsoft.com Wed Dec 23 07:39:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49023A69AA for ; Wed, 23 Dec 2009 07:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8Gch88b+9Kz for ; Wed, 23 Dec 2009 07:39:41 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 059843A69A6 for ; Wed, 23 Dec 2009 07:39:41 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 07:39:57 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 23 Dec 2009 07:39:23 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 23 Dec 2009 07:39:23 -0800 From: Christian Huitema To: Cameron Byrne , Iljitsch van Beijnum Thread-Topic: [BEHAVE] Wkp Thread-Index: AQHKg9yaT1iNWeWVF0G3th8w2r3UUpFzPc+AgAADyQD//4H0kA== Date: Wed, 23 Dec 2009 15:39:20 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200E1A@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:39:41 -0000 > Can you please explain in more detail how this scaling works with > strong WKP? My goal is to scale linearly (n number of independent > NAT64 boxes). Right now, i believe WKP does not support this. The > weak WKP might help here, but you said there are some missing bits... > can you be more explcit on what the down fall is? We actually discuss this issue in the "stateless network translation" secti= on. If you want multiple boxes to use the same prefix, you need them to coo= rdinate their mappings. If you want administrative control, use multiple ne= twork specific prefixes. There is no concept of "weak WKP" in the addressing draft. The point never = came, and the definition of WKP as 96 bit long explicitly excludes the conc= ept. -- Christian Huitema From huitema@microsoft.com Wed Dec 23 07:45:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45113A680A for ; Wed, 23 Dec 2009 07:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1t2yPXv3tKi for ; Wed, 23 Dec 2009 07:45:43 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 02D043A6920 for ; Wed, 23 Dec 2009 07:45:43 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 07:45:59 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 23 Dec 2009 07:45:24 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 23 Dec 2009 07:45:25 -0800 From: Christian Huitema To: Iljitsch van Beijnum , Behave WG Thread-Topic: [BEHAVE] Review: draft-ietf-behave-address-format-03 Thread-Index: AQHKg7c6Xe3J3HeixkKrT4CdFXFqPJFyxOXw Date: Wed, 23 Dec 2009 15:45:22 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:45:43 -0000 > Apparently, the authors got swept away by considering how to best solve a= bunch of problems=20 > and thereby losing sight of whether these problems needed solving in the = first place,=20 > and whether those solutions should be IETF standards track. The problems that we address were the problems that we were chartered to ad= dress. > Unless I missed something, the push to include specifications of how use = a non /96 prefix=20 > and/or non-WKP prefix came from a very small group of people, I see no ev= idence that this=20 > is something that the industry as a whole is interested in. As such, it m= akes much more sense=20 > to keep all of this out of this document and create a separate document t= hat describes=20 > all of this if and when desired, rather than tie all this complexity to t= he current NAT64 effort. The non /96 are useful for stateless translation, a problem that we were ex= plicitly required to address. Specifically, safe deployment of IPv4 transla= table IPv6 Addresses requires using prefixes in IGP tables for forwarding a= nd source address checks, and this is better doe with shorter prefixes. > Second, the document needs to update RFC 3484 by making the well known pr= efix less preferred than IPv4.=20 Can't that be left to the revision of RFC 3484? -- Christian Huitema From iljitsch@muada.com Wed Dec 23 07:58:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467853A69B7 for ; Wed, 23 Dec 2009 07:58:00 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFMc8KTXSMTe for ; Wed, 23 Dec 2009 07:57:59 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 35DC73A6992 for ; Wed, 23 Dec 2009 07:57:59 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNFuucB051314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 16:56:56 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 23 Dec 2009 16:57:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:58:00 -0000 On 23 dec 2009, at 16:45, Christian Huitema wrote: > The non /96 are useful for stateless translation, a problem that we = were explicitly required to address. Specifically, safe deployment of = IPv4 translatable IPv6 Addresses requires using prefixes in IGP tables = for forwarding and source address checks, and this is better doe with = shorter prefixes. If the translator prefix is a /96 you can still put the /64 that that = /96 falls under in the routing tables. >> Second, the document needs to update RFC 3484 by making the well = known prefix less preferred than IPv4.=20 > Can't that be left to the revision of RFC 3484? It should be in that, too, yes. Is it coming out anytime soon? But since this document introduces the WKP the document should also = explain how it fits in with the policy table, especially as an important = reason to use the WKP is that it can have lower priority than IPv4, = which solves potential issues in dual stack deployments.= From iljitsch@muada.com Wed Dec 23 08:07:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4FB3A69DD for ; Wed, 23 Dec 2009 08:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-7gFCSHDwkS for ; Wed, 23 Dec 2009 08:07:17 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 10A933A69CE for ; Wed, 23 Dec 2009 08:07:16 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNG6Cqh051371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 17:06:12 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 23 Dec 2009 17:06:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3467BB29-7098-4C98-9DCB-383FC9A69E37@muada.com> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1077) Cc: behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 16:07:18 -0000 On 23 dec 2009, at 16:07, Cameron Byrne wrote: > Can you please explain in more detail how this scaling works with > strong WKP? My goal is to scale linearly (n number of independent > NAT64 boxes). Right now, i believe WKP does not support this. If you need the NAT64 boxes to be in a place where you can't make = routing flow part of your traffic to each, then the strong WKP (where = all 96 bits are the same for all translators) won't help you and you = would either need to get single big translator or put a load balancer in = front of a bunch of smaller ones. > The > weak WKP might help here, but you said there are some missing bits... > can you be more explcit on what the down fall is? Not sure what you mean by downfall... What I meant is that you could have 64:ff9b:aaaa::/96 and = 64:ff9b:bbbb::/96 etc which are all recognized as part of the WKP = because they're all in 64:ff9b::/32. The issue would be when host A tells host B to connect to host C on = 64:ff9b:aaaa::192.0.2.1 while host B uses the 64:ff9b:bbbb::/96 = translator prefix. Or to host C across the world where the = 64:ff9b:aaaa::/96 prefix isn't used. In the first case it can work to a certain degree but slightly = unexpectedly because this session goes through a different translator = and therefore uses a different IPv4 address. In the second case if the = aaaa translator address goes nowhere the referral fails, so you'd have = to cover the whole 64:9bff::/32 to avoid that. So rather than = 64:9bff:aaaa::/96 and 64:9bff:bbbb::/96 you would probably want to use = 64:9bff::/33 and 64:9bff:8000::/33 to cover that whole /32. > Is there still an issue if the n number of NAT64 boxes accept > translations from the WKP? Or if one of n number of NAT64 in a region > announces the WKN prexfix? I don't know...= From phdgang@gmail.com Wed Dec 23 08:36:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81DF3A69ED for ; Wed, 23 Dec 2009 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH09EZmr4BaV for ; Wed, 23 Dec 2009 08:36:51 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 8625A3A69EE for ; Wed, 23 Dec 2009 08:36:50 -0800 (PST) Received: by iwn33 with SMTP id 33so5161562iwn.29 for ; Wed, 23 Dec 2009 08:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gsIAcJwqlI5IKS+u8WjU8QiQCcDlMrbSJMah/zTuEKw=; b=euYM1WGt/qVifhYQQLuX2efWTrka8Js7Cvd6c5yU5hRH1gmEEmFOn9wTzmUd/xEIIf v8pVI7k77waOZJrEEI/VnySrg1cnrvCAfrhdfe3S1MFpCtq4eBVqX8QIGyWSqNGR1VAZ ZAt2hYl/rh4W6cGrWkT0wOEK0jtR845l3WuRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nO+ozKNDIF4hIzIu9ag4VbX7oREtTPYgKR0c3DwgYebHfUJuc7j8tQN5tQxr/AsIeL tuxxyVBKuJ9iG0Yzt3eB3wMaeeYtICuV6M6/FNmkikMBeYhYvF98GuqIsryANZnLzJ7E 3VScf+VMszNU5q2J8EL4G1Wdi2DQyaL3BHfEI= MIME-Version: 1.0 Received: by 10.231.125.28 with SMTP id w28mr117980ibr.50.1261586191192; Wed, 23 Dec 2009 08:36:31 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Dec 2009 00:36:31 +0800 Message-ID: <36ba02b00912230836u21540d9and88ffd1efccc1b71@mail.gmail.com> From: GangChen To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=0016e645b8cac79308047b67ecc7 Cc: cam byrne , behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 16:36:51 -0000 --0016e645b8cac79308047b67ecc7 Content-Type: text/plain; charset=ISO-8859-1 2009/12/23 Iljitsch van Beijnum > On 23 dec 2009, at 15:30, cam byrne wrote: > > > Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? > For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and > 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region > > We had some discussion about "weak WKP" and "strong WKP" where strong = > everyone knows the values of all the 96 bits, and weak = you can recognize > the WKP when you see it, but there are some additional bits in there that > you can't predict so you still need to explicitly learn the WKP before you > can use it. > > The current draft doesn't address this. > > With a strong WKP referrals between hosts served by different translators > should work, with a weak WKP this is not necessarily the case. > I think the concepts of "Weak WKP" and "Strong WKP" are reasonable. Acoording to the draft, WKP is only adopted to stateful translation deployments. All 96bits-matched rules make multiple nat64 load-balance impossible. These concepts could give more flexible usage of WKP. BRs Gang --0016e645b8cac79308047b67ecc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/12/23 Iljitsch van Beijnum <iljitsch@muada.com>
On 23 dec 2009, at 15:30, cam byrne wrote:

> Is= 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? =A0For= example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/= 96 it helps me scale multiple nat64 spystems in the same region

We had some discussion about "weak WKP" and "stron= g WKP" where strong =3D everyone knows the values of all the 96 bits, = and weak =3D you can recognize the WKP when you see it, but there are some = additional bits in there that you can't predict so you still need to ex= plicitly learn the WKP before you can use it.

The current draft doesn't address this.

With a strong WKP re= ferrals between hosts served by different translators should work, with a w= eak WKP this is not necessarily the case.
=A0
=A0I think the concepts of "Weak WKP" and "Strong WKP&q= uot; are reasonable.
=A0Acoording to the draft, WKP is only adopted to s= tateful translation deployments.
=A0All 96bits-matched rules make multip= le nat64 load-balance impossible.
=A0These concepts could give more flexible usage of WKP.
=A0
BRs
=A0
Gang
--0016e645b8cac79308047b67ecc7-- From marcelo@it.uc3m.es Wed Dec 23 09:06:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2883A69EA for ; Wed, 23 Dec 2009 09:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcN4Y4q+3hYF for ; Wed, 23 Dec 2009 09:06:41 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C28B53A69FC for ; Wed, 23 Dec 2009 09:06:40 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-217-144.dialup.adsl.anteldata.net.uy (r190-132-217-144.dialup.adsl.anteldata.net.uy [190.132.217.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E95CD7F4BAE; Wed, 23 Dec 2009 18:06:19 +0100 (CET) Message-ID: <4B324E05.1050800@it.uc3m.es> Date: Wed, 23 Dec 2009 18:06:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17088.000 Cc: cam byrne , "behave@ietf.org" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 17:06:42 -0000 mohamed.boucadair@orange-ftgroup.com escribió: > Dear Cameron, > > The current version of I-D.ietf-behave-address-format does not prevent you to use sub prefixes belonging to the WKP. well, actually, it does. The current draft assigns the WKP to be 64:ff9b::/96 Hence, 64:ff9b:1::/96 for example, has not been assigned for this purpose and would still be in the IANA pool. You could of course use it (as you could use any other prefix for that matter), but this is not supported by the current draft (or allocation policies) In order to do that, we would need to change the WKP to be 64:ff9b::/32 and then define the algorithm to be: WKP+zero padding+IPv4 address Then you could change the zero padding to whatever other padding you want, and then you are on track. Regards, marcelo > Nevertheless, operational issues induced by the enforcement of such policy (e.g., for traffic engineering purposes) are out of scope of I-D.ietf-behave-address-format. > > IMHO, these considerations (and others such as how to ensure traffic symmetry for stateful NAT64) should be captured in a BCP like document. > > Cheers, > Med > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de cam byrne > Envoyé : mercredi 23 décembre 2009 15:30 > À : behave@ietf.org > Objet : [BEHAVE] Wkp > > > > -------- Original Message -------- > Subject: Wkp > From: cam byrne > To: behave@ietf.net > CC: null > > Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region, which is critical for a service provider. Without this, it cannot be expected that a service provider will use the wkp since scale will be bounded by vendor box limitations. > > I understand that if we do this, the host wont be able to automatically discover the local wkp unless we alias the base wkp as anycast on all nat64 systems in addition to dns64 handing out sub-wkp, which may make everyone happy. This way we can scale linearly, identify nat'd flows at the host, and enable the host to pass nat64 manually without dns64. > > Thoughts? > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From huitema@microsoft.com Wed Dec 23 10:00:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2BD3A69EA for ; Wed, 23 Dec 2009 10:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.636 X-Spam-Level: X-Spam-Status: No, score=-9.636 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZsc1inN-Bz4 for ; Wed, 23 Dec 2009 10:00:06 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A1E803A6A32 for ; Wed, 23 Dec 2009 10:00:06 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 10:00:22 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 23 Dec 2009 09:59:49 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 23 Dec 2009 09:59:49 -0800 From: Christian Huitema To: marcelo bagnulo braun , "mohamed.boucadair@orange-ftgroup.com" Thread-Topic: [BEHAVE] Wkp Thread-Index: AQHKg9yaT1iNWeWVF0G3th8w2r3UUpFzPgiAgAAk0YD//4cDwA== Date: Wed, 23 Dec 2009 17:59:47 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> In-Reply-To: <4B324E05.1050800@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cam byrne , "behave@ietf.org" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:00:07 -0000 > In order to do that, we would need to change the WKP to be 64:ff9b::/32=20 > and then define the algorithm to be: > WKP+zero padding+IPv4 address > Then you could change the zero padding to whatever other padding you=20 > want, and then you are on track. We could, but this is certainly not what we set up to do, or what we decide= d. An important benefit about a well known prefix is that every translator = using it will translate a given 32 bit IPv4 address into a specific 128 bit= IPv6 address, with all bits exactly defined. In short, everybody can rely = on this translation being understood everywhere. But for that, we need to s= pecify all 96 bits of the prefix. Med and Cameron are looking for a different design, in which part of the ma= pped addressed are used to indicate specific translators, or maybe some oth= er purpose. There may be a market for that, but the Well Known Prefix is no= t designed to address it. In the short term, they can get their wishes by u= sing network specific prefixes. If they want to get IETF reserved prefixes,= they can do that by going through the process, submit a draft, get WG cons= ensus, etc. But that will be a different draft, not the current addressing = draft. -- Christian Huitema =20 From huitema@microsoft.com Wed Dec 23 10:04:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBFD3A69F9 for ; Wed, 23 Dec 2009 10:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LexPUY6-DFs for ; Wed, 23 Dec 2009 10:04:27 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 34B0C3A69F5 for ; Wed, 23 Dec 2009 10:04:27 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 10:04:08 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 23 Dec 2009 10:03:56 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 23 Dec 2009 10:03:54 -0800 From: Christian Huitema To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] Review: draft-ietf-behave-address-format-03 Thread-Index: AQHKg7c6Xe3J3HeixkKrT4CdFXFqPJFyxOXwgACLDYD//5wdAA== Date: Wed, 23 Dec 2009 18:03:54 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> In-Reply-To: <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:04:28 -0000 So, Iljitsch, if I summarize your request, you would like to see two additi= ons to the current draft: 1) A paragraph explaining the benefits of using the Well Known Prefix whene= ver possible, i.e. the property that most translators will understand it, e= tc. 2) A section about routing preferences, calling for an update to RFC 3484. If these additions do not change the overall balance of the document, we ca= n add them in a revised draft after last call. Do you have candidate text, = by any chance? -- Christian Huitema From iljitsch@muada.com Wed Dec 23 10:07:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799483A6A01 for ; Wed, 23 Dec 2009 10:07:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOTpoAcqaBOj for ; Wed, 23 Dec 2009 10:07:48 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 4C0063A6843 for ; Wed, 23 Dec 2009 10:07:48 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNI6j2t053904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 19:06:46 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 23 Dec 2009 19:07:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com> References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1077) Cc: "behave@ietf.org" , cam byrne , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:07:49 -0000 On 23 dec 2009, at 18:59, Christian Huitema wrote: > But that will be a different draft, not the current addressing draft. The current draft isn't set in stone yet, if there is rough consensus = that this is a useful feature we can incorporate it, IMO. As far as I'm concerned, I don't think adding load balancing bits breaks = anything, so I would support it if others want this in this document.= From mohamed.boucadair@orange-ftgroup.com Wed Dec 23 10:08:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732253A6A0E for ; Wed, 23 Dec 2009 10:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqG8zgHVKHmw for ; Wed, 23 Dec 2009 10:08:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 493963A6843 for ; Wed, 23 Dec 2009 10:08:07 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8D20EC044C; Wed, 23 Dec 2009 19:07:49 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6DB5D15803A; Wed, 23 Dec 2009 19:07:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 23 Dec 2009 19:07:49 +0100 From: To: marcelo bagnulo braun Date: Wed, 23 Dec 2009 19:07:48 +0100 Thread-Topic: [BEHAVE] Wkp Thread-Index: AcqD8kG/edg3Oq1GRa6eyGksOyfHVQABzhWg Message-ID: <6730_1261591669_4B325C75_6730_29625_1_94C682931C08B048B7A8645303FDC9F30EF2B95F97@PUEXCB1B.nanterre.francetelecom.fr> References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr>, <4B324E05.1050800@it.uc3m.es> In-Reply-To: <4B324E05.1050800@it.uc3m.es> 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.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.23.172119 Cc: cam byrne , "behave@ietf.org" Subject: [BEHAVE] RE : Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:08:08 -0000 Dear Marcelo,=20 I was referring to the absence of any statement in the draft to forbid the = address translator to accept a PREFIX starting with 64:ff9b (emulating then= an NSP) as input for the NSP-based address mappings. Cheers, Med ________________________________________ De : marcelo bagnulo braun [marcelo@it.uc3m.es] Date d'envoi : mercredi 23 d=E9cembre 2009 18:06 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : cam byrne; behave@ietf.org Objet : Re: [BEHAVE] Wkp mohamed.boucadair@orange-ftgroup.com escribi=F3: > Dear Cameron, > > The current version of I-D.ietf-behave-address-format does not prevent yo= u to use sub prefixes belonging to the WKP. well, actually, it does. The current draft assigns the WKP to be 64:ff9b::/96 Hence, 64:ff9b:1::/96 for example, has not been assigned for this purpose and would still be in the IANA pool. You could of course use it (as you could use any other prefix for that matter), but this is not supported by the current draft (or allocation policies) In order to do that, we would need to change the WKP to be 64:ff9b::/32 and then define the algorithm to be: WKP+zero padding+IPv4 address Then you could change the zero padding to whatever other padding you want, and then you are on track. Regards, marcelo > Nevertheless, operational issues induced by the enforcement of such poli= cy (e.g., for traffic engineering purposes) are out of scope of I-D.ietf-be= have-address-format. > > IMHO, these considerations (and others such as how to ensure traffic symm= etry for stateful NAT64) should be captured in a BCP like document. > > Cheers, > Med > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de cam byrne > Envoy=E9 : mercredi 23 d=E9cembre 2009 15:30 > =C0 : behave@ietf.org > Objet : [BEHAVE] Wkp > > > > -------- Original Message -------- > Subject: Wkp > From: cam byrne > To: behave@ietf.net > CC: null > > Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? F= or example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2:= :/96 it helps me scale multiple nat64 spystems in the same region, which is= critical for a service provider. Without this, it cannot be expected that= a service provider will use the wkp since scale will be bounded by vendor = box limitations. > > I understand that if we do this, the host wont be able to automatically d= iscover the local wkp unless we alias the base wkp as anycast on all nat64 = systems in addition to dns64 handing out sub-wkp, which may make everyone h= appy. This way we can scale linearly, identify nat'd flows at the host, a= nd enable the host to pass nat64 manually without dns64. > > Thoughts? > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From marcelo@it.uc3m.es Wed Dec 23 10:11:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D07F3A6938 for ; Wed, 23 Dec 2009 10:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOVd-H59-YhT for ; Wed, 23 Dec 2009 10:11:44 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 9ACF63A6A2F for ; Wed, 23 Dec 2009 10:11:43 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-217-144.dialup.adsl.anteldata.net.uy (r190-132-217-144.dialup.adsl.anteldata.net.uy [190.132.217.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 7033A6C37F9; Wed, 23 Dec 2009 19:11:21 +0100 (CET) Message-ID: <4B325D44.901@it.uc3m.es> Date: Wed, 23 Dec 2009 19:11:16 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Huitema References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17088.000 Cc: "behave@ietf.org" , cam byrne , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:11:45 -0000 Christian Huitema escribió: >> In order to do that, we would need to change the WKP to be 64:ff9b::/32 >> and then define the algorithm to be: >> WKP+zero padding+IPv4 address >> Then you could change the zero padding to whatever other padding you >> want, and then you are on track. >> > > We could, but this is certainly not what we set up to do, or what we decided. Right, this issue was discussed at large in the hisorhima meeting and the rough consensus was that the WKP was a /96, knowing that this would prevent using different prefixes within the WKP for different translators. Regards, marcelo > An important benefit about a well known prefix is that every translator using it will translate a given 32 bit IPv4 address into a specific 128 bit IPv6 address, with all bits exactly defined. In short, everybody can rely on this translation being understood everywhere. But for that, we need to specify all 96 bits of the prefix. > > Med and Cameron are looking for a different design, in which part of the mapped addressed are used to indicate specific translators, or maybe some other purpose. There may be a market for that, but the Well Known Prefix is not designed to address it. In the short term, they can get their wishes by using network specific prefixes. If they want to get IETF reserved prefixes, they can do that by going through the process, submit a draft, get WG consensus, etc. But that will be a different draft, not the current addressing draft. > > -- Christian Huitema > > > > > From iljitsch@muada.com Wed Dec 23 10:15:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C3E3A6977 for ; Wed, 23 Dec 2009 10:15:38 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgp5Q7HNxQVI for ; Wed, 23 Dec 2009 10:15:38 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id D1ABF3A6A0A for ; Wed, 23 Dec 2009 10:15:37 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNIEbBR054407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 19:14:39 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 23 Dec 2009 19:15:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E58263F-B426-4998-889A-CF8911FC4D0B@muada.com> References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:15:39 -0000 On 23 dec 2009, at 19:03, Christian Huitema wrote: > So, Iljitsch, if I summarize your request, you would like to see two = additions to the current draft: Yes, and one big removal of all the non-/96 NSP stuff. > 1) A paragraph explaining the benefits of using the Well Known Prefix = whenever possible, i.e. the property that most translators will = understand it, etc. And especially referrals, yes. > 2) A section about routing preferences, calling for an update to RFC = 3484. Right. > If these additions do not change the overall balance of the document, = we can add them in a revised draft after last call. Do you have = candidate text, by any chance? Not at this time. About the WKP load balancing issue: perhaps it's enough to just reserve = 64:ff9b::/32 (ugh, I've been writing it wrong in earlier messages today) = as "possible future WKP-like uses" which would of course get the same = treatment in the policy table but not not specify how anything but the = /96 works, leaving that until there is some real-world experience. Which = is in line with what I want for the NSP.= From iljitsch@muada.com Wed Dec 23 10:16:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23B33A6A26 for ; Wed, 23 Dec 2009 10:16:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gblm84zCwOrr for ; Wed, 23 Dec 2009 10:16:17 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id DA7AB3A6A11 for ; Wed, 23 Dec 2009 10:16:16 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNIEbBS054407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 19:15:15 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B325D44.901@it.uc3m.es> Date: Wed, 23 Dec 2009 19:15:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D73835C-A84D-4FFC-BCAB-378393372CD6@muada.com> References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <4B325D44.901@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: cam byrne , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:16:18 -0000 On 23 dec 2009, at 19:11, marcelo bagnulo braun wrote: >> We could, but this is certainly not what we set up to do, or what we = decided.=20 > Right, this issue was discussed at large in the hisorhima meeting and = the rough consensus was that the WKP was a /96, knowing that this would = prevent using different prefixes within the WKP for different = translators. Decisions are made on the mailinglist, not in meetings.= From marcelo@it.uc3m.es Wed Dec 23 10:19:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FDA3A6A03 for ; Wed, 23 Dec 2009 10:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzeyylSS2TWS for ; Wed, 23 Dec 2009 10:19:43 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 646943A688C for ; Wed, 23 Dec 2009 10:19:43 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-217-144.dialup.adsl.anteldata.net.uy (r190-132-217-144.dialup.adsl.anteldata.net.uy [190.132.217.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E71A1BA8CE9; Wed, 23 Dec 2009 19:19:21 +0100 (CET) Message-ID: <4B325F25.5020100@it.uc3m.es> Date: Wed, 23 Dec 2009 19:19:17 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr>, <4B324E05.1050800@it.uc3m.es> <6730_1261591669_4B325C75_6730_29625_1_94C682931C08B048B7A8645303FDC9F30EF2B95F97@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <6730_1261591669_4B325C75_6730_29625_1_94C682931C08B048B7A8645303FDC9F30EF2B95F97@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17088.000 Cc: cam byrne , "behave@ietf.org" Subject: Re: [BEHAVE] RE : Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:19:46 -0000 mohamed.boucadair@orange-ftgroup.com escribió: > Dear Marcelo, > > I was referring to the absence of any statement in the draft to forbid the address translator to accept a PREFIX starting with 64:ff9b (emulating then an NSP) as input for the NSP-based address mappings. > > but the problem there is that 64:ff9b:2::/96 in the exmaple below belongs to IANA and not the ISP that is deploying the transaltion services. You could do this with the NSP as Christian mentions, but not with any prefix starting with 64:ff9b: cause we are only asking for a 64:ff9b::/96. in other words, is a problem of prefix allocation, not that the mechanisms doesn't support it (for some definition of support) makes sense? Regards, marcelo > Cheers, > Med > > > > ________________________________________ > De : marcelo bagnulo braun [marcelo@it.uc3m.es] > Date d'envoi : mercredi 23 décembre 2009 18:06 > À : BOUCADAIR Mohamed NCPI/NAD/TIP > Cc : cam byrne; behave@ietf.org > Objet : Re: [BEHAVE] Wkp > > mohamed.boucadair@orange-ftgroup.com escribió: > >> Dear Cameron, >> >> The current version of I-D.ietf-behave-address-format does not prevent you to use sub prefixes belonging to the WKP. >> > well, actually, it does. > The current draft assigns the WKP to be 64:ff9b::/96 > Hence, 64:ff9b:1::/96 for example, has not been assigned for this > purpose and would still be in the IANA pool. > You could of course use it (as you could use any other prefix for that > matter), but this is not supported by the current draft (or allocation > policies) > > In order to do that, we would need to change the WKP to be 64:ff9b::/32 > and then define the algorithm to be: > WKP+zero padding+IPv4 address > Then you could change the zero padding to whatever other padding you > want, and then you are on track. > > Regards, marcelo > >> Nevertheless, operational issues induced by the enforcement of such policy (e.g., for traffic engineering purposes) are out of scope of I-D.ietf-behave-address-format. >> >> IMHO, these considerations (and others such as how to ensure traffic symmetry for stateful NAT64) should be captured in a BCP like document. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de cam byrne >> Envoyé : mercredi 23 décembre 2009 15:30 >> À : behave@ietf.org >> Objet : [BEHAVE] Wkp >> >> >> >> -------- Original Message -------- >> Subject: Wkp >> From: cam byrne >> To: behave@ietf.net >> CC: null >> >> Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp? For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region, which is critical for a service provider. Without this, it cannot be expected that a service provider will use the wkp since scale will be bounded by vendor box limitations. >> >> I understand that if we do this, the host wont be able to automatically discover the local wkp unless we alias the base wkp as anycast on all nat64 systems in addition to dns64 handing out sub-wkp, which may make everyone happy. This way we can scale linearly, identify nat'd flows at the host, and enable the host to pass nat64 manually without dns64. >> >> Thoughts? >> ********************************* >> This message and any attachments (the "message") are confidential and intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if altered, changed or falsified. >> If you are not the intended addressee of this message, please cancel it immediately and inform the sender. >> ******************************** >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> > > > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > > > From brian.e.carpenter@gmail.com Wed Dec 23 11:39:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808EE3A6861 for ; Wed, 23 Dec 2009 11:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkc0sEJ1l36u for ; Wed, 23 Dec 2009 11:39:05 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 89F433A67F3 for ; Wed, 23 Dec 2009 11:39:05 -0800 (PST) Received: by yxe30 with SMTP id 30so8554222yxe.29 for ; Wed, 23 Dec 2009 11:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1zEqggZY3GXOJfdrZ7L9uyfnYVivWg08ChAcz9nqhng=; b=snhA0nq8sqwzSoZVz0UeyExbtodga5qS0/NB0cIlTMdVqL+DNW921761CzWmGlEErt hfXqthpMt95h02oFx4H8stAJhG+zsCHzSCihRLZ8Jk5bj8yP6o2c7Cz3nyEYg0aYLfno A5RA1pW1jN8Jy+JqjC2v6P/5ooKsB11quHEnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=rHn5awU63sV01rAJp+y2cVUsbfv8/46MbAOeaSGaNzN0hYredM6Q00zaDLVKH/Te9E wNRVxhLSdwKRCawlMTNxaxLSyxHkgVFg3pTlFQQtaWKrMJBDc2zJ7HtWaIdn08UkJRaf bbvKN421e9zQp4kDwtDQMwrid1Zm6l9IXgxEQ= Received: by 10.101.7.8 with SMTP id k8mr16839359ani.23.1261597123133; Wed, 23 Dec 2009 11:38:43 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 9sm2891826ywf.20.2009.12.23.11.38.40 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 11:38:42 -0800 (PST) Message-ID: <4B3271B8.1020700@gmail.com> Date: Thu, 24 Dec 2009 08:38:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <2E58263F-B426-4998-889A-CF8911FC4D0B@muada.com> In-Reply-To: <2E58263F-B426-4998-889A-CF8911FC4D0B@muada.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:52:16 -0000 On 2009-12-24 07:15, Iljitsch van Beijnum wrote: > On 23 dec 2009, at 19:03, Christian Huitema wrote: > >> So, Iljitsch, if I summarize your request, you would like to see two additions to the current draft: > > Yes, and one big removal of all the non-/96 NSP stuff. I don't think you've shown consensus for that. Personally, I fear that if we don't lay this out precisely, we are inviting implementors and operators to make up their own solutions. > >> 1) A paragraph explaining the benefits of using the Well Known Prefix whenever possible, i.e. the property that most translators will understand it, etc. > > And especially referrals, yes. What do you mean about referrals? > >> 2) A section about routing preferences, calling for an update to RFC 3484. > > Right. I would avoid formal "updates" language in the present draft, to avoid a complicated discussion about what updates what when 3484 is replaced. Just say that the WKP SHOULD have a lower preference than IPv4 in the table. Brian > >> If these additions do not change the overall balance of the document, we can add them in a revised draft after last call. Do you have candidate text, by any chance? > > Not at this time. > > About the WKP load balancing issue: perhaps it's enough to just reserve 64:ff9b::/32 (ugh, I've been writing it wrong in earlier messages today) as "possible future WKP-like uses" which would of course get the same treatment in the policy table but not not specify how anything but the /96 works, leaving that until there is some real-world experience. Which is in line with what I want for the NSP. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From brian.e.carpenter@gmail.com Wed Dec 23 11:50:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEDE3A6924 for ; Wed, 23 Dec 2009 11:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QvJ5r7fmJNJ for ; Wed, 23 Dec 2009 11:50:01 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id D495E3A6859 for ; Wed, 23 Dec 2009 11:50:00 -0800 (PST) Received: by gxk28 with SMTP id 28so1371712gxk.9 for ; Wed, 23 Dec 2009 11:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JSSwCPiorodQGjs5UbqPw10+mRgcq9vDL7mH7Zl0w8Q=; b=b6KrYLSLpY/qru5XYvDvSgRrkpnX9m72fyPANCx5k8zOcTrk6E3prB58ZnHB98cqUd Ah+60myO+ULeZAD4XkMwGBaqJpUCuhqWZRuL0JxT423Oup9UcOaMUDTfaPgY+HJtax4j L86HPa0BjDtGmDXJae3gDKhV0qz9RImZnu7k0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ixjkZxIYsnOlh3+tu6llRdR3k/Z0WcFBWGducs4/Zqpqtwg1JoyeK7S56knJiaTT5+ fCk1lPOfjx1ZqqoLgbIuXw8kMm5hpt8+ubpU9Rzk0UhOIkROUYwT08mnHoT4QhInUzwp sfNXS1cdFkizncQrUOBulB5tKyn4E1XvxVjw0= Received: by 10.101.189.20 with SMTP id r20mr13090339anp.191.1261597781109; Wed, 23 Dec 2009 11:49:41 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 21sm2902895ywh.1.2009.12.23.11.49.38 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 11:49:40 -0800 (PST) Message-ID: <4B32744A.8070904@gmail.com> Date: Thu, 24 Dec 2009 08:49:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com> In-Reply-To: <49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: cam byrne , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:55:29 -0000 On 2009-12-24 07:07, Iljitsch van Beijnum wrote: > On 23 dec 2009, at 18:59, Christian Huitema wrote: > >> But that will be a different draft, not the current addressing draft. > > The current draft isn't set in stone yet, if there is rough consensus that this is a useful feature we can incorporate it, IMO. > > As far as I'm concerned, I don't think adding load balancing bits breaks anything, so I would support it if others want this in this document. Well, for example, it makes using a WKP-based address in a referral even more alarming. What if those load-balancing bits are valid in the context of the referring host but meaningless in the context of the host that receives the referral? Isn't this exactly why we need to document the NSP case? Brian Brian From iljitsch@muada.com Wed Dec 23 11:57:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018883A6926 for ; Wed, 23 Dec 2009 11:57:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNG1e8SoD4Sx for ; Wed, 23 Dec 2009 11:57:04 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E0AB33A682A for ; Wed, 23 Dec 2009 11:57:03 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNJu2GY057050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 20:56:04 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B3271B8.1020700@gmail.com> Date: Wed, 23 Dec 2009 20:56:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <2E58263F-B426-4998-889A-CF8911FC4D0B@muada.com> <4B3271B8.1020700@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:59:03 -0000 On 23 dec 2009, at 20:38, Brian E Carpenter wrote: >> removal of all the non-/96 NSP stuff. > I don't think you've shown consensus for that. In Hiroshima everyone at the mic was asking for simplicity. What's in = the draft now isn't simple. > Personally, I fear that > if we don't lay this out precisely, we are inviting implementors and > operators to make up their own solutions. I'd rather see people figure this out in practice and then standardize = it if that's useful. All of this is internal to a service provider = network so there are no interoperability issues that need to be hamered = out before experimentation can happen. And nobody except the IVI people = has expressed interest in any of this, either. >> And especially referrals, yes. > What do you mean about referrals? If the two of us are behind different NAT64s but both use the WKP then I = can tell you to connect to 64:ff9b::192.0.2.31 that I'm already talking = to and you can actually connect to that address. > I would avoid formal "updates" language in the present draft, to avoid = a > complicated discussion about what updates what when 3484 is replaced. = Just > say that the WKP SHOULD have a lower preference than IPv4 in the = table. Ok.= From cb.list6@gmail.com Wed Dec 23 12:25:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5553A6405 for ; Wed, 23 Dec 2009 12:25:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7QAjNaf5hN7 for ; Wed, 23 Dec 2009 12:25:26 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id E3E3E3A69E7 for ; Wed, 23 Dec 2009 12:25:25 -0800 (PST) Received: by ywh15 with SMTP id 15so7807173ywh.5 for ; Wed, 23 Dec 2009 12:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:date:to:cc :message-id:content-type:mime-version; bh=yMYMzwvdzs0b/eGiIervkwivEkI50q3LPmrEr7Eyndc=; b=GaMx9y6AZwkyvzhjE/J7fvgTvTesX5a1Dcrtz4NhnRQ/Xp01SwDqlVEW60YdlcDogF CH2NN0GDuCjO8JfCQuFUnfwBUcCy7V+uvzYe91EWMGF7Ap0SuJNCiiXKItDIm7iEw1xL oCfRQEDoBWQw5dxOV6U01HZxJ7CcXT1qKu7vI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:date:to:cc:message-id:content-type:mime-version; b=X8h9x5+YvmWUaeY9pWnsYkHI7eiwEQHgYXdXBO5WB9yrcGRjAzaH58y3+yPGAwvj2f RsdaMUzC4qGpBy+Fl3rTBoYdS63gQbaz8ZGLA5uIAJ/6y7HWL9bOYZ8NH0fZunDo5Rkn Fb+aU/kGrp+xvk9l4j3Z7Na9aRpUT/g+e4X+o= Received: by 10.150.238.11 with SMTP id l11mr16243739ybh.217.1261599905101; Wed, 23 Dec 2009 12:25:05 -0800 (PST) Received: from localhost (m3f5a36d0.tmodns.net [208.54.90.63]) by mx.google.com with ESMTPS id 4sm3387535yxd.34.2009.12.23.12.25.01 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 12:25:03 -0800 (PST) From: cam byrne Date: Wed, 23 Dec 2009 15:24:54 -0500 To: Brian E Carpenter , Iljitsch van Beijnum Message-ID: <4B32744A.8070904@gmail.com> Content-Type: multipart/mixed; boundary="----KNHM2YF0BOYS5EOFEKLXOYVU33MHJA" MIME-Version: 1.0 Cc: cam byrne , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 20:25:27 -0000 ------KNHM2YF0BOYS5EOFEKLXOYVU33MHJA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJyaWFuLiBTdHJvbmcgd2twIG1heSB3b3JrIGZvciBlbnRlcnByaXNlIGJ1 dCBub3Qgc2VydmljZSBwcm92aWRlciB3aG8gYXJlIGRlc2lnbmluZyB0byBjZ24gLyBsc24gc2Nh bGUuICBOc3AgaXMgdGhlIG9ubHkgb3B0aW9uIGZvciBsaW5lYXIgc2NhbGluZyBhdCB0aGlzIHBv aW50LiAgV2twIHdpbGwgd29yayB0b2RheSBmb3IgZW50ZXJwcmlzZSAgc2NhbGUgZGVwbG95bWVu dHMsIGJ1dCB0aGUgcG9zaXRpdmUgYXR0cmlidXRlcyBvZiB3a3AgYXJlIG5vdCBhdmFpbGFibGUg dG8gbGFyZ2Ugc2NhbGUgc2VydmljZSBwcm92aWRlcnMgdG9kYXkgc2luY2UgdGhlcmUgaXMgbm90 IGEgd2VhayB3a3AuIAoKYWxzbywgeWV0IGFub3RoZXIgbG9hZCBiYWxhbmNlciBvciBzdGF0ZWZ1 bCBkZXZpY2UgaXMgbm90IGFuIG9wdGlvbiBhdCB0aGUgc2NhbGUgc2VydmljZSBwcm92aWRlcnMg YXJlIGRlc2lnbmluZyBmb3IuICBUaGUgZG5zNjQgbXVzdCBiZSBhYmxlIHRvIG5hdHVyYWxseSBk cml2ZSB0aGUgdHJhZmZpYyBpbiBkaXNjcmV0ZSBpbmNyZW1lbnRzIHN0YXRlbGVzc2x5IHRvIHRo ZSBzdGF0ZWZ1bCBuYXQ2NC4gIEJyZWFraW5nIHRoaXMgbWFzc2l2ZSBhbW91bnQgb2Ygc3RhdGUg aW50byBzbWFsbGVyIGNodW5rcyBpcyB0aGUgb25seSB3YXkgd2UgY2FuIHNvbHZlIHRoZSBzY2Fs aW5nIGlzc3VlLiAgQ3JlYXRpbmcgeWV0IGFub3RoZXIgbGF5ZXIgb2YgbG9hZCBiYWxhbmNlciBz dGF0ZSB3aWxsIG5vdCBzY2FsZS4gIAoKQ2IgICAKCkJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOgoKPk9uIDIwMDktMTItMjQgMDc6MDcsIElsaml0 c2NoIHZhbiBCZWlqbnVtIHdyb3RlOg0KPj4gT24gMjMgZGVjIDIwMDksIGF0IDE4OjU5LCBDaHJp c3RpYW4gSHVpdGVtYSB3cm90ZToNCj4+IA0KPj4+IEJ1dCB0aGF0IHdpbGwgYmUgYSBkaWZmZXJl bnQgZHJhZnQsIG5vdCB0aGUgY3VycmVudCBhZGRyZXNzaW5nIGRyYWZ0Lg0KPj4gDQo+PiBUaGUg Y3VycmVudCBkcmFmdCBpc24ndCBzZXQgaW4gc3RvbmUgeWV0LCBpZiB0aGVyZSBpcyByb3VnaCBj b25zZW5zdXMgdGhhdCB0aGlzIGlzIGEgdXNlZnVsIGZlYXR1cmUgd2UgY2FuIGluY29ycG9yYXRl IGl0LCBJTU8uDQo+PiANCj4+IEFzIGZhciBhcyBJJ20gY29uY2VybmVkLCBJIGRvbid0IHRoaW5r IGFkZGluZyBsb2FkIGJhbGFuY2luZyBiaXRzIGJyZWFrcyBhbnl0aGluZywgc28gSSB3b3VsZCBz dXBwb3J0IGl0IGlmIG90aGVycyB3YW50IHRoaXMgaW4gdGhpcyBkb2N1bWVudC4NCj4NCj5XZWxs LCBmb3IgZXhhbXBsZSwgaXQgbWFrZXMgdXNpbmcgYSBXS1AtYmFzZWQgYWRkcmVzcyBpbiBhIHJl ZmVycmFsIGV2ZW4NCj5tb3JlIGFsYXJtaW5nLiBXaGF0IGlmIHRob3NlIGxvYWQtYmFsYW5jaW5n IGJpdHMgYXJlIHZhbGlkIGluIHRoZSBjb250ZXh0DQo+b2YgdGhlIHJlZmVycmluZyBob3N0IGJ1 dCBtZWFuaW5nbGVzcyBpbiB0aGUgY29udGV4dCBvZiB0aGUgaG9zdCB0aGF0DQo+cmVjZWl2ZXMg dGhlIHJlZmVycmFsPw0KPg0KPklzbid0IHRoaXMgZXhhY3RseSB3aHkgd2UgbmVlZCB0byBkb2N1 bWVudCB0aGUgTlNQIGNhc2U/DQo+DQo+ICAgQnJpYW4NCj4NCj4NCj4gICBCcmlhbg0K ------KNHM2YF0BOYS5EOFEKLXOYVU33MHJA-- From root@core3.amsl.com Wed Dec 23 12:30:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D65973A693E; Wed, 23 Dec 2009 12:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091223203001.D65973A693E@core3.amsl.com> Date: Wed, 23 Dec 2009 12:30:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-sctpnat-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Author(s) : R. Stewart, et al. Filename : draft-ietf-behave-sctpnat-02.txt Pages : 27 Date : 2009-12-21 Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-sctpnat-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-23122019.I-D@ietf.org> --NextPart-- From iljitsch@muada.com Wed Dec 23 13:06:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB913A6917 for ; Wed, 23 Dec 2009 13:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAXdVfovYNDe for ; Wed, 23 Dec 2009 13:06:07 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E2F6F3A69BF for ; Wed, 23 Dec 2009 13:06:06 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNL56Hq057883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 22:05:07 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B32744A.8070904@gmail.com> Date: Wed, 23 Dec 2009 22:05:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com> <4B32744A.8070904@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: cam byrne , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 21:06:08 -0000 On 23 dec 2009, at 20:49, Brian E Carpenter wrote: >> As far as I'm concerned, I don't think adding load balancing bits = breaks anything, so I would support it if others want this in this = document. > Well, for example, it makes using a WKP-based address in a referral = even > more alarming. What if those load-balancing bits are valid in the = context > of the referring host but meaningless in the context of the host that > receives the referral? I think I covered that in my message to Cameron earlier today. Or are = you getting at something else? At least in the non-/96 WKP case there is a chance to get it right, with = an NSP you can only fail. > Isn't this exactly why we need to document the NSP case? You mean the non-/96 NSP business? No, I don't think so. Documenting it = won't help with referrals, because those don't work with an NSP period. Iljitsch (who is going to travel without a computer until sunday so = don't expect detailed responses until next week.)= From iljitsch@muada.com Wed Dec 23 14:29:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE3B3A6882 for ; Wed, 23 Dec 2009 14:29:02 -0800 (PST) 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.275, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkT7ssM1B0LH for ; Wed, 23 Dec 2009 14:29:01 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 94F993A659C for ; Wed, 23 Dec 2009 14:29:01 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNMS1Is058969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 23:28:02 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> Date: Wed, 23 Dec 2009 23:28:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 22:29:02 -0000 On 23 dec 2009, at 23:11, Mark Andrews wrote: >> 3. Hosts running PMTUD must do this, too, and seem to be able to = without issu >> es > Authoritative IPv6 DNS name servers send fragment their DNS/UDP > responses at 1280 because they don't want to have to deal with PMTU > to millions of machines. Ah, I didn't know that. > Authoritative IPv4 DNS nameserver turn off PMTU discovery for DNS/UDP. In IPv4 you have to do PMTUD for UDP in the application, which I don't = think any application does. > We don't want a middle box turning it on underneath us. What I was talking about was the translator "terminating" the IPv6 PMTUD = in this case. So the too big messages aren't relayed to the original = source, so the original source remains unaware of all of this. One thing I forgot to mention in my original message: video streaming = over UDP typically happens with packets just under 1500 bytes. If those = happen to be in the 1473 - 1480 byte range then the fragment header can = push the packet size after translation just over the edge and require = fragmentation that wouldn't be necessary without the fragment header. = People might choose 1476 or 1480 because that's the ethernet MTU with = either GRE or IP-in-IP encapsulation. I seem to remember that 147x was = common, but can't find a reference right now.= From marka@isc.org Wed Dec 23 14:12:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E3A3A6942 for ; Wed, 23 Dec 2009 14:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utUqjG9gxvwS for ; Wed, 23 Dec 2009 14:12:43 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id CF1CA3A67B3 for ; Wed, 23 Dec 2009 14:12:42 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id E3B34E60A4; Wed, 23 Dec 2009 22:12:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBNMBjO0047918; Thu, 24 Dec 2009 09:11:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> To: Iljitsch van Beijnum From: Mark Andrews References: In-reply-to: Your message of "Wed, 23 Dec 2009 16:38:27 BST." Date: Thu, 24 Dec 2009 09:11:45 +1100 Sender: marka@isc.org Cc: Behave WG Subject: Re: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 23:04:22 -0000 In message , Iljitsch van Beijn um writes: > In Hiroshima, the chairs put the question of whether we should work around pa > th MTU discovery issues in a translater to the room. I think this question wa > s largely misunderstood, and many of the people who hummed also did so from a > place of pedanticness, rather than sticking to Jon Postel's robustness princ > iple. Also, the question shouldn't have been asked this way because in order > to answer it, it's necessary to know what the cost of the workaround is. > > So I want to revisit this issue. Please respond with technical arguments. > > It's legal for IPv4 hosts to run PMTUD and have a path MTU < 1280. And accord > ing to RFC 2460: > > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC-1981], in order to discover and take advantage of path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit implementation > of Path MTU Discovery. > > Now IPv6 hosts will generally implement PMTUD, but operators may disable it b > y using an MTU of 1280 and then filtering incoming packet too big messages. T > hat is certainly not breaking RFC 2460 as much as filtering those incoming to > o big messages while still sending IPv4 packets with DF=1 that many IPv4 netw > orks do, even ones that know the RFCs like Microsoft with www.microsoft.com. > More importantly, MTU=1280 and too big filtering doesn't break anything in IP > v6. > > So an IPv4 practice that is ok within IPv4, and an IPv6 practice that is ok w > ithin IPv6. Now put a translator between them, and a black hole is born if no > changes to the currently defined method of translation is done: the IPv6 hos > t sends a 1280-byte packet, IPv4 host says "too big, try 576" and the IPv6 ho > st never sees that message and keeps sending those 1280-byte packets. > > Solution: simply set the DF bit to 0 for all IPv6 packets <= 1280 bytes that > are translated to IPv4. This doesn't get in the way if the too bigs aren't fi > ltered, because the fragment header is still there in that case, but it does > solve the PMTUD blackhole issue with absolutely no disadvantages. Two lines o > f code, that's all. > > Then the handling of IPv4 packets with DF=0 that are translated to IPv6. > > The xlate draft currently says to add a fragment header if the packet is smal > ler than 1280 bytes (and DF=0). That fragment header on unfragmented packets > is there for the benefit of a translator that may want to translate back into > IPv4 that can then set DF=0. If DF is always set to 0 for packets < 1280, th > en the code to detect this condition is unnecessary, as are the cycles to add > the fragment header and 64 bits of network capacity are saved. Also, many IP > v6 packet filters play fast and loose and don't recognize a packet as TCP or > UDP if there is a fragment header in between. So not having this unnecessary > fragment header also increases robustness. > > Last but not least, mandating that a translator always fragment packets with > DF=0 > 1280 very strange, and can end up being very suboptimal. Because there > can't be any PMTUD for these packets, they need some additional handling. Al > ways fragmenting them is one solution, but it has the downside that packets a > re fragmented even if they could have been carried to the destination without > problem because the path MTU is large enough. The alternative is for the tra > nslator to simply send the packet intact initially, and thereby implicitly ru > n PTMUD. If there is then a too big message, obviously this can't be forwarde > d to the original source because with DF=0 that host will not expect such a m > essage and not reduce its packet size. So in this case the translator would h > ave to fragment subsequent packets. > > Now this seems like an imposition, but: > > 1. The state is per destination address, not per flow > 2. There is only actual state for destination addresses with a reduced path M > TU > 3. Hosts running PMTUD must do this, too, and seem to be able to without issu > es Authoritative IPv6 DNS name servers send fragment their DNS/UDP responses at 1280 because they don't want to have to deal with PMTU to millions of machines. Authoritative IPv4 DNS nameserver turn off PMTU discovery for DNS/UDP. We don't want a middle box turning it on underneath us. > Practical tradeoffs could happen in both directions: a stateless translator i > mplemented on a router platform with fast hardware-assisted processing but re > latively constrained state storage facilities serving 6to4 (or similar) hosts > all using a 1280-byte MTU would probably want to simply always fragment. A s > tateful translator serving hosts running native IPv6 over ethernet (which wou > ld normally have a 1500-byte MTU) may not see many PMTUD hits and/or not be c > oncerned with the small increase in state. > > So our specifications should allow for both solutions. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From iljitsch@muada.com Wed Dec 23 15:04:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CCF3A6A21 for ; Wed, 23 Dec 2009 15:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH-lzv5zJiq4 for ; Wed, 23 Dec 2009 15:04:42 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 9FC113A6A29 for ; Wed, 23 Dec 2009 15:04:41 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBNN3gnf059363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Dec 2009 00:03:42 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <200912232250.nBNMoOj2048086@drugs.dv.isc.org> Date: Thu, 24 Dec 2009 00:04:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC224F2-F60C-4E69-BDD6-AAE92298F8B9@muada.com> References: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> <200912232250.nBNMoOj2048086@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1077) Cc: Behave WG Subject: Re: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 23:04:42 -0000 On 23 dec 2009, at 23:50, Mark Andrews wrote: >> In IPv4 you have to do PMTUD for UDP in the application, which I = don't =3D >> think any application does. > There are kernels which turn it on PMTUD for *everything* in IPv4 = despite > the fact the it was explicitly advised against. Note that sending packets with DF=3D1 is not the same thing as = performing PMTUD. I once talked to a root server from behind a 296 MTU and I never got any = packets because they set DF to 1. If they had actually been running = PMTUD I would have received the retransmissions. >> What I was talking about was the translator "terminating" the IPv6 = PMTUD =3D >> in this case. So the too big messages aren't relayed to the original = =3D >> source, so the original source remains unaware of all of this. > But you still loose the original UDP response. Only the first packet within the time that the PMTU is cached. And as we learned in another thread recently, it is a profoundly bad = idea to run a DNS resolver through NAT64 so authoritative servers don't = have anything to worry about in any event. Note that I'm not saying that the translator doing "proxy PMTUD" is = always the best option. It's just that fragmenting all packets with DF=3D0= is also not always the best option. > With DNSSEC DNS/UDP packet are often 2-3K range. I've got a change > request to raise the maximum UDP packet we support to 8K from the > 4K we currently support. O, I thought that was already a configuration setting in BIND. Iljitsch= From marka@isc.org Wed Dec 23 14:51:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC083A68BD for ; Wed, 23 Dec 2009 14:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVuGAmBGP-ql for ; Wed, 23 Dec 2009 14:51:23 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 5051A3A672E for ; Wed, 23 Dec 2009 14:51:23 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 51289E60A4; Wed, 23 Dec 2009 22:50:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBNMoOj2048086; Thu, 24 Dec 2009 09:50:34 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912232250.nBNMoOj2048086@drugs.dv.isc.org> To: Iljitsch van Beijnum From: Mark Andrews References: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 23 Dec 2009 23:28:36 BST." Date: Thu, 24 Dec 2009 09:50:24 +1100 Sender: marka@isc.org Cc: Behave WG Subject: Re: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 23:04:55 -0000 In message , Iljitsch van Beijn um writes: > On 23 dec 2009, at 23:11, Mark Andrews wrote: > > >> 3. Hosts running PMTUD must do this, too, and seem to be able to = > without issu > >> es > > > Authoritative IPv6 DNS name servers send fragment their DNS/UDP > > responses at 1280 because they don't want to have to deal with PMTU > > to millions of machines. > > Ah, I didn't know that. > > > Authoritative IPv4 DNS nameserver turn off PMTU discovery for DNS/UDP. > > In IPv4 you have to do PMTUD for UDP in the application, which I don't = > think any application does. There are kernels which turn it on PMTUD for *everything* in IPv4 despite the fact the it was explicitly advised against. > > We don't want a middle box turning it on underneath us. > > What I was talking about was the translator "terminating" the IPv6 PMTUD = > in this case. So the too big messages aren't relayed to the original = > source, so the original source remains unaware of all of this. But you still loose the original UDP response. There are already too many middle boxes that do the wrong things with DNS/UDP today. We don't need yet another one. With DNSSEC DNS/UDP packet are often 2-3K range. I've got a change request to raise the maximum UDP packet we support to 8K from the 4K we currently support. Mark > One thing I forgot to mention in my original message: video streaming = > over UDP typically happens with packets just under 1500 bytes. If those = > happen to be in the 1473 - 1480 byte range then the fragment header can = > push the packet size after translation just over the edge and require = > fragmentation that wouldn't be necessary without the fragment header. = > People might choose 1476 or 1480 because that's the ethernet MTU with = > either GRE or IP-in-IP encapsulation. I seem to remember that 147x was = > common, but can't find a reference right now.= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Dec 23 15:30:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6DB3A680D for ; Wed, 23 Dec 2009 15:30:29 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8f9l4eZnrHJ for ; Wed, 23 Dec 2009 15:30:28 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 3B5EA3A67AE for ; Wed, 23 Dec 2009 15:30:28 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A8E96E60C7; Wed, 23 Dec 2009 23:30:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nBNNTW1p048480; Thu, 24 Dec 2009 10:29:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200912232329.nBNNTW1p048480@drugs.dv.isc.org> To: Iljitsch van Beijnum From: Mark Andrews References: <200912232211.nBNMBjO0047918@drugs.dv.isc.org> <200912232250.nBNMoOj2048086@drugs.dv.isc.org> <6BC224F2-F60C-4E69-BDD6-AAE92298F8B9@muada.com> In-reply-to: Your message of "Thu, 24 Dec 2009 00:04:17 BST." <6BC224F2-F60C-4E69-BDD6-AAE92298F8B9@muada.com> Date: Thu, 24 Dec 2009 10:29:32 +1100 Sender: marka@isc.org Cc: Behave WG Subject: Re: [BEHAVE] DF bit handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 23:30:29 -0000 In message <6BC224F2-F60C-4E69-BDD6-AAE92298F8B9@muada.com>, Iljitsch van Beijn um writes: > On 23 dec 2009, at 23:50, Mark Andrews wrote: > > >> In IPv4 you have to do PMTUD for UDP in the application, which I = > don't =3D > >> think any application does. > > > There are kernels which turn it on PMTUD for *everything* in IPv4 = > despite > > the fact the it was explicitly advised against. > > Note that sending packets with DF=3D1 is not the same thing as = > performing PMTUD. > > I once talked to a root server from behind a 296 MTU and I never got any = > packets because they set DF to 1. If they had actually been running = > PMTUD I would have received the retransmissions. Which require that the ICMP messages got back to them and required that the kernel is keeping a per host table. > >> What I was talking about was the translator "terminating" the IPv6 = > PMTUD =3D > >> in this case. So the too big messages aren't relayed to the original = > =3D > >> source, so the original source remains unaware of all of this. > > > But you still loose the original UDP response. > > Only the first packet within the time that the PMTU is cached. And DNS clients ask with EDNS@4096, then on timeout ask with EDNS@512, which then often triggers fallback to TCP as there is not enough space in 512 bytes to fit the response which fits quite well into 4096 bytes. > And as we learned in another thread recently, it is a profoundly bad = > idea to run a DNS resolver through NAT64 so authoritative servers don't = > have anything to worry about in any event. There is nothing wrong with providing authoritative service through a NAT64. > Note that I'm not saying that the translator doing "proxy PMTUD" is = > always the best option. It's just that fragmenting all packets with DF=3D0= > is also not always the best option. It's a router where the effective next hop MTU is 1280. If the IPv4 packet says fragmentment me if needed then fragment the packet. > > With DNSSEC DNS/UDP packet are often 2-3K range. I've got a change > > request to raise the maximum UDP packet we support to 8K from the > > 4K we currently support. > > O, I thought that was already a configuration setting in BIND. Named support EDNS between 512-4096. Also one shouldn't have to tweak settings in named because of stupid middleware. > Iljitsch= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Wed Dec 23 17:10:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA743A6867 for ; Wed, 23 Dec 2009 17:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev660igLjXil for ; Wed, 23 Dec 2009 17:10:14 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 3633D3A6842 for ; Wed, 23 Dec 2009 17:10:10 -0800 (PST) Received: by ywh15 with SMTP id 15so7993402ywh.5 for ; Wed, 23 Dec 2009 17:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/ysal16t62RgvTvtf3nQntY0ZXkdcRYXykyu/PvFm2s=; b=IgeVGQdPkrdyN9mqfz11kbdaWkB8SJCUhbSBRGLK6yy+ErKFSw4Z0WzUhUZsYXDgFN vlQ2RpXRfEiq+OFAtPGFAhRqRiwhd6a5MVNt2swALfPX+xBMwq+b1ShiYIoesy9JttDR KwnSjIVc0ou3hjAQ90LQBh+PgxAnKmXpAM3Js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=EXorXmSI1ryaeT6LmNLywYAZ/w3vhKlHbWHydlAjzKk9HzT9yjSRwTZxUyXcb2rI8a P5QqT6Yq+R27nhNuQTH58x2NfxbF//NUq8/DJUp6oQmY1luu/BR7mfjhoo152hvwQl7N aSToD2JZFNcZ1JEYa576WfbSEeWeakRbn9u+4= Received: by 10.150.245.3 with SMTP id s3mr16622527ybh.237.1261616988244; Wed, 23 Dec 2009 17:09:48 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 20sm2980671ywh.2.2009.12.23.17.09.45 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 17:09:47 -0800 (PST) Message-ID: <4B32BF51.80706@gmail.com> Date: Thu, 24 Dec 2009 14:09:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <6B55F0F93C3E9D45AF283313B8D342BA21200E32@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6E83E45D-D556-4486-AF65-D151C3CB7870@muada.com> <6B55F0F93C3E9D45AF283313B8D342BA21200F47@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <2E58263F-B426-4998-889A-CF8911FC4D0B@muada.com> <4B3271B8.1020700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] Review: draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 01:10:17 -0000 On 2009-12-24 08:56, Iljitsch van Beijnum wrote: > On 23 dec 2009, at 20:38, Brian E Carpenter wrote: > >>> removal of all the non-/96 NSP stuff. > >> I don't think you've shown consensus for that. > > In Hiroshima everyone at the mic was asking for simplicity. What's in the draft now isn't simple. > >> Personally, I fear that >> if we don't lay this out precisely, we are inviting implementors and >> operators to make up their own solutions. > > I'd rather see people figure this out in practice and then standardize it if that's useful. All of this is internal to a service provider network so there are no interoperability issues that need to be hamered out before experimentation can happen. And nobody except the IVI people has expressed interest in any of this, either. It's a matter of taste I guess. The essential thing I believe is to insist on the u/g bit, and recommending to skip a complete byte seems to make sense. It's correct that the rest of the detail could probably be dropped for now without causing interoperability issues. People might need to do this if load balancing with the WKP blows up. >>> And especially referrals, yes. > >> What do you mean about referrals? > > If the two of us are behind different NAT64s but both use the WKP then I can tell you to connect to 64:ff9b::192.0.2.31 that I'm already talking to and you can actually connect to that address. That will definitely fail if multiple WKPs are used for load balancing at one site and not the other. I think it will also fail (like 6to4) if the IPv4 address space fragments some years from now, but that's going to be a problem anyway. Brian >> I would avoid formal "updates" language in the present draft, to avoid a >> complicated discussion about what updates what when 3484 is replaced. Just >> say that the WKP SHOULD have a lower preference than IPv4 in the table. > > Ok. From brian.e.carpenter@gmail.com Wed Dec 23 17:14:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953BC3A68AB for ; Wed, 23 Dec 2009 17:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnqb0n0uP4YX for ; Wed, 23 Dec 2009 17:14:14 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9B1D63A6895 for ; Wed, 23 Dec 2009 17:14:12 -0800 (PST) Received: by yxe30 with SMTP id 30so8812613yxe.29 for ; Wed, 23 Dec 2009 17:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fJhuXzdJoI3wWwaJjJhnmN/NB74EwcJGt+YIF7GBw4M=; b=NWjAtbxkvt0v/zAqxUbSXccBVDwE0/tsqdng1AGseQ7YA+3FlMNrY3YaW5xh0ChXbV EcQHnXcImgAlo+EYGsI2WiuepePEupSKnnZoUUXqkOpq27okxmgqPYqjN9a3RyVpDWJH sF4fV5azVBt0xj6fjzT5+4TZPHbRWuK+lVAh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=F52tfexILTnXnBqprKagJwZEWAMaiody4sn/8kihhCLHQxENcZPvFAIMPpi54fc4Ty a3yIZOZt2iLbhvJQCKI48XhJTizeq92PI/EacrobNF3vsc61tGKqb1GT311iem4AdD5A zvp7PnO7FLTF0OjY8EWogZlGMcruM8SUEWo+w= Received: by 10.151.19.35 with SMTP id w35mr7522043ybi.54.1261617232862; Wed, 23 Dec 2009 17:13:52 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 8sm2990503ywg.4.2009.12.23.17.13.50 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 17:13:52 -0800 (PST) Message-ID: <4B32C047.2090908@gmail.com> Date: Thu, 24 Dec 2009 14:13:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com> <4B32744A.8070904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: cam byrne , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 01:14:15 -0000 On 2009-12-24 10:05, Iljitsch van Beijnum wrote: > On 23 dec 2009, at 20:49, Brian E Carpenter wrote: > >>> As far as I'm concerned, I don't think adding load balancing bits breaks anything, so I would support it if others want this in this document. > >> Well, for example, it makes using a WKP-based address in a referral even >> more alarming. What if those load-balancing bits are valid in the context >> of the referring host but meaningless in the context of the host that >> receives the referral? > > I think I covered that in my message to Cameron earlier today. Or are you getting at something else? > > At least in the non-/96 WKP case there is a chance to get it right, with an NSP you can only fail. > >> Isn't this exactly why we need to document the NSP case? > > You mean the non-/96 NSP business? No, I don't think so. Documenting it won't help with referrals, because those don't work with an NSP period. Yes, but inspecting the NSP will give a clue *why* it fails. Referrals and NATs don't mix well, I think we agree on that. Happy holidays. Brian > Iljitsch (who is going to travel without a computer until sunday so don't expect detailed responses until next week.) From xuxh@huawei.com Wed Dec 23 18:07:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503D23A6806 for ; Wed, 23 Dec 2009 18:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySUQNdeURrjg for ; Wed, 23 Dec 2009 18:07:09 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5794E3A6784 for ; Wed, 23 Dec 2009 18:07:09 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV400ARKWJCNF@szxga02-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 10:06:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV40055YWJCBZ@szxga02-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 10:06:48 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV400EP9WJCAI@szxml04-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 10:06:48 +0800 (CST) Date: Thu, 24 Dec 2009 10:06:48 +0800 From: Xu Xiaohu In-reply-to: <4B32744A.8070904@gmail.com> To: 'cam byrne' , 'Brian E Carpenter' , 'Iljitsch van Beijnum' Message-id: <003e01ca843d$c037e300$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcqEDhIBNtIZELofR+iupWVoT14cEQAKWqMg Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 02:44:51 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED cam > byrne > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 4:25 > =CA=D5=BC=FE=C8=CB: Brian E Carpenter; Iljitsch van Beijnum > =B3=AD=CB=CD: cam byrne; behave@ietf.org; = mohamed.boucadair@orange-ftgroup.com > =D6=F7=CC=E2: Re: [BEHAVE] Wkp >=20 > I agree with Brian. Strong wkp may work for enterprise but not service provider > who are designing to cgn / lsn scale. Nsp is the only option for = linear scaling > at this point. Wkp will work today for enterprise scale deployments, = but the > positive attributes of wkp are not available to large scale service providers > today since there is not a weak wkp. Support. Besides the WKP (e.g., 64:ff9b::/96) and NSP already defined in = the draft-ietf-behave-address-format, we need a third option (temporarily = called hybrid type prefix, HTP in short). As depicted in the following figure, = it starts with a well-know binary value (e.g., 0x15) but the following part = is network specific. Note that the boundary between the well-known binary = value and the Network Specific Part is just an example. This HTP can be used = for the load-balancing in the IPv6 network to IPv4 internet scenario. To = ease the deployment further, a special /80 prefix(e.g., 15::/80) can be = reserved, the rightmost 8 bits of the Network Specific Parts can used to assign different values to different NAT boxes. This special /80 prefix can be = used independently by different IPv6 site networks. +--------+--------------------------------+-----------------+ |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| +--------+--------------------------------+-----------------+ (HTP Example) +--------+-----------------------+--------+-----------------+ |00010101| All zero (80 bits) |(8 bits)|IPv4 addr (32bit)| +--------+-----------------------+--------+-----------------+ ( A specific HTP reserved for load-balancing usage in IPv6 network to = IPv4 internet scenario). In fact, this hybrid type prefix has been discussed in other thread "Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ?". For more details, please see http://www.ietf.org/mail-archive/web/behave/current/msg07800.html =20 Xiaohu > also, yet another load balancer or stateful device is not an option at = the scale > service providers are designing for. The dns64 must be able to = naturally drive > the traffic in discrete increments statelessly to the stateful nat64. > Breaking this massive amount of state into smaller chunks is the only = way we > can solve the scaling issue. Creating yet another layer of load = balancer state > will not scale. >=20 > Cb >=20 > Brian E Carpenter wrote: >=20 > >On 2009-12-24 07:07, Iljitsch van Beijnum wrote: > >> On 23 dec 2009, at 18:59, Christian Huitema wrote: > >> > >>> But that will be a different draft, not the current addressing = draft. > >> > >> The current draft isn't set in stone yet, if there is rough = consensus that > this is a useful feature we can incorporate it, IMO. > >> > >> As far as I'm concerned, I don't think adding load balancing bits breaks > anything, so I would support it if others want this in this document. > > > >Well, for example, it makes using a WKP-based address in a referral = even > >more alarming. What if those load-balancing bits are valid in the = context > >of the referring host but meaningless in the context of the host that > >receives the referral? > > > >Isn't this exactly why we need to document the NSP case? > > > > Brian > > > > > > Brian From xuxh@huawei.com Wed Dec 23 19:06:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D3C3A6810 for ; Wed, 23 Dec 2009 19:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.807 X-Spam-Level: * X-Spam-Status: No, score=1.807 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu2ej4RRLG-q for ; Wed, 23 Dec 2009 19:06:01 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A685A3A67B7 for ; Wed, 23 Dec 2009 19:06:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV400G99Z9AWN@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 11:05:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV400EKSZ990W@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 11:05:33 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV400K03Z99FD@szxml06-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 11:05:33 +0800 (CST) Date: Thu, 24 Dec 2009 11:05:33 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA21200BCC@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <005401ca8445$f56b72f0$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AQHKg4l7aUXh78SbWUm9Nlr2w13AN5FyNZpggAFMmsA= Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 03:06:02 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C223=C8=D5 15:19 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'Dan Wing'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 > > Then how about synthesizing the above AAAAs with a specific NSP = which starts > > with a special binary value (depicted as follows)? That is to say, = the > > specific NSP is a 96/ prefix which starts with a well-known binary (e.g., > > 00010101) while the remaining part is network specific. > > > > +--------+--------------------------------+-----------------+ > > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > > +--------+--------------------------------+-----------------+ > > > > > > This specific NSP is topologically aggregatable, hence it will not result > in > > routing scalability issues in the IPv6 internet. In addition, since = it > > begins with a special binary value, the synthetic IPv6 addresses = with such > a > > prefix can be easily distinguished from ordinary IPv6 addresses. >=20 > To do that, we would need to define a new class of IPv6 prefixes, with = new > registry to manage the allocations. That seems like a big operational problem. >=20 > Also, you mention that these new IPv6 prefixes would be topologically > aggregatable. That is only true if we allow the prefixes to be used = for a variety > of address allocations, e.g. both translation and allocation of = regular IPv6 > addresses. But if we do that, the well known binary prefix will become > meaningless. No, these specific NSPs can be aggregated as 15::/8 to the utmost = extent. It has nothing to do with the aggregation of the regular IPv6 addresses. > It seems that you are trying really hard to make sure that addresses constructed > by translation can be easily distinguished from regular IPv6 = addresses. But > why is that such a big issue? At worst, it means that some connection = will be > a little bit slower than normally expected. This happens all the time = in > multihoming scenario, without translation. Irrelated to whether slower or faster. The major purpose is to avoid = ADDRESS FAMILY translation if possible. Xiaohu > -- Christian Huitema >=20 >=20 From dwing@cisco.com Wed Dec 23 21:40:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3435F3A68F9 for ; Wed, 23 Dec 2009 21:40:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGqo47wGHpb6 for ; Wed, 23 Dec 2009 21:40:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 039043A68EF for ; Wed, 23 Dec 2009 21:40:05 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAH6NMktAZnwN/2dsb2JhbACIOIEUtWWWa4QzBIFl X-IronPort-AV: E=Sophos;i="4.47,447,1257120000"; d="scan'208";a="76376275" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Dec 2009 05:39:45 +0000 Received: from dwingwxp01 (rtp-vpn5-1324.cisco.com [10.82.237.49]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBO5dd0p001425; Thu, 24 Dec 2009 05:39:40 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Brian E Carpenter'" References: <20064_1261580068_4B322F24_20064_447_1_94C682931C08B048B7A8645303FDC9F30EF2D23A03@PUEXCB1B.nanterre.francetelecom.fr> <4B324E05.1050800@it.uc3m.es> <6B55F0F93C3E9D45AF283313B8D342BA21200F33@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com><49FCE054-8AF7-4C5E-BCC3-2139A45F8CD0@muada.com><4B32744A.8070904@gmail.com> Date: Wed, 23 Dec 2009 21:39:39 -0800 Message-ID: <001f01ca845b$7ffd2f70$31ed520a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqEE8NX6B8maES+Ty6kYqWEz6MCSwAR2abg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Cc: mohamed.boucadair@orange-ftgroup.com, 'cam byrne' , behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 05:40:07 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Wednesday, December 23, 2009 1:06 PM > To: Brian E Carpenter > Cc: cam byrne; behave@ietf.org; mohamed.boucadair@orange-ftgroup.com > Subject: Re: [BEHAVE] Wkp > > On 23 dec 2009, at 20:49, Brian E Carpenter wrote: > > >> As far as I'm concerned, I don't think adding load > balancing bits breaks anything, so I would support it if > others want this in this document. > > > Well, for example, it makes using a WKP-based address in a > referral even > > more alarming. What if those load-balancing bits are valid > in the context > > of the referring host but meaningless in the context of the > host that > > receives the referral? > > I think I covered that in my message to Cameron earlier > today. Or are you getting at something else? > > At least in the non-/96 WKP case there is a chance to get it > right, with an NSP you can only fail. > > > Isn't this exactly why we need to document the NSP case? > > You mean the non-/96 NSP business? No, I don't think so. > Documenting it won't help with referrals, because those don't > work with an NSP period. I agree that referrals of the NSP IPv6 will fail when the peer is on a different network (and thus can't use the origin network's prefix). That's why IPv4 address referrals are useful when referring to IPv4 peers. And is what SIP does. And, I expect, what IPv6 applications will do -- if they want to work with IPv4-only instances of the same application, or want to work with IPv6-only instances of the same application, or with dual-stack instances of the same application. IPv6-only referrals are a myth. -d > Iljitsch (who is going to travel without a computer until > sunday so don't expect detailed responses until next week.) > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Wed Dec 23 22:37:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D833A688C for ; Wed, 23 Dec 2009 22:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.818 X-Spam-Level: * X-Spam-Status: No, score=1.818 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+Tg5qgGeOWv for ; Wed, 23 Dec 2009 22:37:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7288A3A6868 for ; Wed, 23 Dec 2009 22:37:17 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV5003HH91DW6@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 14:36:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV500C0L91DIN@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 14:36:49 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV500CDG91CP9@szxml04-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 14:36:49 +0800 (CST) Date: Thu, 24 Dec 2009 14:36:48 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA21201285@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <005901ca8463$78988290$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AQHKg4l7aUXh78SbWUm9Nlr2w13AN5FyNZpggAFMmsCAACYcEIAAFJfA Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 06:37:20 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 13:29 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'Dan Wing'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 > >> It seems that you are trying really hard to make sure that = addresses > constructed > >> by translation can be easily distinguished from regular IPv6 = addresses. But > >> why is that such a big issue? At worst, it means that some = connection will > be > >> a little bit slower than normally expected. This happens all the = time in > >> multihoming scenario, without translation. > > > > Irrelated to whether slower or faster. The major purpose is to avoid ADDRESS > > FAMILY translation if possible. >=20 > The WKP allows for easy distinction between translated and native addresses, > thus avoiding address family translation. Can the WKP be used in the IPv6 internet to IPv4 network scenario? > You are actually asking for something > else, a solution to run multiple translators with multiple prefixes.=20 Besides being a solution to run multiple translators with multiple = prefixes, it can also be used in the IPv6 internet to IPv4 network scenario where = the communication initiator (dual-stack host) wants to distinguish the = synthetic AAAA of the IPv4 correspondent from native IPv6 addresses. Xiaohu > We studied > that, and note that such deployments create tensions between multiple > requirements. Load balancing between multiple NAT is easier to achieve with > multiple prefixes, one per NAT, while references are better handled = with a > single prefix, unique for the whole Internet. Multiple prefix also are > difficult to reconcile with P2P applications using STUN. >=20 > I would rather spend more efforts in developing coordinated = translators that > use the same prefix. That will get us the best of both worlds. >=20 > -- Christian Huitema >=20 >=20 From xuxh@huawei.com Thu Dec 24 02:03:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920D53A692E for ; Thu, 24 Dec 2009 02:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.828 X-Spam-Level: * X-Spam-Status: No, score=1.828 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8keMadW9pHu for ; Thu, 24 Dec 2009 02:03:46 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9A6913A6919 for ; Thu, 24 Dec 2009 02:03:46 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV500L1HILI49@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:03:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV5005LKILI7K@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:03:18 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV500HE9ILHPN@szxml06-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:03:18 +0800 (CST) Date: Thu, 24 Dec 2009 18:03:17 +0800 From: Xu Xiaohu In-reply-to: <6B55F0F93C3E9D45AF283313B8D342BA21201285@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> To: 'Christian Huitema' , 'Dan Wing' , 'marcelo bagnulo braun' Message-id: <005c01ca8480$5094a680$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AQHKg4l7aUXh78SbWUm9Nlr2w13AN5FyNZpggAFMmsCAACYcEIAATJNg Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 10:03:47 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 13:29 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'Dan Wing'; 'marcelo bagnulo braun' > =B3=AD=CB=CD: behave@ietf.org > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > ALLnon-0::/3 IPv6 addresses ? >=20 > >> It seems that you are trying really hard to make sure that = addresses > constructed > >> by translation can be easily distinguished from regular IPv6 = addresses. But > >> why is that such a big issue? At worst, it means that some = connection will > be > >> a little bit slower than normally expected. This happens all the = time in > >> multihoming scenario, without translation. > > > > Irrelated to whether slower or faster. The major purpose is to avoid ADDRESS > > FAMILY translation if possible. >=20 > The WKP allows for easy distinction between translated and native addresses, > thus avoiding address family translation. You are actually asking for something > else, a solution to run multiple translators with multiple prefixes. = We studied > that, and note that such deployments create tensions between multiple > requirements. Load balancing between multiple NAT is easier to achieve with > multiple prefixes, one per NAT, while references are better handled = with a > single prefix, unique for the whole Internet. Multiple prefix also are > difficult to reconcile with P2P applications using STUN. >=20 > I would rather spend more efforts in developing coordinated = translators that > use the same prefix. That will get us the best of both worlds. +-------------+ | | +------------+ | H2 | | +---+--+ | | +----------------+ | |NAT64a+-+ IPv4 ISP#1 +----+ | | H1 +---+--+ +-------------+ | | | +---+--+ +-------------+ | IPv4 Internet | | |NAT64b+-+ H3 +----+ | |IPv6 Site---+--+ | | +----------------+ +------------+ | | | IPv4 ISP#2 | +-------------+ In the above scenario, NAT64a is configure with prefix64-a, while NAT64b = is configured with prefix64-b. If H1 wants to initiate a communication to = H2, it'd better to use the prefix64-a for synthesizing the IPv6 address of = H2. If H1 want to initiate a communication to H3, it'd better to use the prefix64-b for synthesizing the IPv6 address of H2. In the way, traffic forwarding path is shorten by using different prefix64 for different = IPv4 destination hosts. That can also be used for traffic-engineering purpose according to the correspondents' IPv4 addresses (i.e., using = corresponding prefix64 according to the IPv4 address of the correspondent). I wonder whether using the same WKP on these NAT64 boxes can achieve the same = goal. Xiaohu From xuxh@huawei.com Thu Dec 24 02:05:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97653A694D for ; Thu, 24 Dec 2009 02:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.838 X-Spam-Level: * X-Spam-Status: No, score=1.838 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JXTdJtxi6du for ; Thu, 24 Dec 2009 02:05:48 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 86FAE3A6805 for ; Thu, 24 Dec 2009 02:05:48 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV500LIEIOW49@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:05:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KV500JAVIOWQ0@szxga03-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:05:20 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.227]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KV500HKXIOWPN@szxml06-in.huawei.com> for behave@ietf.org; Thu, 24 Dec 2009 18:05:20 +0800 (CST) Date: Thu, 24 Dec 2009 18:05:19 +0800 From: Xu Xiaohu In-reply-to: To: 'Xu Xiaohu' , 'cam byrne' , 'Brian E Carpenter' , 'Iljitsch van Beijnum' Message-id: <005d01ca8480$99b6ba10$e30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcqEDhIBNtIZELofR+iupWVoT14cEQAKWqMgABI85WA= Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org Subject: Re: [BEHAVE] Wkp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 10:05:49 -0000 Hi all, I would like to write a draft about this hybrid type prefix, is there anybody else interested on co-authoring it? Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Xu Xiaohu [mailto:xuxh@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 10:07 > =CA=D5=BC=FE=C8=CB: 'cam byrne'; 'Brian E Carpenter'; 'Iljitsch van = Beijnum' > =B3=AD=CB=CD: 'behave@ietf.org'; = 'mohamed.boucadair@orange-ftgroup.com' > =D6=F7=CC=E2: re: [BEHAVE] Wkp >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED cam > > byrne > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 4:25 > > =CA=D5=BC=FE=C8=CB: Brian E Carpenter; Iljitsch van Beijnum > > =B3=AD=CB=CD: cam byrne; behave@ietf.org; = mohamed.boucadair@orange-ftgroup.com > > =D6=F7=CC=E2: Re: [BEHAVE] Wkp > > > > I agree with Brian. Strong wkp may work for enterprise but not = service provider > > who are designing to cgn / lsn scale. Nsp is the only option for = linear > scaling > > at this point. Wkp will work today for enterprise scale = deployments, but > the > > positive attributes of wkp are not available to large scale service providers > > today since there is not a weak wkp. >=20 > Support. Besides the WKP (e.g., 64:ff9b::/96) and NSP already defined = in the > draft-ietf-behave-address-format, we need a third option (temporarily called > hybrid type prefix, HTP in short). As depicted in the following = figure, it > starts with a well-know binary value (e.g., 0x15) but the following = part is > network specific. Note that the boundary between the well-known binary value > and the Network Specific Part is just an example. This HTP can be used = for the > load-balancing in the IPv6 network to IPv4 internet scenario. To ease = the > deployment further, a special /80 prefix(e.g., 15::/80) can be = reserved, the > rightmost 8 bits of the Network Specific Parts can used to assign different > values to different NAT boxes. This special /80 prefix can be used independently > by different IPv6 site networks. >=20 > +--------+--------------------------------+-----------------+ > |00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)| > +--------+--------------------------------+-----------------+ > (HTP Example) >=20 > +--------+-----------------------+--------+-----------------+ > |00010101| All zero (80 bits) |(8 bits)|IPv4 addr (32bit)| > +--------+-----------------------+--------+-----------------+ > ( A specific HTP reserved for load-balancing usage in IPv6 network to = IPv4 > internet scenario). >=20 > In fact, this hybrid type prefix has been discussed in other thread "Reason(s) > for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ?". = For more > details, please see > http://www.ietf.org/mail-archive/web/behave/current/msg07800.html >=20 > Xiaohu >=20 > > also, yet another load balancer or stateful device is not an option = at the > scale > > service providers are designing for. The dns64 must be able to naturally > drive > > the traffic in discrete increments statelessly to the stateful = nat64. > > Breaking this massive amount of state into smaller chunks is the = only way > we > > can solve the scaling issue. Creating yet another layer of load balancer > state > > will not scale. > > > > Cb > > > > Brian E Carpenter wrote: > > > > >On 2009-12-24 07:07, Iljitsch van Beijnum wrote: > > >> On 23 dec 2009, at 18:59, Christian Huitema wrote: > > >> > > >>> But that will be a different draft, not the current addressing draft. > > >> > > >> The current draft isn't set in stone yet, if there is rough = consensus that > > this is a useful feature we can incorporate it, IMO. > > >> > > >> As far as I'm concerned, I don't think adding load balancing bits breaks > > anything, so I would support it if others want this in this = document. > > > > > >Well, for example, it makes using a WKP-based address in a referral even > > >more alarming. What if those load-balancing bits are valid in the context > > >of the referring host but meaningless in the context of the host = that > > >receives the referral? > > > > > >Isn't this exactly why we need to document the NSP case? > > > > > > Brian > > > > > > > > > Brian From zhangdong_rh@huaweisymantec.com Thu Dec 24 20:06:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4B23A6866 for ; Thu, 24 Dec 2009 20:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.525 X-Spam-Level: * X-Spam-Status: No, score=1.525 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ahW+SXY0Mn for ; Thu, 24 Dec 2009 20:06:02 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 20D0E3A6857 for ; Thu, 24 Dec 2009 20:06:02 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TTFqEJRn+4/FWT13QCygFw)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KV6000AQWP99V80@hstga02-in.huaweisymantec.com> for behave@ietf.org; Fri, 25 Dec 2009 12:05:34 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KV600C5EWP9FX10@hstml01-in.huaweisymantec.com> for behave@ietf.org; Fri, 25 Dec 2009 12:05:33 +0800 (CST) Date: Fri, 25 Dec 2009 12:05:33 +0800 From: Dong Zhang To: marcelo Message-id: <200912251205331162149@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: behave Subject: [BEHAVE] A consistency issue about draft-ietf-behave-v6v4-xlate-stateful-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 04:06:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TTFqEJRn+4/FWT13QCygFw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Marcelo and all, In the section 2.5 and 3.2.2 of the framework draft, it mentions stateful translation [I-D.ietf-behave-v6v4-xlate-stateful] can be used for scenario 5, an IPv6 network to an IPv4 network. However, draft-ietf-behave-v6v4-xlate-stateful-07 does not include scenario 5, while only secnario 1 and secnario 3. I think draft-ietf-behave-v6v4-xlate-stateful-07 should be consistent with the framework, if I do not miss the discussion on this issue before. Thanks. 2009-12-25 Dong Zhang --Boundary_(ID_TTFqEJRn+4/FWT13QCygFw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Marcelo and all,
 
In the section 2.5 and 3.2.2 of the framework draft, it mentions stateful translation [I-D.ietf-behave-v6v4-xlate-stateful] can be used for scenario 5, an IPv6 network to an IPv4 network. However, draft-ietf-behave-v6v4-xlate-stateful-07 does not include scenario 5, while only secnario 1 and secnario 3.
I think draft-ietf-behave-v6v4-xlate-stateful-07 should be consistent with the framework, if I do not miss the discussion on this issue before.
 
Thanks.
 
2009-12-25
Dong Zhang
 
 --Boundary_(ID_TTFqEJRn+4/FWT13QCygFw)-- From dwing@cisco.com Mon Dec 28 07:40:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7D83A6857 for ; Mon, 28 Dec 2009 07:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=-2.695, BAYES_50=0.001, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErkrW1JFU39W for ; Mon, 28 Dec 2009 07:40:38 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3350A3A682A for ; Mon, 28 Dec 2009 07:40:38 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAFtgOEtAZnwN/2dsb2JhbACDaYRLgRS2BIZ6CI0ugSuCLloEgWU X-IronPort-AV: E=Sophos;i="4.47,463,1257120000"; d="scan'208";a="77092184" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Dec 2009 15:40:18 +0000 Received: from dwingwxp01 (rtp-vpn6-1080.cisco.com [10.82.252.60]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBSFeHEO009974; Mon, 28 Dec 2009 15:40:18 GMT From: "Dan Wing" To: "'Xu Xiaohu'" , "'Christian Huitema'" , "'marcelo bagnulo braun'" References: <6B55F0F93C3E9D45AF283313B8D342BA21201285@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <005901ca8463$78988290$e30c6f0a@china.huawei.com> Date: Mon, 28 Dec 2009 07:40:15 -0800 Message-ID: <014301ca87d4$0dd9e240$3cfc520a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <005901ca8463$78988290$e30c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AQHKg4l7aUXh78SbWUm9Nlr2w13AN5FyNZpggAFMmsCAACYcEIAAFJfAgAbjxNA= Cc: behave@ietf.org Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6 addresses ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 15:40:39 -0000 =20 > -----Original Message----- > From: Xu Xiaohu [mailto:xuxh@huawei.com]=20 > Sent: Wednesday, December 23, 2009 10:37 PM > To: 'Christian Huitema'; 'Dan Wing'; 'marcelo bagnulo braun' > Cc: behave@ietf.org > Subject: re: [BEHAVE] Reason(s) for Modified EUI-64 format to=20 > apply to ALLnon-0::/3 IPv6 addresses ? >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Christian Huitema [mailto:huitema@microsoft.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA12=D4=C224=C8=D5 13:29 > > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; 'Dan Wing'; 'marcelo bagnulo braun' > > =B3=AD=CB=CD: behave@ietf.org > > =D6=F7=CC=E2: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to = apply to > > ALLnon-0::/3 IPv6 addresses ? > >=20 > > >> It seems that you are trying really hard to make sure=20 > that addresses > > constructed > > >> by translation can be easily distinguished from regular=20 > IPv6 addresses. > But > > >> why is that such a big issue? At worst, it means that=20 > some connection > will > > be > > >> a little bit slower than normally expected. This happens=20 > all the time > in > > >> multihoming scenario, without translation. > > > > > > Irrelated to whether slower or faster. The major purpose=20 > is to avoid > ADDRESS > > > FAMILY translation if possible. > >=20 > > The WKP allows for easy distinction between translated and native > addresses, > > thus avoiding address family translation. >=20 > Can the WKP be used in the IPv6 internet to IPv4 network scenario? No, that would require the WKP to be advertised as a route on the public Internet. -d > > You are actually asking for something > > else, a solution to run multiple translators with multiple=20 > prefixes.=20 >=20 > Besides being a solution to run multiple translators with=20 > multiple prefixes, > it can also be used in the IPv6 internet to IPv4 network=20 > scenario where the > communication initiator (dual-stack host) wants to=20 > distinguish the synthetic > AAAA of the IPv4 correspondent from native IPv6 addresses. >=20 > Xiaohu >=20 > > We studied > > that, and note that such deployments create tensions=20 > between multiple > > requirements. Load balancing between multiple NAT is easier=20 > to achieve > with > > multiple prefixes, one per NAT, while references are better=20 > handled with a > > single prefix, unique for the whole Internet. Multiple=20 > prefix also are > > difficult to reconcile with P2P applications using STUN. > >=20 > > I would rather spend more efforts in developing coordinated=20 > translators > that > > use the same prefix. That will get us the best of both worlds. > >=20 > > -- Christian Huitema > >=20 > >=20 >=20 >=20 From xing@cernet.edu.cn Tue Dec 29 05:56:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E013A693E for ; Tue, 29 Dec 2009 05:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.981 X-Spam-Level: X-Spam-Status: No, score=0.981 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_05=-1.11, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sham+zuFbg7a for ; Tue, 29 Dec 2009 05:56:04 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 0B50C3A67A6 for ; Tue, 29 Dec 2009 05:56:02 -0800 (PST) Received: from [192.168.1.100]([125.34.55.118]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b3a30f2; Tue, 29 Dec 2009 21:55:39 +0800 Message-ID: <4B3A0A56.3000508@cernet.edu.cn> Date: Tue, 29 Dec 2009 21:55:34 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: GangChen References: <36ba02b00912190144h698f3f05ufe693208c9222ad6@mail.gmail.com> In-Reply-To: <36ba02b00912190144h698f3f05ufe693208c9222ad6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: Vzz7cZXB Cc: Behave WG Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-framework-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 13:56:05 -0000 Thanks for the review. We will update the draft after the WGLC. xing GangChen 写é“: > > Some technical comments: > > 1. In section 2, "The intention of this document is to focus on > *network-based* translations solutions under all kinds of situations". > > After the interim meeting, the draft has updated definitons of both > IPv4 network and IPv6 network, which indicates that A NETWORK could be > a A HOST. Corresponding to the changes, the draft is suggested to > remove the limitation of "network-based". Although the "network-based" > could cover "host-based" according to the new defined terms, but it > could be better to reword the statement to avoid confusions. > > 2. In section 1.4, "Transition Phase: This is the last stage of "S" > curve." > > According to the context, I guess it should be middle stage. > > Some Editorial comments: > > 1. In section 1, "What if the process of moving a network and its > components...." > > It could be easy to understand if we seperate the whole long sentence > into several sub-sentences. How about this, > "What if the process of moving a network and its components or > customers is too late for contract cycles to affect IPv6 turn-up on > important parts? At this point, it becomes uneconomical to deploy > global IPv4 addresses in new services." > > 2.In section 1.1, "but configuring IPv4 routing is not in the network > operator's view the most desirable strategy" > > How about: "but configuring IPv4 routing is not the most desirable > strategy from the network operator's view" > BRs > Gang > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From caozhenpku@gmail.com Wed Dec 30 08:06:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7923A6A3B for ; Wed, 30 Dec 2009 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJY+Nfg4V+hc for ; Wed, 30 Dec 2009 08:06:42 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 4A9153A68EA for ; Wed, 30 Dec 2009 08:06:42 -0800 (PST) Received: by pwi20 with SMTP id 20so8065999pwi.29 for ; Wed, 30 Dec 2009 08:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dDccUhvwL77h4Tcg8exDVZzU/XlJMR9xrO6WpeiinVg=; b=XWHSOxk23yLFPPMg3QDokBBIzCtImO43Mfn/OpCA/RTWURc//41/3+TFo20t0FdePs 95x5l43davXZ4Zeti24te9/wtOtjWavGOqJd9CkT4eU+pFNH9i2VDxMH/4ZduiJKi04p ppf2xfzLyaQ9f6XqiQzknc5ggt94xoI4RaRx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NqQfBGkpOxe9jywi5x9Szej8ikSR1ojUSe4h+c15kFwT5rbwu/4wJnBYEEeGoMP1N2 4FfGYBrFecgmR4/fmklF4lPa4pY95kYy7UuIGFOTSqnh8PnUD+7aBMXEj7Sld1BJLxFS uJSr8xEpekK/4oblrfhJGb/9SE6uUr3Z1fZNk= MIME-Version: 1.0 Received: by 10.142.3.35 with SMTP id 35mr12385423wfc.205.1262189179771; Wed, 30 Dec 2009 08:06:19 -0800 (PST) In-Reply-To: <4B28E654.9080609@cernet.edu.cn> References: <4B28E654.9080609@cernet.edu.cn> Date: Thu, 31 Dec 2009 00:06:19 +0800 Message-ID: From: Zhen Cao To: Xing Li Content-Type: multipart/alternative; boundary=00504502c10db31bdd047bf451f4 Cc: Behave WG Subject: Re: [BEHAVE] Comments on the xlate draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:06:43 -0000 --00504502c10db31bdd047bf451f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xing, I would like to add one more comment as below: "translator device" that appears in section 2.5 and 3.4 would be more appropriate if changed to "translator function". Expert these two places, the document mainly treat the translator as a function. So it is desirable to keep the consistence. Thanks for the efforts in delivering this well shaped document. Happy new year - in advanced:) Best regards, Zhen On Wed, Dec 16, 2009 at 9:53 PM, Xing Li wrote: > Hi, Zhen, > > Thanks. > > Zhen Cao =E5=86=99=E9=81=93: > > Hi All, >> >> Some comments on the draft before the interim meeting. >> >> 1. section1.3, when discussing the stateful and stateless mode, a >> reference to the framework draft is important because there is a clear >> definition of stateless and stateful translation. >> >> > > Added. > > > 2. section2.3 [page 13], handling of ICMPv4 error message to ICMPv6 on >> Code 4: I believe that adjust of the MTU should be the minimum of the >> original advertised MTU + 20, the translator's MTU on the IPv6 side >> and the translator's MTU on the IPv4 side+20, i.e. min (advertised >> MTU+20, MTU_t6, MTU_t4+20). That's what the xlate-stateful draft's >> wording. >> >> > Modified. > > > 3. section3.2 [page 20], handling of ICMPv6 error message to ICMPv4 on >> Type 2: similar to the above, min (advertised MTU-20, MTU_t4, >> MTU_t6-20). >> >> > > Modified. > > > 4. section 5, for IPsec ESP tunnel model, "the ipv6 node needs to be >> able to generate an inner IPv4 header...", that's not possible IMO. >> The IPv6 application has no way to fill in the IPv4 inner address. >> Often, the tunnel insider ipv4 address is used for further routing at >> the IPsec terminator. Only if the client is using the IPv4 application >> could this case happen. So i think ESP tunnel cannot work through the >> translator. >> >> > Yes, this is the meaning this document reads, in a softer wording. > > Thanks for the comments. > > xing > > > Thanks for discussion, >> Zhen >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> >> > > --00504502c10db31bdd047bf451f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xing,=C2=A0

I would like to add one more comment as b= elow:=C2=A0

"translator device" that app= ears in section 2.5 and 3.4 would be more appropriate if changed to "t= ranslator function".=C2=A0

Expert these two places, the document mainly treat the = translator as a function. So it is desirable to keep the consistence.=C2=A0=

Thanks for the efforts in delivering this well sh= aped document.=C2=A0

Happy new year - in advanced:)

Best regards,
Zhen

On Wed, Dec 16, 2009 at 9:53 PM, Xing Li <xing@cernet.edu.cn> wrote:
Hi, Zhen,

Thanks.

Zhen Cao =E5=86=99=E9=81=93:

Hi All,

Some comments on the draft before the interim meeting.

1. section1.3, when discussing the stateful and stateless mode, a
reference to the framework draft is important because there is a clear
definition of stateless and stateful translation.
=C2=A0

Added.


2. section2.3 [page 13], handling of ICMPv4 error message to ICMPv6 on
Code 4: I believe that adjust of the MTU should be the minimum of the
original advertised MTU + 20, the translator's MTU on the IPv6 side
and the translator's MTU on the IPv4 side+20, i.e. min (advertised
MTU+20, MTU_t6, MTU_t4+20). That's what the xlate-stateful draft's<= br> wording.
=C2=A0
Modified.


3. section3.2 [page 20], handling of ICMPv6 error message to ICMPv4 on
Type 2: similar to the above, min (advertised MTU-20, MTU_t4,
MTU_t6-20).
=C2=A0

Modified.


4. section 5, for IPsec ESP tunnel model, "the ipv6 node needs to be able to generate an inner IPv4 header...", that's not possible IMO= .
The IPv6 application has no way to fill in the IPv4 inner address.
Often, the tunnel insider ipv4 address is used for further routing at
the IPsec terminator. Only if the client is using the IPv4 application
could this case happen. So i think ESP tunnel cannot work through the
translator.
=C2=A0
Yes, this is the meaning this document reads, in a softer wording.

Thanks for the comments.

xing


Thanks for discussion,
Zhen

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


=C2=A0


--00504502c10db31bdd047bf451f4-- From ebisawa@sablenetworks.net Wed Dec 30 11:08:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7763A68F5 for ; Wed, 30 Dec 2009 11:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIZFG3PkxlTc for ; Wed, 30 Dec 2009 11:08:56 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 6A0A23A67E4 for ; Wed, 30 Dec 2009 11:08:56 -0800 (PST) Received: (qmail 10732 invoked by SAV 20091230.024 by uid 0); 31 Dec 2009 04:08:35 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 31 Dec 2009 04:08:35 +0900 Date: Thu, 31 Dec 2009 04:08:14 +0900 From: Kentaro Ebisawa To: Xing Li , "Senthil Sivakumar (ssenthil)" In-Reply-To: <4B2C3E87.2050107@cernet.edu.cn> References: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> <4B2C3E87.2050107@cernet.edu.cn> Message-Id: <20091231033219.3035.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 19:08:57 -0000 Hi, Some comments inline. On Sat, 19 Dec 2009 10:46:31 +0800 Xing Li wrote: > >> 5.Section 2.1 > >> > >> Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." > >> > > Got the idea. How about we change the wording from MSUT to SHOULD? > > If the DF flag is not set and the IPv4 packet will result in an IPv6 > packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented > prior to translating it. I think what we want to make sure is it will be fragmented regardless of the link MTU of the traslator's IPv6 interface when DF bit was not set. To fragment it prior to or after the tanslation is an implementation issue, but there might be more risk of "fragmenting only when it exeeds link MTU" if one does it after the translation. So rather than changing it to SHOULD, how about changing it like below ? If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes, the packet MUST be fragmented so the resulting IPv6 packet (with Fragment header added to each fragment) will be less than or equal to 1280 bytes. For example, if the packet is fragmented prior to the translation, the IPv4 packets must be fragmented so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the Fragment header). The resulting fragments are then translated independently using the logic described below. > >> 6. Section 2.1 > >> > >> [Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn$B!G(Bt be a reason for us not to do better. > >> > >> > How about > > Hop Limit: TTL value copied from IPv4 header. Since the translator > is a router, as part of forwarding the packet it needs to > decrement the IPv4 TTL before the translation. > As part of decrementing the > TTL, the translator (as any router) needs to check for > zero and send the ICMPv4 "ttl exceeded" error. I agree that it will be more efficient to decrement TTL before translation, but it should not be specified in the RFC but chosen by who implements it. So I would prefer keeping the original sentence. For example, one might already have an software module which has full IPv6 router functionality and chose to implement an module doing the translation. In that case, translator (as a system) will do translation first and then pass the translated IPv6 packet to the IPv6 router module which will handle TTL and any other routing/forwarding functionality. > >> 8. Section 3.1 > >> Time to Live - Same comment as hoplimit for IPv6. > > How about the wording > > Time to Live: Hop Limit value copied from IPv6 header. Since the > translator is a router, as part of forwarding the packet it needs > to decrement the IPv6 Hop Limit before the translation. > As part of decrementing the > Hop Limit, the translator (as any router) needs to check for > zero and send the ICMPv6 "hop limit > exceeded" error. As previously mentioned, I think this should be up to the implementation and prefer keeping the original sentence. Regards, -- Kentaro Ebisawa From ssenthil@cisco.com Wed Dec 30 11:44:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171603A68F9 for ; Wed, 30 Dec 2009 11:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktPY6kv6v0rK for ; Wed, 30 Dec 2009 11:44:08 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FFB33A68F7 for ; Wed, 30 Dec 2009 11:44:08 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABI8O0urR7Ht/2dsb2JhbADCMZRkhDEEgWiLTA X-IronPort-AV: E=Sophos;i="4.47,476,1257120000"; d="scan'208";a="458914058" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 30 Dec 2009 19:43:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBUJhmGQ000173; Wed, 30 Dec 2009 19:43:48 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Dec 2009 11:43:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Dec 2009 11:43:45 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> In-Reply-To: <20091231033219.3035.B01659E3@sablenetworks.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 Thread-Index: AcqJg33e4l9Rcv96QImgozXZhLqlIQAAwzCA References: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> <4B2C3E87.2050107@cernet.edu.cn> <20091231033219.3035.B01659E3@sablenetworks.net> From: "Senthil Sivakumar (ssenthil)" To: "Kentaro Ebisawa" , "Xing Li" X-OriginalArrivalTime: 30 Dec 2009 19:43:48.0349 (UTC) FILETIME=[67CC72D0:01CA8988] Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 19:44:09 -0000 =20 -----Original Message----- From: Kentaro Ebisawa [mailto:ebisawa@sablenetworks.net]=20 Sent: Wednesday, December 30, 2009 2:08 PM To: Xing Li; Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 Hi, Some comments inline. On Sat, 19 Dec 2009 10:46:31 +0800 Xing Li wrote: > >> 5.Section 2.1 > >> > >> Para 1 ".....IPv4 packet MUST be fragmented prior to translating it." > >> >=20 > Got the idea. How about we change the wording from MSUT to SHOULD? >=20 > If the DF flag is not set and the IPv4 packet will result in an IPv6=20 > packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented=20 > prior to translating it. I think what we want to make sure is it will be fragmented regardless of the link MTU of the traslator's IPv6 interface when DF bit was not set. To fragment it prior to or after the tanslation is an implementation issue, but there might be more risk of "fragmenting only when it exeeds link MTU" if one does it after the translation. So rather than changing it to SHOULD, how about changing it like below ? If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes, the packet MUST be fragmented so the resulting IPv6 packet (with Fragment header added to each fragment) will be less than or equal to 1280 bytes. For example, if the packet is fragmented prior to the translation, the IPv4 packets must be fragmented so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the Fragment header). The resulting fragments are then translated independently using the logic described below. [Senthil] That sounds fine, as long as the MUST does not specifiy whether one should translate and fragment or fragment & translate. > >> 6. Section 2.1 > >> > >> [Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn't be a reason for us not to do better.=20 > >> > >> =20 > How about >=20 > Hop Limit: TTL value copied from IPv4 header. Since the translator is=20 > a router, as part of forwarding the packet it needs to decrement the=20 > IPv4 TTL before the translation. > As part of decrementing the > TTL, the translator (as any router) needs to check for zero and send=20 > the ICMPv4 "ttl exceeded" error. I agree that it will be more efficient to decrement TTL before translation, but it should not be specified in the RFC but chosen by who implements it. So I would prefer keeping the original sentence. For example, one might already have an software module which has full IPv6 router functionality and chose to implement an module doing the translation. In that case, translator (as a system) will do translation first and then pass the translated IPv6 packet to the IPv6 router module which will handle TTL and any other routing/forwarding functionality. [Senthil] I think the original wording is not good. We know the translator is a router which has both IPv4 and IPv6 functionality built in -- so why do you have to specify the ttl is to be decremented, as all the routers do that (IPv4 or IPv6). I am saying if it is not to be done by translator don't specify it.=20 > >> 8. Section 3.1 > >> Time to Live - Same comment as hoplimit for IPv6. >=20 > How about the wording >=20 > Time to Live: Hop Limit value copied from IPv6 header. Since the=20 > translator is a router, as part of forwarding the packet it needs to=20 > decrement the IPv6 Hop Limit before the translation. > As part of decrementing the > Hop Limit, the translator (as any router) needs to check for zero and=20 > send the ICMPv6 "hop limit exceeded" error. As previously mentioned, I think this should be up to the implementation and prefer keeping the original sentence. [Senthil] Same sentiment as above. Thanks Senthil Regards, -- Kentaro Ebisawa From brian.e.carpenter@gmail.com Wed Dec 30 12:15:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8373A68F6 for ; Wed, 30 Dec 2009 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4xYOguw5Jt2 for ; Wed, 30 Dec 2009 12:15:53 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 7E4123A68E5 for ; Wed, 30 Dec 2009 12:15:53 -0800 (PST) Received: by gxk28 with SMTP id 28so5821871gxk.9 for ; Wed, 30 Dec 2009 12:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sJ5Yh+IfJXkxxaYPbP6O4lwthXrJH0hsTqVjYcQoJKk=; b=XOjHYpkpwVERrvcmHTsVYN8ps70duE1Q69CftO1uHfUC8NMJlrYbBoTBMtc0VG+eYC OdCzLxibMPWe3J9JIDZrAJdbkqYJZ0DqqamSY1ZPujWd2IQodtjiOFvkCP/V+ebc4Y4d lKhd9TGLn7nnZOyBb+dp6ASd9/WbD/dzPthSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pDQ0Vs4pBm+TSWaNEswjvep69AH/SiaVUDI03Gb9Vry2nrs3cyca3X0pBn+k47taer KTguxa92akoFI1CzDLeAsuGLWy3a+WsdkQsc37WyrycHrI9psfAZdfgr3aT7ibakXU2E y5qC2nj6MfdnoxtWMlbmM4qXY8RM9ZSTgqluU= Received: by 10.100.17.30 with SMTP id 30mr3262618anq.156.1262204130609; Wed, 30 Dec 2009 12:15:30 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 4sm4843513ywd.14.2009.12.30.12.15.28 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Dec 2009 12:15:30 -0800 (PST) Message-ID: <4B3BB4DD.3060802@gmail.com> Date: Thu, 31 Dec 2009 09:15:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> <4B2C3E87.2050107@cernet.edu.cn> <20091231033219.3035.B01659E3@sablenetworks.net> <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Kentaro Ebisawa , Xing Li Subject: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:15:54 -0000 On 2009-12-31 08:43, Senthil Sivakumar (ssenthil) wrote: ... >>>> 6. Section 2.1 >>>> >>>> [Senthil] I think decrementing the TTL after translation is > inefficient. I just noticed that 2765 has the same text too, but that > shouldn't be a reason for us not to do better. >>>> >> How about >> >> Hop Limit: TTL value copied from IPv4 header. Since the translator is >> a router, as part of forwarding the packet it needs to decrement the >> IPv4 TTL before the translation. >> As part of decrementing the >> TTL, the translator (as any router) needs to check for zero and send >> the ICMPv4 "ttl exceeded" error. > > I agree that it will be more efficient to decrement TTL before > translation, but it should not be specified in the RFC but chosen by who > implements it. > > So I would prefer keeping the original sentence. > > For example, one might already have an software module which has full > IPv6 router functionality and chose to implement an module doing the > translation. > In that case, translator (as a system) will do translation first and > then pass the translated IPv6 packet to the IPv6 router module which > will handle TTL and any other routing/forwarding functionality. > > [Senthil] I think the original wording is not good. We know the > translator is a router which has both IPv4 and IPv6 functionality built > in -- so why do you have to specify the ttl is to be decremented, as all > the routers do that (IPv4 or IPv6). I am saying if it is not to be done > by translator don't specify it. No, we don't *know* that the translator is a router. Actually the document is inconsistent on this. The clearest statement is: 2.7. Knowing when to Translate If the IP/ICMP translator is implemented in a router providing both translation and normal forwarding,... which makes it clear that the tranlsator may or may not be in the same box as a router. The above extract from section 2.1 asserts that the translator is a router. Then section 1.4 says: Note that the translator MUST behave as a router, i.e. the translator MUST send packet too big error message when the packet size exceeds the MTU of the next hop interface. So, I think we need to clean up all these three to make them consistent. For example, IMHO 2.1 should say If the translator is combined with an IPv6 router, the router MUST perform normal Hop Count processing [RFC2460]. Otherwise the translator MUST emulate this processing. and so one for all three points. Brian From dthaler@microsoft.com Wed Dec 30 12:18:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B843A68B4 for ; Wed, 30 Dec 2009 12:18:46 -0800 (PST) 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.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxgrW7v57jky for ; Wed, 30 Dec 2009 12:18:45 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 85DE23A686D for ; Wed, 30 Dec 2009 12:18:39 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Dec 2009 12:18:56 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 30 Dec 2009 12:18:19 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 30 Dec 2009 12:18:20 -0800 From: Dave Thaler To: Brian E Carpenter , "Senthil Sivakumar (ssenthil)" Thread-Topic: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] Thread-Index: AQHKiYzw/BHTTJhc+0+cKL94n+vF6ZF+Bx4A Date: Wed, 30 Dec 2009 20:18:15 +0000 Message-ID: References: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> <4B2C3E87.2050107@cernet.edu.cn> <20091231033219.3035.B01659E3@sablenetworks.net> <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> <4B3BB4DD.3060802@gmail.com> In-Reply-To: <4B3BB4DD.3060802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xing Li , Kentaro Ebisawa , "behave@ietf.org" Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:18:46 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Wednesday, December 30, 2009 12:15 PM > To: Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org; Kentaro Ebisawa; Xing Li > Subject: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4- > xlate-05] >=20 > On 2009-12-31 08:43, Senthil Sivakumar (ssenthil) wrote: > ... > >>>> 6. Section 2.1 > >>>> > >>>> [Senthil] I think decrementing the TTL after translation is > > inefficient. I just noticed that 2765 has the same text too, but that > > shouldn't be a reason for us not to do better. > >>>> > >> How about > >> > >> Hop Limit: TTL value copied from IPv4 header. Since the translator > is > >> a router, as part of forwarding the packet it needs to decrement the > >> IPv4 TTL before the translation. > >> As part of decrementing the > >> TTL, the translator (as any router) needs to check for zero and send > >> the ICMPv4 "ttl exceeded" error. > > > > I agree that it will be more efficient to decrement TTL before > > translation, but it should not be specified in the RFC but chosen by > who > > implements it. > > > > So I would prefer keeping the original sentence. > > > > For example, one might already have an software module which has full > > IPv6 router functionality and chose to implement an module doing the > > translation. > > In that case, translator (as a system) will do translation first and > > then pass the translated IPv6 packet to the IPv6 router module which > > will handle TTL and any other routing/forwarding functionality. > > > > [Senthil] I think the original wording is not good. We know the > > translator is a router which has both IPv4 and IPv6 functionality > built > > in -- so why do you have to specify the ttl is to be decremented, as > all > > the routers do that (IPv4 or IPv6). I am saying if it is not to be > done > > by translator don't specify it. >=20 > No, we don't *know* that the translator is a router. Actually the > document > is inconsistent on this. The clearest statement is: >=20 > 2.7. Knowing when to Translate >=20 > If the IP/ICMP translator is implemented in a router providing both > translation and normal forwarding,... >=20 > which makes it clear that the tranlsator may or may not be in the > same box as a router. The above extract from section 2.1 asserts that > the translator is a router. Then section 1.4 says: >=20 > Note that the translator MUST behave as a router, i.e. the > translator MUST send packet too big error message when the packet > size exceeds the MTU of the next hop interface. >=20 > So, I think we need to clean up all these three to make them > consistent. >=20 > For example, IMHO 2.1 should say >=20 > If the translator is combined with an IPv6 router, the router MUST > perform normal Hop Count processing [RFC2460]. Otherwise the > translator MUST emulate this processing. >=20 > and so one for all three points. I think the translator must decrement the TTL (either before or after translation), which makes it a router in my book. -Dave From ssenthil@cisco.com Wed Dec 30 12:24:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261503A67D6 for ; Wed, 30 Dec 2009 12:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XOzu-OOcKtg for ; Wed, 30 Dec 2009 12:24:35 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 44B053A6829 for ; Wed, 30 Dec 2009 12:24:35 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALhFO0urRN+K/2dsb2JhbADCOZRkhDEEgWg X-IronPort-AV: E=Sophos;i="4.47,476,1257120000"; d="scan'208";a="68601078" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Dec 2009 20:24:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBUKOFU3027547; Wed, 30 Dec 2009 20:24:15 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Dec 2009 12:24:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Dec 2009 12:24:14 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4B3BB4DD.3060802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] Thread-Index: AcqJjNdZZr6LMnZhR9u9HgP/PD1K/AAAJdFg References: <85B2F271FDF6B949B3672BA5A7BB62FB090FEBD3@xmb-sjc-236.amer.cisco.com> <4B2C3E87.2050107@cernet.edu.cn> <20091231033219.3035.B01659E3@sablenetworks.net> <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> <4B3BB4DD.3060802@gmail.com> From: "Senthil Sivakumar (ssenthil)" To: "Brian E Carpenter" X-OriginalArrivalTime: 30 Dec 2009 20:24:15.0537 (UTC) FILETIME=[0E83F210:01CA898E] Cc: behave@ietf.org, Kentaro Ebisawa , Xing Li Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:24:36 -0000 We always have the confusion of whether a translator (nat or nat64) a router, a host or both? In my opinion it acts as both - even though I heard conflicting opinions.=20 - Why it is a router? It decrements the TTL and forwards the packet. - Why is it a host ? It does reassembly of fragments, segments that are purely non-router functionality and hence a host. I agree that the draft is a little inconsistent on the wording. But my question is when is a translator not a router? Senthil =20 -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Wednesday, December 30, 2009 3:15 PM To: Senthil Sivakumar (ssenthil) Cc: Kentaro Ebisawa; Xing Li; behave@ietf.org Subject: Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] On 2009-12-31 08:43, Senthil Sivakumar (ssenthil) wrote: ... >>>> 6. Section 2.1 >>>> >>>> [Senthil] I think decrementing the TTL after translation is > inefficient. I just noticed that 2765 has the same text too, but that=20 > shouldn't be a reason for us not to do better. >>>> =20 >> How about >> >> Hop Limit: TTL value copied from IPv4 header. Since the translator is >> a router, as part of forwarding the packet it needs to decrement the >> IPv4 TTL before the translation. >> As part of decrementing the >> TTL, the translator (as any router) needs to check for zero and send=20 >> the ICMPv4 "ttl exceeded" error. >=20 > I agree that it will be more efficient to decrement TTL before=20 > translation, but it should not be specified in the RFC but chosen by=20 > who implements it. >=20 > So I would prefer keeping the original sentence. >=20 > For example, one might already have an software module which has full > IPv6 router functionality and chose to implement an module doing the=20 > translation. > In that case, translator (as a system) will do translation first and=20 > then pass the translated IPv6 packet to the IPv6 router module which=20 > will handle TTL and any other routing/forwarding functionality. >=20 > [Senthil] I think the original wording is not good. We know the=20 > translator is a router which has both IPv4 and IPv6 functionality=20 > built in -- so why do you have to specify the ttl is to be=20 > decremented, as all the routers do that (IPv4 or IPv6). I am saying if > it is not to be done by translator don't specify it. No, we don't *know* that the translator is a router. Actually the document is inconsistent on this. The clearest statement is: 2.7. Knowing when to Translate If the IP/ICMP translator is implemented in a router providing both translation and normal forwarding,... which makes it clear that the tranlsator may or may not be in the same box as a router. The above extract from section 2.1 asserts that the translator is a router. Then section 1.4 says: Note that the translator MUST behave as a router, i.e. the translator MUST send packet too big error message when the packet size exceeds the MTU of the next hop interface. So, I think we need to clean up all these three to make them consistent. For example, IMHO 2.1 should say If the translator is combined with an IPv6 router, the router MUST perform normal Hop Count processing [RFC2460]. Otherwise the translator MUST emulate this processing. and so one for all three points. Brian From ebisawa@sablenetworks.net Wed Dec 30 12:31:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AB33A6829 for ; Wed, 30 Dec 2009 12:31:14 -0800 (PST) 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.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66uZQwDoxq09 for ; Wed, 30 Dec 2009 12:31:13 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id F02DF3A67D6 for ; Wed, 30 Dec 2009 12:31:12 -0800 (PST) Received: (qmail 30783 invoked by SAV 20091230.033 by uid 0); 31 Dec 2009 05:30:52 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 31 Dec 2009 05:30:52 +0900 Date: Thu, 31 Dec 2009 05:30:26 +0900 From: Kentaro Ebisawa To: Xing Li Message-Id: <20091231050027.3038.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.50 [ja] Cc: behave@ietf.org Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-05 (review) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:31:14 -0000 Hi Xing, Other than the items still discussed in the ML, I have 4 more comments on the draft-ietf-behave-v6v4-xlate-05. 1. [Page 14] 2.5. Translator sending ICMP error message > If the packet is discarded, then the translator SHOULD be able to > send back an ICMP message to the original sender of the packet, > unless the discarded packet is itself an ICMP message. The ICMP > message, if sent, has a type of 3 (Destination Unreachable) and a > code of 13 (Communication Administratively Prohibited). The > translator device MUST allow to configure whether the ICMP error > messages are sent, rate-limited or not sent. There are some cases which translator drops packet and send ICMPv4 packet other than Type 3, Code 13 like when doing part of path MTU discovery. So we should mention "unless otherwise specified in this document or [I-D.ietf-behave-v6v4-xlate-stateful]" like below : =2E.. message, if sent, has a type of 3 (Destination Unreachable) and a code of 13 (Communication Administratively Prohibited) unless otherwise specified in this document or in [I-D.ietf-behave-v6v4-xlate-= stateful]. =2E.. 2. [Page 19] 3.2. Translating ICMPv6 Headers into ICMPv4 Headers > ICMPv6 error messages: >=20 > Destination Unreachable (Type 1) Set the Type field to 3. > Translate the code field as follows: =2E.. > Code 4 (port unreachable): Set Code to 3 (port unreachable). I think we should add below (code 5, 6 should be droped) : Other Code values: Silently drop > Packet Too Big (Type 2) Translate to an ICMPv4 Destination > Unreachable with code 4. The MTU field needs to be adjusted Add Type for clarification. Packet Too Big (Type 2) Translate to an ICMPv4 Destination Unreachable (Type 3) with code 4. The MTU field needs to be adj= usted 3. [Page 21] 3.4. Translator sending ICMPv6 error message > If the packet is discarded, then the translator SHOULD be able to > send back an ICMPv6 message to the original sender of the packet, > unless the discarded packet is itself an ICMPv6 message. The ICMPv6 > message, if sent, has a type of 1 (Destination Unreachable) and a > code of 1 (Communication with destination administratively > prohibited). The translator device MUST allow configuring whether > the ICMPv6 error messages are sent, rate-limited or not sent. As discussed in "[Page 14] 2.5. Translator sending ICMP error message", we should mention "unless otherwise specified in this doecument or [I-D.ietf-behave-v6v4-xlate-stateful]" like below : =2E.. message, if sent, has a type of 1 (Destination Unreachable) and a code of 1 (Communication with destination administratively prohibited) unless otherwise specified in this doecument or [I-D.ietf-behave-v6v4-xlate-stateful]. =2E.. 4. [Page 23] 7. Appendix A: Translating pointer in Parameter Problem We need to modify this based on the feedback during the WGLC. (Noted just as a reminder) Regards, --=20 Kentaro Ebisawa From ebisawa@sablenetworks.net Wed Dec 30 12:50:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD843A691F for ; Wed, 30 Dec 2009 12:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L1MLT3yN3ve for ; Wed, 30 Dec 2009 12:50:51 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id AB1A63A67B2 for ; Wed, 30 Dec 2009 12:50:50 -0800 (PST) Received: (qmail 13337 invoked by SAV 20091230.033 by uid 0); 31 Dec 2009 05:50:30 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 31 Dec 2009 05:50:30 +0900 Date: Thu, 31 Dec 2009 05:50:03 +0900 From: Kentaro Ebisawa To: "Senthil Sivakumar (ssenthil)" , "Brian E Carpenter" In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> Message-Id: <20091231053442.303D.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: behave@ietf.org, Xing Li Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:50:52 -0000 Hi, I also think translator act as both, router and host. My point was we should let implementor decide when to decrement TTL. (before or after the translation) To answer to the Brian's comment : > 2.7. Knowing when to Translate > > If the IP/ICMP translator is implemented in a router providing both > translation and normal forwarding,... > > which makes it clear that the tranlsator may or may not be in the same > box as a router. One can implement a translator which would NOT forward packet which doesn't need translation. Such implementation would not do v6 to v6 nor v4 to v4 packet forwarding, but will act as a router for v6v4 or v4v6 packet and do v6v4(v4v6) packet forwarding. I think in the sentense above, "translation" implies "translation + v6v4(v4v6) forwarding" and "normal forwarding" means "v4v4 or v6v6 forwarding without translation". So for both cases, translator act as a router (decrements TTL). -- Kentaro Ebisawa On Wed, 30 Dec 2009 12:24:14 -0800 "Senthil Sivakumar (ssenthil)" wrote: > We always have the confusion of whether a translator (nat or nat64) a > router, a host or both? > In my opinion it acts as both - even though I heard conflicting > opinions. > - Why it is a router? > It decrements the TTL and forwards the packet. > > - Why is it a host ? > It does reassembly of fragments, segments that are purely non-router > functionality and hence a host. > > I agree that the draft is a little inconsistent on the wording. But my > question is when is a translator not a router? > > Senthil > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Wednesday, December 30, 2009 3:15 PM > To: Senthil Sivakumar (ssenthil) > Cc: Kentaro Ebisawa; Xing Li; behave@ietf.org > Subject: Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] > > On 2009-12-31 08:43, Senthil Sivakumar (ssenthil) wrote: > ... > >>>> 6. Section 2.1 > >>>> > >>>> [Senthil] I think decrementing the TTL after translation is > > inefficient. I just noticed that 2765 has the same text too, but that > > shouldn't be a reason for us not to do better. > >>>> > >> How about > >> > >> Hop Limit: TTL value copied from IPv4 header. Since the translator is > > >> a router, as part of forwarding the packet it needs to decrement the > >> IPv4 TTL before the translation. > >> As part of decrementing the > >> TTL, the translator (as any router) needs to check for zero and send > >> the ICMPv4 "ttl exceeded" error. > > > > I agree that it will be more efficient to decrement TTL before > > translation, but it should not be specified in the RFC but chosen by > > who implements it. > > > > So I would prefer keeping the original sentence. > > > > For example, one might already have an software module which has full > > IPv6 router functionality and chose to implement an module doing the > > translation. > > In that case, translator (as a system) will do translation first and > > then pass the translated IPv6 packet to the IPv6 router module which > > will handle TTL and any other routing/forwarding functionality. > > > > [Senthil] I think the original wording is not good. We know the > > translator is a router which has both IPv4 and IPv6 functionality > > built in -- so why do you have to specify the ttl is to be > > decremented, as all the routers do that (IPv4 or IPv6). I am saying if > > > it is not to be done by translator don't specify it. > > No, we don't *know* that the translator is a router. Actually the > document is inconsistent on this. The clearest statement is: > > 2.7. Knowing when to Translate > > If the IP/ICMP translator is implemented in a router providing both > translation and normal forwarding,... > > which makes it clear that the tranlsator may or may not be in the same > box as a router. The above extract from section 2.1 asserts that the > translator is a router. Then section 1.4 says: > > Note that the translator MUST behave as a router, i.e. the > translator MUST send packet too big error message when the packet > size exceeds the MTU of the next hop interface. > > So, I think we need to clean up all these three to make them consistent. > > For example, IMHO 2.1 should say > > If the translator is combined with an IPv6 router, the router MUST > perform normal Hop Count processing [RFC2460]. Otherwise the > translator MUST emulate this processing. > > and so one for all three points. > > Brian From ebisawa@sablenetworks.net Wed Dec 30 13:10:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20303A67E1 for ; Wed, 30 Dec 2009 13:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PADCPGRcRKjO for ; Wed, 30 Dec 2009 13:10:43 -0800 (PST) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 54CDF3A6917 for ; Wed, 30 Dec 2009 13:10:39 -0800 (PST) Received: (qmail 29308 invoked by SAV 20091230.034 by uid 0); 31 Dec 2009 06:10:19 +0900 Received: from unknown (HELO ?10.90.2.66?) (ebisawa@202.215.8.2) by dc12.etius.jp (202.229.133.90) with ESMTPA; 31 Dec 2009 06:10:19 +0900 Date: Thu, 31 Dec 2009 06:09:51 +0900 From: Kentaro Ebisawa To: "Senthil Sivakumar (ssenthil)" In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> References: <20091231033219.3035.B01659E3@sablenetworks.net> <85B2F271FDF6B949B3672BA5A7BB62FB091844C3@xmb-sjc-236.amer.cisco.com> Message-Id: <20091231055330.3040.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Cc: behave@ietf.org, Xing Li Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 21:10:45 -0000 Hi, Comments inline. On Wed, 30 Dec 2009 11:43:45 -0800 "Senthil Sivakumar (ssenthil)" wrote: > -----Original Message----- > From: Kentaro Ebisawa [mailto:ebisawa@sablenetworks.net] > Sent: Wednesday, December 30, 2009 2:08 PM > To: Xing Li; Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04 > > Hi, > > Some comments inline. > > > On Sat, 19 Dec 2009 10:46:31 +0800 > Xing Li wrote: > > > >> 5.Section 2.1 > > >> > > >> Para 1 ".....IPv4 packet MUST be fragmented prior to translating > it." > > >> > > > > Got the idea. How about we change the wording from MSUT to SHOULD? > > > > If the DF flag is not set and the IPv4 packet will result in an IPv6 > > packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented > > prior to translating it. > > I think what we want to make sure is it will be fragmented regardless of > the link MTU of the traslator's IPv6 interface when DF bit was not set. > To fragment it prior to or after the tanslation is an implementation > issue, but there might be more risk of "fragmenting only when it exeeds > link MTU" if one does it after the translation. > > So rather than changing it to SHOULD, how about changing it like below ? > > If the DF flag is not set and the IPv4 packet will result in an IPv6 > packet larger than 1280 bytes, the packet MUST be fragmented so the > resulting IPv6 packet (with Fragment header added to each fragment) > will be less than or equal to 1280 bytes. For example, if the packet > is fragmented prior to the translation, the IPv4 packets must be > fragmented so that their length, excluding the IPv4 header, is at > most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the > Fragment header). The resulting fragments are then translated > independently using the logic described below. > > [Senthil] That sounds fine, as long as the MUST does not specifiy > whether one should translate and fragment or fragment & translate. [Kentaro] MUST is only for the fragmentation. And does not specify the order. > > >> 6. Section 2.1 > > >> > > >> [Senthil] I think decrementing the TTL after translation is > inefficient. I just noticed that 2765 has the same text too, but that > shouldn't be a reason for us not to do better. > > >> > > >> > > How about > > > > Hop Limit: TTL value copied from IPv4 header. Since the translator is > > a router, as part of forwarding the packet it needs to decrement the > > IPv4 TTL before the translation. > > As part of decrementing the > > TTL, the translator (as any router) needs to check for zero and send > > the ICMPv4 "ttl exceeded" error. > > I agree that it will be more efficient to decrement TTL before > translation, but it should not be specified in the RFC but chosen by who > implements it. > > So I would prefer keeping the original sentence. > > For example, one might already have an software module which has full > IPv6 router functionality and chose to implement an module doing the > translation. > In that case, translator (as a system) will do translation first and > then pass the translated IPv6 packet to the IPv6 router module which > will handle TTL and any other routing/forwarding functionality. > > [Senthil] I think the original wording is not good. We know the > translator is a router which has both IPv4 and IPv6 functionality built > in -- so why do you have to specify the ttl is to be decremented, as all > the routers do that (IPv4 or IPv6). I am saying if it is not to be done > by translator don't specify it. [Kentaro] Translator acting as router implies it needs to decrement TTL. So in that point of view, you don't have to specify it in this document. But in this context, I think we should remind to decrement TTL since it will be misleading if you delete it and just write : > Hop Limit: TTL value copied from IPv4 header. If only above is mentioned in the doc, then one might think this is an exception for translator and just need to copy the value without decrementing it. So understanding that it might be rephrasing something already implied, I think we should leave the explanation of decrementing TTL for clarification. Thanks, -- Kentaro Ebisawa > > >> 8. Section 3.1 > > >> Time to Live - Same comment as hoplimit for IPv6. > > > > How about the wording > > > > Time to Live: Hop Limit value copied from IPv6 header. Since the > > translator is a router, as part of forwarding the packet it needs to > > decrement the IPv6 Hop Limit before the translation. > > As part of decrementing the > > Hop Limit, the translator (as any router) needs to check for zero and > > send the ICMPv6 "hop limit exceeded" error. > > As previously mentioned, I think this should be up to the implementation > and prefer keeping the original sentence. > > [Senthil] Same sentiment as above. > > Thanks > Senthil > > Regards, > -- > Kentaro Ebisawa From brian.e.carpenter@gmail.com Wed Dec 30 17:16:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C593A69DF for ; Wed, 30 Dec 2009 17:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im1bPPSj1pwe for ; Wed, 30 Dec 2009 17:16:18 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 5D0653A69E7 for ; Wed, 30 Dec 2009 17:16:18 -0800 (PST) Received: by yxe30 with SMTP id 30so14226970yxe.29 for ; Wed, 30 Dec 2009 17:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6L3Uasgaa1ij7Ckt814tohISdQaMRyknQgTMoOgBKds=; b=W0VQGYLxGjO2by6ar0KErYdE/xo9coV3VhnZFXAOWEWqkQ8xTmIvJ4U8eNzltodLmG pdDwpoxlEShCyjmY050Cc1DjRUvd6JiYcSZqFc3yHufFP3cu3CexOSV9GX2UkPVhhioW qT0dYFIH+0gjFv/YoM4h12vQLK/I/LZPQT9Mc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=hYTmIPxKbBaczcyWjg6NZMwDazvJtGUJv6kc3Cv4+UWEqIx49F6iYtlP9c1noeD2Ez 49Lyzhhzh0ebmaPsFvf1cY8EhAoUGwZ7dzhHDp9kVaXTaczetm8LkjbW26uniX4P3Uyb wWFNjXpnkcurwALd0pnGPqNw3qtZha6zx+cEs= Received: by 10.151.89.36 with SMTP id r36mr17682858ybl.129.1262222154729; Wed, 30 Dec 2009 17:15:54 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 9sm4929597ywf.20.2009.12.30.17.15.52 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Dec 2009 17:15:54 -0800 (PST) Message-ID: <4B3BFB4A.7010801@gmail.com> Date: Thu, 31 Dec 2009 14:15:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kentaro Ebisawa References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> In-Reply-To: <20091231053442.303D.B01659E3@sablenetworks.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Xing Li Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 01:16:19 -0000 I perhaps wasn't clear enough. I agree that a node that contains a translator should always decrement the hop count; it's clearly a hop. But consider what happens to the packet after it's been translated. Does the node simply send the packet off to its default router, like any other IPv6 node? Or does it pass the packet on to a routing daemon, with its own routing table and executing at least one routing protocol? If it's the second case, and we don't specify things more carefully, the hop count will get decremented twice in one node (once by the translator and then a second time by the routing daemon). If we don't want that to happen, we need to specify the two cases separately. That is what my proposed text does (for the v4 to v6 direction): If the translator is combined with an IPv6 router, the router MUST perform normal Hop Count processing [RFC2460]. Otherwise the translator MUST emulate this processing. Brian On 2009-12-31 09:50, Kentaro Ebisawa wrote: > Hi, > > I also think translator act as both, router and host. > My point was we should let implementor decide when to decrement TTL. > (before or after the translation) > > To answer to the Brian's comment : > >> 2.7. Knowing when to Translate >> >> If the IP/ICMP translator is implemented in a router providing both >> translation and normal forwarding,... >> >> which makes it clear that the tranlsator may or may not be in the same >> box as a router. > > One can implement a translator which would NOT forward packet which doesn't > need translation. Such implementation would not do v6 to v6 nor v4 to v4 > packet forwarding, but will act as a router for v6v4 or v4v6 packet and do > v6v4(v4v6) packet forwarding. > > I think in the sentense above, "translation" implies "translation + v6v4(v4v6) forwarding" > and "normal forwarding" means "v4v4 or v6v6 forwarding without translation". > > So for both cases, translator act as a router (decrements TTL). > From dthaler@microsoft.com Wed Dec 30 21:52:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F953A6A19 for ; Wed, 30 Dec 2009 21:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwRlYeD2KME1 for ; Wed, 30 Dec 2009 21:52:45 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 57AFA3A6A18 for ; Wed, 30 Dec 2009 21:52:45 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Dec 2009 21:53:02 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 30 Dec 2009 21:52:25 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 30 Dec 2009 21:52:24 -0800 From: Dave Thaler To: Brian E Carpenter , Kentaro Ebisawa Thread-Topic: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] Thread-Index: AQHKiY4vwy5fU7QA0UuKR1ljMwqr0pF+llGAgABKRwD//5GQgA== Date: Thu, 31 Dec 2009 05:52:24 +0000 Message-ID: References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> In-Reply-To: <4B3BFB4A.7010801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xing Li , "behave@ietf.org" Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 05:52:46 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Wednesday, December 30, 2009 5:16 PM > To: Kentaro Ebisawa > Cc: behave@ietf.org; Xing Li > Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave- > v6v4-xlate-05] >=20 > I perhaps wasn't clear enough. I agree that a node that contains > a translator should always decrement the hop count; it's clearly > a hop. >=20 > But consider what happens to the packet after it's been translated. > Does the node simply send the packet off to its default router, > like any other IPv6 node? Or does it pass the packet on to > a routing daemon, A routing daemon doesn't handle packets (at least in most routers). The forwarding place in the kernel does. A routing daemon just handles routing protocols. > with its own routing table and executing at > least one routing protocol?=20 A router need not execute at least one routing protocol. If a router uses static routes, it's still a router. > If it's the second case, and we > don't specify things more carefully, the hop count will get > decremented twice in one node (once by the translator and > then a second time by the routing daemon). If we don't want that > to happen, we need to specify the two cases separately. I don't think you need to specify that level of detail. -Dave >=20 > That is what my proposed text does (for the v4 to v6 direction): >=20 > If the translator is combined with an IPv6 router, the router MUST > perform normal Hop Count processing [RFC2460]. Otherwise the > translator MUST emulate this processing. The above text is confusing to me, since "combined" is ambiguous. If a v4/v6 translator is running on the same box as a regular IPv6 router, but they're not chained, just running ships in the night, they're still "combined" in the "same box" sense. -Dave >=20 > Brian >=20 > On 2009-12-31 09:50, Kentaro Ebisawa wrote: > > Hi, > > > > I also think translator act as both, router and host. > > My point was we should let implementor decide when to decrement TTL. > > (before or after the translation) > > > > To answer to the Brian's comment : > > > >> 2.7. Knowing when to Translate > >> > >> If the IP/ICMP translator is implemented in a router providing > both > >> translation and normal forwarding,... > >> > >> which makes it clear that the tranlsator may or may not be in the > same > >> box as a router. > > > > One can implement a translator which would NOT forward packet which > doesn't > > need translation. Such implementation would not do v6 to v6 nor v4 to > v4 > > packet forwarding, but will act as a router for v6v4 or v4v6 packet > and do > > v6v4(v4v6) packet forwarding. > > > > I think in the sentense above, "translation" implies "translation + > v6v4(v4v6) forwarding" > > and "normal forwarding" means "v4v4 or v6v6 forwarding without > translation". > > > > So for both cases, translator act as a router (decrements TTL). > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From maxpassion@gmail.com Thu Dec 31 07:56:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CF33A6878 for ; Thu, 31 Dec 2009 07:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcjzV3KMqFH7 for ; Thu, 31 Dec 2009 07:56:20 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id AC3403A67AB for ; Thu, 31 Dec 2009 07:56:20 -0800 (PST) Received: by pwi20 with SMTP id 20so8643119pwi.29 for ; Thu, 31 Dec 2009 07:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bA7sakg07AE3HdRnqQlY/WW57IRQxeSJ/m2yMuBvdow=; b=q9WISIzqn0hWS7YJqPX40CgGOrE6geyu98picPiQbCI/uAak/kRxviFohqEfn7glo4 2/m73WP4x25p7gBXVZpPV/lqKi0Ss1kbt5fkpG+fKkuV4TOB0EbJSBqKvkrmcx7uUKPy ET170TZxx5+ncRPE6kme+2X/RNk4rHtFFjXd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=X33PiYGjjYkBLHcL3hssa+LQHuKeE0lzMa4/jlbmr17FAKYgK80a+CN1OAHijOnNYv OJeFHFsi44YWlp+czfymGkyRrDRZ0J4kmjL/1xJp5WRQVNIGDYat1nCKbGiaqVHNOTdr SnUVqejp87D6tBp81AHiHmj6OlfBWcyMHkvFY= MIME-Version: 1.0 Received: by 10.142.5.40 with SMTP id 40mr1484468wfe.76.1262274958058; Thu, 31 Dec 2009 07:55:58 -0800 (PST) Date: Thu, 31 Dec 2009 23:55:57 +0800 Message-ID: <25e1aaa40912310755rfa95575q6c452b576d651576@mail.gmail.com> From: liu dapeng To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] Review: draft-ietf-behave-ftp64-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 15:56:21 -0000 This is my review comments of draft-ietf-behave-ftp64-00.txt: 1.Introduction The last sentence of 3rd paragraph from back: "Client that want to engage more complex behavior, such as server-to-server transfer,may take an FTP ALG go into transparent mode by issuing an AUTH command". Shall we make this point more clearly by elaboration the reason, such as: "...such as server-to-server transfer,may take an FTP ALG go into transparent mode by issuing an AUTH command(see section 4.1 for using AUTH to switch off the ALG function). 3. Client recommendations "In that case, the cache entry should be cleared if older than 7 days and the server indicates EPSV support in its FEAT response where it previously did not indicate EPSV support in its FEAT response." Should we make it more flexible by not specifying a fixed time of the cache entry, such as: "...In that case, the cache entry should be cleared if older than a period of time such as 7 days ...." "...the server will respond to the PASV command with an IPv4 address that the client must use to connect to for the data connection. " little change of the wording: "...the server will respond to the PASV command with an IPv4 address that the client is supposed to use to connect to for the data connection. " "The main rationale for ignoring the IPv4 address in the 227 response, even if the client has IPv4 connectivity, is the fact that most servers will only allow a data connection from the same client address as seen in the control channel connection, see . Using IPv6 for the control channel and IPv4 for the data channel means that the source address will almost certainly be different in both cases, making it unlikely that the data connection can be established successfully." propose to add one short sentence in the end of the above paragraph: "...making it unlikely that the data connection can be established successfully. There are also other reasons that makes it inappropriate to use the IPv4 address in the response message even if the client has IPv4 connectivity, such as: the IPv4 connectivity may can not reach the server due to configuration or other reasons." "EPSV ALL" indicates that the client will use EPSV for all transfers, but an ALG may translate EPSV commands to PASV commands, conflicting with the earlier "EPSV ALL". Comments: Requiring client not using "EPSV ALL" at all maybe a not a good approach considering that there are chances that the server support EPSV ALL command and the communication between them may not need an ALG. 4. ALG functionality Propose to add some sentences to clarity that there maybe a chance that for optimized client and server which comply with this document using ALG may lead to un-optimized result. Appendix B. Acknowledgements Propose to move the Acknowledgements section in to the main body of the document and add a "contributors" section that lists all the contributors of this document. Best regards, Dapeng Liu From maxpassion@gmail.com Thu Dec 31 08:15:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B5D3A69F0 for ; Thu, 31 Dec 2009 08:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[AWL=-5.421, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxNVZ+HJADUq for ; Thu, 31 Dec 2009 08:15:58 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 5E4903A6841 for ; Thu, 31 Dec 2009 08:15:58 -0800 (PST) Received: by pwi20 with SMTP id 20so8652357pwi.29 for ; Thu, 31 Dec 2009 08:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=0xoc419RRoJ+A8SeuX2/hJUnZEHv9khZUtR9cBaOkSg=; b=V3PeUnT5xdj4Qt1SdFyRa7tTl+z5ifBextotAVza8CVnLd8nTjpf+rOMVLL/8jK1qr L6Y0Z3uNmXdAhpAySJCuRu+geihv+l7OajZjwGnjbh0Ghi1GIhdon44AwA/Fz/5iMJPy KN7H5nUN1moPmYTX+rJUoEUh/SPgPPZBsqu3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DS0lXMrDvZzxUU1j7tDFiveW74IEPhxVQ4FOuTDexQQt5un8XkS8aqpx2KgngGuLGG /NEW+DdDe1t+M+6MAbx9TmnVuXuR+Tt0AK0SVloG6UX6Eu1qCmYsRXzOQ05OcmsissQH lDZzFqZcetFhRHq8UiCg2ydAGZOe4Acc9jcTQ= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr13187085wfa.157.1262276135555; Thu, 31 Dec 2009 08:15:35 -0800 (PST) In-Reply-To: <25e1aaa40912310755rfa95575q6c452b576d651576@mail.gmail.com> References: <25e1aaa40912310755rfa95575q6c452b576d651576@mail.gmail.com> Date: Fri, 1 Jan 2010 00:15:35 +0800 Message-ID: <25e1aaa40912310815i681e11e0jb7cce0268b081e12@mail.gmail.com> From: liu dapeng To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [BEHAVE] Review: draft-ietf-behave-ftp64-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 16:15:59 -0000 2009/12/31, liu dapeng : > This is my review comments of draft-ietf-behave-ftp64-00.txt: > > 1.Introduction > The last sentence of 3rd paragraph from back: "Client that want to > engage more complex behavior, such as server-to-server transfer,may > take an FTP ALG go into transparent mode by issuing an AUTH command". > Shall we make this point more clearly by elaboration the reason, such > as: "...such as server-to-server transfer,may take an FTP ALG go into > transparent mode by issuing an AUTH command(see section 4.1 for using > AUTH to switch off the ALG function). > > 3. Client recommendations > "In that case, the cache entry should be cleared if older than 7 days > and the server indicates EPSV support in its FEAT response where it > previously did not indicate EPSV support in its > FEAT response." > Should we make it more flexible by not specifying a fixed time of the > cache entry, such as: "...In that case, the cache entry should be > cleared if older than a period of time such as 7 days ...." > > "...the server will respond to the PASV command with an IPv4 address > that the client must > use to connect to for the data connection. " > little change of the wording: "...the server will respond to the PASV > command with an IPv4 address that the client is supposed to use to > connect to for the data connection. " > > "The main rationale for ignoring the IPv4 address in the 227 response, > even if the client has IPv4 connectivity, is the fact that most > servers will only allow a data connection from the same client > address as seen in the control channel connection, see > . Using IPv6 for the control > channel and IPv4 for the data channel means that the source address > will almost certainly be different in both cases, making it unlikely > that the data connection can be established successfully." > > propose to add one short sentence in the end of the above paragraph: > "...making it unlikely that the data connection can be established > successfully. There are also other reasons that makes it inappropriate > to use the IPv4 address in the response message even if the client has > IPv4 connectivity, such as: the IPv4 connectivity may can not reach > the server due to configuration or other reasons." > > > "EPSV ALL" indicates that the client will use EPSV for all > transfers, but an ALG may translate EPSV commands to PASV commands, > conflicting with the earlier "EPSV ALL". > > Comments: Requiring client not using "EPSV ALL" at all maybe a not a > good approach considering that there are chances that the server > support EPSV ALL command and the communication between them may not > need an ALG. > > 4. ALG functionality > Propose to add some sentences to clarity that there maybe a chance > that for optimized client and server which comply with this document > using ALG may lead to un-optimized result. Proposed text for this clarification maybe: "It is noted that there may be chances for the client and server which comply with this document's recommendation may avoid using ALG but since there is no ways for these client/server to inform the translator to switch off ALG, it may lead to unoptimized situation that the communications always go through an ALG even if it could be avoided. " > Appendix B. Acknowledgements > > Propose to move the Acknowledgements section in to the main body of > the document and add a "contributors" section that lists all the > contributors of this document. > > > Best regards, > Dapeng Liu > From brian.e.carpenter@gmail.com Thu Dec 31 11:36:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D423A6864 for ; Thu, 31 Dec 2009 11:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.573 X-Spam-Level: ** X-Spam-Status: No, score=2.573 tagged_above=-999 required=5 tests=[AWL=-5.185, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHsyh10DQ8zU for ; Thu, 31 Dec 2009 11:36:21 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 325483A659A for ; Thu, 31 Dec 2009 11:36:21 -0800 (PST) Received: by yxe30 with SMTP id 30so14887808yxe.29 for ; Thu, 31 Dec 2009 11:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=s4RNwllhkO44avc6uzMMj2nXX1kkJi1jnG+qfPWkiCQ=; b=eplahK4rqujSyhT/GnNwXU/jr4CLJAaied1Pqp1ifUvZvN+E5TkLKRF4A9H89QmUUc JDgGUxiQHsELVIgfSKB+lDAnR99yfmCbmlB+uqQTujqpaLneG6RBYqheJPwm7iKc//if tmoh84jAE7HU//SvarzvkyRlkn5tzAxN+8TsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Rz4cdbPf8ANJa/SLWJ5gCGgUTGH4CEnQ9Tykjt8hbgt0eZsoB8Leq7LAHZHpniQ+Bh dF7qRBBgKNJKg16K8HnXKi8CyFe52Cbedr77FhsRaoiPjCj99xU5V2D6xlbgzoAQi93P DFuqSPGaA9h5PKc+fdIPRq+I+qc33N4HdxaX0= Received: by 10.100.243.16 with SMTP id q16mr24043173anh.113.1262288157357; Thu, 31 Dec 2009 11:35:57 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 4sm5146115ywi.27.2009.12.31.11.35.52 (version=SSLv3 cipher=RC4-MD5); Thu, 31 Dec 2009 11:35:56 -0800 (PST) Message-ID: <4B3CFD10.5020905@gmail.com> Date: Fri, 01 Jan 2010 08:35:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Xing Li , Kentaro Ebisawa , "behave@ietf.org" Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 19:36:22 -0000 On 2009-12-31 18:52, Dave Thaler wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Wednesday, December 30, 2009 5:16 PM >> To: Kentaro Ebisawa >> Cc: behave@ietf.org; Xing Li >> Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave- >> v6v4-xlate-05] >> >> I perhaps wasn't clear enough. I agree that a node that contains >> a translator should always decrement the hop count; it's clearly >> a hop. >> >> But consider what happens to the packet after it's been translated. >> Does the node simply send the packet off to its default router, >> like any other IPv6 node? Or does it pass the packet on to >> a routing daemon, > > A routing daemon doesn't handle packets (at least in most routers). > The forwarding place in the kernel does. A routing daemon just > handles routing protocols. > >> with its own routing table and executing at >> least one routing protocol? > > A router need not execute at least one routing protocol. > If a router uses static routes, it's still a router. Yes, OK. I phrased it carelessly. > >> If it's the second case, and we >> don't specify things more carefully, the hop count will get >> decremented twice in one node (once by the translator and >> then a second time by the routing daemon). If we don't want that >> to happen, we need to specify the two cases separately. > > I don't think you need to specify that level of detail. > > -Dave > >> That is what my proposed text does (for the v4 to v6 direction): >> >> If the translator is combined with an IPv6 router, the router MUST >> perform normal Hop Count processing [RFC2460]. Otherwise the >> translator MUST emulate this processing. > > The above text is confusing to me, since "combined" is ambiguous. > If a v4/v6 translator is running on the same box as a regular > IPv6 router, but they're not chained, just running ships in the night, > they're still "combined" in the "same box" sense. Sure, "combined in series" is the case that concerns me. Specifically, I'm concerned if a perfectly OK forwarding engine (which decrements hop count) is combined in series with a perfectly OK translator (which decrements hop count). Brian > > -Dave > >> Brian >> >> On 2009-12-31 09:50, Kentaro Ebisawa wrote: >>> Hi, >>> >>> I also think translator act as both, router and host. >>> My point was we should let implementor decide when to decrement TTL. >>> (before or after the translation) >>> >>> To answer to the Brian's comment : >>> >>>> 2.7. Knowing when to Translate >>>> >>>> If the IP/ICMP translator is implemented in a router providing >> both >>>> translation and normal forwarding,... >>>> >>>> which makes it clear that the tranlsator may or may not be in the >> same >>>> box as a router. >>> One can implement a translator which would NOT forward packet which >> doesn't >>> need translation. Such implementation would not do v6 to v6 nor v4 to >> v4 >>> packet forwarding, but will act as a router for v6v4 or v4v6 packet >> and do >>> v6v4(v4v6) packet forwarding. >>> >>> I think in the sentense above, "translation" implies "translation + >> v6v4(v4v6) forwarding" >>> and "normal forwarding" means "v4v4 or v6v6 forwarding without >> translation". >>> So for both cases, translator act as a router (decrements TTL). >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From dthaler@microsoft.com Thu Dec 31 12:55:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDE03A686E for ; Thu, 31 Dec 2009 12:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4dRZmKHkaTe for ; Thu, 31 Dec 2009 12:55:11 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DC68D3A67B6 for ; Thu, 31 Dec 2009 12:55:11 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 12:54:50 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 31 Dec 2009 12:54:49 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 31 Dec 2009 12:54:49 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Translating ICMPv4 error messages Thread-Index: AcqKW344AulKaUeAQH+W1qCX0CjjLQ== Date: Thu, 31 Dec 2009 20:54:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Translating ICMPv4 error messages X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 20:55:12 -0000 Draft-ietf-behave-v6v4-xlate-05 section 2.4 states: > The translation of the inner IP header can be done by recursively > invoking the function that translated the outer IP headers. The embedded transport-layer header needs to be translated too,=20 if the address translation is not checksum neutral, correct? Currently this section only mentions IP headers. Assuming so, there's one case that deserves special mention:=20 if you get an ICMPv4 error that embeds an ICMPv4 error that=20 embeds an ICMPv4 error that... (etc until MTU is reached),=20 do you have to keep traversing the entire packet and do all=20 the translations? I would hope not, but "recursively invoking" sure sounds like it. -Dave From ajs@shinkuro.com Thu Dec 31 13:38:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8ED83A67E1 for ; Thu, 31 Dec 2009 13:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-1.296, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYuJ0x8VGJkF for ; Thu, 31 Dec 2009 13:38:06 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 367683A67B6 for ; Thu, 31 Dec 2009 13:38:06 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 34C9C2FE8CA1 for ; Thu, 31 Dec 2009 21:37:45 +0000 (UTC) Date: Thu, 31 Dec 2009 16:37:43 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091231213743.GB10622@shinkuro.com> References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> <4B3CFD10.5020905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B3CFD10.5020905@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 21:38:07 -0000 On Fri, Jan 01, 2010 at 08:35:44AM +1300, Brian E Carpenter wrote: > Sure, "combined in series" is the case that concerns me. Specifically, > I'm concerned if a perfectly OK forwarding engine (which decrements > hop count) is combined in series with a perfectly OK translator (which > decrements hop count). Surely this is a scenario that needs to be faced head on? It's almost certainly going to happen. Even just noting, "This can happen. It might be bad," would be useful. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From joelja@bogus.com Thu Dec 31 14:40:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1483A67B5 for ; Thu, 31 Dec 2009 14:40:42 -0800 (PST) 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.409, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt6hPUjphm-N for ; Thu, 31 Dec 2009 14:40:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 46B623A67B2 for ; Thu, 31 Dec 2009 14:40:41 -0800 (PST) Received: from [192.168.11.104] (c-67-189-76-178.hsd1.wa.comcast.net [67.189.76.178]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id nBVMeI2d047883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Dec 2009 22:40:19 GMT (envelope-from joelja@bogus.com) Message-ID: <4B3D284B.3010408@bogus.com> Date: Thu, 31 Dec 2009 14:40:11 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andrew Sullivan References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> <4B3CFD10.5020905@gmail.com> <20091231213743.GB10622@shinkuro.com> In-Reply-To: <20091231213743.GB10622@shinkuro.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 31 Dec 2009 22:40:20 +0000 (UTC) Cc: behave@ietf.org Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 22:40:42 -0000 Considered in the context of what is done in an ipv4 implementation (e.g. linux iptables nat), header rewrite is performed (in iptables) before handing off for forwarding and it's the forwarding stage (ip_forward.c) that is responsible for decrimenting the ttl before dropping it in the output queue. joel Andrew Sullivan wrote: > On Fri, Jan 01, 2010 at 08:35:44AM +1300, Brian E Carpenter wrote: >> Sure, "combined in series" is the case that concerns me. Specifically, >> I'm concerned if a perfectly OK forwarding engine (which decrements >> hop count) is combined in series with a perfectly OK translator (which >> decrements hop count). > > Surely this is a scenario that needs to be faced head on? It's almost > certainly going to happen. Even just noting, "This can happen. It > might be bad," would be useful. > > A > From dthaler@microsoft.com Thu Dec 31 18:45:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6281A3A6889 for ; Thu, 31 Dec 2009 18:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.178 X-Spam-Level: X-Spam-Status: No, score=-5.178 tagged_above=-999 required=5 tests=[AWL=-4.936, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1datotzOHQJj for ; Thu, 31 Dec 2009 18:45:50 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9CEF83A6868 for ; Thu, 31 Dec 2009 18:45:50 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 18:46:07 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 31 Dec 2009 18:45:31 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 31 Dec 2009 18:45:31 -0800 From: Dave Thaler To: Brian E Carpenter Thread-Topic: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] Thread-Index: AQHKiY4vwy5fU7QA0UuKR1ljMwqr0pF+llGAgABKRwD//5GQgIABoboA///xbWA= Date: Fri, 1 Jan 2010 02:45:27 +0000 Message-ID: References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> <4B3CFD10.5020905@gmail.com> In-Reply-To: <4B3CFD10.5020905@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Xing Li , Kentaro Ebisawa , "behave@ietf.org" Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 02:45:51 -0000 QnJpYW4gQ2FycGVudGVyIHdyb3RlOg0KPiA+PiBUaGF0IGlzIHdoYXQgbXkgcHJvcG9zZWQgdGV4 dCBkb2VzIChmb3IgdGhlIHY0IHRvIHY2IGRpcmVjdGlvbik6DQo+ID4+DQo+ID4+ICAgIElmIHRo ZSB0cmFuc2xhdG9yIGlzIGNvbWJpbmVkIHdpdGggYW4gSVB2NiByb3V0ZXIsIHRoZSByb3V0ZXIN Cj4gTVVTVA0KPiA+PiAgICBwZXJmb3JtIG5vcm1hbCBIb3AgQ291bnQgcHJvY2Vzc2luZyBbUkZD MjQ2MF0uIE90aGVyd2lzZSB0aGUNCj4gPj4gICAgdHJhbnNsYXRvciBNVVNUIGVtdWxhdGUgdGhp cyBwcm9jZXNzaW5nLg0KPiA+DQo+ID4gVGhlIGFib3ZlIHRleHQgaXMgY29uZnVzaW5nIHRvIG1l LCBzaW5jZSAiY29tYmluZWQiIGlzIGFtYmlndW91cy4NCj4gPiBJZiBhIHY0L3Y2IHRyYW5zbGF0 b3IgaXMgcnVubmluZyBvbiB0aGUgc2FtZSBib3ggYXMgYSByZWd1bGFyDQo+ID4gSVB2NiByb3V0 ZXIsIGJ1dCB0aGV5J3JlIG5vdCBjaGFpbmVkLCBqdXN0IHJ1bm5pbmcgc2hpcHMgaW4gdGhlDQo+ IG5pZ2h0LA0KPiA+IHRoZXkncmUgc3RpbGwgImNvbWJpbmVkIiBpbiB0aGUgInNhbWUgYm94IiBz ZW5zZS4NCj4gDQo+IFN1cmUsICJjb21iaW5lZCBpbiBzZXJpZXMiIGlzIHRoZSBjYXNlIHRoYXQg Y29uY2VybnMgbWUuIFNwZWNpZmljYWxseSwNCj4gSSdtIGNvbmNlcm5lZCBpZiBhIHBlcmZlY3Rs eSBPSyBmb3J3YXJkaW5nIGVuZ2luZSAod2hpY2ggZGVjcmVtZW50cw0KPiBob3AgY291bnQpIGlz IGNvbWJpbmVkIGluIHNlcmllcyB3aXRoIGEgcGVyZmVjdGx5IE9LIHRyYW5zbGF0b3IgKHdoaWNo DQo+IGRlY3JlbWVudHMgaG9wIGNvdW50KS4NCg0KSSBndWVzcyBpdCBkb2Vzbid0IHBhcnRpY3Vs YXJseSBjb25jZXJuIG1lLiAgSXQgc2VlbXMgdG8gYmUgYW4gaW50ZXJuYWwgDQppbXBsZW1lbnRh dGlvbiBkZXRhaWwuICBJZiBzb21lb25lIHJlYWxseSBjaG9vc2VzIHRvIGltcGxlbWVudCBhIA0K c2luZ2xlIHBoeXNpY2FsIGJveCB0aGF0IGFwcGVhcnMgYXMgdHdvIHNlcGFyYXRlIHZpcnR1YWwg aG9wcywNCm9uZSBiZWhpbmQgdGhlIG90aGVyLCBpdCBzaG91bGRu4oCZdCBicmVhayBhbnl0aGlu Zy4NCg0KLURhdmUNCg== From huitema@microsoft.com Thu Dec 31 19:22:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C973A68E7 for ; Thu, 31 Dec 2009 19:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.34 X-Spam-Level: X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=-5.098, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xse-j5JOCQL6 for ; Thu, 31 Dec 2009 19:22:37 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9525A3A68F1 for ; Thu, 31 Dec 2009 19:22:37 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 19:22:54 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 31 Dec 2009 19:22:14 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 31 Dec 2009 19:22:16 -0800 From: Christian Huitema To: Brian E Carpenter , Dave Thaler Thread-Topic: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] Thread-Index: AQHKid2NPun5MJYjLUWc7fM+h/7h+pGAE0QA///7wJA= Date: Fri, 1 Jan 2010 03:22:07 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA21207AB8@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4B3BB4DD.3060802@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB091844C7@xmb-sjc-236.amer.cisco.com> <20091231053442.303D.B01659E3@sablenetworks.net> <4B3BFB4A.7010801@gmail.com> <4B3CFD10.5020905@gmail.com> In-Reply-To: <4B3CFD10.5020905@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , Kentaro Ebisawa , Xing Li Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-xlate-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 03:22:38 -0000 What about acknowledging that a translator is a third type of nodes, beside= s hosts and routers? A Chimera of sorts, which should be recognized as such= in the Internet architecture? -- Christian Huitema From dthaler@microsoft.com Thu Dec 31 19:39:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F93C3A6860 for ; Thu, 31 Dec 2009 19:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=-4.760, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbHKw4OZSzqS for ; Thu, 31 Dec 2009 19:39:36 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 933113A67B1 for ; Thu, 31 Dec 2009 19:39:36 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 19:39:53 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 31 Dec 2009 19:39:15 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 31 Dec 2009 19:39:17 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-v6v4-xlate-05 Thread-Index: AcqKkjtYH5P3zGbwR0u2EVJAarvt+g== Date: Fri, 1 Jan 2010 03:39:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 03:39:37 -0000 My comments and suggested wording changes on this document are marked up in= the PDF at http://research.microsoft.com/~dthaler/draft-ietf-behave-v6v4-xlate-05.pdf To summarize the main technical comments (see the PDF for full editorial et= c comments): 1) What MUST/SHOULD a translator do if the derivation fails for a source ad= dress?=20 (e.g. if you would get an illegal address from it) Drop it? Forward it a= nyway? The security considerations section hints that one should do something, = but nowhere does it say what. 2) The question I posted to the list earlier today about handling of=20 nested ICMP error messages. 3) Sections 3.2 and 3.3 contradict section 3.1. Section 3.1 already explai= ns how to deal with packets coming from IPv6 addresses that aren't IPv4-tra= nslatable, by saying you do stateful. 3.2 and 3.3 then refer to some "special bloc= k" which isn't explained. The "special block" text should be removed. 4) The appendix (which should be moved into the body of the doc), is ambigu= ous and needs more information. What does "-" mean? That no parameter prob= lem message is sent? When multiple values appear on the right, how do you choose which one to use? -Dave From dthaler@microsoft.com Thu Dec 31 19:44:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807AE3A691D for ; Thu, 31 Dec 2009 19:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[AWL=-4.596, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+ppkmEq++gq for ; Thu, 31 Dec 2009 19:44:29 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A708A3A6918 for ; Thu, 31 Dec 2009 19:44:29 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 19:44:09 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 31 Dec 2009 19:44:09 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 31 Dec 2009 19:44:09 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-address-format-03 Thread-Index: AcqKjxl+kpUSr0drSY+kd8XFi4dlpA== Date: Fri, 1 Jan 2010 03:44:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-ietf-behave-address-format-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 03:44:30 -0000 My comments and suggested wording changes on this document are marked up in= the PDF at http://research.microsoft.com/~dthaler/draft-ietf-behave-address-format-03.= pdf To summarize the main comments: 1) Someplace needs to discuss how a node gets an IPv4-translatable address.= =20 It seems they cannot be used with SLAAC on a regular interface. Are they usable only with DHCPv6 or manual configurable? Assuming so,=20 someplace needs to say so. 2) Section 3.3 is really hard to follow without a diagram. 3) The last row in figure 1 is still wrong. 4) Sections 3.1 and 3.2 appear to contradict each other regarding whether the WKP can appear in interdomain routing tables. 5) The argument that WKP MUST NOT contain non-global IPv4 addresses because "Doing so would introduce ambiguous IPv6 addresses" doesn't hold in the "an IPv6 network to an IPv4 network" scenario. The doc needs to either motivate it, change the restriction, or just=20 remove the incorrect motivation leave the restriction without=20 explanation. -Dave From dthaler@microsoft.com Thu Dec 31 19:44:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D44F3A690E for ; Thu, 31 Dec 2009 19:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.685 X-Spam-Level: X-Spam-Status: No, score=-4.685 tagged_above=-999 required=5 tests=[AWL=-4.443, BAYES_00=-2.599, FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFk+Qge8ZNFk for ; Thu, 31 Dec 2009 19:44:36 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7AEC53A692B for ; Thu, 31 Dec 2009 19:44:36 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 31 Dec 2009 19:44:53 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 31 Dec 2009 19:44:15 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 31 Dec 2009 19:44:17 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-v6v4-framework-04 Thread-Index: AcqKkKMUihdCH1KsQq2I+Lejr9Cmjw== Date: Fri, 1 Jan 2010 03:44:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {40D84DB1-95A0-4E6E-AE18-313D00E57184} x-cr-hashedpuzzle: Ba3v Bx1n Dkw4 Dv84 D8/h EPjC EQB2 Fk2x FrA5 GaFp I/eV Jkgl JlQ8 JxGo KBZj KFIi; 1; YgBlAGgAYQB2AGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {40D84DB1-95A0-4E6E-AE18-313D00E57184}; ZAB0AGgAYQBsAGUAcgBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Fri, 01 Jan 2010 03:44:11 GMT; QwBvAG0AbQBlAG4AdABzACAAbwBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGIAZQBoAGEAdgBlAC0AdgA2AHYANAAtAGYAcgBhAG0AZQB3AG8AcgBrAC0AMAA0AA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-framework-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 03:44:37 -0000 The biggest comment is that the Security Considerations section needs to be replaced with something that includes real information. For=20 example, the discussion in RFC 2766 section 9, RFC 4966 section 6, and=20 RFC 4924 section 3 seems relevant and should be referenced or incorporated. See http://research.microsoft.com/~dthaler/draft-ietf-behave-v6v4-framework-04.= pdf for all comments and suggested wording changes. -Dave